Guide: the 93 Annex A controls and where the kit covers each

A reading aid that lists every Annex A control number of ISO/IEC 27001:2022 with a short theme in plain words and the kit documents that implement it, for use when building the Statement of Applicability and the control tracker.

Serves: ISO/IEC 27001:2022 Annex A; ISO/IEC 27001:2022 clause 6.1.3. Owner: Information Security Manager.

1. How to use this guide

Annex A of ISO/IEC 27001:2022 lists 93 reference controls in four groups: organisational (5.1 to 5.37), people (6.1 to 6.8), physical (7.1 to 7.14) and technological (8.1 to 8.34). The standard requires you to compare the controls you chose from your risk treatment with this list, confirm that nothing necessary was missed, and record in a Statement of Applicability which controls apply, why, and whether they are implemented.

The tables below give each control number a theme written in this kit's own words. The themes are a memory aid, not the standard's titles; when you need the authoritative text, read the standard itself. The third column names the kit documents that implement the control. Where several documents are listed, the first is the primary one and the others supply records or related rules.

Use the tables in three places:

1. ISMS-REG-01 Statement of Applicability. The control numbers and themes are prefilled there. For each row decide Applicable Yes or No, write a justification in one or two sentences, set the implementation status, and copy the kit IDs you actually use into the implementing documents column.
2. ISMS-REG-02 Control implementation tracker. The same 93 rows carry the owner, the evidence, the test method and the last test result for each applicable control. ISMS-PRO-04 explains how controls are tested.
3. Gap analysis in step 3 of PB-02. Walk the tables with the people who run each area and mark what exists, what exists informally and what does not exist.

Three rules save time at audit. First, a control marked Not applicable needs a justification that an auditor can accept: either no risk in GOV-REG-05 needs it and no requirement in ISMS-REG-03 demands it, or the activity it governs does not happen at all in the scope (for example in-house development where no software is developed). "We use the cloud" is not by itself a justification for excluding the physical controls; it moves most of them to the provider and leaves offices, home working and devices with you. Second, every applicable control needs an owner and evidence that it operates, not only a document. Third, the justification should name the risk or requirement it satisfies, so that when the risk changes the Statement of Applicability can be re-checked.

The 2022 edition also attaches attributes to each control (control type, security property, cybersecurity concept, operational capability, security domain). The kit does not reproduce them. If you want to filter controls by, for example, detective versus preventive, add an attribute column to ISMS-REG-01 and populate it from your own copy of the standard.

2. Organisational controls (5.1 to 5.37)

3. People controls (6.1 to 6.8)

4. Physical controls (7.1 to 7.14)

5. Technological controls (8.1 to 8.34)

6. Controls that most often need attention

Experience of first certifications points to the same handful of controls where a document exists but the evidence does not. Check these first:

• 5.9 and 7.10. The asset inventory is often a spreadsheet nobody reconciles. GOV-PRO-16 sets a quarterly reconciliation; keep the dated export.
• 5.18. Access reviews are promised quarterly and performed once. GOV-REG-12 should show four dated entries per system per year, each with the account list that was reviewed.
• 5.22. Supplier reviews stop after onboarding. GOV-REG-07 needs a review date within twelve months for every Tier 1 supplier.
• 6.3. Training records show attendance but not currency. GOV-REG-09 should let you compute, for any date, who is overdue.
• 8.8. Severity windows are written but not measured. GOV-REG-14 should produce the closure measure in ISMS-PRO-04 without manual work.
• 8.13. Backups run; restores are never tested. GOV-REG-15 needs a test per critical system per quarter with the time taken.
• 8.15 and 8.16. Logs exist; nobody looks at them. GOV-PRO-14 defines a review cadence; keep the review notes and the alert tickets.
• 8.32. Emergency changes bypass the record. GOV-REG-11 should hold every production change, including the emergency ones with their retrospective approval.

7. Where the kit leaves decisions to you

The kit cannot decide applicability for you. Controls 7.1 to 7.14 depend on whether you have offices, server rooms or only laptops and a provider; GOV-PRO-17 explains what remains for a cloud only organisation. Controls 8.4, 8.25 to 8.31 and 8.33 apply only where software is developed or materially configured in house. Control 8.30 applies only where development is outsourced. Control 5.23 applies to almost everyone. Record every decision, and its reason, in ISMS-REG-01.

8. Related documents

• ISMS-REG-01 Statement of Applicability
• ISMS-REG-02 Control implementation tracker
• GOV-PRO-05 Risk assessment and treatment methodology
• ISMS-PRO-04 Monitoring, measurement, analysis and evaluation procedure
• ISMS-GDE-02 Guide to mandatory documented information and records
• GOV-REG-27 Framework crosswalk

Guide: mandatory documented information and records for ISO/IEC 27001:2022

Lists the documents and records that ISO/IEC 27001:2022 explicitly requires, the kit item that satisfies each, and the further documents that are not required by name but that auditors expect and that make the system run.

Serves: ISO/IEC 27001:2022 clause 4.3; ISO/IEC 27001:2022 clause 5.2; ISO/IEC 27001:2022 clause 6.1.2; ISO/IEC 27001:2022 clause 6.1.3; ISO/IEC 27001:2022 clause 6.2; ISO/IEC 27001:2022 clause 7.2; ISO/IEC 27001:2022 clause 7.5; ISO/IEC 27001:2022 clause 8.1; ISO/IEC 27001:2022 clause 8.2; ISO/IEC 27001:2022 clause 8.3; ISO/IEC 27001:2022 clause 9.1; ISO/IEC 27001:2022 clause 9.2; ISO/IEC 27001:2022 clause 9.3; ISO/IEC 27001:2022 clause 10.2. Owner: Information Security Manager.

1. Two kinds of documented information

The standard uses one term, documented information, for two things that behave differently. Documents say what you intend to do: the scope, the policy, the risk method, the objectives. They are approved, versioned and reviewed. Records show what you did: an audit report, a risk assessment result, a management review minute, a training record. They are created by running a process and are not edited afterwards. GOV-PRO-01 controls both.

The standard names a short list of items that must exist. Everything else is at your discretion, with one condition: you must keep whatever documented information you yourself decide is needed for the management system to work. In practice, an auditor who finds a process running well without a procedure will accept it; an auditor who finds a process running inconsistently will ask for the procedure that should have prevented it. The discretionary table in section 4 lists what experience says is worth having.

2. Documents the standard requires by name

3. Records the standard requires by name

Annex A adds its own documentation expectations where a control is applicable, for example topic specific policies (5.1), rules for acceptable use (5.10), supplier agreements (5.20), incident records (5.26 and 5.28), legal requirements (5.31), operating procedures (5.37), confidentiality agreements (6.6), logs (8.15), change records (8.32) and secure development rules (8.25 to 8.28). ISMS-GDE-01 maps each of these to the kit document that provides it.

4. Discretionary documents and why they earn their place

5. What auditors look for in each item

• A control block on every document (identifier, owner, approver, version, dates) and a revision history that matches GOV-REG-01.
• Approval evidence for the policy, the scope and the risk method: a signature, an approval record or a minute.
• Dates that make sense. The risk assessment precedes the Statement of Applicability, which precedes the treatment plan; the internal audit and the management review both precede the stage 2 audit.
• Records that are not editable after the fact, or that carry a change history if they are.
• Consistency. The scope in ISMS-STM-01, the asset list in GOV-REG-10, the systems in GOV-REG-24 and the risks in GOV-REG-05 describe the same organisation. A system that appears in one and not the others is the first question an auditor asks.
• Currency. Every document within its review date; every register with entries from the current period.

6. Building your master list

Create GOV-REG-01 before anything else and add every item in sections 2 to 4 as a row with status Draft. As each document is approved, change the status and record the version and location. The master list is then both your project plan and your proof of clause 7.5. ISMS-REG-05 holds the implementation tasks that produce each item; PB-02 gives the order.

7. Related documents

• GOV-PRO-01 Document control procedure
• GOV-REG-01 Master list of documents and records
• ISMS-GDE-01 Guide to the 93 Annex A controls
• ISMS-GDE-03 Guide to the certification journey
• ISMS-REG-05 Implementation project plan
• GOV-CHK-03 Pre-audit readiness checklist

Guide: the certification journey from decision to recertification

Walks through every stage of an ISO/IEC 27001 certification, from the business case to the three year recertification, with what each stage demands, the findings that most often derail it, and how to choose a certification body.

Serves: ISO/IEC 27001:2022 clause 4.3; ISO/IEC 27001:2022 clause 6.1.3; ISO/IEC 27001:2022 clause 9.2; ISO/IEC 27001:2022 clause 9.3; ISO/IEC 27001:2022 clause 10.2. Owner: Information Security Manager.

1. What certification is and is not

Certification is an independent, accredited body's confirmation that your management system conforms to ISO/IEC 27001:2022 and is operating. It is not a statement that you are secure, that no incident will happen, or that every control works perfectly. It says that you have a system that identifies risk, treats it, checks itself and improves. A certificate lasts three years, with surveillance audits in between, and the scope wording on it is the only thing a customer can rely on.

The journey below assumes you are implementing with this kit. PB-02 gives the twelve implementation steps; this guide covers what happens around them and after them.

2. Stage by stage

2.1 Decision and business case

Someone has to decide that certification is worth the cost, and that decision has to be made by the people who will fund it. Write the case in one page: which customers or markets require it, what it costs (certification body fees, internal time, tooling, possibly external support), what it saves (shorter security questionnaires, fewer bespoke audits, lower insurance friction), and the earliest realistic date. Get the Chief Executive Officer to sign GOV-STM-01 at this point, not at the end. A certificate pursued without that signature stalls at the first budget conversation.

2.2 Scope

Decide what the certificate will cover. A narrow scope (one product, one location) is quicker to certify and harder to sell; a wide scope is the reverse. The wording goes into ISMS-STM-01 and later onto the certificate. Two tests: would a customer reading the certificate conclude that the service they buy is covered, and can you honestly include every system that touches that service? Scopes that exclude the support team, the identity provider or the build pipeline do not survive a careful customer or a careful auditor.

2.3 Gap analysis

Compare what exists with clauses 4 to 10 and with the Annex A tables in ISMS-GDE-01. Record three states: exists and evidenced, exists informally, does not exist. GOV-REG-28 is built for this. The output is the task list in ISMS-REG-05 with owners and weeks. Resist the urge to write policies before the gap analysis is finished; the gap analysis tells you which policies you actually need.

2.4 Risk assessment

Run GOV-PRO-05 across the scope. The method must be written before the first assessment, and the first assessment must be complete before the Statement of Applicability. Auditors read risk registers closely: they expect risks that reflect your business (your data, your providers, your people), not a generic list, and they expect the treatment column to point to real controls and real tasks.

2.5 Statement of Applicability

Complete ISMS-REG-01. Every one of the 93 controls gets a decision and a reason. The Statement of Applicability is the document most referenced during stage 2, because the auditor uses it as the sampling frame. Its version number appears in your scope wording and in the audit report; change control it strictly.

2.6 Implementation

Work through ISMS-REG-05. Policies and procedures are approved under GOV-PRO-01, controls are implemented and evidenced in ISMS-REG-02, registers start to fill. The common mistake is to treat this as a writing exercise. A procedure that has never been followed is worth nothing at audit; a control that has been operating for three months with records is worth everything.

2.7 Operating evidence

Certification bodies expect to see the management system operating, not only designed. Plan for at least three months of operation before stage 2, during which the following have all happened at least once: an access review, a vulnerability cycle with closures, a change through change management, a backup restore test, an incident or an incident exercise, awareness training with records, a supplier review, a risk review, a quarterly performance report under ISMS-PRO-04, and a steering committee meeting with minutes. Some bodies accept less for a very small organisation; none accept zero.

2.8 Internal audit

Clause 9.2 requires an internal audit covering the whole system before certification. Use GOV-PRO-02 and the checklist ISMS-REG-04. The auditor must be independent of the areas audited; in a small organisation that usually means an external person or a trained colleague from an unrelated function. The audit must produce findings. An internal audit report with no findings is itself a finding, because no first implementation is clean. Record the corrective actions in GOV-REG-03 and close or at least plan every one before stage 2.

2.9 Management review

Clause 9.3 requires a management review with the inputs listed in GOV-PRO-03, minuted with GOV-TPL-03. It must happen after the internal audit and before stage 2, because audit results are a mandatory input. Keep it real: a review in which leadership only receives information, and decides nothing, reads as a formality. Decisions about resources, objectives and improvements are what the auditor looks for in the minutes.

2.10 Stage 1 audit

The certification body's auditor reviews your documented information and your readiness, usually over one or two days and often remotely. They check the scope, the policy, the risk method and results, the Statement of Applicability, the audit and review evidence, and whether the system has operated long enough. Stage 1 produces a list of concerns, any of which could become a nonconformity at stage 2 if not addressed. Run GOV-CHK-03 four weeks before stage 1 and fix what it shows.

2.11 Stage 2 audit

The auditor tests whether the system operates as documented. Expect interviews with the Chief Executive Officer, the Information Security Manager, system owners, developers, support staff and people in the business who have no security role, sampling of records from every register, inspection of configurations, and a walk through of offices or a review of the provider's assurance where you have none. Findings are graded, usually as major nonconformity (a requirement is missing or systematically not met), minor nonconformity (an isolated lapse), observation, and opportunity for improvement. A major blocks the certificate until closed and verified; minors need an accepted corrective action plan. The certificate is issued after the body's independent review of the audit report, typically four to eight weeks after stage 2.

2.12 Surveillance

In each of the two years after certification the body audits a sample of the system, always including the clauses on leadership, risk, internal audit, management review and corrective action, plus a rotation through Annex A so that every applicable control is seen within the three year cycle. The evidence they want is continuity: the registers kept filling, the audits and reviews happened on schedule, actions closed, changes were controlled. Surveillance is where organisations that treated certification as a project rather than an operating system lose their certificate.

2.13 Recertification

Before the certificate expires the body performs a full audit comparable to stage 2, reviews the three years of performance, and issues a new certificate for a further three years. Scope changes, mergers and major incidents in the cycle are examined closely. Start preparing six months ahead; use the same readiness checklist.

3. Typical findings and how to avoid them

4. Choosing a certification body

• Accreditation. Use a body accredited by the national accreditation body for ISO/IEC 27001 certification. An unaccredited certificate is not recognised by informed customers and some tenders reject it outright.
• Sector and size fit. Ask which clients of your size and sector they certify. A body used to large enterprises may bring expectations and day rates that do not fit a forty person company.
• Auditor continuity and competence. Ask whether the same lead auditor will perform stage 1, stage 2 and surveillance where possible, and what the auditor's background is in your technology. Technical scopes need auditors who can read a cloud configuration.
• Audit days and cost. The number of audit days is calculated from headcount and complexity by the accreditation rules, so quotes should be similar; large differences deserve a question. Ask for the full three year cost, including surveillance and travel.
• Scheduling. Lead times of two to four months for stage 1 are normal. Book when your internal audit is scheduled, not when it is finished.
• Language and location. Confirm that audits can be conducted in the languages your staff work in, and remotely where your scope allows.
• Report quality. Ask for a sample report. A report with specific, evidence based findings is worth more to you than a tick list.
• Integrated audits. If you plan ISO/IEC 27701 or other standards, a body that can audit them together saves days every year.

5. Keeping the certificate

After certification, the management system is a calendar. The recurring events that surveillance auditors check are: quarterly access reviews, quarterly performance reports, at least annual risk review, at least annual internal audit covering the programme in ISMS-PLN-03, at least annual management review, annual awareness refresher, annual supplier reviews, annual policy reviews, and corrective actions closed with effectiveness verified. Put every one in a shared calendar with an owner, and let GOV-REG-21 show whether each happened. A system that runs on the calendar passes surveillance without a project.

6. Related documents

• PB-02 Playbook: ISO/IEC 27001:2022 implementation in twelve steps
• ISMS-GDE-01 Guide to the 93 Annex A controls
• ISMS-GDE-02 Guide to mandatory documented information and records
• ISMS-REG-05 Implementation project plan
• GOV-CHK-03 Pre-audit readiness checklist
• GOV-PRO-02 Internal audit procedure
• GOV-PRO-03 Management review procedure
• GOV-PRO-04 Nonconformity and corrective action procedure
• GOV-STM-01 Top management commitment statement

Information security objectives and plan

The rules for setting measurable information security objectives, the objectives for the current period with their measures, owners and actions, and how progress is measured and reported.

Serves: ISO/IEC 27001:2022 clause 6.2; ISO/IEC 27001:2022 clause 5.2; ISO/IEC 27001:2022 clause 9.1; SOC 2 CC3.1. Owner: Information Security Manager.

1. Purpose

This plan turns the commitments in GOV-POL-03 into a small number of measurable objectives for the period, each with an owner, actions, resources and a date, so that leadership can see whether the management system is improving the outcomes it exists for.

2. Scope

The plan covers the whole scope in ISMS-STM-01. It is set for one financial year and tracked in GOV-REG-21.

3. Rules for setting objectives

3.1 Each objective is consistent with GOV-POL-03 and traceable to at least one of: a risk in GOV-REG-05, a requirement in ISMS-REG-03, a legal or contractual obligation in GOV-REG-04, or a result reported under ISMS-PRO-04.

3.2 Each objective is measurable. Before it is approved, the measure, the formula, the target, the frequency and the data source are written against it. An objective that cannot be measured is rewritten until it can be.

3.3 Each objective has an owner role, a list of actions, the resources needed, and a completion date within the period.

3.4 The steering committee approves the objectives in the month after the management review, and the Information Security Manager records them in GOV-REG-21 and communicates them under ISMS-PLN-02 to the roles that contribute to them.

3.5 Progress is reviewed quarterly by the steering committee. Each objective carries a status of Green (on target), Amber (behind but recoverable within the period) or Red (target will be missed without intervention). An objective that is Red at two consecutive reviews is raised as a nonconformity under GOV-PRO-04.

3.6 An objective may be changed during the period only by the steering committee, with the reason recorded in GOV-REG-22.

3.7 The plan holds between six and ten objectives. More than ten dilutes attention; fewer than six usually means a risk area has been left without a target.

4. Objectives for [Year]

The objectives below are examples of the form a complete objective takes. Replace them with [Organisation]'s own, keeping the same structure.

5. Actions and resources

6. Measurement and reporting

6.1 Owners extract the measure for each objective from the named register by the fifth working day after each period, using the formula written in GOV-REG-21.

6.2 The Information Security Manager compiles the values into the quarterly performance report produced under ISMS-PRO-04, assigns the Green, Amber or Red status, and adds one sentence of commentary and one sentence on the next action for every objective not Green.

6.3 The steering committee reviews the report each quarter. The year end values and the status of every objective are an input to the management review under GOV-PRO-03, which decides the objectives for the next period.

7. Records and evidence

• GOV-REG-21 Security objectives and measures tracker: the approved objectives, the latest values and the status history.
• Quarterly performance reports under ISMS-PRO-04.
• Steering committee minutes approving the objectives and recording quarterly reviews.
• GOV-REG-22 entries where objectives were changed or carried over.

8. Review and maintenance

The Information Security Manager reviews this plan annually after the management review, and within thirty days of a change to GOV-POL-03, a change of scope, or a severity 1 incident that shows an objective was missing.

9. Related documents

• GOV-POL-03 Information security policy
• GOV-REG-21 Security objectives and measures tracker
• ISMS-PRO-04 Monitoring, measurement, analysis and evaluation procedure
• ISMS-PLN-02 Communication plan
• GOV-PRO-03 Management review procedure
• GOV-PRO-04 Nonconformity and corrective action procedure
• GOV-REG-05 Information security risk register
• ISMS-REG-03 Interested parties and requirements register

Communication plan

Who communicates what about information security and privacy, to whom, when and through which channel, inside and outside [Organisation], and how those communications are approved and recorded.

Serves: ISO/IEC 27001:2022 clause 7.4; ISO/IEC 27701 clause 6.4.4; SOC 2 CC2.2; SOC 2 CC2.3. Owner: Information Security Manager.

1. Purpose

This plan fixes the routine communications that keep the management system working: staff hear about the rules and the results, leadership hears about performance and risk, and customers, regulators, suppliers and auditors hear what they are entitled to hear, on time and from an authorised voice.

2. Scope

It covers planned communications about the management system inside the scope of ISMS-STM-01 and to the interested parties in ISMS-REG-03. Communications during an incident or a personal data breach follow GOV-PRO-07 and PIMS-PRO-04; section 6 explains how this plan hands over to them.

3. Principles

3.1 Every communication in the tables below has one named sending role. Nobody else sends it, and a deputy is named for each when the role holder is absent.

3.2 External statements about [Organisation]'s security or privacy posture, including answers to customer questionnaires, are approved by the Information Security Manager before they leave, and by the Chief Executive Officer when they commit [Organisation] to a new obligation.

3.3 No communication claims a certification, an audit result or a level of compliance that a current certificate or report does not support. Safe wording is "operates an information security management system aligned with" until a certificate exists, and "certified to" with the scope wording from ISMS-STM-01 afterwards.

3.4 Communications about individuals (disciplinary matters, personal data breaches affecting named people) go only to the roles with a need to know.

3.5 A record is kept of what was sent, when, to whom and by whom. For internal broadcast items the record is the message in the channel; for external items it is a copy filed with the customer, supplier or regulator record.

4. Internal communications

5. External communications

6. Incident and breach communications

6.1 When an incident is declared under GOV-PRO-07, the Incident Lead owns all communications about it until closure. The tables above do not apply to incident updates; the incident procedure's roles, approval rules and templates (GOV-TPL-05, GOV-TPL-11) do.

6.2 Any external statement about an incident, including to customers, media or on a public status page, is approved by the Chief Executive Officer. Statements describe confirmed facts, the actions taken and the next update time; they do not speculate on cause or attribution.

6.3 Where an incident involves personal data, the Privacy Officer runs the breach assessment and notifications under PIMS-PRO-04 in parallel, and the two leads agree a single message to any party that both must inform.

7. Approval and records

7.1 The steering committee approves this plan and any change to it.

7.2 The Information Security Manager keeps a communications log for external items: date, recipient, subject, approver and file location. Internal broadcast items are evidenced by the message itself in the channel.

7.3 Contact details for every external party in section 5 are checked once a year and after any change of counterpart, and the check is recorded in ISMS-REG-03.

8. Review and maintenance

The Information Security Manager reviews this plan annually, after any incident where a communication was late or sent by the wrong role, and within thirty days of a change to ISMS-REG-03 that adds or removes an external party.

9. Related documents

• ISMS-REG-03 Interested parties and requirements register
• GOV-PRO-07 Information security incident management procedure
• PIMS-PRO-04 Personal data breach assessment and notification procedure
• GOV-PRO-08 Security and privacy awareness and training procedure
• GOV-PRO-06 Supplier and third party security procedure
• GOV-PRO-27 Threat intelligence and vulnerability disclosure handling procedure
• GOV-PRO-25 Legal, regulatory and contractual compliance procedure
• GOV-REG-23 Policy acknowledgement register
• ISMS-PLN-01 Information security objectives and plan

Annual internal audit plan

The schedule of internal audits for one year of the audit cycle, giving for each audit the scope area, the clauses and controls covered, the auditor, the auditee, the timing and the method, together with the coverage rule that proves every clause and every applicable control is audited within the cycle and the statement of auditor independence.

Serves: ISO/IEC 27001:2022 clause 9.2.1; ISO/IEC 27001:2022 clause 9.2.2; ISO/IEC 27001:2022 Annex A 5.35; SOC 2 CC4.1. Owner: Information Security Manager.

1. Purpose

This plan turns the audit programme in GOV-PRO-02 into a dated schedule for year [Number] of the [Number]-year cycle. It tells auditees when to expect an audit and what will be examined, tells auditors what they are responsible for, and gives the Chief Executive Officer and the external auditor a single page that shows the whole management system is independently checked.

2. Scope and criteria

The plan covers the management system described in ISMS-STM-01. The criteria for every audit are the clause 4 to 10 requirements of ISO/IEC 27001:2022, the Annex A controls declared applicable in ISMS-REG-01, the SOC 2 criteria tagged to those controls in GOV-REG-27 where a SOC 2 report is in scope, and the policies, procedures and registers of [Organisation] as listed in GOV-REG-01. Where ISO/IEC 27701 has been adopted, the privacy extensions audited in each area are those tagged in the Statement of Applicability.

3. The cycle and this year's position

The audit cycle is [Number] years, matching the certification cycle. Year 1 of the cycle, and the year before a first certification audit, covers every clause and every applicable control. In later years the clause 4 to 10 requirements are audited every year, controls that meet any of the annual triggers in section 4 are audited every year, and the remaining controls are spread across the cycle so that none goes unaudited for more than [Number] years.

This plan is for year [Number]. The programme in section 6 is written for a year in which everything is covered; when a later year rotates controls, the rows are kept and the clauses and controls column is reduced, with the reconciliation in section 4 proving that nothing falls out of the cycle.

4. Coverage rule

4.1 Every clause 4 to 10 requirement is audited every year. Audits IA-01 and IA-10 carry this coverage between them.

4.2 Every control marked Applicable in ISMS-REG-01 is audited at least once within the cycle, and every control that meets one of the following triggers is audited every year: it treats a risk rated High or Critical in GOV-REG-05; a major nonconformity against it is open or was closed within the last twelve months; an incident in GOV-REG-08 involved it within the last twelve months; or the system or process it protects changed significantly during the year.

4.3 At the end of each year the Information Security Manager reconciles the Criteria column of every audit marked Reported or Closed in GOV-REG-02 against the applicable controls in ISMS-REG-01 and against clauses 4.1 to 10.2. Any item not covered is scheduled in the first quarter of the next year's plan. No clause and no applicable control may remain unaudited when the cycle ends.

4.4 A control added to ISMS-REG-01 during the year, or changed from Not applicable to Applicable, is added to the next audit whose scope area fits, and in any case audited within twelve months of the change.

4.5 Coverage is recorded in GOV-REG-02, not in this plan. This plan states the intention; the register proves the outcome.

5. Independence statement

5.1 No auditor audits work they performed, managed or designed, or an area where they hold a control owner role in ISMS-REG-02. The Internal Auditor does not report to the Information Security Manager for the purpose of audit work and is not directed by the auditee on what to examine.

5.2 The Information Security Manager owns the management system and therefore does not audit any clause 4 to 10 requirement, nor any control whose owner column in ISMS-REG-02 names that role.

5.3 The Internal Auditor performs or witnesses control tests under ISMS-PRO-04 during the year. Audit IA-10, which examines performance evaluation and improvement, is therefore assigned to a second auditor: a trained person from a department outside the security function, or an external auditor engaged for the purpose.

5.4 Where no independent internal person is available for an area, the Information Security Manager engages an external auditor before the audit's planned quarter and records the arrangement in GOV-REG-02.

5.5 Independence is confirmed in writing for each audit in the Notes column of GOV-REG-02 before fieldwork begins, naming the auditor role and the reason the auditor is independent of the area.

6. Programme by quarter

Each audit is identified as IA-[Year]-[Number]. Timing is given in weeks of the quarter so that the plan can be re-dated each year without rewriting; the agreed dates are entered in GOV-REG-02 when the audit plan is issued. Method follows GOV-PRO-02 step 4.6: document review, interview, observation and sampling of records chosen by the auditor from the full population.

Quarter 1

Quarter 2

Quarter 3

Quarter 4

Coverage check for this plan

7. Timetable for each audit

8. Resources

The programme needs about [Number] auditor days for the year: two days of preparation and fieldwork and one day of reporting for each audit, plus [Number] days for follow-up. Auditees should expect to give two to four hours per audit for interviews and evidence. The Internal Auditor must meet the competence requirements in GOV-PRO-02 step 4.3 before leading an audit; where the second auditor for IA-10 is external, the engagement is approved by the Chief Executive Officer in the first quarter so that availability is secured.

9. Changes to the plan

An audit may be moved within its quarter by agreement between the auditor and the auditee, recorded in GOV-REG-02. Moving an audit to a later quarter needs the written approval of the Chief Executive Officer under GOV-PRO-02 section 6, and no audit may be moved out of the year. A new system, supplier, site or incident of severity 1 or 2 during the year triggers a review of whether an additional audit is needed; the Information Security Manager proposes it to the steering committee within one month of the trigger.

10. Records and evidence

• GOV-REG-02 Audit programme and findings: one row per audit in this plan, with dates, independence note, status and finding counts.
• The audit plan issued for each audit and the completed ISMS-REG-04 checklist.
• Audit reports on GOV-TPL-01 and the corrective actions in GOV-REG-03.
• The year-end coverage reconciliation described in section 4.3, filed with the plan for the following year.

11. Review and maintenance

The Information Security Manager drafts the plan for the following year in the last quarter, using the coverage reconciliation, the risk register, the incident register and the findings of the current year to set which controls need annual attention. The Chief Executive Officer approves it before the year begins. The plan is also reviewed when the scope changes, when a framework is added or withdrawn, and after any external audit finding about internal audit.

12. Related documents

• GOV-PRO-02 Internal audit procedure
• GOV-REG-02 Audit programme and findings
• ISMS-REG-04 Internal audit checklist
• ISMS-REG-01 Statement of Applicability
• ISMS-REG-02 Control implementation tracker
• GOV-TPL-01 Internal audit report template
• GOV-TPL-02 Corrective action request form
• GOV-REG-03 Corrective action log
• GOV-PRO-03 Management review procedure
• GOV-REG-27 Framework crosswalk
• PB-06 Playbook: running your first internal audit cycle

Context of the organisation and interested parties procedure

How [Organisation] identifies the internal and external issues that affect its security and privacy outcomes, the parties with an interest in those outcomes and their requirements, and how the results shape the scope, risks and objectives of the management system.

Serves: ISO/IEC 27001:2022 clause 4.1; ISO/IEC 27001:2022 clause 4.2; ISO/IEC 27001:2022 clause 4.3; ISO/IEC 27701 clause 5.2.1; ISO/IEC 27701 clause 5.2.2; SOC 2 CC3.1. Owner: Information Security Manager.

1. Purpose

This procedure gives [Organisation] a repeatable way to understand the conditions it operates in, who depends on its security and privacy performance, and what those parties require, so that the scope, the risk assessment and the objectives rest on recorded facts rather than assumptions.

2. Scope

It applies to the whole management system described in ISMS-STM-01, every function and location within it, and the privacy extension where [Organisation] operates one. It runs at least once a year and after any trigger event in step 4.1.

3. Roles and responsibilities

4. Procedure

4.1 Timing. The Information Security Manager schedules the context review once a year, in the quarter before the management review, and within thirty days of any of these events: a new market or jurisdiction, a new service or product, an acquisition or divestment, a change of principal supplier, a change in applicable law, a severity 1 or 2 incident, a customer gained or lost that changes the risk profile, or a change of ownership or leadership.

4.2 Preparation. Five working days before the workshop the Information Security Manager circulates the current ISMS-REG-03, the previous issues analysis, a summary of GOV-REG-05 and GOV-REG-04, incident and audit trends for the period, and the security questionnaires and contract clauses received from customers since the last review.

4.3 Internal issues. In a workshop of at most two hours the participants answer the questions in table 1 for each category. Each issue is recorded as one sentence that states the condition and whether it helps or hinders a security or privacy outcome, with the function that owns it. An issue that cannot be stated as a condition with an effect is not recorded.

Table 1. Internal issue categories

4.4 External issues. The participants repeat the method with table 2. Each issue is recorded with the source it was learned from, so that it can be re-checked at the next review.

Table 2. External issue categories

4.5 Interested parties. The participants confirm the list of interested parties using the categories in table 3, adding and removing parties as the business has changed. For each party the register records the relationship and why the party cares about [Organisation]'s performance.

Table 3. Interested party categories

4.6 Requirements. For each party the Information Security Manager records every requirement in ISMS-REG-03 as one row: the party, the requirement in plain words, its type (Legal, Contractual, Voluntary commitment or Expectation), the source, the owner, how it is addressed and its priority. Whether the requirement is met through the management system is recorded explicitly; a requirement handled outside it names the function that handles it.

4.7 Using the results. Within twenty working days of the workshop the Information Security Manager: (a) updates ISMS-STM-01 if an issue or requirement changes the boundary; (b) raises or updates a risk in GOV-REG-05, using GOV-PRO-05, for every issue that hinders an outcome; (c) adds or updates obligations in GOV-REG-04 for every legal or contractual requirement; (d) proposes objectives for ISMS-PLN-01 where a requirement needs a measurable commitment; (e) checks ISMS-REG-01 for any control whose applicability justification depends on an issue or requirement that has changed.

4.8 Approval. The steering committee reviews the issues analysis and ISMS-REG-03 at its next meeting and records acceptance in its minutes. Where participants disagree about whether a requirement applies, the committee decides and the decision is minuted.

4.9 Reporting. A summary of the changes in context since the last review is a mandatory input to the management review under GOV-PRO-03.

5. Records and evidence

• ISMS-REG-03 Interested parties and requirements register, with a last reviewed date on every row.
• The completed issues analysis (tables 1 and 2), dated and controlled under GOV-PRO-01.
• The workshop attendance list and the preparation pack.
• Steering committee minutes recording acceptance.
• Entries in GOV-REG-05, GOV-REG-04 and ISMS-PLN-01 that cite the review date as their source.

6. Exceptions

The workshop may be replaced by a desk review by the Information Security Manager only when none of the events in step 4.1 occurred in the period and the previous review was workshop based. The substitution is recorded in ISMS-REG-03 and may not be used in two consecutive years.

7. Review and maintenance

The Information Security Manager reviews this procedure annually and after any audit finding against clauses 4.1 to 4.3. Changes follow GOV-PRO-01.

8. Related documents

• ISMS-STM-01 ISMS scope statement
• ISMS-REG-03 Interested parties and requirements register
• ISMS-PLN-01 Information security objectives and plan
• ISMS-REG-01 Statement of Applicability
• GOV-PRO-05 Risk assessment and treatment methodology
• GOV-REG-05 Information security risk register
• GOV-REG-04 Legal, regulatory and contractual register
• GOV-PRO-25 Legal, regulatory and contractual compliance procedure
• GOV-PRO-03 Management review procedure
• GOV-POL-01 Information security and privacy governance framework

Competence and awareness procedure

How [Organisation] decides what competence each security role needs, checks whether the people in those roles have it, closes gaps, keeps the records, and makes every person aware of what the management system expects of them.

Serves: ISO/IEC 27001:2022 clause 7.2; ISO/IEC 27001:2022 clause 7.3; ISO/IEC 27001:2022 Annex A 6.3; SOC 2 CC1.4. Owner: Information Security Manager.

1. Purpose

This procedure makes sure that the people who operate, administer, develop, audit and lead within the management system are able to do so, and that everyone else knows the rules that apply to them and why they matter. Awareness content and delivery are described in GOV-PRO-08; this procedure defines the competence requirements, the assessment and the records.

2. Scope

It applies to employees, contractors and temporary workers who hold any role in the competence matrix in step 4.1, and to all staff for the awareness requirements in step 4.6. Supplier personnel who administer in-scope systems are covered through the equivalence rule in step 4.7.

3. Roles and responsibilities

4. Procedure

4.1 Competence matrix. The Information Security Manager maintains the matrix below. A person who holds more than one role meets the requirements of each.

4.2 Assessment. On appointment and once a year the line manager compares the person with the row for each role held, records whether each element of competence is met, and lists gaps. The assessment is dated and kept with the training record.

4.3 Gap closing. For each gap the line manager and the Information Security Manager choose one or more actions: a course, mentoring or supervised practice, a temporary external specialist, or recruitment. Each action has a due date. A gap in a role with privileged access or incident authority is closed within ninety days; until then the person acts under the supervision of someone who meets the requirement.

4.4 Verification of effectiveness. After the action is complete the line manager confirms competence by one of: a test result, a task observed and signed off, an audit or review result, or the quality of work produced over the following quarter. The method and result are recorded; an action without a recorded verification is not counted as closed.

4.5 Records. The Head of People records every assessment, course, certificate, supervised task and verification in GOV-REG-09, with the session record GOV-TPL-10 where a session was delivered. Records are kept for the period of engagement plus [Number] years.

4.6 Awareness. Every person in scope knows the information security policy GOV-POL-03, how their work contributes to the objectives in ISMS-PLN-01, the benefit of following the controls that apply to them, how to report an event under GOV-PRO-07, and the consequences of not following the rules under GOV-PRO-18. Awareness is delivered under GOV-PRO-08 and acknowledged in GOV-REG-23.

4.7 Contractors and supplier personnel. Before access is granted, the engaging manager obtains evidence that the person meets the matrix row for the role, or that the supplier applies an equivalent requirement under the contract managed through GOV-PRO-06. The evidence or the contract reference is recorded in GOV-REG-09.

4.8 Auditor competence and independence. Before each internal audit the Information Security Manager confirms that the auditor meets the matrix row, has no responsibility for the area audited in the preceding twelve months, and has reviewed the current audit plan. Where no independent internal person exists for an area, an external auditor is engaged and the same evidence is obtained.

4.9 Review of the matrix. The Information Security Manager reviews the matrix annually and within thirty days of a new system, a new role, a change in law that affects the Privacy Officer, or an incident or audit finding that points to a competence gap.

5. Records and evidence

• GOV-REG-09 Training and awareness register: assessments, courses, verifications and due dates for every person in scope.
• GOV-TPL-10 Awareness session record and acknowledgement for each delivered session.
• GOV-REG-23 Policy acknowledgement register.
• The dated competence matrix and the annual review note.
• Auditor independence confirmations filed with each audit under GOV-PRO-02.

6. Exceptions

A person may be appointed to a role before meeting the matrix row only with the written agreement of the Information Security Manager, a named supervisor who meets the row, and a closing date within ninety days recorded in GOV-REG-09. No exception applies to the Internal Auditor independence rule.

7. Review and maintenance

The Information Security Manager reviews this procedure annually and after any audit finding against clauses 7.2 or 7.3. Changes follow GOV-PRO-01.

8. Related documents

• GOV-PRO-08 Security and privacy awareness and training procedure
• GOV-REG-09 Training and awareness register
• GOV-TPL-10 Awareness session record and acknowledgement
• GOV-REG-23 Policy acknowledgement register
• GOV-PRO-02 Internal audit procedure
• GOV-PRO-18 Human resources security procedure
• GOV-PRO-06 Supplier and third party security procedure
• GOV-POL-03 Information security policy
• ISMS-PLN-01 Information security objectives and plan

Operational planning and control procedure

How the processes that deliver the management system's controls are planned, given operating criteria, implemented from the risk treatment plan, kept under control when they change, and governed when another organisation performs them.

Serves: ISO/IEC 27001:2022 clause 8.1; ISO/IEC 27001:2022 clause 6.3; ISO/IEC 27001:2022 clause 6.1.3; SOC 2 CC5.1; SOC 2 CC5.3. Owner: Information Security Manager.

1. Purpose

This procedure connects the plans of the management system (the risk treatment plan, the objectives, the policies) to day to day operation. It defines which processes exist, what each must achieve, how a control agreed in the Statement of Applicability becomes something that actually runs, how planned and unplanned changes are handled, and how processes performed by suppliers stay under [Organisation]'s control.

2. Scope

It applies to every operational process that implements a control in ISMS-REG-01 or an action in GOV-REG-05, whether performed by staff, contractors or an external provider, across the whole scope in ISMS-STM-01.

3. Roles and responsibilities

4. Procedure

4.1 Process inventory. The Information Security Manager maintains the inventory below. Every process has a governing document, operating criteria (the measurable conditions that show it is working) and the records that prove it ran.

4.2 Setting criteria. When a process is created or its governing document changes, the process owner proposes the operating criteria and the Information Security Manager confirms that each criterion can be measured from the process's own records. Criteria that cannot be measured are rewritten before the document is approved under GOV-PRO-01.

4.3 Implementing treatments. Each treatment action in GOV-REG-05, and each control marked Planned or Partial in ISMS-REG-01, is given a task with an owner and a due date in ISMS-REG-02. The owner implements it, attaches evidence that it operates (configuration export, record sample, screenshot showing account and date), and the Information Security Manager updates the status in ISMS-REG-01 and ISMS-REG-02. A control is not marked Implemented until evidence of operation exists.

4.4 Planned changes to the management system. A change to scope, policy, process, organisation structure or principal technology that affects how a control operates is proposed in writing with its purpose, the controls affected, the resources needed, and the responsibilities that move. The Information Security Manager assesses the effect on GOV-REG-05 and ISMS-REG-01; the steering committee approves; the affected documents are updated under GOV-PRO-01 before the change takes effect. Technical changes to systems follow GOV-PRO-09 in addition.

4.5 Unintended changes. When a change has happened without this review (for example a provider alters a service, a team adopts a new tool, a control stops operating), the person who notices reports it as an event under GOV-PRO-07. The Information Security Manager reviews the consequences within five working days, records any new or changed risk in GOV-REG-05, and raises a nonconformity under GOV-PRO-04 if a control failed.

4.6 Externally provided processes. Where a supplier performs a process in the inventory, or part of one, the Head of Operations records it in GOV-REG-07 with the process name, the contract clause that requires the operating criteria, the evidence the supplier must provide and how often, and the person who reviews that evidence. Cloud services are governed under GOV-PRO-26 and the shared responsibility split in ISMS-STM-01. A supplier's failure to meet a criterion is handled as a nonconformity against the supplier under GOV-PRO-06.

4.7 Documented information from operation. Each process keeps the records named in the inventory for the retention period in the retention schedule, in a form that shows who did what and when. Records are controlled under GOV-PRO-01.

4.8 Monthly operations review. The Information Security Manager meets the process owners each month, checks each process against its criteria using the latest records, lists breaches of criteria, and agrees corrections. Breaches that repeat for two months, or that affect a critical system, go to GOV-PRO-04. The review note is filed and feeds the quarterly report under ISMS-PRO-04.

5. Records and evidence

• The process inventory in step 4.1, dated at each revision.
• ISMS-REG-02 Control implementation tracker: implementation tasks, evidence and status for every applicable control.
• ISMS-REG-01 Statement of Applicability with implementation status.
• Change proposals and steering committee approvals for planned changes.
• Monthly operations review notes.
• GOV-REG-07 entries for processes performed by suppliers, with the evidence received.

6. Exceptions

A treatment or control may operate without the evidence in step 4.3 for at most thirty days after implementation while the first records accumulate. No process may operate without a named owner.

7. Review and maintenance

The Information Security Manager reviews this procedure annually and after any audit finding against clause 8.1 or 6.3. Changes follow GOV-PRO-01.

8. Related documents

• ISMS-REG-01 Statement of Applicability
• ISMS-REG-02 Control implementation tracker
• GOV-PRO-05 Risk assessment and treatment methodology
• GOV-REG-05 Information security risk register
• GOV-PRO-09 Change management procedure
• GOV-PRO-06 Supplier and third party security procedure
• GOV-PRO-26 Cloud services security procedure
• GOV-PRO-04 Nonconformity and corrective action procedure
• ISMS-PRO-04 Monitoring, measurement, analysis and evaluation procedure
• GOV-PRO-01 Document control procedure

Monitoring, measurement, analysis and evaluation procedure

What [Organisation] measures about its controls and its management system, how and how often the data is collected, who analyses it, how control effectiveness is tested, and how results reach the steering committee and the management review.

Serves: ISO/IEC 27001:2022 clause 9.1; ISO/IEC 27001:2022 clause 6.2; ISO/IEC 27001:2022 Annex A 5.36; SOC 2 CC4.1; SOC 2 CC4.2. Owner: Information Security Manager.

1. Purpose

This procedure produces the evidence that the management system works: a fixed set of measures with formulas and targets, a test of every applicable control at least once a year, and a quarterly report that tells leadership where performance is below target and what is being done about it.

2. Scope

It applies to every process in the inventory of ISMS-PRO-03, every applicable control in ISMS-REG-01, and every objective in ISMS-PLN-01, across the scope in ISMS-STM-01.

3. Roles and responsibilities

4. Procedure

4.1 Measurement set. The measures below are collected for every period. Each is defined by a formula, a target, a frequency and the register it is drawn from, so that two people would compute the same value.

4.2 Data collection. By the fifth working day after each period the process owner extracts the value from the named register, keeps the extract (export or filtered view with its date), and enters the value and the extract location in GOV-REG-21. A value that cannot be computed because the register is incomplete is recorded as missing, not estimated.

4.3 Control effectiveness testing. At the start of each year the Information Security Manager plans a test of every control marked Implemented in ISMS-REG-01 and records the plan in ISMS-REG-02: the test method, the sample, the tester and the quarter. Methods are inspection of configuration, sampling of records, re-performance of the control, interview, and observation. Controls that protect restricted information or privileged access are tested by someone who does not operate them. The tester records the result as Pass or Fail with the evidence reference and the date. A Fail is raised under GOV-PRO-04 within five working days.

4.4 Sampling rule. For a control that runs daily or more often, the tester examines at least 25 instances spread across the year; weekly, at least 10; monthly, at least 3; quarterly or less often, every instance. A single exception in the sample is a Fail unless the process owner shows it was detected and corrected by the process itself at the time.

4.5 Analysis. The Information Security Manager compares each value with its target and with the previous four periods, assigns Green (at or better than target), Amber (within 10 percent of target or a single miss after four Greens) or Red (below that), and writes one sentence of cause and one of action for every Amber and Red. Trends matter as much as single values: three consecutive periods moving away from target is reported as Amber even if still above target.

4.6 Quarterly report. Within fifteen working days of quarter end the Information Security Manager issues the quarterly performance report containing: the measurement table with status, the objectives from ISMS-PLN-01 with status, control test results from ISMS-REG-02 (tests planned, performed, passed, failed), open nonconformities from GOV-REG-03 by age, and the actions proposed. The steering committee reviews it at its next meeting and the decisions are minuted.

4.7 Annual evaluation. The year's four reports, the full year control test results and the trend of every measure are an input to the management review under GOV-PRO-03. The review confirms or changes the measures and targets for the next year, and the Information Security Manager updates this procedure and GOV-REG-21 within thirty days.

4.8 Data quality. Every reported value can be traced to a dated extract. If a formula or source changes, the change is recorded in GOV-REG-21 and values before the change are not compared with values after it without a note.

5. Records and evidence

• GOV-REG-21 Security objectives and measures tracker: values, extracts and status for every measure and objective.
• ISMS-REG-02 Control implementation tracker: the test plan and the result of every control test.
• Quarterly performance reports and the steering committee minutes that reviewed them.
• Dated extracts from the source registers.
• Nonconformities raised in GOV-REG-03 from failed tests or Red measures.

6. Exceptions

A measure may be suspended for at most two periods when its source register is being rebuilt, with the reason recorded in GOV-REG-21 and reported in the quarterly report. No control marked Implemented may go untested for more than twelve months.

7. Review and maintenance

The Information Security Manager reviews this procedure annually after the management review, and within thirty days of a change to ISMS-PLN-01 or to the process inventory in ISMS-PRO-03. Changes follow GOV-PRO-01.

8. Related documents

• ISMS-PLN-01 Information security objectives and plan
• GOV-REG-21 Security objectives and measures tracker
• ISMS-REG-01 Statement of Applicability
• ISMS-REG-02 Control implementation tracker
• ISMS-PRO-03 Operational planning and control procedure
• GOV-PRO-03 Management review procedure
• GOV-PRO-04 Nonconformity and corrective action procedure
• GOV-PRO-02 Internal audit procedure

ISMS scope statement

Defines the boundary of the information security management system, the organisation, locations, services, systems, interfaces and exclusions it covers, and how that boundary is changed.

Serves: ISO/IEC 27001:2022 clause 4.3; ISO/IEC 27001:2022 clause 4.1; ISO/IEC 27001:2022 clause 4.2. Owner: Information Security Manager.

1. Statement of scope

The information security management system (ISMS) of [Organisation] covers the people, processes, information and technology used to design, deliver, operate and support [Service or product description] for its customers from the locations listed in section 2, together with the corporate functions named there. The boundary was set after the context analysis recorded in ISMS-REG-03 and takes account of the internal and external issues, the interested parties and the dependencies described below.

The scope wording used on certificates and in public statements is:

The information security management system supporting the design, development, operation and support of [Service or product description] for customers, delivered from [Location] and the hosted infrastructure described in the Statement of Applicability version [Number].

2. Organisation and locations

Employees, contractors and temporary workers who perform work within the functions above are inside the scope for the duration of their engagement.

3. Services and products

4. Information, systems and networks

5. Interfaces and dependencies

[Organisation] relies on external providers for parts of the environment. The split of responsibility is recorded here and in GOV-PRO-26, and the providers themselves are listed in GOV-REG-07.

Interfaces between in-scope and out-of-scope elements, for example an integration from [Service name] to a customer's own system, are listed in GOV-REG-25 with their classification and protection.

6. Exclusions and justification

An exclusion is permitted only where it does not reduce [Organisation]'s ability to protect in-scope information or to meet a requirement recorded in ISMS-REG-03. Each exclusion is re-examined during the annual risk assessment.

7. Requirements considered

The scope reflects the requirements of the interested parties recorded in ISMS-REG-03, the legal and contractual obligations in GOV-REG-04, and the issues identified through ISMS-PRO-01. Where a customer contract requires a particular system or location to sit within a certified scope, that requirement is recorded against the contract in GOV-REG-04 and reflected here.

8. Changes to the scope

8.1 Any role may propose a scope change. The proposal names the element to add or remove, the reason, the affected interested parties and the expected effect on risk.

8.2 The Information Security Manager assesses the proposal against the risk register (GOV-REG-05) and the Statement of Applicability (ISMS-REG-01) and presents it to the steering committee defined in GOV-POL-01.

8.3 The Chief Executive Officer approves the change. The Information Security Manager then updates this statement, GOV-REG-10, the risk assessment and ISMS-REG-01 within thirty days, and notifies the certification body where a certificate is held.

8.4 The following events require a scope review within thirty days: a new product or service, a new office or hosting region, an acquisition or divestment, a new category of customer data, a change of principal provider, or a contract that requires a change of scope.

9. Records and related documents

• ISMS-REG-03 Interested parties and requirements register
• ISMS-REG-01 Statement of Applicability
• ISMS-PRO-01 Context of the organisation and interested parties procedure
• GOV-REG-10 Information asset register
• GOV-REG-25 Data flow and interface inventory
• GOV-REG-07 Supplier register
• GOV-REG-04 Legal, regulatory and contractual register
• GOV-POL-01 Information security and privacy governance framework
• GOV-PRO-26 Cloud services security procedure

Internal audit checklist

One question per clause requirement of ISO/IEC 27001:2022 and one per Annex A control, each answerable yes or no, with the evidence to ask for and the role to ask. Copied once per audit, trimmed to the audit's criteria, and completed with the result, the evidence seen and the sampling notes so that the finished copy is itself an audit record.

Serves: ISO/IEC 27001:2022 clause 9.2; ISO/IEC 27001:2022 clause 9.2.2; ISO/IEC 27001:2022 Annex A; SOC 2 CC4.1.

Columns:

• Clause or control: Clause number 4.1 to 10.2 or Annex A control number.
• Question: Answer yes or no from evidence
• Evidence to request: What to ask for before fieldwork. Replace kit IDs with your own document names where they differ.
• Interviewee role: Role to ask. Change it to match your organisation chart.
• Result: Grades as defined in GOV-PRO-02 step 4.7. Not applicable needs the Statement of Applicability reason in Notes.
• Evidence seen: File names as named under PB-09. Never write seen or discussed.
• Notes: Population
• Finding reference: Finding ID in the GOV-TPL-01 report and the GOV-REG-03 entry raised from it.

Statement of Applicability

One row per Annex A control of ISO/IEC 27001:2022, recording whether it applies, why, how far it is implemented, which kit documents implement it and where the evidence is. Reviewed with every risk assessment and whenever the scope or the context changes, and version controlled because its version appears in the certificate scope wording.

Serves: ISO/IEC 27001:2022 clause 6.1.3; ISO/IEC 27001:2022 Annex A.

Columns:

• Control: Annex A control number.
• Theme: A reminder in plain words. Read the standard for the authoritative text.
• Applicable
• Justification: The risk or requirement that makes the control apply
• Status: Implementation status. Implemented requires operating evidence.
• Implementing documents: Kit document IDs separated by semicolons. Replace with your own where you have changed them.
• Evidence reference: Folder
• Owner: Role that owns the control.
• Last reviewed
• Notes

Control implementation tracker

One row per Annex A control, tracking who owns it, how far implementation has got, where the operating evidence is, how and when it was last tested and with what result. It is the working companion of the Statement of Applicability and the source of the control test results reported under the monitoring procedure.

Serves: ISO/IEC 27001:2022 clause 6.1.3; ISO/IEC 27001:2022 clause 8.1; ISO/IEC 27001:2022 clause 9.1; ISO/IEC 27001:2022 Annex A.

Columns:

• Control: Annex A control number.
• Theme: A reminder in plain words. Read the standard for the authoritative text.
• Owner: Role that owns the control.
• Status
• Evidence: Folder
• Test method
• Last tested
• Result
• Next test due: Within twelve months of the last test.
• Notes: Sample size

Interested parties and requirements register

One row per requirement of each party with an interest in the organisation's security and privacy performance, stating the requirement in plain words, its type and source, whether it is met through the management system, how, and who owns it. Produced and reviewed under the context procedure and used to set the scope, the risks and the objectives.

Serves: ISO/IEC 27001:2022 clause 4.2; ISO/IEC 27001:2022 clause 4.1; ISO/IEC 27701 clause 5.2.2.

Columns:

• Party ID: Sequential reference
• Interested party: The party or category
• Internal or external
• Relationship: Why this party cares about the organisation's security or privacy performance.
• Requirement: One requirement per row
• Requirement type
• Source: Law
• Addressed through ISMS
• How addressed: Kit document IDs
• Owner: Role accountable for meeting the requirement.
• Priority
• Status
• Last reviewed
• Notes

Implementation project plan

The task list for implementing the management system, organised by the twelve steps of the implementation playbook with the kit deliverable, owner role and planned weeks for each task. Prefilled with a typical 26 week plan for an organisation of up to about one hundred people; adjust the weeks and owners before use and add rows for the gaps found in the gap analysis.

Serves: ISO/IEC 27001:2022 clause 5.1; ISO/IEC 27001:2022 clause 6.2; ISO/IEC 27001:2022 clause 8.1.

Columns:

• Step: One of the twelve steps in PB-02.
• Task
• Deliverable: Kit document or register IDs produced or updated by the task.
• Owner role
• Planned start week
• Planned end week
• Duration (weeks)
• Status
• Actual end week
• Notes

Guide: ISO/IEC 27701 Annex A (controller) and Annex B (processor) controls and where the kit covers each

A reading aid that lists every control in Annex A and Annex B of ISO/IEC 27701 with a short theme in plain words and the kit documents that implement it, and explains how the clause 5 and clause 6 extensions change an existing ISMS, for use when extending the Statement of Applicability.

Serves: ISO/IEC 27701 Annex A; ISO/IEC 27701 Annex B; ISO/IEC 27701 clause 5.4.1.3. Owner: Privacy Officer.

1. How to use this guide

ISO/IEC 27701 does not stand alone. It extends an information security management system built on ISO/IEC 27001 and ISO/IEC 27002 so that it also manages personal data, and it calls the result a privacy information management system. The 2019 edition has four working parts. Clause 5 adds privacy requirements to each ISO/IEC 27001 clause, mostly by saying that wherever the security standard says information security, you read information security and privacy, and by requiring you to decide whether you act as a controller, a processor, or both. Clause 6 adds privacy guidance to the ISO/IEC 27002 controls, for example on training, classification, backups, logs, test data, suppliers and incidents. Clause 7 gives guidance for controllers and clause 8 for processors. Annex A lists the controller controls and Annex B the processor controls; these two annexes are normative, which means your Statement of Applicability must cover them in the same way it covers the ISO/IEC 27001 Annex A controls.

Which annex applies depends on the role decision under PIMS-PRO-01. A pure controller applies Annex A; a pure processor applies Annex B; an organisation that is both, which is most product companies, applies both, and the justification column of ISMS-REG-01 says for which processing activities each applies.

The tables below give each control number a theme written in this kit's own words. The themes are a memory aid, not the standard's titles; read the standard itself for the requirement. The third column names the kit documents that implement the control, the first being the primary one. Use the tables in three places:

1. ISMS-REG-01 Statement of Applicability. Add the Annex A and Annex B rows under the ISO/IEC 27001 rows, decide Applicable Yes or No for each, justify, set the implementation status, and copy the kit IDs you actually use.
2. ISMS-REG-02 Control implementation tracker. Add the same rows with owner, evidence, test method and the effectiveness grade from PIMS-PRO-07.
3. Gap analysis in step 5 of PB-05. Walk the tables with the Processing Owners and mark what exists, what exists informally and what does not exist.

2. Annex A: controls for controllers

3. Annex B: controls for processors

4. What clause 5 and clause 6 change in an existing ISMS

The annexes are the visible part. An auditor spends as much time on the clause 5 extensions, because they change documents the ISMS already has. The table lists the extensions most organisations have to act on and the kit document that carries the change.

5. Editions and numbering

This guide uses the numbering of the 2019 edition of ISO/IEC 27701, in which the standard is an extension to ISO/IEC 27001:2013 and ISO/IEC 27002:2013 and the controller and processor controls sit in Annex A and Annex B as listed above. A later edition restructures the standard so that it can be certified on its own and renumbers its clauses and annexes; the themes above survive the restructuring, the numbers do not. Before building your Statement of Applicability, confirm with your certification body which edition it audits against, add a column to ISMS-REG-01 for that edition's numbering, and map each theme row once. The kit document IDs do not change; only the control reference in the first column does. Keep the mapping with GOV-REG-01 as an external document reference so that the next auditor can follow it.

6. Related documents

• ISMS-REG-01 Statement of Applicability
• ISMS-REG-02 Control implementation tracker
• ISMS-GDE-01 Guide: the 93 Annex A controls and where the kit covers each
• PIMS-POL-01 Privacy information management policy
• PIMS-PRO-01 Determining controller and processor roles
• PIMS-PRO-07 Privacy control effectiveness monitoring procedure
• PB-05 Playbook: adding ISO/IEC 27701 privacy management to an existing ISMS

Privacy information management policy

The top-level commitment that extends the information security management system to the protection of personal data, the principles every processing activity must satisfy, and the roles that make them happen.

Serves: ISO/IEC 27701 clause 5.3.2; ISO/IEC 27701 clause 5.2.1; ISO/IEC 27701 clause 6.2.1.1; ISO/IEC 27001:2022 clause 5.2; ISO/IEC 27001:2022 Annex A 5.34; GDPR Article 5; GDPR Article 24. Owner: Privacy Officer.

1. Purpose

This policy extends [Organisation]'s information security management system into a privacy information management system. It states the principles that every processing of personal data must satisfy, names the roles accountable for them, and commits [Organisation] to the procedures and records that prove the principles are applied.

2. Scope

It applies to all personal data that [Organisation] processes within the scope in ISMS-STM-01, whether as a controller, a processor, or both, in every system, service, office and supplier arrangement, and to every employee, contractor and supplier who handles that data. Personal data means any information relating to an identified or identifiable individual, including identifiers, online identifiers and data that becomes identifying when combined.

3. Roles and responsibilities

4. Policy statements

4.1 Lawfulness, fairness and transparency. Every processing activity has a lawful basis recorded in PIMS-REG-01 before it starts, and the individuals concerned are told about it through a notice managed under PIMS-PRO-05. No personal data is processed in a way the individuals would not reasonably expect from that notice.

4.2 Purpose limitation. Personal data is collected for the specific purposes recorded in PIMS-REG-01 and is not used for a new purpose unless the Privacy Officer confirms in writing that the new purpose is compatible or that a new lawful basis and notice are in place.

4.3 Minimisation. Each processing activity collects and keeps only the data fields the recorded purpose needs. The Processing Owner confirms this at the privacy by design review in PIMS-PRO-06 and at every inventory review.

4.4 Accuracy. Personal data is kept accurate and up to date in proportion to the harm an error could cause. Individuals can correct their data through PIMS-PRO-03, and corrections reach every system and recipient that holds the data.

4.5 Storage limitation. Personal data is kept no longer than the period in PIMS-REG-07, set under PIMS-POL-02, and is then deleted, anonymised or returned, including copies in backups and logs within their own cycle.

4.6 Integrity and confidentiality. Personal data is protected by the controls in the Statement of Applicability ISMS-REG-01, selected through GOV-PRO-05 with the harm to individuals treated as an impact in its own right. Access is granted under GOV-PRO-10 on a need to know basis only.

4.7 Accountability. [Organisation] can show that each statement in this policy is met, through the registers in section 5, the assessments in PIMS-REG-08 and the monitoring report produced quarterly under PIMS-PRO-07.

4.8 Roles decided first. Before any new processing activity, contract or supplier arrangement starts, the Privacy Officer records under PIMS-PRO-01 whether [Organisation] acts as controller, joint controller or processor, because the obligations differ.

4.9 Privacy risk and impact assessment. Every new or changed processing activity is screened under PIMS-PRO-02 before design approval, and a data protection impact assessment is completed and approved before processing that is likely to result in a high risk to individuals begins.

4.10 Rights of individuals. Requests from individuals are handled under PIMS-PRO-03 within one month of receipt, free of charge, with every request and its outcome recorded in PIMS-REG-02.

4.11 Breaches. A suspected personal data breach is reported immediately through the incident channel in GOV-PRO-07 and assessed under PIMS-PRO-04, with the supervisory authority notified within 72 hours of awareness where the risk to individuals requires it and the controller notified without undue delay where [Organisation] is a processor.

4.12 Processors and sharing. Personal data is shared with a processor only under written terms that meet GDPR Article 28, based on PIMS-TPL-02, after approval under GOV-PRO-06, and the processor is listed in PIMS-REG-06.

4.13 International transfers. Personal data leaves the region in which [Organisation] is established only under a mechanism approved in PIMS-POL-03 and recorded in PIMS-REG-05.

4.14 Privacy by design and by default. Every product, feature, system and procurement that processes personal data passes the review in PIMS-PRO-06, and the default configuration offered to individuals is the most privacy-protective option available.

4.15 Training. Every person completes privacy training at induction and annually under GOV-PRO-08, with role-based content for people who design systems, handle requests or respond to incidents, recorded in GDPR-REG-05.

4.16 One management system. Privacy controls are selected, implemented, audited and reviewed through the same processes as security controls: GOV-PRO-05 for risk, ISMS-REG-01 for applicability of the ISO/IEC 27701 Annex A and Annex B controls, GOV-PRO-02 for internal audit and GOV-PRO-03 for management review. The Privacy Officer attends every management review.

4.17 Consequences. A breach of this policy is handled under the disciplinary process in GOV-PRO-18, and for a supplier under the contract.

5. Records and evidence

• PIMS-REG-01 Personal data processing inventory, with roles, purposes, bases and retention.
• PIMS-REG-02 Data subject request register and PIMS-REG-03 Personal data breach register.
• PIMS-REG-04 Consent record register, PIMS-REG-05 International transfer register and PIMS-REG-06 Processor and sub-processor register.
• PIMS-REG-07 Retention schedule with check results and PIMS-REG-08 DPIA register.
• ISMS-REG-01 Statement of Applicability showing the Annex A and Annex B controls that apply.
• Quarterly privacy monitoring reports under PIMS-PRO-07 and GOV-REG-23 acknowledgements of this policy.

6. Exceptions

No exception to statements 4.1 to 4.7 is possible, because they restate legal obligations. An exception to any other statement is requested under GOV-PRO-24 with the Privacy Officer's written assessment of the effect on individuals and is approved by the Chief Executive Officer.

7. Review and maintenance

The Privacy Officer reviews this policy annually, after a personal data breach notified to a supervisory authority, after a change in applicable privacy law recorded in GOV-REG-04, after a change in [Organisation]'s role under PIMS-PRO-01, and after an audit finding against it. Changes follow GOV-PRO-01 and are communicated under ISMS-PLN-02.

8. Related documents

• GOV-POL-01 Information security and privacy governance framework
• GOV-POL-03 Information security policy
• GDPR-POL-01 Data protection policy
• PIMS-PRO-01 Determining controller and processor roles
• PIMS-PRO-02 Privacy risk and data protection impact assessment procedure
• PIMS-PRO-03 Data subject rights handling procedure
• PIMS-PRO-04 Personal data breach assessment and notification procedure
• PIMS-PRO-05 Consent and privacy notice management procedure
• PIMS-PRO-06 Privacy by design and by default procedure
• PIMS-PRO-07 Privacy control effectiveness monitoring procedure
• PIMS-POL-02 Data retention and disposal policy
• PIMS-POL-03 International transfer policy
• PIMS-GDE-01 Guide to the ISO/IEC 27701 Annex A and Annex B controls
• PB-05 Playbook: adding ISO/IEC 27701 privacy management to an existing ISMS

Data retention and disposal policy

The rules that decide how long each category of information is kept, what starts the clock, how it is disposed of, how legal holds suspend disposal, and how backups and logs are treated, with the schedule itself held in PIMS-REG-07.

Serves: ISO/IEC 27701 clause 7.4.7; ISO/IEC 27701 clause 7.4.8; ISO/IEC 27701 clause 7.4.5; ISO/IEC 27701 Annex A 7.4.7; ISO/IEC 27701 Annex A 7.4.8; ISO/IEC 27701 Annex B 8.4.2; ISO/IEC 27001:2022 Annex A 5.33; ISO/IEC 27001:2022 Annex A 8.10; GDPR Article 5. Owner: Privacy Officer.

1. Purpose

This policy keeps information for as long as it is needed and no longer. Over-retention increases the harm of every breach, makes requests from individuals harder to answer and breaks the storage limitation principle; under-retention loses records that the law, a contract or a dispute requires.

2. Scope

It applies to all information that [Organisation] holds, in every system, backup, archive, log, mailbox, device, paper file and supplier service, with particular rules for personal data. Where [Organisation] is a processor, the client's instructions and the agreement take precedence over the schedule, and the policy governs what happens at the end of the service.

3. Roles and responsibilities

4. Policy statements

4.1 The schedule. Every category of information is listed in PIMS-REG-07 with its systems, its retention period, the trigger that starts the period, the reason for the period, the disposal method and the owner. A category not in the schedule is added within thirty days of being found, and until then is treated as held for the default in 4.3.

4.2 Justified periods. Each period is justified by one of: a statutory retention requirement, a contractual requirement, the limitation period for legal claims, or a documented operational need, in that order of preference. The justification names the source in GOV-REG-04 where it is legal or contractual. "We might need it" is not a justification.

4.3 Default period. Personal data with no entry in the schedule is deleted [Number] months after the purpose for which it was collected ends, and at most twelve months after.

4.4 Triggers. Periods run from a defined event (end of contract, last activity, decision date, end of employment, financial year end, closure of a case, creation of the record), never from an undefined "when no longer needed". The trigger is recorded in the system where possible.

4.5 Configured disposal. Where a system can enforce retention, the System Owner configures it and records where. Where it cannot, the System Owner runs a disposal at least quarterly and records the run. The Privacy Officer samples each category at least annually and records Pass, Fail or To confirm in PIMS-REG-07.

4.6 Disposal methods. Personal data is disposed of by secure deletion, by irreversible anonymisation, or by return to the controller or individual. Paper is cross-cut shredded or placed in confidential waste. Media and devices are wiped or destroyed under GOV-PRO-16 and recorded in GOV-REG-20. Deleting a reference, a link or an index entry while the data remains is not disposal.

4.7 Anonymisation. Data counts as disposed of by anonymisation only when no party, using means reasonably likely to be used, can re-identify the individuals, and the Privacy Officer has recorded the assessment. Pseudonymised data remains personal data and stays in the schedule.

4.8 Copies and derived data. Disposal covers every copy: primary stores, replicas, exports, reports, caches, temporary files, search indexes, analytics data sets, test environments and data held by processors. The Processing Owner lists the locations from GOV-REG-25 and PIMS-REG-06 and confirms each.

4.9 Backups. Backups are kept for the period set under GOV-PRO-12 and recorded in PIMS-REG-07, so that data deleted from a primary system leaves the backups within that period without a separate deletion. Data restored from backup during recovery that had been deleted from the primary system is deleted again within five working days of the restore.

4.10 Logs. Logs are kept for the period set under GOV-PRO-14 and recorded in PIMS-REG-07. Logs are personal data where they identify an individual and are disposed of on the same terms; they are not kept longer than the security purpose needs because they might one day be useful.

4.11 Legal hold. When litigation, an investigation, an authority enquiry or a complaint is reasonably anticipated, the Privacy Officer or the legal adviser issues a written legal hold naming the categories, systems, individuals and custodians affected. Disposal of the named information is suspended, custodians are instructed in writing, configured deletion is paused for the affected data, and the hold is reviewed every ninety days and lifted in writing. Legal holds are listed in PIMS-REG-07.

4.12 End of a processor service. When [Organisation] stops acting as processor for a client, it returns or deletes the client's personal data as the agreement based on PIMS-TPL-02 requires, within the time it states, and provides written confirmation of deletion. When a supplier stops processing for [Organisation], the supplier owner obtains the same confirmation under GOV-PRO-06 and records it in PIMS-REG-06.

4.13 Requests and breaches. Erasure requests under PIMS-PRO-03 override the schedule unless an exemption applies. Records of requests, breaches, assessments and consents are themselves in the schedule, because they prove compliance.

4.14 Schedule examples. The following rows illustrate the form of PIMS-REG-07. Every period is an example for [Organisation] to replace from its own obligations in GOV-REG-04; none is a legal statement.

5. Records and evidence

• PIMS-REG-07 Retention schedule: every category with its period, trigger, configuration, check results and legal holds.
• Configuration exports showing retention settings in each system.
• Disposal run records and GOV-REG-20 Media and equipment disposal log.
• Deletion confirmations from processors and to clients.
• Legal hold notices, custodian instructions and lift notices.

6. Exceptions

An extension beyond the schedule for a named data set is approved by the Privacy Officer for a stated reason and a stated end date of no more than twelve months, recorded in PIMS-REG-07, and reviewed at the end date. A legal hold is not an exception; it is a suspension under 4.11.

7. Review and maintenance

The Privacy Officer reviews this policy and the schedule annually, after a change in statutory periods in GOV-REG-04, after a new system or processor starts holding personal data, and after a breach or request that revealed over-retention. Changes follow GOV-PRO-01.

8. Related documents

• PIMS-REG-07 Retention schedule
• PIMS-POL-01 Privacy information management policy
• PIMS-PRO-03 Data subject rights handling procedure
• PIMS-TPL-02 Data processing agreement template
• GOV-PRO-12 Backup and restore testing procedure
• GOV-PRO-14 Logging, monitoring and alert handling procedure
• GOV-PRO-16 Asset management, classification and handling procedure
• GOV-REG-20 Media and equipment disposal log
• GOV-REG-04 Legal, regulatory and contractual register
• GOV-PRO-25 Legal, regulatory and contractual compliance procedure

International transfer policy

The rules under which personal data may leave the region in which [Organisation] is established, the transfer mechanisms in plain words, the assessment required before a transfer relies on contractual safeguards, and the register that records every transfer.

Serves: ISO/IEC 27701 clause 7.5.1; ISO/IEC 27701 clause 7.5.2; ISO/IEC 27701 clause 7.5.3; ISO/IEC 27701 clause 8.5.1; ISO/IEC 27701 Annex A 7.5.1; ISO/IEC 27701 Annex A 7.5.2; ISO/IEC 27701 Annex A 7.5.3; ISO/IEC 27701 Annex B 8.5.1; ISO/IEC 27701 Annex B 8.5.2; ISO/IEC 27701 Annex B 8.5.4; ISO/IEC 27701 Annex B 8.5.5; GDPR Article 44; GDPR Article 45; GDPR Article 46; GDPR Article 47; GDPR Article 49. Owner: Privacy Officer.

1. Purpose

This policy keeps the protection that individuals have at home attached to their data when it goes abroad. A transfer without a recognised mechanism is unlawful regardless of how secure the recipient is, and a mechanism applied without assessing the destination can be unlawful too.

2. Scope

It applies to every movement of personal data from [Organisation] to a recipient in another country or international organisation, including hosting, backup and support arrangements, remote access by a supplier or employee from abroad, sub-processors of processors, group companies, clients, authorities and any onward transfer by a recipient. It applies whether [Organisation] is controller or processor. The region of establishment is [Region], as recorded in GOV-REG-04.

3. Roles and responsibilities

4. Policy statements

4.1 What counts as a transfer. Personal data is transferred when it is sent to, stored in, or made accessible from another country, including remote viewing by a support engineer, replication to a backup region, and processing by a sub-processor abroad. Transit through another country with no access and no storage is not a transfer. The Privacy Officer decides doubtful cases.

4.2 No transfer without a recorded mechanism. Personal data leaves the region of establishment only after the Privacy Officer has approved a mechanism in 4.3 and recorded the transfer in PIMS-REG-05 with the importer, the destination, the data, the mechanism and its reference. A transfer found without an entry is stopped or regularised within ten working days and recorded as a nonconformity under GOV-PRO-04.

4.3 Mechanisms in plain words. The Privacy Officer selects the first of these that applies:

4.4 Transfer impact assessment. Before a transfer relies on standard contractual clauses, binding corporate rules or a code or certification, the Privacy Officer completes GDPR-TPL-08: the data and the individuals; the importer and its role; the law and practice of the destination, including access by public authorities and the remedies available to individuals; the importer's own experience of such access; and the supplementary measures that close any gap, such as encryption with keys held only in the region of establishment, pseudonymisation before export, split processing, or contractual commitments to challenge and notify access requests. The assessment is approved before the first transfer, referenced in PIMS-REG-05, and repeated every [Number] months and whenever the destination's law, the importer or the data changes.

4.5 Supplementary measures. Where the assessment finds that the destination's law undermines the clauses and no supplementary measure closes the gap, the transfer does not take place. Measures are implemented and evidenced before the transfer starts, not promised.

4.6 Suppliers and sub-processors. The supplier owner establishes under GOV-PRO-06, before contract, every country in which the supplier and its sub-processors store, process, back up or access the data, records them in PIMS-REG-06 and GOV-REG-07, and obtains notice of any change. Hosting regions are chosen under GOV-PRO-26 to avoid transfers where a regional option exists at reasonable cost.

4.7 Onward transfers. An importer may pass personal data to another country only under a mechanism that gives equivalent protection and that is recorded in the contract. Sub-processor chains are followed to the last link.

4.8 Transfers where [Organisation] is a processor. [Organisation] transfers a client's personal data only on the client's documented instruction, under the mechanism the client has approved, and notifies the client of every country involved and every change. A request from a client to transfer without a lawful mechanism is declined and recorded.

4.9 Working from abroad. An employee or contractor accessing personal data from outside the region of establishment is a transfer; approval under GOV-POL-05 includes the Privacy Officer's confirmation of the mechanism and the device and network controls that apply.

4.10 Requests from foreign authorities. A legally binding request from a public authority outside the region for personal data is handled under GOV-PRO-25 by the Privacy Officer and the legal adviser: its validity is checked, the minimum data is disclosed, the controller is told where [Organisation] is a processor and the law allows, and individuals are told where the law allows. Each request and response is recorded in PIMS-REG-05 as a disclosure.

4.11 Individuals informed. Every notice under PIMS-PRO-05 states that data is transferred, where, under which mechanism, and how the individual can see the safeguards.

4.12 Records. PIMS-REG-05 records every transfer and every disclosure to a foreign authority; PIMS-REG-01 and GDPR-REG-02 cross-reference it. Signed clauses, assessments and approvals are kept for the life of the transfer plus the period in PIMS-REG-07.

4.13 Change in law. When an adequacy recognition is withdrawn, a clause set is replaced, or a court decision changes the assessment of a destination, the Privacy Officer reviews every affected PIMS-REG-05 entry within thirty days and reports to the next management review.

5. Records and evidence

• PIMS-REG-05 International transfer register with the mechanism, reference and assessment for every transfer.
• Completed GDPR-TPL-08 transfer impact assessments and their reviews.
• Signed standard contractual clauses or other instruments, with the version and the module used.
• PIMS-REG-06 and GOV-REG-07 location entries for suppliers and sub-processors.
• GOV-PRO-26 region evidence and GOV-POL-05 approvals for working abroad.

6. Exceptions

A derogation under 4.3 is the only exception and is used as that row describes. No transfer proceeds on the basis that a mechanism will be put in place later.

7. Review and maintenance

The Privacy Officer reviews this policy annually, after any change in transfer law or adequacy recognitions recorded in GOV-REG-04, after a request from a foreign authority, and after an audit finding. Changes follow GOV-PRO-01.

8. Related documents

• GDPR-TPL-08 Transfer impact assessment template
• PIMS-REG-05 International transfer register
• PIMS-REG-06 Processor and sub-processor register
• PIMS-REG-01 Personal data processing inventory
• PIMS-TPL-02 Data processing agreement template
• PIMS-PRO-05 Consent and privacy notice management procedure
• GOV-PRO-06 Supplier and third party security procedure
• GOV-PRO-26 Cloud services security procedure
• GOV-PRO-25 Legal, regulatory and contractual compliance procedure
• GOV-POL-05 Remote and mobile working policy
• GDPR-REG-02 Data flow and transfer map

Determining controller and processor roles

The test applied to every processing activity and every counterparty to decide whether [Organisation] acts as controller, joint controller or processor, how the decision is recorded, and what obligations follow from it.

Serves: ISO/IEC 27701 clause 5.2.1; ISO/IEC 27701 clause 7.2.6; ISO/IEC 27701 clause 7.2.7; ISO/IEC 27701 clause 8.2.1; ISO/IEC 27701 Annex A 7.2.7; ISO/IEC 27701 Annex B 8.2.1; GDPR Article 4; GDPR Article 26; GDPR Article 28. Owner: Privacy Officer.

1. Purpose

This procedure makes the role decision explicit and recorded, because the role decides which obligations apply: a controller answers to individuals and the supervisory authority for the whole processing, a processor answers to the controller for following instructions, and joint controllers must agree who does what. Getting the role wrong leaves obligations unowned.

2. Scope

It applies to every processing activity in PIMS-REG-01, every supplier that receives personal data, every client contract under which [Organisation] receives personal data, every group company arrangement and every data sharing agreement, from the first proposal until the processing ends.

3. Roles and responsibilities

4. Procedure

4.1 Trigger. The Processing Owner, supplier owner or account lead asks the Privacy Officer for a role decision when a processing activity is proposed, when a supplier or client arrangement involving personal data is proposed, when the purpose or the parties of an existing activity change, and at the annual review of PIMS-REG-01. No personal data flows under a new arrangement until the decision is recorded.

4.2 Facts gathered. The requester provides, in writing: the parties involved, who initiated the processing, what each party gets out of it, which party chose the data items, the individuals concerned, the retention period and the recipients, which party could stop the processing, and whether any party may use the data for anything of its own.

4.3 The decision test. The Privacy Officer answers five questions for each party.

Three or more answers in the controller column make the party a controller. A party that decides the purpose is always a controller, however the other answers fall. A party that processes only within another party's documented instructions, decides nothing essential and gains nothing beyond its fee is a processor.

4.4 Joint controllership. Where two or more parties are controllers of the same processing, the Privacy Officer asks whether they decided the purposes and means together, including the case where each party's decision depends on the other's so that the processing could not happen without both. If so they are joint controllers and an arrangement is required. If each party pursues its own purpose with its own means on the same data, they are independent controllers and a data sharing agreement is used instead.

4.5 Recurring cases. The Privacy Officer applies the test, not a label, but records the usual outcome for recurring patterns in a short table kept with this procedure: cloud hosting and software providers acting on instruction (processor); payroll providers and benefits administrators (usually processor); professional advisers, auditors and regulators using data for their own professional duties (controller); payment and banking services (usually controller); staff augmentation working under [Organisation]'s direction (part of [Organisation], not a separate party); a group company providing a shared service to other group companies (processor for that service); a client that sends personal data for [Organisation] to deliver a service (client is controller, [Organisation] is processor); a client that buys data [Organisation] collected for its own purposes (both controllers). A pattern never overrides facts that point the other way.

4.6 Documenting the decision. The Privacy Officer records in PIMS-REG-01 the role for each processing activity and, in a note on the row, the reasoning in no more than three sentences and the date. For a supplier the role is also recorded in PIMS-REG-06 and the processor terms flag in GOV-REG-07. For a client contract the role is recorded in the contract summary held by the account lead and in PIMS-REG-01.

4.7 Consequences for [Organisation] as controller. The Processing Owner applies the full set: a lawful basis and a notice (PIMS-PRO-05), inventory entry (PIMS-REG-01), impact assessment screening (PIMS-PRO-02), rights handling (PIMS-PRO-03), breach notification to the authority and individuals (PIMS-PRO-04), processor terms with every processor (PIMS-TPL-02), transfer mechanisms (PIMS-POL-03) and retention (PIMS-POL-02).

4.8 Consequences for [Organisation] as processor. The Processing Owner applies: processing only on the controller's documented instructions and flagging any instruction that appears unlawful; confidentiality commitments from staff; the security measures in the agreement; no sub-processor without the controller's authorisation and no change without notice (PIMS-REG-06); assistance with rights requests, security, breaches and assessments; notification of breaches to the controller without undue delay (PIMS-PRO-04); deletion or return at the end of the service; processor records in PIMS-REG-01; and making information available for the controller's audits. [Organisation] does not use the data for its own purposes, including product improvement, analytics or marketing, unless the agreement allows it and [Organisation] becomes a controller for that use.

4.9 Consequences for joint controllers. The Privacy Officer agrees a written arrangement with the other controllers that allocates the notice, the rights handling, the breach notification, the contact point for individuals and the record keeping, and makes the essence of the arrangement available to individuals through the notice. Each controller remains answerable to individuals regardless of the allocation.

4.10 Contract alignment. The legal adviser confirms before signature that the contract wording matches the decided role: processor terms based on PIMS-TPL-02 for a processor, a joint controller arrangement for joint controllers, a data sharing agreement for independent controllers. A contract that labels a party a processor while the facts make it a controller is corrected, not signed.

4.11 Disputed cases. Where the counterparty disagrees with the role decision, the Privacy Officer records both positions and the reasons, and the legal adviser decides. Until the dispute is settled, [Organisation] applies the controller obligations, which are the wider set.

4.12 Re-assessment. The decision is re-assessed when the purpose, the parties, the data items or the benefit to any party changes, when a processor starts using data for its own ends, and at the annual inventory review under GDPR-PRO-01. A changed decision is recorded with the date and triggers a contract review within thirty days.

5. Records and evidence

• PIMS-REG-01 Personal data processing inventory: the role column and the reasoning note on each row.
• PIMS-REG-06 Processor and sub-processor register and GOV-REG-07 Supplier register entries.
• Signed processor terms, joint controller arrangements and data sharing agreements.
• The recurring-case table kept with this procedure, with the date of its last review.

6. Exceptions

No exception applies. A processing activity without a recorded role is not started, and an existing one found without a role is assessed within five working days of discovery.

7. Review and maintenance

The Privacy Officer reviews this procedure annually, after guidance from a supervisory authority or a court decision that changes how roles are assessed, and after any dispute under step 4.11. Changes follow GOV-PRO-01.

8. Related documents

• PIMS-POL-01 Privacy information management policy
• PIMS-REG-01 Personal data processing inventory
• PIMS-REG-06 Processor and sub-processor register
• PIMS-TPL-02 Data processing agreement template
• GOV-PRO-06 Supplier and third party security procedure
• GOV-REG-07 Supplier register
• GDPR-PRO-01 Data mapping and records of processing procedure
• GDPR-TPL-09 Supplier GDPR assessment questionnaire

Privacy risk and data protection impact assessment procedure

How every new or changed processing activity is screened for privacy risk, when a full data protection impact assessment is required, how risks to individuals are scored and treated, who approves the residual risk, and when the supervisory authority is consulted first.

Serves: ISO/IEC 27701 clause 7.2.5; ISO/IEC 27701 clause 5.4.1.2; ISO/IEC 27701 Annex A 7.2.5; GDPR Article 35; GDPR Article 36. Owner: Privacy Officer.

1. Purpose

This procedure finds the harm a processing activity could do to the individuals concerned before the activity starts, reduces that harm by design, and records the decision so that [Organisation] can show it considered the risk. It also satisfies the legal duty to assess, and where necessary consult the authority about, processing likely to result in a high risk.

2. Scope

It applies to every new processing activity, every significant change to an existing one (new purpose, new data items, new individuals, new technology, new recipient, new country), every system or feature that handles personal data, and every procurement of a service that will process personal data. It applies whether [Organisation] is controller or processor; as a processor [Organisation] assists the controller's assessment rather than approving its own.

3. Roles and responsibilities

4. Procedure

4.1 Screening at concept stage. Before design approval, the Processing Owner completes section 1 of PIMS-TPL-01, answering each screening trigger Yes or No with one line of justification, and sends it to the Privacy Officer. The triggers are:

1. evaluation or scoring of individuals, including profiling and prediction of behaviour, location, health, interests or reliability;
2. decisions made about individuals by automated means that have legal or similarly significant effects;
3. systematic monitoring of individuals, including monitoring of a publicly accessible area, employee monitoring and tracking of location or online behaviour;
4. special categories of data, criminal offence data or data of a highly personal nature such as financial detail or private communications;
5. processing on a large scale, judged by the number of individuals, the volume and range of data, the duration and the geographical extent;
6. matching or combining data sets from different sources or collected for different purposes;
7. data about individuals who may be vulnerable or have little choice, including children, patients, employees and applicants;
8. use of new or innovative technology, including machine learning, biometrics, connected devices and AI features;
9. processing that could deny individuals a service, a contract, a benefit or access, or could lead to discrimination, exclusion or physical harm;
10. data obtained without the individuals' direct involvement where a notice is impractical;
11. transfer of personal data outside the region where [Organisation] is established;
12. any processing type that the supervisory authority has listed as requiring an assessment, as recorded in GOV-REG-04.

4.2 Screening decision. Within five working days the Privacy Officer records the outcome in PIMS-REG-08. A full assessment is required when two or more triggers apply, when trigger 2, 4 or 12 applies on its own, or when the Privacy Officer judges any single trigger to carry a high risk. A decision that no assessment is required is recorded with reasons, and the processing still passes the privacy by design review in PIMS-PRO-06.

4.3 Stage gates. A required assessment advances through four gates, each recorded in PIMS-REG-08: gate 1, description and necessity complete before build starts; gate 2, risks scored and measures agreed before the go-live gate in PB-07; gate 3, residual risk approved before any personal data is processed in production; gate 4, review at the interval in step 4.11. A project does not pass a gate on a promise; a measure not yet built is a To confirm item with an owner and a due date.

4.4 Description of the processing. The Processing Owner completes section 2 of PIMS-TPL-01: nature (how data is collected, used, stored, shared and deleted, with a data flow referenced in GOV-REG-25 or GDPR-REG-02), scope (data items, special categories, volume, individuals, retention, geography), context (relationship with the individuals, their expectations, prior concerns, technology novelty) and purposes (the benefit to [Organisation], to the individuals and to others).

4.5 Necessity and proportionality. The Processing Owner and the Privacy Officer record in section 3 why the purpose cannot be achieved with less data or less intrusion, the lawful basis, how each principle in PIMS-POL-01 is met, the alternatives considered and rejected, how individuals are informed and how they exercise rights, the processors involved and the transfer mechanism.

4.6 Consultation. The Privacy Officer decides who is consulted and records it in section 4: the Information Security Manager always; the individuals or their representatives, through user research, a survey, a works council or a client advisory group, unless the Privacy Officer records why that is not practicable; processors, for the measures they operate; and the legal adviser where the lawful basis or a transfer is in question. Views received, and whether they changed the design, are recorded.

4.7 Identifying risks to individuals. The project team lists risks from the individual's point of view, not the organisation's: loss of control over their data, unauthorised disclosure, re-identification, inaccurate data leading to a wrong decision, discrimination, financial loss, identity theft, reputational damage, physical danger, loss of a service, distress, and inability to exercise rights. Each risk names its source (an event, an actor or a design weakness).

4.8 Scoring. Each risk is scored on the 1 to 5 likelihood scale in GOV-PRO-05 and on a severity scale for individuals: 1 negligible (inconvenience, easily overcome); 2 limited (annoyance, minor cost, short-lived); 3 significant (real difficulty, financial loss, distress, recoverable with effort); 4 severe (lasting harm, serious financial or psychological consequence, hard to recover from); 5 critical (danger to life, irreversible harm, loss of liberty). Score is likelihood multiplied by severity, banded as in GOV-PRO-05: 1 to 4 low, 5 to 9 medium, 10 to 15 high, 16 to 25 critical.

4.9 Measures and residual risk. For every risk at medium or above the team records the measures that remove the source, reduce likelihood or reduce severity (less data, pseudonymisation, encryption, access limits, shorter retention, transparency, human review, opt-out, contractual terms), the owner and the date. The risk is re-scored after the measures. Every measure becomes a backlog item or a contract clause, and every medium or higher residual risk also appears in GOV-REG-05 with a cross-reference to the assessment.

4.10 Approval of residual risk. Residual low or medium is approved by the Processing Owner with the Privacy Officer's written agreement. Residual high is approved only by the Chief Executive Officer after written advice from the Privacy Officer, and is reviewed every six months. Residual critical is not approved; the processing is redesigned or abandoned. The approval, the approver and the date are recorded in section 7 of PIMS-TPL-01 and in PIMS-REG-08.

4.11 Prior consultation with the supervisory authority. Where a residual high risk cannot be reduced further, the Privacy Officer prepares a consultation containing the assessment, the roles of the parties, the purposes, the measures and the Privacy Officer's contact details, and submits it to the authority. The processing does not start until the authority responds or the period set by law expires without a response. The Chief Executive Officer decides whether to consult or to abandon the processing.

4.12 Review. The Processing Owner reviews a completed assessment annually where residual risk is high, every two years otherwise, and immediately when a change in step 2 occurs, a breach affects the processing, a complaint is received about it, or the law or authority guidance changes. The review outcome is recorded even when nothing changes.

4.13 Processor assistance. Where [Organisation] is a processor, the Processing Owner supplies the controller, within the time in the agreement, with the description of the processing, the security measures and the sub-processors involved, and implements the measures the controller's assessment requires.

5. Records and evidence

• PIMS-REG-08 DPIA register: every screening outcome and every assessment with its gate dates, residual rating, approver and next review.
• Completed PIMS-TPL-01 documents, stored with the project record and retained for the life of the processing plus the period in PIMS-REG-07.
• GOV-REG-05 entries for medium and higher residual risks; backlog items and contract clauses for measures.
• Consultation records and any correspondence with the supervisory authority.

6. Exceptions

An activity may start before gate 3 only in a declared Severity 1 or 2 incident under GOV-PRO-07 where the processing is needed to contain harm, and then only with the Privacy Officer's recorded agreement; the assessment is completed within ten working days afterwards. No other exception applies.

7. Review and maintenance

The Privacy Officer reviews this procedure annually, after any prior consultation, after new authority guidance on assessments, and after an audit finding. Changes follow GOV-PRO-01.

8. Related documents

• PIMS-TPL-01 Data protection impact assessment template
• PIMS-REG-08 DPIA register
• PIMS-POL-01 Privacy information management policy
• PIMS-PRO-06 Privacy by design and by default procedure
• GOV-PRO-05 Risk assessment and treatment methodology
• GOV-REG-05 Information security risk register
• GOV-REG-25 Data flow and interface inventory
• GDPR-REG-02 Data flow and transfer map
• PB-07 Playbook: the go-live security and privacy gate for a software project
• AI-PRO-01 AI risk assessment procedure

Data subject rights handling procedure

How a request from an individual about their personal data is received, verified, logged, answered within one month and recorded, right by right, including when a request may be refused and what [Organisation] does when it is a processor.

Serves: ISO/IEC 27701 clause 7.3.1; ISO/IEC 27701 clause 7.3.6; ISO/IEC 27701 clause 7.3.9; ISO/IEC 27701 clause 8.3.1; ISO/IEC 27701 Annex A 7.3.5; ISO/IEC 27701 Annex A 7.3.6; ISO/IEC 27701 Annex A 7.3.7; ISO/IEC 27701 Annex A 7.3.8; ISO/IEC 27701 Annex A 7.3.9; ISO/IEC 27701 Annex A 7.3.10; ISO/IEC 27701 Annex B 8.3.1; GDPR Article 12; GDPR Article 15; GDPR Article 16; GDPR Article 17; GDPR Article 18; GDPR Article 20; GDPR Article 21; GDPR Article 22. Owner: Privacy Officer.

1. Purpose

This procedure gets every request from an individual answered correctly and on time, by named people following the same steps, so that individuals get what the law gives them and [Organisation] can prove it.

2. Scope

It applies to every request, however phrased and through whatever channel, in which an individual asks about or wants something done with personal data that [Organisation] holds about them as a controller: access, rectification, erasure, restriction, portability, objection, review of an automated decision and withdrawal of consent. It also sets what [Organisation] does with a request it receives as a processor.

3. Roles and responsibilities

4. Procedure

4.1 Intake. Requests arrive through the privacy mailbox and web form published in the notice, by post, through customer support, through account managers, through Human Resources, or verbally to any employee. Every channel counts. A request made verbally is written down by the person who received it, with the date, and confirmed back to the individual. A request does not have to cite the law or use any particular words.

4.2 Logging. The request handler records the request in PIMS-REG-02 within one working day of receipt: date received, channel, requester type, the rights exercised, and the clock start. The one month period runs from the day of receipt and ends on the same date of the following month, or the last day of that month if there is no such date.

4.3 Identity verification. The handler confirms identity in proportion to the sensitivity of the data. Where the individual writes from the contact details held on their account, or is signed in to their account, no further proof is requested. Otherwise the handler asks, within three working days and using the GDPR-TPL-05 verification letter, for the minimum extra information that confirms identity, and records in PIMS-REG-02 the date it arrives; the period then runs from that date. Identity documents received are deleted once checked. A request made by a representative is honoured only with written authority from the individual.

4.4 Acknowledgement and scope. Within three working days of logging, the handler sends the GDPR-TPL-05 acknowledgement with the expected response date. Where the request is broad, the handler may ask the individual to clarify what they want, without stopping the clock; if no answer arrives within ten working days the handler responds to the request as reasonably understood.

4.5 Extension. Where the request is complex or the individual has made several, the Privacy Officer may extend the period by up to two further months. The extension and its reasons are sent to the individual before the first month ends, using the GDPR-TPL-05 extension letter, and are recorded in PIMS-REG-02.

4.6 Locating the data. The handler identifies every system and processor that may hold the individual's data from PIMS-REG-01 and PIMS-REG-06, instructs each System Owner and processor in writing with a deadline of no more than ten working days, and records the confirmations. Searches cover primary systems, support tools, email and messaging where the individual is a subject, derived data, and backups where restorable within the period.

4.7 Handling each right.

4.8 Refusal and limitation. A request is refused or limited only on a ground the Privacy Officer confirms in writing: the request is manifestly unfounded or excessive, in particular because it repeats a recent request; the data is covered by an exemption in the law recorded in GOV-REG-04; or disclosure would adversely affect the rights of another person. The refusal letter in GDPR-TPL-05 states the reasons, the right to complain to the supervisory authority and the right to seek a judicial remedy, and is sent within the period. A partial refusal still answers the rest of the request.

4.9 Fees. Responses are free. A reasonable fee covering administrative cost is charged only for further copies or for a request the Privacy Officer has recorded as manifestly unfounded or excessive, and the individual is told the fee before work continues.

4.10 Response. The handler sends the response using the GDPR-TPL-05 response letter through a channel that matches the sensitivity of the content: the account portal, encrypted file transfer or password-protected archive with the password sent separately. Paper responses go by tracked post. The response is written in plain language and, where the individual is a child, in language a child can understand.

4.11 Requests received as a processor. Where the request concerns data [Organisation] processes for a client, the handler forwards it to the client within two working days, tells the individual that it has been passed to the controller, takes no other action unless the client instructs it, and records it in PIMS-REG-02 with the client named. Assistance requested by the client is provided within the time in the agreement.

4.12 Closure and records. The handler records in PIMS-REG-02 the outcome, the date closed and whether the deadline was met, and files the correspondence and the search confirmations with the request. Request records are retained for the period in PIMS-REG-07. A complaint about the handling is recorded and reviewed by the Privacy Officer within five working days.

4.13 Monitoring. The Privacy Officer reports the number of requests, the proportion answered on time, extensions, refusals and complaints quarterly under PIMS-PRO-07. Two late responses in a quarter raise a corrective action in GOV-REG-03.

5. Records and evidence

• PIMS-REG-02 Data subject request register: every request with dates, rights, handler, outcome and timeliness.
• The correspondence for each request, including GDPR-TPL-05 letters sent and identity verification records.
• Written confirmations from System Owners and processors for each search, correction, restriction or deletion.
• Privacy Officer decisions on extensions, refusals, fees and objections, with reasons.

6. Exceptions

Where a search cannot be completed within the extended period because data is held in an archive that cannot be restored in time, the handler provides everything found, states what remains outstanding and when it will follow, and the Privacy Officer records the case. No other exception applies.

7. Review and maintenance

The Privacy Officer reviews this procedure annually, after any complaint to a supervisory authority about request handling, after a change in law or authority guidance on rights, and after a new system or processor changes where personal data is held. Changes follow GOV-PRO-01.

8. Related documents

• GDPR-TPL-05 Data subject request response letters
• PIMS-REG-02 Data subject request register
• PIMS-REG-01 Personal data processing inventory
• PIMS-REG-06 Processor and sub-processor register
• PIMS-PRO-05 Consent and privacy notice management procedure
• PIMS-POL-02 Data retention and disposal policy
• GDPR-TPL-07 Legitimate interests assessment template
• PIMS-PRO-07 Privacy control effectiveness monitoring procedure

Personal data breach assessment and notification procedure

What happens from the moment an incident is found to involve personal data: the 72 hour clock, the assessment of risk to individuals, the decision whether to notify the supervisory authority and the individuals, the processor duty to tell the controller, and the record kept whether or not anyone is notified.

Serves: ISO/IEC 27701 clause 6.13.1.1; ISO/IEC 27701 clause 6.13.1.5; ISO/IEC 27701 Annex B 8.2.5; GDPR Article 33; GDPR Article 34. Owner: Privacy Officer.

1. Purpose

This procedure turns an incident involving personal data into a documented assessment and, where required, a notification made within the legal deadline, so that individuals can protect themselves, the authority is told what the law requires, and [Organisation] can show its reasoning afterwards.

2. Scope

It applies to every breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data that [Organisation] holds as controller or processor, including breaches at a processor or sub-processor. It runs alongside GOV-PRO-07, which handles the technical response; this procedure handles the assessment, the notification decisions and the privacy record.

3. Roles and responsibilities

4. Procedure

4.1 Trigger and time of awareness. GOV-PRO-07 step 4.4 triggers this procedure. The Incident Lead records the time at which [Organisation] became aware, meaning the time at which a person in [Organisation] had a reasonable degree of certainty that a breach of personal data had occurred, not the time the investigation finished. For a breach reported by a processor, awareness is the time the processor's report is received. The 72 hour clock runs from this time, including outside working hours.

4.2 Register entry. Within two hours of the trigger the Privacy Officer opens an entry in PIMS-REG-03 with the GOV-REG-08 reference, the time of awareness and the 72 hour deadline, and sets the status to Under assessment.

4.3 Facts within 24 hours. The Privacy Officer obtains from the Incident Lead and the Processing Owner, within 24 hours of awareness: what happened and how; whether the breach affects confidentiality, integrity, availability or several; the categories and approximate number of individuals and of records; whether special categories, financial data, credentials or children's data are involved; whether the data was encrypted or pseudonymised and whether the keys are safe; who received or could access the data and whether it has been recovered; whether the breach is ongoing; and which processing activities in PIMS-REG-01 are affected. Facts not yet known are recorded as unknown with the time they are expected.

4.4 Role check. For each affected data set the Privacy Officer confirms from PIMS-REG-01 whether [Organisation] is controller or processor. A single incident can put [Organisation] in both roles for different data; each role follows its own path below.

4.5 Processor path. Where [Organisation] is a processor, the Privacy Officer notifies each affected controller without undue delay and in any case within the time in the agreement, or within 24 hours of awareness where no time is agreed, using the contact in PIMS-REG-06 or the contract. The notification gives the facts known, states what is still being established, and promises updates at the agreed cadence. [Organisation] does not notify the authority or the individuals for the controller's data unless the controller instructs it in writing, and gives the controller the assistance it needs to meet its own deadline.

4.6 Risk assessment to individuals. Where [Organisation] is a controller, the Privacy Officer assesses the risk to the individuals using the likelihood and severity scales in PIMS-PRO-02 step 4.8, considering: the type of breach; the nature, sensitivity and volume of the data; how easily individuals can be identified; the severity of the consequences (identity theft, fraud, financial loss, discrimination, reputational damage, physical harm, distress, loss of control); whether the individuals are vulnerable; the number affected; the nature of the recipient, if known; and the measures already in place, such as encryption with uncompromised keys, or taken since, such as recovery of the data before it was read. The outcome is one of three: risk unlikely, risk likely, high risk likely.

4.7 Decision table. The Privacy Officer applies the table within 48 hours of awareness and records the decision, the reasoning and the legal adviser's confirmation in PIMS-REG-03.

4.8 Notification to the authority. The Privacy Officer completes GDPR-TPL-10 with the nature of the breach, the categories and approximate numbers of individuals and records, the contact point, the likely consequences and the measures taken or proposed, informs the Chief Executive Officer, and submits it through the authority's published channel within 72 hours of awareness. Where the facts are incomplete, the notification is made in phases: the initial notification within 72 hours with what is known, and further information as soon as it is available. A notification made after 72 hours states the reasons for the delay. Where individuals in more than one jurisdiction are affected, the legal adviser identifies the lead authority and any further authorities from GOV-REG-04.

4.9 Notification to individuals. Where high risk is likely, the Privacy Officer drafts a notice in plain language stating what happened, the contact point, the likely consequences, the measures [Organisation] has taken and the steps individuals can take to protect themselves. The Chief Executive Officer approves it and the communications lead sends it directly to each individual by the most reliable channel available. Direct notification may be replaced by a public communication only where the Privacy Officer records that one of these applies: the data was made unintelligible to any unauthorised person, for example by encryption with keys not compromised; measures taken since mean the high risk is no longer likely to materialise; or individual contact would involve disproportionate effort. The authority may require notification even where [Organisation] decided against it.

4.10 Other notifications. The Privacy Officer and legal adviser check GOV-REG-07 for clients with contractual notification rights, GOV-REG-04 for other regulators and sector obligations, the insurance policy for its notification time, and decide with the Incident Lead whether law enforcement is informed. Each is recorded in PIMS-REG-03.

4.11 Record keeping. Every breach, notified or not, is recorded in PIMS-REG-03 with the facts, the effects, the measures taken, the assessment outcome and the reasoning behind each decision. The record is retained for the period in PIMS-REG-07 and is available to the authority on request.

4.12 Review and corrective action. The post-incident review under GOV-PRO-07, using GOV-TPL-11, includes the Privacy Officer and covers whether the time of awareness was set correctly, whether the deadlines were met and whether the notifications were adequate. Corrective actions go to GOV-REG-03; the affected risks in GOV-REG-05 and any assessment in PIMS-REG-08 are updated within thirty days.

4.13 Timeline summary. From awareness: register entry within 2 hours; facts within 24 hours; processor notification to controller within the agreed time or 24 hours; decision within 48 hours; authority notification within 72 hours; individuals without undue delay once high risk is established; post-incident review within ten working days of closure.

5. Records and evidence

• PIMS-REG-03 Personal data breach register: one entry per breach with the times, the assessment, the decisions and their reasoning.
• GOV-REG-08 Incident register entry and GOV-TPL-05 incident report for the technical response.
• Completed GDPR-TPL-10 forms, authority acknowledgements and correspondence.
• Notices sent to individuals and controllers, with the approval record and the distribution evidence.
• GOV-TPL-11 post-incident review and GOV-REG-03 corrective actions.

6. Exceptions

No exception applies to the deadlines. Where a deadline is missed, the reasons are recorded in PIMS-REG-03 and in the notification itself, and the miss is reported at the next management review.

7. Review and maintenance

The Privacy Officer reviews this procedure annually, after every breach notified to an authority, after an annual breach exercise run with GOV-PRO-13, and after a change in notification law or authority guidance. Changes follow GOV-PRO-01.

8. Related documents

• GOV-PRO-07 Information security incident management procedure
• GOV-REG-08 Incident register
• GOV-TPL-05 Incident report form
• GOV-TPL-11 Post-incident review template
• GDPR-TPL-10 Personal data breach notification form
• PIMS-REG-03 Personal data breach register
• PIMS-REG-01 Personal data processing inventory
• PIMS-REG-06 Processor and sub-processor register
• PIMS-TPL-02 Data processing agreement template
• ISMS-PLN-02 Communication plan

Consent and privacy notice management procedure

When consent is the right basis, what makes it valid, how it is captured, recorded and withdrawn, what every privacy notice must contain and when it must be shown, and how notices are changed under control.

Serves: ISO/IEC 27701 clause 7.2.3; ISO/IEC 27701 clause 7.2.4; ISO/IEC 27701 clause 7.3.2; ISO/IEC 27701 clause 7.3.3; ISO/IEC 27701 clause 7.3.4; ISO/IEC 27701 Annex A 7.2.3; ISO/IEC 27701 Annex A 7.2.4; ISO/IEC 27701 Annex A 7.3.2; ISO/IEC 27701 Annex A 7.3.3; ISO/IEC 27701 Annex A 7.3.4; GDPR Article 7; GDPR Article 12; GDPR Article 13; GDPR Article 14. Owner: Privacy Officer.

1. Purpose

This procedure makes consent provable and notices accurate. A consent that cannot be shown to have been given freely, specifically and knowingly is no basis at all, and a notice that does not match what actually happens to the data is a transparency failure that every other control inherits.

2. Scope

It applies to every processing activity in PIMS-REG-01 where [Organisation] is a controller, to every point at which personal data is collected from or about an individual, to every privacy notice, cookie notice and consent form published by [Organisation], and to the systems that record consent and withdrawal.

3. Roles and responsibilities

4. Procedure

4.1 Choosing the basis. For each purpose the Processing Owner proposes a lawful basis and the Privacy Officer confirms it in PIMS-REG-01. Consent is used only where the individual has a genuine choice and can refuse or withdraw without detriment. It is not used for processing needed to deliver a contract, to meet a legal obligation, or that [Organisation] would carry out regardless of the answer. For employees and applicants consent is used only for genuinely optional matters, such as a voluntary benefit, because the imbalance of power makes other consent unreliable. Where legitimate interests are proposed, GDPR-TPL-07 is completed first.

4.2 Conditions for valid consent. A consent capture approved under this procedure meets all of these: the request is separate from other terms and written in plain language; the purpose is specific, and each distinct purpose has its own choice; the individual is told who is asking, what data, for what purpose, that they can withdraw at any time and how, and what happens if they refuse; consent is given by a clear affirmative act, never by a pre-ticked box, silence, inactivity or continued use; refusing has no effect on the service beyond the part that depends on the consent; and withdrawing is as easy as giving. For special categories the consent is explicit: a statement or a ticked statement that names the category and the purpose. For children below the age set in GOV-REG-04 for the jurisdiction, consent is given or authorised by the holder of parental responsibility, verified in proportion to the risk.

4.3 Designing a capture point. Before a capture point goes live the Processing Owner records it in PIMS-REG-04 with the purpose, the audience, the mechanism, the notice version shown, the consent wording version, where the records are stored and the withdrawal method, and obtains the Privacy Officer's approval. Forms are based on GDPR-TPL-06. Cookie and tracker consent follows GDPR-TPL-04 and the inventory in GDPR-REG-04, with non-essential trackers blocked until consent is given.

4.4 Recording consent. The system records, for each consent: who gave it, when, through which capture point, the version of the notice and of the wording shown, which purposes were accepted and which refused, and the evidence of the affirmative act. Records are kept in the system of record for the life of the processing plus the period in PIMS-REG-07, protected against alteration, and exportable for a request under PIMS-PRO-03 or an authority enquiry. A consent whose record cannot be produced is treated as not given.

4.5 Withdrawal. Withdrawal is available through at least the channel through which consent was given, and always through the privacy mailbox. The Processing Owner actions a withdrawal within two working days, and for marketing within 72 hours: processing for that purpose stops, the suppression is applied so that the individual is not re-added by a later import, processors are instructed within the same time, and the data is deleted under PIMS-POL-02 unless another recorded basis applies to it. The withdrawal is recorded with the date and confirmed to the individual. Processing that took place before withdrawal remains lawful.

4.6 Refreshing consent. The Processing Owner reviews each capture point every twelve months and records it in PIMS-REG-04. Consent is obtained again when the purpose, the data or the recipients change materially, when the wording that was shown would no longer meet step 4.2, and for marketing where there has been no contact for [Number] months.

4.7 Notice content. Every notice covers, for data collected from the individual: the identity and contact details of [Organisation] and of the Privacy Officer; each purpose and its lawful basis; the legitimate interests relied on; the recipients and categories of recipients; transfers outside the region and the safeguard used; the retention period or the criteria that set it; the rights, including withdrawal of consent and the right to complain to the supervisory authority; whether providing the data is a legal or contractual requirement and what happens if it is not provided; and the existence, logic and significance of any automated decision making. For data not collected from the individual the notice also states the categories of data and their source. The templates GDPR-TPL-01, GDPR-TPL-02, GDPR-TPL-03 and GDPR-TPL-04 contain these elements.

4.8 Notice timing. A notice is provided at the point of collection where data comes from the individual, with a layered summary at the form and the full notice one step away. Where data comes from elsewhere, the notice is provided within one month, or at the first communication with the individual, or before the first disclosure to another recipient, whichever is earliest, unless the Privacy Officer records that the individual already has the information or that providing it is impossible or would involve disproportionate effort, in which case the information is published instead.

4.9 Notice form. Notices are written in plain language, structured under headings that match the content list, readable on a small screen, available in the languages [Organisation] serves its individuals in, and in language a child can understand where children are the audience. Each notice shows its version and effective date, and every previous version is retained.

4.10 Notice change control. A change to a notice is drafted by the Privacy Officer from a change in PIMS-REG-01, PIMS-REG-05 or PIMS-REG-06, reviewed by the legal adviser, approved by the Privacy Officer and published under GOV-PRO-01 with a new version number. A change that adds a purpose, a recipient, a transfer or a longer retention is communicated to the affected individuals before it takes effect, through the channel in ISMS-PLN-02, and consent is obtained again where the change affects a consented purpose. Notice versions are listed in GOV-REG-01.

4.11 Annual check. Once a year the Privacy Officer compares every published notice against PIMS-REG-01, PIMS-REG-05, PIMS-REG-06 and GDPR-REG-04, samples consent records from each capture point, tests a withdrawal end to end, and records the results in PIMS-REG-04. A notice that does not match the registers is corrected within thirty days and the gap is recorded in GOV-REG-03.

5. Records and evidence

• PIMS-REG-04 Consent record register: every capture point with its versions, record location, checks and status.
• Consent records in the systems of record, exportable per individual.
• Published notices with version history and approval records in GOV-REG-01.
• GDPR-REG-04 Cookie and tracker inventory and the consent configuration of the website.
• Withdrawal confirmations and suppression list exports.

6. Exceptions

A capture point may go live with a notice summary rather than the full notice only where the full notice is reachable from it in one step. No exception applies to the conditions in step 4.2.

7. Review and maintenance

The Privacy Officer reviews this procedure annually, after a complaint about consent or transparency, after authority guidance on consent or cookies, and after a new product or channel starts collecting personal data. Changes follow GOV-PRO-01.

8. Related documents

• GDPR-TPL-01 Privacy notice template (customers and website)
• GDPR-TPL-02 Employee privacy notice template
• GDPR-TPL-03 Job applicant privacy notice template
• GDPR-TPL-04 Cookie and tracking technologies notice template
• GDPR-TPL-06 Consent form templates (customers and employees)
• GDPR-TPL-07 Legitimate interests assessment template
• GDPR-REG-04 Cookie and tracker inventory
• PIMS-REG-04 Consent record register
• PIMS-REG-01 Personal data processing inventory
• PIMS-PRO-03 Data subject rights handling procedure
• ISMS-PLN-02 Communication plan

Privacy by design and by default procedure

The checklist that every product, feature, system and procurement involving personal data passes through the development and purchasing lifecycle, so that minimisation, protective defaults, access limits, retention, transparency, security and rights support are built in rather than added later.

Serves: ISO/IEC 27701 clause 7.4.1; ISO/IEC 27701 clause 7.4.2; ISO/IEC 27701 clause 7.4.3; ISO/IEC 27701 clause 7.4.4; ISO/IEC 27701 clause 7.4.5; ISO/IEC 27701 clause 7.4.6; ISO/IEC 27701 clause 7.4.9; ISO/IEC 27701 clause 8.4.1; ISO/IEC 27701 Annex A 7.4.1; ISO/IEC 27701 Annex A 7.4.2; ISO/IEC 27701 Annex A 7.4.4; ISO/IEC 27701 Annex B 8.4.1; GDPR Article 25. Owner: Privacy Officer.

1. Purpose

This procedure puts privacy decisions at the points where they are cheap: in the backlog, the design review, the supplier selection and the go-live gate. It turns the principles in PIMS-POL-01 into checks with evidence, and makes the most protective setting the one an individual gets without doing anything.

2. Scope

It applies to every new product, feature, system, integration, report, internal tool and AI feature that processes personal data, to every significant change to one, and to every procurement of a service that will process personal data, whether [Organisation] is controller or processor. It works alongside GOV-PRO-15 for development, GOV-PRO-06 for suppliers, GOV-PRO-09 for changes and PB-07 for the go-live gate.

3. Roles and responsibilities

4. Procedure

4.1 Entry points. The procedure starts when: a product or feature involving personal data enters the backlog; a change request under GOV-TPL-08 answers Yes to personal data processing changed; a supplier is proposed under GOV-PRO-06 for a service that processes personal data; an AI feature or tool is proposed under AI-POL-02; or an existing system is found processing personal data without a record. The Product Owner opens a privacy review record with the project reference and the PIMS-REG-01 processing ID, new or existing.

4.2 Privacy requirements. At the same time as the security requirements in GOV-PRO-15 step 4.1, the Product Owner writes privacy requirements as backlog items with acceptance criteria: which data items are needed and why, the retention period and deletion mechanism, which settings are on by default, how individuals are informed, how each right is supported, and who may access what. The Privacy Officer screens the processing under PIMS-PRO-02 step 4.1 at this point.

4.3 The checklist. The team completes the checklist below at design and again before go-live, attaching evidence for each check. Each check is Verified, To confirm (with owner and date), Not implemented or Not applicable (with reason).

4.4 Registers updated. Before gate 2 of PIMS-PRO-02, or before go-live where no assessment is required, the Product Owner updates PIMS-REG-01 (purpose, basis, data, retention, recipients), GOV-REG-25 and GDPR-REG-02 (flows and interfaces), PIMS-REG-06 (processors) and PIMS-REG-05 (transfers), and records any new risk in GOV-REG-05.

4.5 Test data. Development, test and staging environments use synthetic or irreversibly masked data. A request to use production personal data outside production is an exception under GOV-PRO-24, approved by the Privacy Officer only with the same controls as production and a deletion date of no more than thirty days.

4.6 Procurement path. For a supplier service, the supplier owner applies the checklist to the service as offered, using GDPR-TPL-09 and the supplier's documentation and configuration options as evidence, records the result in the supplier assessment under GOV-PRO-06, and the Privacy Officer confirms processor terms based on PIMS-TPL-02 and a transfer mechanism under PIMS-POL-03 before any personal data is sent.

4.7 Default verification. Before go-live the System Owner creates a fresh account or tenant, records every privacy-relevant setting at its default, and attaches the record. A default that exposes data or enables optional processing without an affirmative act is a blocker at the gate in PB-07.

4.8 Go-live gate. The Privacy Officer reviews the completed checklist and the register updates at the gate in PB-07. Any Not implemented check in Minimisation, Defaults, Retention or Rights support stops production use of personal data until fixed; a To confirm item needs an owner and a date within thirty days; the review and its outcome are recorded on the privacy review record.

4.9 Operation and change. The checklist is repeated for a significant change under GOV-PRO-09 and at the assessment review in PIMS-PRO-02. New data items added through configuration, integrations or forms without a review are treated as a nonconformity under GOV-PRO-04.

4.10 Decommissioning. When a system or feature is retired, the System Owner exports what the schedule requires, deletes the rest under PIMS-POL-02, obtains deletion confirmation from processors, and the Product Owner sets the PIMS-REG-01 status to Ceased with the date.

5. Records and evidence

• The privacy review record for each project with the completed checklist, its evidence and the Privacy Officer's gate reviews.
• Updated rows in PIMS-REG-01, PIMS-REG-05, PIMS-REG-06, PIMS-REG-07, GOV-REG-25 and GDPR-REG-02.
• Default verification records and test data confirmations.
• GOV-REG-29 go-live checklist entries and GOV-TPL-12 verdict notes for the privacy area.

6. Exceptions

A check may be marked Not applicable only with a reason the Privacy Officer accepts. Production personal data in a non-production environment is permitted only under step 4.5. No other exception applies.

7. Review and maintenance

The Privacy Officer reviews this procedure annually, after a breach or complaint traced to a design decision, after a change in the development lifecycle under GOV-PRO-15, and after authority guidance on privacy by design. Changes follow GOV-PRO-01.

8. Related documents

• PIMS-POL-01 Privacy information management policy
• PIMS-PRO-02 Privacy risk and data protection impact assessment procedure
• PIMS-PRO-03 Data subject rights handling procedure
• PIMS-PRO-05 Consent and privacy notice management procedure
• PIMS-POL-02 Data retention and disposal policy
• PIMS-POL-03 International transfer policy
• GOV-PRO-15 Secure development lifecycle procedure
• GOV-PRO-06 Supplier and third party security procedure
• GOV-PRO-09 Change management procedure
• GOV-TPL-08 Change request form
• GDPR-TPL-09 Supplier GDPR assessment questionnaire
• PB-07 Playbook: the go-live security and privacy gate for a software project
• AI-POL-02 AI system development, procurement and deployment policy

Privacy control effectiveness monitoring procedure

The measures that show whether the privacy controls work, how they are collected and graded each quarter, the structure of the quarterly privacy report, and how the results reach the management review and the corrective action process.

Serves: ISO/IEC 27701 clause 5.7.1; ISO/IEC 27701 clause 5.7.3; ISO/IEC 27001:2022 clause 9.1; GDPR Article 24. Owner: Privacy Officer.

1. Purpose

This procedure replaces the feeling that privacy is under control with numbers that are collected the same way every quarter, graded against targets, and acted on. It gives the management review the privacy performance input it needs and gives the Privacy Officer early warning before a missed deadline becomes a regulatory matter.

2. Scope

It applies to every privacy procedure and register in the kit, to the ISO/IEC 27701 Annex A and Annex B controls marked applicable in ISMS-REG-01, and to the processing activities in PIMS-REG-01. It extends ISMS-PRO-04, which covers security measurement, and uses the same reporting cycle.

3. Roles and responsibilities

4. Procedure

4.1 The measure set. The Privacy Officer maintains the measures below in GOV-REG-21 with their targets. Each has a defined formula, a named source register and a frequency, so that two people computing it get the same number.

4.2 Collection. By the fifth working day after each quarter end, owners send the register exports and evidence named in the source column. The Privacy Officer computes each value, records it in GOV-REG-21 with the date and the export used, and files the exports under the evidence rules in PB-09 so that the Internal Auditor can recompute any value.

4.3 Sampling. Each quarter the Privacy Officer samples, in addition to the measures: five closed requests from PIMS-REG-02 for correctness of the response; every breach entry for the quality of the risk assessment; three processing activities from PIMS-REG-01 for a match between the notice, the inventory row and the system; and one withdrawal tested end to end. Sample results are recorded with the report.

4.4 Control effectiveness grades. For each applicable Annex A and Annex B control in ISMS-REG-01, the Privacy Officer records in ISMS-REG-02 a grade from the measures and samples that bear on it: Effective, the measures are at target and the sample found no exception; Largely effective, one measure is below target or one sample exception was found, with an action open; Partly effective, two or more measures are below target, a sample found a repeated exception, or any statutory deadline was missed; Not effective, the control is not operating or the exceptions are systemic. Partly effective and Not effective raise a corrective action in GOV-REG-03 within ten working days.

4.5 The quarterly privacy report. The Privacy Officer issues the report by the fifteenth working day after quarter end, with these sections: 1 Overall grade and the three things management must know; 2 Measures against targets with the trend over four quarters; 3 Breaches and incidents involving personal data, notifications made and lessons; 4 Requests from individuals, complaints and authority contact; 5 Assessments completed, overdue and the significant changes in processing; 6 Processors, sub-processor changes and transfers; 7 Training and awareness; 8 Audit findings, corrective actions and their status; 9 Risks changed in GOV-REG-05 and decisions required from management. The overall grade uses the scale in step 4.4 applied to the programme as a whole.

4.6 Distribution and action. The report goes to the Chief Executive Officer, the Information Security Manager and the steering committee under GOV-POL-01, and forms the privacy input to the management review under GOV-PRO-03, where decisions on resources and improvements are minuted in GOV-TPL-03 and tracked in GOV-REG-22.

4.7 Annual consolidation. The fourth quarter report includes the year's trend for every measure, the effectiveness grade for every applicable control, the outcome of the annual notice check under PIMS-PRO-05 and the annual retention sampling under PIMS-POL-02, and proposes targets for the following year for approval at the management review.

4.8 Changing the measure set. A measure is added, changed or retired by the Privacy Officer with the Information Security Manager's agreement, recorded in GOV-REG-21 with the reason, and never within a quarter already being reported, so that trends stay comparable.

5. Records and evidence

• GOV-REG-21 Security objectives and measures tracker: the privacy measures, their targets and each quarter's values.
• Quarterly privacy reports with the register exports and sample records behind them.
• ISMS-REG-02 Control implementation tracker: effectiveness grades for Annex A and Annex B controls.
• GOV-REG-03 Corrective action log entries raised from the grades.
• GOV-TPL-03 Management review minutes recording the privacy input and decisions.

6. Exceptions

A measure whose source register holds no items in the quarter is reported as Not applicable for that quarter with the reason, not as 100 percent. No other exception applies.

7. Review and maintenance

The Privacy Officer reviews this procedure annually at the fourth quarter consolidation, after a management review that changed the measure set, and after an audit finding about performance evaluation. Changes follow GOV-PRO-01.

8. Related documents

• ISMS-PRO-04 Monitoring, measurement, analysis and evaluation procedure
• GOV-REG-21 Security objectives and measures tracker
• ISMS-REG-01 Statement of Applicability
• ISMS-REG-02 Control implementation tracker
• GOV-PRO-03 Management review procedure
• GOV-PRO-04 Nonconformity and corrective action procedure
• GOV-REG-03 Corrective action log
• PB-09 Playbook: evidence management that survives an audit
• PIMS-POL-01 Privacy information management policy

Data protection impact assessment template

The form used under PIMS-PRO-02 to screen a processing activity, describe it, test its necessity, record consultation, score the risks to individuals before and after measures, and obtain approval of the residual risk.

Serves: GDPR Article 35; ISO/IEC 27701 clause 7.2.5; ISO/IEC 27701 Annex A 7.2.5. Owner: Privacy Officer.

Guidance notes are in italics. One assessment per processing activity or project. The reference is assigned by the Privacy Officer from PIMS-REG-08. Complete section 1 at concept stage; the remaining sections only when section 1 results in "assessment required". Write for a reader who was not in the project: an auditor or the supervisory authority may read this document.

1. Screening

2. Description of the processing

Describe what will actually happen to the data. Reference a data flow in GOV-REG-25 or GDPR-REG-02 rather than drawing a new one here.

3. Necessity and proportionality

4. Consultation

5. Risks to individuals

Write each risk from the individual's point of view. Score likelihood 1 to 5 and severity 1 to 5 as defined in PIMS-PRO-02 step 4.8. Score is likelihood multiplied by severity. Bands: 1 to 4 low, 5 to 9 medium, 10 to 15 high, 16 to 25 critical.

6. Measures and residual risk

One row per risk at medium or above. Each measure has an owner and a due date and exists as a backlog item, a configuration, a contract clause or a procedure. A measure not yet in place is To confirm until evidence is attached.

7. Approval and sign-off

8. Review log

9. Related documents

• PIMS-PRO-02 Privacy risk and data protection impact assessment procedure
• PIMS-REG-08 DPIA register
• PIMS-REG-01 Personal data processing inventory
• PIMS-PRO-06 Privacy by design and by default procedure
• GOV-PRO-05 Risk assessment and treatment methodology
• GOV-REG-05 Information security risk register
• GDPR-TPL-07 Legitimate interests assessment template
• GDPR-TPL-08 Transfer impact assessment template

Data processing agreement template

Plain-English processing terms, with placeholders, covering every element a contract between a controller and a processor must contain, for [Organisation] to use when it engages a processor or when it acts as a processor for a client, together with the three annexes that describe the processing, the security measures and the approved sub-processors.

Serves: GDPR Article 28; ISO/IEC 27701 clause 7.2.6; ISO/IEC 27701 clause 8.2.1; ISO/IEC 27701 Annex A 7.2.6; ISO/IEC 27701 Annex B 8.2.1; ISO/IEC 27701 Annex B 8.5.6; ISO/IEC 27701 Annex B 8.5.7. Owner: Privacy Officer.

Guidance notes are in italics. This template is a starting point for the legal adviser, not legal advice; the legal adviser confirms the wording against the law of each jurisdiction in GOV-REG-04 before signature. Use it in two directions: as the terms [Organisation] requires from a processor it engages, and as the terms [Organisation] offers when it is the processor. The word Controller below means the party that decides the purposes and means under PIMS-PRO-01, and Processor means the party that processes on the Controller's instructions. Where standard contractual clauses are needed for an international transfer under PIMS-POL-03, they are attached as a further annex and take precedence over any conflicting term here.

1. Parties and roles

1.1 These terms form part of the main agreement and apply whenever the Processor processes personal data on behalf of the Controller in performing it. If these terms conflict with the main agreement on the processing of personal data, these terms prevail.

1.2 The parties agree that, for the processing described in Annex 1, the Controller determines the purposes and means and the Processor acts only on the Controller's behalf. Each party remains responsible for its own compliance with the law that applies to it.

2. Definitions

2.1 Personal data, processing, data subject, personal data breach, supervisory authority and special categories have the meanings given to them in the data protection law that applies to the Controller, named in Annex 1.

2.2 Sub-processor means any third party engaged by the Processor to process personal data under these terms. Instructions means the Controller's written instructions, including the main agreement, Annex 1 and any later instruction given through the contact in section 1.

3. Subject matter, duration, nature and purpose

3.1 The subject matter, duration, nature and purpose of the processing, the types of personal data and the categories of data subjects are set out in Annex 1. The Processor processes personal data only to the extent and for the duration needed to provide the services.

3.2 The processing lasts for the term of the main agreement and for the deletion or return period in section 13 after it ends.

4. Instructions

4.1 The Processor processes personal data only on the Controller's documented instructions, including with regard to transfers to another country, unless the law that applies to the Processor requires otherwise. In that case the Processor tells the Controller of the legal requirement before processing, unless that law prohibits the notice on important grounds of public interest.

4.2 The Processor tells the Controller without delay if, in its opinion, an instruction infringes data protection law. The Processor may suspend the instruction concerned until the Controller confirms or withdraws it.

4.3 The Processor does not process personal data for its own purposes, including product improvement, analytics, marketing, profiling or the training of any model, unless Annex 1 expressly allows a specific use and the Controller has confirmed the lawful basis for it.

4.4 Instructions are given by the Controller's privacy contact or a person the Controller names in writing. The Processor may ask for an instruction to be confirmed in writing before acting.

5. Confidentiality

5.1 The Processor allows access to personal data only to people who need it to provide the services, who are bound by a written confidentiality obligation or a statutory duty of confidentiality, and who have received training in the protection of personal data.

5.2 The Processor keeps a record of the people and roles authorised to access the Controller's personal data and makes it available to the Controller on request.

6. Security

6.1 The Processor implements and maintains the technical and organisational measures in Annex 2, and any further measures needed to provide a level of security appropriate to the risk, taking into account the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing and the risks to individuals.

6.2 The Processor may update the measures in Annex 2 provided the level of protection does not fall below what Annex 2 provides, and gives the Controller notice of material changes.

6.3 The Processor assists the Controller in meeting the Controller's own security obligations, taking into account the nature of the processing and the information available to the Processor.

7. Sub-processors

7.1 The Processor engages a sub-processor only with the Controller's authorisation. The parties choose one of the following: [Specific authorisation: each sub-processor is approved in writing before engagement] or [General authorisation: the sub-processors in Annex 3 are approved, and the Processor gives the Controller at least [Number] days' written notice of any addition or replacement, during which the Controller may object on reasonable grounds relating to data protection].

7.2 Where the Controller objects under a general authorisation and the parties cannot resolve the objection within [Number] days, the Controller may terminate the affected services without penalty.

7.3 The Processor imposes on every sub-processor, by written contract, data protection obligations no less protective than these terms, in particular the security measures in Annex 2. The Processor remains fully liable to the Controller for the sub-processor's performance.

7.4 The Processor keeps Annex 3 current, including the location of each sub-processor's processing, and provides it to the Controller on request.

8. Assistance with the rights of individuals

8.1 The Processor assists the Controller, by appropriate technical and organisational measures and so far as possible, in responding to requests from individuals to exercise their rights, including access, rectification, erasure, restriction, portability, objection and the review of automated decisions.

8.2 The Processor forwards to the Controller, within [Number] working days of receipt, any request from an individual that concerns the Controller's personal data, and does not respond to the individual except to say the request has been passed to the Controller, unless the Controller instructs otherwise.

8.3 The Processor provides the assistance in section 8.1 within [Number] working days of the Controller's request, or sooner where the Controller's legal deadline requires it.

9. Assistance with assessments and consultation

9.1 The Processor assists the Controller with data protection impact assessments and with any prior consultation with a supervisory authority, by providing the information about the processing, the security measures and the sub-processors that the Controller reasonably requests, within [Number] working days.

10. Personal data breach

10.1 The Processor notifies the Controller without undue delay, and in any case within [Number] hours, after becoming aware of a personal data breach affecting the Controller's personal data, through the Controller's privacy contact.

10.2 The notification describes, so far as known, the nature of the breach, the categories and approximate numbers of individuals and records concerned, the likely consequences, the measures taken or proposed, and a contact point. Information not available at first is provided in phases without undue delay.

10.3 The Processor cooperates with the Controller's investigation, preserves evidence, takes the containment measures the Controller reasonably instructs, and does not notify a supervisory authority, individuals or the public about the Controller's data unless the Controller instructs it in writing or the law requires the Processor to do so.

11. International transfers

11.1 The Processor does not transfer personal data to, or allow access from, a country outside [Region] except as set out in Annex 1 or Annex 3, or on the Controller's documented instruction, and only under a transfer mechanism that satisfies the applicable law.

11.2 Where a transfer relies on standard contractual clauses or similar safeguards, the parties execute them as an annex to these terms and the Processor cooperates with any transfer impact assessment the Controller performs.

11.3 The Processor tells the Controller of any legally binding request for the Controller's personal data from a public authority, before disclosure where the law allows, discloses only the minimum the request lawfully requires, and records every such request and disclosure.

12. Audits and information

12.1 The Processor makes available to the Controller all information necessary to demonstrate compliance with these terms, including relevant certifications and independent assurance reports where they exist.

12.2 The Processor allows and contributes to audits and inspections conducted by the Controller or an auditor mandated by the Controller, no more than once in any twelve months unless a breach or a supervisory authority requires otherwise, on at least [Number] days' notice, during business hours, under reasonable confidentiality terms and without unreasonable disruption to the Processor's operations. The Controller may rely on an independent assurance report in place of an on-site audit where the report covers the services and the period.

12.3 The Processor informs the Controller immediately if an audit reveals that an instruction or a part of the services infringes data protection law.

13. Deletion or return

13.1 At the end of the services, or earlier on the Controller's instruction, the Processor, at the Controller's choice, deletes or returns all personal data to the Controller in a commonly used format, and deletes existing copies, within [Number] days, unless the law that applies to the Processor requires storage of the personal data. In that case the Processor tells the Controller what is retained, under which law and for how long, and continues to protect it under these terms.

13.2 The Processor provides written confirmation of deletion, including deletion by sub-processors, and confirms that backup copies expire within [Number] days under the Processor's normal backup cycle and are not restored to production.

14. Records and demonstration of compliance

14.1 The Processor keeps a record of the categories of processing carried out on behalf of the Controller containing the information the law requires, and makes it available to the supervisory authority on request.

14.2 Each party keeps these terms, the annexes and the records they generate for the term of the main agreement and the period required by its retention schedule.

15. Liability and indemnity

15.1 Placeholder for the legal adviser. State how liability for breaches of these terms relates to the liability provisions of the main agreement, whether any cap applies to data protection claims, and the indemnity, if any, that each party gives the other for regulatory fines and third party claims arising from its own breach. [Liability and indemnity wording]

16. Term, termination and precedence

16.1 These terms start on the effective date and continue until the Processor has deleted or returned all personal data under section 13.

16.2 Either party may terminate the affected services if the other party is in material breach of these terms and does not remedy it within [Number] days of written notice.

16.3 Changes to these terms are made in writing and signed by both parties. The parties review these terms when the law, the services, the data or the sub-processors change, and at least every [Number] months.

17. Signatures

Annex 1: Processing details

Annex 2: Technical and organisational security measures

Describe the measures in place, not aspirations. Where the Processor holds a certification or an assurance report, reference it and still describe the measures. Suggested headings:

Annex 3: Approved sub-processors

Related documents

• PIMS-PRO-01 Determining controller and processor roles
• PIMS-REG-06 Processor and sub-processor register
• PIMS-POL-03 International transfer policy
• PIMS-PRO-04 Personal data breach assessment and notification procedure
• PIMS-PRO-03 Data subject rights handling procedure
• PIMS-POL-02 Data retention and disposal policy
• GOV-PRO-06 Supplier and third party security procedure
• GOV-TPL-04 Supplier security and privacy questionnaire
• GDPR-TPL-09 Supplier GDPR assessment questionnaire
• GDPR-TPL-08 Transfer impact assessment template

Personal data processing inventory

One row per processing activity, recording what personal data is processed, why, on what basis, who receives it, where it goes and how long it is kept. This is the record of processing that the organisation keeps as a controller, and the operational source for notices, assessments and requests.

Serves: ISO/IEC 27701 clause 7.2.8; ISO/IEC 27701 Annex A 7.2.8; GDPR Article 30.

Columns:

• Processing ID: Permanent identifier for the activity.
• Activity
• Role
• Purpose
• Lawful basis
• Special category: Health
• Data subjects
• Data categories
• Recipients: Internal functions and third parties
• Transfers outside region: Countries outside the home jurisdiction
• Safeguard: Mechanism for any transfer
• Retention: Period and trigger
• Owner (role)
• DPIA reference: PIMS-REG-08 row
• Last review
• Notes

Data subject request register

One row per request from an individual to exercise a right over their personal data. Records the clock, the identity check, the outcome and the proof, so that the one-month deadline is met and the handling can be shown.

Serves: ISO/IEC 27701 clause 7.3; GDPR Article 12.

Columns:

• Request ID
• Received: Starts the one-month clock.
• Requester
• Right requested
• Identity verified
• Due: One month from receipt
• Extension taken
• Outcome
• Refusal basis: Required when the outcome is a refusal or a partial fulfilment.
• Closed
• Owner (role)
• Evidence reference
• Status
• Notes

Personal data breach register

One row per personal data breach, whether or not it was notifiable. Records the awareness time that starts the seventy-two hour clock, the assessment of risk to individuals, and the notification decisions, so that accountability can be shown even when no notification was required.

Serves: ISO/IEC 27701 clause 6.13.1.5; GDPR Article 33; GDPR Article 34.

Columns:

• Breach ID
• Detected
• Awareness time: Starts the seventy-two hour clock for the authority.
• Summary
• Data subjects affected
• Data categories
• Risk to individuals
• Authority notified
• Authority notified at
• Individuals notified
• Containment
• Corrective action: GOV-REG-03 reference.
• Owner (role)
• Status
• Notes

Consent record register

One row per consent given, where consent is the lawful basis. Records what was consented to, how, when and the wording shown, so that valid consent can be demonstrated and withdrawal honoured.

Serves: ISO/IEC 27701 clause 7.2.3; GDPR Article 7.

Columns:

• Consent ID
• Data subject
• Processing: PIMS-REG-01 activity the consent covers.
• Purpose consented
• Method: How consent was captured
• Notice version: Version of the privacy notice shown at the time.
• Given at
• Withdrawn at
• Owner (role)
• Evidence reference
• Status
• Notes

International transfer register

One row per transfer of personal data outside the home jurisdiction. Records the destination, the mechanism that makes the transfer lawful and the assessment behind it, so that transfers can be shown to be governed rather than incidental.

Serves: ISO/IEC 27701 clause 7.5; GDPR Article 44.

Columns:

• Transfer ID
• Processing: PIMS-REG-01 activity.
• Exporter
• Importer
• Destination
• Data categories
• Mechanism
• Assessment done: Transfer impact assessment
• Supplementary measures
• Owner (role)
• Review date
• Status
• Notes

Processor and sub-processor register

One row per processor and sub-processor that handles personal data on the organisation's behalf. Records the data they access, the contract terms that bind them and the assurance held, linking to the wider supplier register.

Serves: ISO/IEC 27701 clause 7.2.6; GDPR Article 28.

Columns:

• Processor ID
• Name
• Role
• Service
• Processing: PIMS-REG-01 activities served.
• Data categories
• Location
• Processing terms: Article 28 terms in place
• Assurance: Certification
• Supplier register: GOV-REG-07 row.
• Owner (role)
• Last review
• Status
• Notes

Retention schedule

One row per category of personal data, recording how long it is kept, what triggers the clock, how it is disposed of and where that is configured. Checked on a cycle so that data is not kept longer than its basis allows.

Serves: ISO/IEC 27701 clause 7.4.7; GDPR Article 5.

Columns:

• Category
• System
• Retention period
• Trigger: The event that starts the retention clock.
• Disposal method
• Where configured: Where the rule is enforced
• Last check
• Result
• Deviation action: GOV-REG-03 reference where the check failed.
• Owner (role)
• Status
• Notes

Data protection impact assessment register

One row per data protection impact assessment, recording the processing it covered, the screening outcome, the residual risk and the approval. The index to the assessments held as PIMS-TPL-01.

Serves: ISO/IEC 27701 clause 7.2.5; GDPR Article 35.

Columns:

• DPIA ID
• Processing: PIMS-REG-01 activity assessed.
• Trigger: Why a DPIA was required.
• Screening outcome
• Residual risk
• Decision
• Approved by (role)
• Approved date
• Review date
• Owner (role)
• Evidence reference: The completed PIMS-TPL-01.
• Status
• Notes

Guide: SOC 2 in plain words

What a SOC 2 report is and is not, the difference between Type 1 and Type 2, the five categories, how criteria, controls and tests relate, and the parts of the process that surprise organisations the first time, written for a reader who has to run one.

Serves: SOC 2 CC1.1; SOC 2 CC2.3; SOC 2 CC4.1; SOC 2 CC9.2. Owner: Information Security Manager.

1. What a SOC 2 report is

A SOC 2 report is an independent auditor's opinion on whether a service organisation's controls are suitably designed, and for a Type 2 report whether they operated effectively over a period, to meet a published set of criteria called the Trust Services Criteria. The criteria are issued by the American Institute of Certified Public Accountants. The opinion is signed by a licensed public accounting firm, not by a certification body, and it is addressed to the organisation's customers and their auditors, who use it to decide how much they can rely on the organisation's controls without testing them themselves.

Three things follow from that. SOC 2 is an attestation, not a certification: there is no certificate, no register of certified organisations and no "SOC 2 compliant" status in law. The report is the deliverable, and it is a restricted-use document shared with customers under a non-disclosure agreement, not published. And the controls are the organisation's own: the criteria say what outcome must be achieved; [Organisation] decides how, writes its controls down in SOC-REG-01, and the auditor tests those.

2. Type 1 and Type 2

A Type 1 report gives an opinion on the design of controls at a single date: were the controls in place and capable of meeting the criteria on that day. A Type 2 report gives an opinion on design and on operating effectiveness across a period, usually between three and twelve months, by testing samples of the controls' records from inside that period.

Customers almost always want a Type 2. A Type 1 is still useful as a milestone: it proves the control set is complete and designed well before the clock starts, and it gives sales teams something to show while the first period runs. PB-03 treats the Type 1 as the day 90 outcome and the Type 2 as what follows the observation period. An organisation that skips the Type 1 saves money and loses an early warning.

3. The five categories

The criteria are grouped into five categories. Security is mandatory and is made up of the common criteria, CC1 to CC9, which cover the control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management and risk mitigation including vendors. The other four are added when a service makes commitments in that area.

Choose categories by the commitments [Organisation] has actually made in contracts and service descriptions, not by ambition. Every added category adds controls, evidence and testing. A processor that handles personal data on customers' instructions usually covers that through Confidentiality and the security criteria, with privacy law met through the PIMS and GDPR documents in this kit, rather than adding the Privacy category.

4. Criteria, controls and tests

The three words are used loosely and the confusion costs time.

• A criterion is an outcome the auditor must conclude on, for example that access is removed when no longer needed (CC6.2 in theme). The criteria are fixed and the same for every organisation.
• A control is something [Organisation] does, written as an object and a state that can be checked: "quarterly access reviews completed and signed off for every in-scope system". One criterion usually needs several controls, and one control often serves several criteria. The controls live in SOC-REG-01.
• A test is what the auditor does to a control: inspects a sample of access reviews, re-performs a calculation, observes a process, asks a person. The organisation's own version of the tests, run during the period, is SOC-PRO-01.

The auditor's report lists the controls and the tests side by side with the results. If a control is written vaguely ("access is managed appropriately") there is nothing to test, and the auditor will either rewrite it with you or report it as not testable.

5. Points of focus

Each criterion comes with points of focus: considerations that illustrate what the criterion is getting at. They are not requirements and the auditor does not issue an opinion on each one. Use them in two ways. When writing controls, read the points of focus for a criterion and check that the control set covers the themes they raise; a theme with no control is a gap to explain. When a point of focus does not apply (a cloud-only organisation and physical data centres, for example), say so in SOC-REG-01 so the auditor does not ask.

6. The audit period

For a Type 2, evidence must come from inside the period. A control that started operating in month four of a twelve month period is reported as operating for nine months, and the auditor's opinion will say so. A control that has no records for a month, because the person who ran it was on leave and nobody covered, is a gap in that month whether or not anything went wrong.

Periods run consecutively: the next report's period starts the day after the previous one ended, so that a customer reading two reports sees no uncovered time. Between the period end and the report's issue, and between reports, customers may ask for a bridge letter, a short statement from management that nothing material has changed. SOC-PRO-02 explains the same letter from the other side, when [Organisation] receives one from a supplier.

Most organisations choose a first period of three to six months to get a report into customers' hands, then move to twelve month periods aligned to the financial year.

7. Sampling

The auditor does not test every occurrence of a control. For each control they define the population, every occurrence in the period, and select a sample whose size depends on how often the control runs. Monthly controls might see three items tested, weekly five, daily twenty or more; the auditor's own table governs, and SOC-PRO-01 section 4.4 gives [Organisation]'s internal equivalent.

Two practical consequences. The auditor chooses the items, not the organisation, so there is no value in preparing beautiful examples; prepare complete populations as system exports instead. And a population must be complete: if the leaver list from the people system shows fourteen leavers and the identity provider shows sixteen accounts disabled, the auditor will ask about the two, and the answer had better be in a record.

8. Exceptions

An exception is a tested item that did not meet the control: a leaver whose access was removed in nine days instead of five, a change ticket with no approval. The auditor reports every exception with management's response. One isolated exception with a documented cause and a fix rarely affects the opinion. A pattern of exceptions in one control may lead the auditor to conclude the control did not operate effectively, which appears in the opinion as a qualification: the opinion holds except for that control and the criteria it serves. Customers read qualifications closely.

Handle an exception the way SOC-PRO-01 section 4.8 describes: classify it, find the cause, fix it, and show the fix operating. An exception found by [Organisation] in its own testing and corrected before the auditor arrives is reported as a corrected deviation; the same exception found first by the auditor is a surprise. Both are better than a hidden one, which becomes a question of integrity rather than of control.

9. The report's sections

A SOC 2 report has a fixed shape, and knowing it helps both in writing [Organisation]'s own and in reading a supplier's.

Readers go to the opinion first, then the exceptions, then the complementary user entity controls. Write the description knowing that.

10. Complementary user entity controls

Some criteria can only be met if the customer does its part: manages its own users in the service, keeps its own credentials secret, reviews the reports the service sends. The description lists these as complementary user entity controls. They are honest statements of shared responsibility, not disclaimers, and the auditor will check that each one is genuinely needed for a criterion.

The same mechanism applies in reverse. Every supplier report [Organisation] relies on lists user entity controls that [Organisation] must operate. SOC-PRO-02 section 4.6 maps each of them to a control in SOC-REG-01, because a supplier's assurance does not hold if the organisation ignores its side.

11. Subservice organisations

A subservice organisation is a supplier whose controls are necessary for [Organisation] to meet a criterion: typically the hosting provider, sometimes the identity provider, payment processor or managed security service. The description must name them and say how they are treated.

Under the carve-out method, the default, the supplier's controls are excluded from [Organisation]'s report. The description names the supplier, the services used, the criteria that depend on them, and the complementary subservice organisation controls that [Organisation] assumes the supplier operates. [Organisation] then monitors the supplier by reviewing its own SOC report under SOC-PRO-02. Under the inclusive method the supplier's controls are tested inside [Organisation]'s report, which needs the supplier's agreement, participation and its own management assertion; it is rare outside closely held group companies.

A supplier that is merely a vendor, whose failure would not by itself cause a criterion to fail, is handled under GOV-PRO-06 and CC9.2 and does not need to be in the description.

12. Who the auditor is

The opinion must be signed by a licensed public accounting firm that is independent of [Organisation] and subject to peer review of its attestation practice. The same firm cannot design the controls and then audit them; a firm that offers both services separates the teams and will say so in its engagement letter. A readiness consultant who helps write controls is not the auditor, and the auditor will test what the consultant wrote exactly as hard as anything else.

When choosing, ask: how many SOC 2 examinations the firm issued in the last year for organisations of [Organisation]'s size and technology; who will do the fieldwork and how senior they are; the firm's sample size table; whether evidence is collected through a portal or by request list; how exceptions are communicated and when; the timeline from period end to issued report; and the total cost for the readiness review, the Type 1 and the Type 2. Price varies with the number of categories, systems, locations and controls, and with how organised the evidence is. A tidy evidence folder built as PB-09 describes is the single largest cost reducer.

13. Common misunderstandings

14. Where to go next

Read PB-03 for the ninety day plan to the start of the observation period. Use SOC-REG-01 to write the control matrix, SOC-REG-03 to measure readiness, SOC-REG-02 to schedule the recurring evidence, SOC-TPL-01 to draft the description, SOC-PRO-01 to test the controls before the auditor does, SOC-PRO-02 for supplier reports, and SOC-GDE-02 for what the auditor will ask for and where in the kit each answer lives. SOC-GDE-03 maps every criterion to the kit documents that serve it.

Guide: the auditor's request list and how to answer it from the kit

The evidence requests a SOC 2 auditor typically issues, grouped by the team that produces each one, with the kit register or document that holds the answer and the form the answer should take.

Serves: SOC 2 CC4.1; SOC 2 CC2.1; SOC 2 CC6.1; SOC 2 CC7.2; SOC 2 CC8.1; SOC 2 CC9.2. Owner: Information Security Manager.

1. How the request list works

A few weeks before fieldwork the auditor sends a request list: one line per item of evidence, each tied to one or more controls in SOC-REG-01, with a due date. The list is long, the dates are short, and the items land on five or six different teams. Organisations that struggle are not short of controls; they are short of a person who knows which team holds each answer and what form it should take.

This guide groups the typical requests by the owner who produces them. For each request it names the criteria, the kit register or document that holds the answer, and how to deliver it. Read it with PB-09, which sets the evidence rules that apply to every item: dated system exports over screenshots, complete populations over examples, file names that say what the file proves, and a To confirm status for anything not yet seen.

Four rules apply to every request.

1. Deliver populations, not examples. The auditor samples; [Organisation] supplies the whole list with identifiers and dates and lets the auditor choose.
2. Deliver evidence from inside the period. A record dated after the period end proves nothing about the period, however good it is.
3. Deliver the system of record's own export. A spreadsheet typed from memory is not evidence of anything except memory.
4. Deliver through one channel, with one person tracking status per item. The Information Security Manager owns the list; the teams below own the items.

2. People team

3. Engineering

4. IT and operations

5. Policy owner (Information Security Manager)

6. Risk owner

7. Privacy Officer (when the Privacy category or personal data is in scope)

8. Requests that catch organisations out

• The population reconciliation. The auditor compares the people system's leavers to the identity provider's disabled accounts, and change tickets to deployments. Reconcile both yourself before fieldwork and have an explanation for every difference.
• The quarter with no access review. A review done in month four and month nine is two reviews, not four. SOC-REG-02 exists so that this is seen in month five, not at the audit.
• The policy acknowledged before it was approved. Acknowledgement exports must name the version, and the version's approval date must precede the acknowledgement.
• The restore test that restored nothing. A backup job success export is not a restore test. GOV-REG-15 needs a restored item, a verification and a date.
• The vendor report nobody read. Having a subservice organisation's SOC report on file is not CC9.2 evidence; the SOC-PRO-02 review record is.
• The incident with no post-incident review. GOV-TPL-11 within the window in GOV-PRO-07, or the control did not operate for that incident.
• The screenshot with no date or account. Retake it as PB-09 section 5 describes.
• The control owner who is also the tester. SOC-PRO-01 section 4 requires independence; the auditor will ask who performed each internal test.

9. Preparing in advance

Everything in sections 2 to 7 can be produced on the day the control runs, which is what SOC-REG-02 schedules. An organisation that files the quarterly access review export on the day the review closes, the monthly vulnerability scan on the day it completes, and the change ticket export at month end, answers the request list in a week. An organisation that starts collecting when the list arrives answers it in two months and loses items to section 8. Use SOC-REG-03 to check readiness before the period starts, and keep the owner column of SOC-REG-01 current so that every request has a name on it before the auditor asks.

Guide: Trust Services Criteria mapped to kit documents

Every Trust Services Criterion with its theme in plain words and the kit policies, procedures, templates and registers that implement and evidence it, so that a control matrix, a gap assessment or an auditor's question can be answered from one table.

Serves: SOC 2 CC1.1; SOC 2 CC6.1; SOC 2 CC7.1; SOC 2 CC8.1; SOC 2 A1.1; SOC 2 C1.1; SOC 2 PI1.1; SOC 2 P1.1. Owner: Information Security Manager.

1. How to read this map

Each table lists the criteria of one category. The theme column is a reminder in plain words of what the criterion is about; it is not the criterion's text, which belongs to its publisher and should be read in the original when writing controls. The documents column names the kit policies, procedures, guides and templates that implement the theme. The registers column names the registers and records that evidence it. Where this kit has no dedicated document, the entry says which general document carries the theme.

Use the map in three places: when filling the Kit documents column of SOC-REG-01, when answering a request from SOC-GDE-02, and when running the gap assessment in PB-03. The kit does not replace the criteria; an organisation writing controls reads the criteria and their points of focus for itself.

2. CC1: control environment

3. CC2: communication and information

4. CC3: risk assessment

5. CC4: monitoring activities

6. CC5: control activities

7. CC6: logical and physical access controls

8. CC7: system operations

9. CC8: change management

10. CC9: risk mitigation

11. A1: availability

12. C1: confidentiality

13. PI1: processing integrity

14. P1 to P8: privacy

15. Where the kit is thin

Three themes are carried by general documents rather than dedicated ones, and an organisation may want to add its own. Fraud risk (CC3.3) is a scenario class inside GOV-PRO-05 and a segregation rule inside GOV-PRO-10; an organisation handling payments should add explicit fraud scenarios to GOV-REG-05. Anomaly analysis (CC7.2) rests on GOV-PRO-14's alert triage; a larger operation will want a written triage runbook. Processing specifications (PI1.1) are required by SOC-POL-01 but have no template in the kit; the output and input catalogues in SOC-PRO-03 and SOC-PRO-04 give the headings.

Processing integrity policy

The rules that keep [Organisation]'s processing complete, accurate, timely and authorised, from the moment an input arrives to the moment an output is delivered and the data is stored, and the records that prove it.

Serves: SOC 2 PI1.1; SOC 2 PI1.2; SOC 2 PI1.3; SOC 2 PI1.4; SOC 2 PI1.5. Owner: Head of Engineering.

1. Purpose

Processing integrity means that [Organisation]'s systems do what they promise: inputs are accepted only when complete, accurate and authorised; processing follows the written specification; outputs reach the right people complete, correct and on time; and stored data is not silently altered or lost. This policy sets the rules the processing integrity criteria are tested against.

2. Scope

Every service [Organisation] provides whose processing integrity category is in the report scope, the systems inside the boundary in SOC-TPL-01, the interfaces that feed them, the outputs they deliver and the data stores that hold inputs, items in processing and outputs. It applies to automated processing and to the manual steps staff perform within it.

3. Roles and responsibilities

4. Policy statements

4.1 Specification. Every in-scope service has a written processing specification, approved by the Head of Engineering, that defines its inputs, validation rules, processing logic in plain words, outputs, recipients, timing commitments and the data retained. The specification is controlled under GOV-PRO-01 and changes only through GOV-PRO-09.

4.2 Commitments match the specification. Processing commitments made to customers in contracts, service descriptions and the system description in SOC-TPL-01 are derived from the specification. The product or service manager reviews them against it at least annually and at every specification change, and records the review.

4.3 Inputs. A system accepts an input only after validating it against the specification's rules for format, range, referential integrity, completeness, duplication and authorisation. A rejected input is held in a quarantine with its reason, reported to the submitter within [Number] hours, and never silently discarded or silently corrected. SOC-PRO-03 governs.

4.4 Manual inputs. A manual input that changes customer data or a financial value is entered by one person and verified by a second before it takes effect, or is covered by a system check that the System Owner has documented as equivalent.

4.5 Processing. Every processing job records its start, end, items in, items out, items rejected and errors in a log kept under GOV-PRO-14. A job that fails, or whose counts fall outside the specification's tolerance, raises an alert to the operations team within [Number] minutes and is not marked complete until resolved.

4.6 Reconciliation. The operations team reconciles inputs received to items processed and outputs produced at least daily for each in-scope service, investigates every difference the same working day, and records the result with a preparer and a separate reviewer.

4.7 Outputs. Outputs are delivered complete, accurate and within the time the specification states, to the recipients and by the channel it names, over encrypted transport under GOV-PRO-23. A missed or incomplete delivery is detected by the system, not by the recipient, and is treated as an incident under GOV-PRO-07 when a customer commitment is missed. SOC-PRO-04 governs.

4.8 Corrections. An output found to be wrong is corrected by reissue with a version marker. The original is retained, the recipient is told what changed and why, and the cause is entered in the processing error log, with a corrective action under GOV-PRO-04 where the cause is systemic.

4.9 Storage. Inputs, items in processing and outputs are stored with controls that prevent and detect unauthorised alteration: access restriction under GOV-PRO-10, integrity checks under SOC-PRO-04 and backups under GOV-PRO-12. They are kept for the period in PIMS-REG-07 and are recoverable to the state at any processing step the specification requires.

4.10 Segregation of duties. No single person may both submit an input and approve it, both develop processing logic and deploy it to production, or both perform a reconciliation and resolve its differences without a second person's record. Where headcount makes this impossible, the compensating review is recorded in GOV-REG-06.

4.11 Errors and incidents. Processing errors are logged with cause, items affected, correction and date. An error that affects a customer commitment, more than [Number] items, or any financial value is an incident under GOV-PRO-07.

4.12 Measures. The System Owner reports monthly: inputs rejected by reason, reconciliation differences and time to resolve, outputs delivered late, corrections issued, and open processing errors. Targets are held in GOV-REG-21 and reviewed at management review under GOV-PRO-03.

5. Records and evidence

• Approved processing specifications per service, with their change history in GOV-REG-11.
• Input rejection and quarantine records with submitter notifications.
• Job logs and alerts under GOV-PRO-14.
• Daily reconciliation records with preparer and reviewer, and difference investigations.
• Output delivery logs, acknowledgements and reissue records.
• The processing error log and the monthly measures report.
• SOC-PRO-01 workpapers for the processing integrity controls in SOC-REG-01.

6. Exceptions

A service may deviate from a statement only under GOV-PRO-24, with a compensating control approved by the Head of Engineering and a duration of no more than twelve months. No exception applies to statement 4.3 (no silent discard or correction) or statement 4.8 (retention of the original output).

7. Review and maintenance

The Head of Engineering reviews this policy annually, after any processing incident, and when a new service enters the report scope. Changes follow GOV-PRO-01.

8. Related documents

• SOC-PRO-03 Input validation and reconciliation procedure
• SOC-PRO-04 Output distribution and storage integrity procedure
• SOC-TPL-01 System description template
• SOC-REG-01 Trust Services Criteria control matrix
• GOV-PRO-09 Change management procedure
• GOV-PRO-14 Logging, monitoring and alert handling procedure
• GOV-PRO-07 Information security incident management procedure
• GOV-PRO-12 Backup and restore testing procedure
• PIMS-REG-07 Retention schedule

Control testing and sampling procedure

How [Organisation] tests its own SOC 2 controls before and during an examination period, with defined populations, sample sizes by frequency, deviation handling and workpapers that an external auditor can re-perform.

Serves: SOC 2 CC4.1; SOC 2 CC4.2; ISO/IEC 27001:2022 clause 9.1. Owner: Information Security Manager.

1. Purpose

This procedure sets how the controls in SOC-REG-01 are tested by [Organisation] itself, so that a control that has stopped operating is found and repaired months before the external auditor finds it, and so that every test leaves a workpaper the auditor can rely on and re-perform.

2. Scope

Every control listed in SOC-REG-01 Trust Services Criteria control matrix with a status of Operating or Tested, for every system inside the boundary described in SOC-TPL-01. It covers manual controls, controls a system performs on a schedule and controls that run on every transaction. It does not replace the internal audit programme in GOV-PRO-02, which examines the management system as a whole; the two share their findings through GOV-REG-03.

3. Roles and responsibilities

4. Procedure

4.1 Testing plan. At the start of each examination period, and at least annually, the Information Security Manager lists every control in SOC-REG-01 with its frequency, owner, the quarter in which it will be tested and the assigned tester. Every control is tested at least once per period. A control with a deviation in the previous period, a linked risk rated High or Critical in GOV-REG-05, or a change during the period is tested twice.

4.2 Population definition. Before selecting anything, the tester writes down the population: what one occurrence of the control looks like (one access review, one change ticket, one backup job, one new starter), the system of record that holds the occurrences, the date range, and the total count. The control owner produces the population as a system export that carries an identifier and a date for every item. A hand-typed list or a filtered screen view is not accepted; the tester records the refusal and requests the export.

4.3 Population completeness. The tester checks the population against an independent source before sampling: the leaver list against the people system, change tickets against the deployment log, new accounts against the identity provider's creation events. A difference above 2 percent of items, or any missing item that should have triggered the control, is a deviation under 4.8 before testing begins.

4.4 Sample sizes. The tester selects at least the number of items in the table below. Where the population is smaller than the sample size, the tester tests every item.

For an event-driven control (a joiner, a leaver, an incident, a change) the row is chosen by how many events occurred in the period. For a shorter period the typical counts fall but the minimum samples stay.

4.5 Selection method. The tester selects items at random by a method that can be repeated from the recorded inputs, for example a seeded random number list applied to the exported row numbers. Where the period is long, the tester spreads the sample so that every quarter is represented. The tester records the method, the seed or formula and the selected identifiers. The control owner never chooses the items and does not see the selection until evidence is requested.

4.6 Test methods and attributes. The tester applies at least one of: inspection of a record the control produced, re-performance of the control on the selected item, observation of the control being performed, or inquiry of the operator. Inquiry on its own is never sufficient; it is paired with inspection or re-performance. Each test states the attributes checked, for example: reviewer named, review dated inside the quarter, every account dispositioned, removals actioned within five working days, sign-off by the System Owner.

4.7 Performing the test. For every selected item the tester records the identifier, the date, each attribute checked and a result of Pass or Fail, with a reference to the evidence file named as PB-09 describes. Evidence is taken from the system of record by the tester or in the tester's presence. Evidence forwarded by the control owner without the tester seeing its source is marked To confirm until the source is shown.

4.8 Deviations. Any item that fails an attribute is a deviation. The tester records it the same day with the item, the attribute, the facts observed and the control owner's explanation. The Information Security Manager classifies it within five working days as one of the following.

• Isolated: one item, a cause that applies only to that item, no effect on others. The tester doubles the sample from the same population; if no further deviation appears, the control is reported as operating with one noted exception.
• Systemic: more than one item, or a cause that could affect other items (a step nobody owns, a tool change, a person who left). The control is reported as not operating effectively for the period of the cause, and a corrective action is raised in GOV-REG-03 under GOV-PRO-04.
• Design gap: the control as written cannot meet the criterion even when performed perfectly. SOC-REG-01 is updated with a redesigned control and its start date, and the gap is reported to the steering committee.

4.9 Remediation and retest. The control owner implements the corrective action by the date in GOV-REG-03. The tester retests after at least one full operating cycle of the control has completed following the fix, using a fresh sample drawn from occurrences after the fix date. A control fixed and retested inside the period is reported with both results and both dates.

4.10 Workpaper. Every test produces one workpaper containing: control identifier and text from SOC-REG-01, criteria served, period tested, population definition and count, completeness check, selection method and sample, attributes tested, results per item, deviations and their classification, conclusion, tester name and date, reviewer name and date. Workpapers are stored in the evidence folder area for audit and review, hashed as PB-09 describes and retained with the period's evidence.

4.11 Quality review. Each quarter the Internal Auditor reviews at least [Number] workpapers, checking that the tester was independent, that the population came from a system of record, that the sample was random and recorded, and that the conclusion follows from the results. Findings about testing quality become corrective actions in GOV-REG-03.

4.12 Reporting. The Information Security Manager reports to the steering committee quarterly: controls tested, controls passed, open deviations by classification, retests due, and controls not yet tested in the period. The period-end summary is an input to management review under GOV-PRO-03 and is given to the external auditor on request as evidence for CC4.1 and CC4.2.

5. Records and evidence

• The testing plan for each period.
• SOC-REG-01 with Status and Test method completed for every control.
• One workpaper per test, with the population export, the selection record and the evidence files.
• Deviation records and their corrective actions in GOV-REG-03.
• Quarterly testing summaries and the Internal Auditor's quality reviews.

6. Exceptions

A control may be tested by its own operator only where no independent person has the knowledge to test it; the Information Security Manager records the reason and the Internal Auditor re-performs that test in the quarterly quality review. A sample size may be reduced only with the written agreement of the Information Security Manager, recorded in the workpaper with the reason. No exception permits the control owner to choose the sample.

7. Review and maintenance

The Information Security Manager reviews this procedure annually, after each external examination (to adopt the auditor's population and sample expectations where they differ), and when the control set in SOC-REG-01 changes materially. Changes follow GOV-PRO-01.

8. Related documents

• SOC-REG-01 Trust Services Criteria control matrix
• SOC-REG-02 Evidence calendar
• SOC-TPL-01 System description template
• GOV-PRO-02 Internal audit procedure
• GOV-PRO-04 Nonconformity and corrective action procedure
• GOV-REG-03 Corrective action log
• PB-09 Playbook: evidence management that survives an audit
• SOC-GDE-01 Guide: SOC 2 in plain words

Subservice organisation and vendor assurance report review procedure

How [Organisation] obtains, reviews and acts on the SOC and equivalent assurance reports of its subservice organisations and critical vendors, including bridge letters, exceptions and the complementary user entity controls those reports place on [Organisation].

Serves: SOC 2 CC9.2; SOC 2 CC3.4; ISO/IEC 27001:2022 Annex A 5.22. Owner: Information Security Manager.

1. Purpose

A subservice organisation operates controls that [Organisation]'s own service commitments depend on: hosting, identity, payment, email delivery, support tooling. This procedure makes sure those controls have been examined by somebody, that [Organisation] reads the result rather than filing it, and that the user entity controls each report expects of [Organisation] are actually in place.

2. Scope

Every supplier in GOV-REG-07 that is a subservice organisation named in SOC-TPL-01, every Tier 1 supplier, and any other supplier whose failure would cause [Organisation] to miss a service commitment. Assurance reports covered are SOC 1, SOC 2 and SOC 3 reports, ISO/IEC 27001 certificates with their Statement of Applicability, and other independent attestation reports a supplier offers in their place.

3. Roles and responsibilities

4. Procedure

4.1 Identify. When a supplier is onboarded under GOV-PRO-06, and at each annual review, the Information Security Manager marks in GOV-REG-07 whether it is a subservice organisation (its controls are necessary for [Organisation] to meet a criterion) or a vendor, and records the assurance type expected: SOC 2 Type 2, SOC 1 Type 2, ISO/IEC 27001 certificate, or questionnaire only.

4.2 Request. The supplier relationship owner requests the current report within 30 days of onboarding and then annually, no later than 60 days after the supplier's expected report date. The request names the services and locations [Organisation] uses so that the supplier sends the report that covers them. Reports are stored in the evidence folder area for suppliers, classified Confidential, and used only as the supplier's terms permit.

4.3 Coverage check. Before reading the detail, the reviewer confirms four things and records each: the report type (Type 2 is required for a subservice organisation; a Type 1 is accepted only for a supplier in its first year); the period covered; that the services, systems and locations [Organisation] uses are inside the report's scope; and that the categories match the dependency (a hosting provider must cover Security and Availability, for example). A report that fails any check is treated as absent and step 4.9 applies.

4.4 Bridge letter. Where the report period ended more than three months before the review date, or more than three months before the end of [Organisation]'s own examination period, the supplier relationship owner obtains a bridge letter in which the supplier states whether its controls have changed and whether it knows of any failures since the period end. A gap of more than twelve months without a new report is escalated to the steering committee.

4.5 Opinion and exceptions. The reviewer reads the auditor's opinion first. A qualified, adverse or disclaimed opinion is escalated to the Information Security Manager the same day. The reviewer then lists every exception in the testing section with: the control, the exception, the supplier's management response, and whether the control is one [Organisation] depends on. For each dependent exception the reviewer decides whether [Organisation]'s own controls compensate; if they do not, the reviewer raises a risk in GOV-REG-05 and a corrective action in GOV-REG-03.

4.6 Complementary user entity controls. The reviewer extracts the complementary user entity controls the report lists and, with the System Owner, maps each to a control in SOC-REG-01, recording the mapping in the review record. Each unmapped user entity control is a gap: it is assigned an owner and a due date of no more than 60 days, because the supplier's assurance does not hold without it.

4.7 The supplier's own subservice organisations. The reviewer notes the supplier's carved-out subservice organisations and whether any of them hold [Organisation] data. Those that do are added to GOV-REG-07 as fourth parties with the supplier as relationship owner, and the supplier's monitoring of them is noted in the review record.

4.8 Review record. For every report the reviewer completes a record with: supplier, report type and period, auditor, opinion, scope match, categories, exceptions and their disposition, user entity control mapping, bridge letter status, overall conclusion (Acceptable, Acceptable with actions, Not acceptable), reviewer and date. GOV-REG-07 is updated with the assurance type, last review date, next review date and status.

4.9 No report available. Where a subservice organisation cannot provide an assurance report, the Information Security Manager obtains instead a completed GOV-TPL-04 questionnaire, an independent penetration test summary dated within twelve months, and a contractual right to audit or to receive security information; records the supplier as unattested in GOV-REG-07; and raises a risk in GOV-REG-05 for the steering committee to accept or treat. For [Organisation]'s own report, an unattested subservice organisation is disclosed in SOC-TPL-01 and discussed with the external auditor before the period begins.

4.10 Carve-out or inclusive. For each subservice organisation the Information Security Manager records in SOC-TPL-01 whether [Organisation] uses the carve-out method (the supplier's controls are excluded from [Organisation]'s report and the complementary subservice organisation controls [Organisation] relies on are listed) or the inclusive method (the supplier's controls are examined within [Organisation]'s report, which needs the supplier's written agreement and participation). The carve-out method is the default.

4.11 Actions and follow up. Actions from 4.5 and 4.6 are tracked in GOV-REG-03 and reported at the quarterly supplier review. A supplier whose conclusion is Not acceptable at two consecutive reviews is referred to the steering committee for a decision on exit under GOV-PRO-06.

5. Records and evidence

• GOV-REG-07 Supplier register with assurance type, last and next review dates and status.
• The supplier assurance reports and bridge letters in the evidence folder.
• One review record per report, including the complementary user entity control mapping.
• Risks in GOV-REG-05 and corrective actions in GOV-REG-03 arising from exceptions or gaps.
• Steering committee minutes for escalations.

6. Exceptions

A Tier 1 supplier that is not a subservice organisation may be accepted on an ISO/IEC 27001 certificate and Statement of Applicability without a SOC report where the Information Security Manager records that no [Organisation] criterion depends on the supplier's controls. No exception removes the requirement to map complementary user entity controls where a report lists them.

7. Review and maintenance

The Information Security Manager reviews this procedure annually, after any supplier incident, and when a new subservice organisation is added to the system boundary. Changes follow GOV-PRO-01.

8. Related documents

• GOV-PRO-06 Supplier and third party security procedure
• GOV-REG-07 Supplier register
• GOV-TPL-04 Supplier security and privacy questionnaire
• SOC-TPL-01 System description template
• SOC-REG-01 Trust Services Criteria control matrix
• SOC-GDE-01 Guide: SOC 2 in plain words
• PIMS-REG-06 Processor and sub-processor register

Input validation and reconciliation procedure

How inputs to an in-scope service are catalogued, validated, rejected, corrected and reconciled, so that processing starts from complete, accurate and authorised data and every difference between what arrived and what was processed is explained the same day.

Serves: SOC 2 PI1.2; SOC 2 PI1.3. Owner: Head of Engineering.

1. Purpose

This procedure puts SOC-POL-01 statements 4.3 to 4.6 into daily practice. It defines the catalogue of inputs, the validation rules each input must pass, what happens to an input that fails, and the daily reconciliation that proves nothing was lost, duplicated or changed between receipt and processing.

2. Scope

All inputs to services whose processing integrity category is in the report scope: files, interface calls, messages, user forms, manual entries by staff and data fed from other systems. It covers the point of receipt through to confirmation that processing consumed the input.

3. Roles and responsibilities

4. Procedure

4.1 Input catalogue. The System Owner keeps, within the processing specification, a catalogue of every input: name, source, channel, format, expected volume and timing, authorisation method, owner, and the validation rules that apply. A new input is added to the catalogue before it goes live and the entry is reviewed at each change under GOV-PRO-09.

4.2 Validation rules. For each input the System Owner defines rules in the following classes and writes the specific values in the catalogue.

• Format: type, length, encoding, schema version.
• Range and domain: permitted values, minimum and maximum, dates that cannot be in the future.
• Referential: identifiers must exist in the master data they refer to.
• Completeness: mandatory fields present; for a batch, header and trailer present and record count equal to the trailer count.
• Duplication: an item with the same key as one already accepted inside the deduplication window is rejected or flagged, as the specification states.
• Authorisation: the submitter is authenticated and permitted to send this input for this account.

4.3 Implementation and testing. The developer implements each rule with an automated test that proves a failing item is rejected and a passing item is accepted. Rules are deployed through GOV-PRO-09 and the change record references the catalogue version.

4.4 Control totals. Every batch input carries a record count and, where values are numeric, a control total generated by the sender. The system compares the received count and total to the batch header before processing. A mismatch rejects the whole batch.

4.5 Rejection and quarantine. A rejected item or batch is written to a quarantine store with the reason code, the time, the submitter and the item identifier. Nothing is deleted and nothing is corrected automatically unless the specification names the correction (trimming surrounding spaces, for example) and the correction is logged. The submitter is notified within [Number] hours with the reason.

4.6 Working the quarantine. The operations team reviews the quarantine at least daily. Each item is dispositioned as Resubmitted (corrected by the submitter and accepted), Corrected internally (only on the submitter's written instruction, recorded against the item, entered by one person and verified by another), or Closed without processing (with the submitter's agreement). An item in quarantine for more than [Number] working days is escalated to the System Owner.

4.7 Daily reconciliation. At the end of each processing day the operations team reconciles, for each input: items received, items accepted, items rejected, items processed and items pending, so that received equals accepted plus rejected, and accepted equals processed plus pending. The figures come from system counts, never from manual tallies.

4.8 Differences. Any difference, or any pending count older than the specification's tolerance, is investigated the same working day. The investigation records the cause, the items involved, the correction and who verified it. A difference caused by a defect raises a change under GOV-PRO-09 and, where a customer commitment was affected, an incident under GOV-PRO-07.

4.9 Reconciliation record. The reconciliation is recorded with date, service, the five figures, differences and their disposition, preparer and reviewer. The reviewer is not the preparer. The record is retained for the examination period plus one further period.

4.10 Interface reconciliation. For inputs received from another system by interface, the sending system's daily count is obtained and compared to items received at least daily. Each interface is listed in GOV-REG-25 with its reconciliation method.

4.11 Monitoring. The System Owner reviews monthly: rejection rate by reason, quarantine ageing, reconciliation differences and time to resolve, and rule changes. A rising rejection rate for one submitter is raised with that submitter; a rising rate across submitters triggers a review of the rules.

5. Records and evidence

• The input catalogue inside each processing specification, version controlled.
• Automated test results for validation rules, retained with the release.
• Quarantine store entries and submitter notifications.
• Daily reconciliation records with preparer and reviewer.
• Difference investigations and the changes or incidents they raised.
• The monthly monitoring report.

6. Exceptions

A reconciliation may be performed weekly instead of daily only for an input with fewer than [Number] items per week, recorded in the catalogue and approved by the Head of Engineering. No exception permits silent correction or deletion of a rejected item.

7. Review and maintenance

The Head of Engineering reviews this procedure annually, after any processing incident, and when an input is added or changed. Changes follow GOV-PRO-01.

8. Related documents

• SOC-POL-01 Processing integrity policy
• SOC-PRO-04 Output distribution and storage integrity procedure
• SOC-PRO-01 Control testing and sampling procedure
• GOV-PRO-09 Change management procedure
• GOV-PRO-07 Information security incident management procedure
• GOV-REG-25 Data flow and interface inventory
• SOC-REG-01 Trust Services Criteria control matrix

Output distribution and storage integrity procedure

How outputs of an in-scope service are checked for completeness and accuracy, delivered on time to authorised recipients only, corrected when wrong, and how inputs, items in processing and outputs are stored so that alteration or loss is prevented or detected.

Serves: SOC 2 PI1.4; SOC 2 PI1.5. Owner: Head of Engineering.

1. Purpose

This procedure puts SOC-POL-01 statements 4.7 to 4.9 into practice. It defines the catalogue of outputs, the checks an output passes before release, the controls on who receives it and how, the handling of corrections, and the integrity controls over every store that holds processing data.

2. Scope

All outputs of services whose processing integrity category is in the report scope: files, reports, interface responses, notifications and data feeds to customers or other systems. It also covers every data store holding inputs, items in processing or outputs for those services, including temporary and queue storage.

3. Roles and responsibilities

4. Procedure

4.1 Output catalogue. The System Owner keeps, within the processing specification, a catalogue of every output: name, content, recipients, channel, format, schedule and deadline, completeness and accuracy checks, retention period and store. A new output is catalogued before it goes live.

4.2 Completeness checks. At generation the system computes the record count and, for numeric values, the control total of each output, and compares them to the items processed for that run. A checksum of each output file is computed at generation and delivered with the file or published where the recipient can verify it. Sequenced outputs carry a sequence number so that a missing delivery is visible to the recipient.

4.3 Accuracy checks. The system applies automated assertions to each output before release: totals balance to inputs, mandatory fields present, no empty values where the specification forbids them, values inside expected ranges. For an output carrying financial values or customer-visible figures, a member of the operations team who did not generate it verifies a sample of [Number] items against source data each run, or each day for continuous outputs, and records the result.

4.4 Timeliness. Every scheduled output is registered in the job monitor with its deadline. The monitor alerts the operations team if the output has not been delivered [Number] minutes before the deadline. A missed deadline is recorded with cause and, where a customer commitment is missed, handled as an incident under GOV-PRO-07.

4.5 Authorised recipients. The System Owner keeps a recipient list for each output, naming the accounts, addresses or endpoints and the customer or team each belongs to. Delivery goes only to listed recipients, only by the catalogued channel, and over encrypted transport under GOV-PRO-23 and GOV-PRO-20. The recipient list is reviewed quarterly with the access reviews in GOV-REG-12 and the review is recorded.

4.6 Recipient changes. A change to a recipient list requires a written request from the customer authorised contact or the internal owner, verification of the requester's identity by a method independent of the request, and approval by the System Owner. The change is recorded with request, approver and date.

4.7 Delivery confirmation. The system records each delivery with time, recipient and result. Where the specification requires acknowledgement, the recipient's acknowledgement or the channel's delivery receipt is captured. A failed delivery is retried as the specification states and then escalated to the operations team within [Number] minutes.

4.8 Corrections and reissue. An output found to be wrong is reissued with a version marker and a note of what changed. The original is retained unaltered. The recipient is told what changed, why, and which version to use. The cause is entered in the processing error log and, where systemic, raised under GOV-PRO-04.

4.9 Storage integrity. Every store holding inputs, items in processing or outputs has access restricted under GOV-PRO-10 to the service identities and roles the specification names. Where the platform offers versioning, write-once retention or object locking, the System Owner enables it for output stores. Each stored object carries a checksum computed on write.

4.10 Integrity verification. The operations team verifies stored checksums on a schedule: monthly for a random sample of at least [Number] objects per store, and in full before any migration and after any restore. A mismatch is an incident under GOV-PRO-07 and the affected objects are restored from backup under GOV-PRO-12.

4.11 Retention and disposal. Stored processing data is kept for the period in PIMS-REG-07 and then deleted by the method PIMS-POL-02 names, with the deletion recorded. A legal hold under GOV-PRO-25 suspends deletion for the objects it names.

4.12 Backup and capacity. Processing stores are backed up under GOV-PRO-12, and the quarterly restore test includes verifying the checksum of at least one restored output. Capacity thresholds for processing stores are monitored under GOV-PRO-19 and a failed write raises an alert.

4.13 Monitoring. The System Owner reviews monthly: outputs delivered late, completeness or accuracy check failures, failed deliveries, reissues, recipient changes, integrity verification results and disposal actions.

5. Records and evidence

• The output catalogue and recipient lists, with quarterly review records.
• Generation check results, checksums and sequence records per run.
• Sample accuracy verification records.
• Job monitor alerts and delivery logs with acknowledgements.
• Recipient change requests and approvals.
• Reissue records and the processing error log.
• Integrity verification results, disposal records and restore test results.

6. Exceptions

An output may be delivered to an unlisted recipient only in an incident, on the written instruction of the System Owner, with the delivery recorded and the recipient list corrected within one working day. No exception permits alteration of an original output after release.

7. Review and maintenance

The Head of Engineering reviews this procedure annually, after any processing incident or integrity failure, and when an output or store is added or changed. Changes follow GOV-PRO-01.

8. Related documents

• SOC-POL-01 Processing integrity policy
• SOC-PRO-03 Input validation and reconciliation procedure
• GOV-PRO-23 Information transfer and data loss prevention procedure
• GOV-PRO-20 Cryptography and key management procedure
• GOV-PRO-12 Backup and restore testing procedure
• GOV-PRO-19 Capacity and availability management procedure
• PIMS-POL-02 Data retention and disposal policy
• PIMS-REG-07 Retention schedule
• SOC-REG-01 Trust Services Criteria control matrix

System description template

The template for the system description section of [Organisation]'s SOC 2 report, with every section the description criteria expect, placeholders, and guidance notes on what each section must and must not say.

Serves: SOC 2 CC2.1; SOC 2 CC2.3; SOC 2 CC9.2. Owner: Information Security Manager.

1. How to use this template

The system description is written by [Organisation] and included in the SOC 2 report under management's assertion. The auditor tests whether it is fairly presented: complete enough that a reader understands the system, accurate against what the auditor observes, and free of claims the controls do not support. Write in the present tense for the period covered. Every statement about a control must match a row in SOC-REG-01. Remove the italic guidance before issue. Keep names of staff out; use roles. The description is a controlled document under GOV-PRO-01 and is re-approved for every report.

2. Overview and services provided

Two to four paragraphs. What [Organisation] is, what the service does for its customers, who the customers are in general terms, and the business function the service performs. A reader with no prior knowledge should understand the service after this section.

[Organisation] provides [System name], a [description of service] used by [type of customer] to [business purpose]. The service is delivered as [delivery model, for example a multi-tenant web application and an interface for programmatic access] and is operated by [Organisation]'s [team names by function].

3. Principal service commitments and system requirements

Service commitments are what [Organisation] promises customers: in contracts, service level agreements, terms of service, privacy notices and public security statements. System requirements are what the system must do internally to keep those promises. Each category in scope needs at least one commitment. Every commitment here must be real and traceable to a signed or published document; the auditor will ask for it.

4. Components of the system

4.1 Infrastructure

The physical and virtual resources that run the service: hosting provider accounts, network segments, compute, storage, databases, content delivery, identity provider. Describe by function and by provider type, with the region or location category stated in general terms. Do not list internal addresses or account identifiers.

4.2 Software

The application software [Organisation] writes and the commercial or open source software it relies on: operating systems, platforms, databases, monitoring, ticketing, source control, build and deployment tooling. Group by purpose; version numbers are not needed.

4.3 People

The teams involved in operating the system and their responsibilities, by role. Include third parties who perform roles, such as a managed security provider. The reader should see who approves access, who deploys changes, who answers incidents.

4.4 Procedures

The automated and manual procedures that run the service. Reference the kit documents by ID rather than restating them; the auditor reads the documents themselves. Cover at a minimum: access management, change management, incident management, vulnerability and patch management, backup and recovery, logging and monitoring, vendor management, and the procedures for each additional category in scope.

4.5 Data

The types of data the system processes, their classification under GOV-PRO-16, how they enter and leave the system, and where they are stored. State whether personal information is processed and in what role (controller or processor). Reference GOV-REG-25 and PIMS-REG-01 rather than reproducing them.

5. System boundaries

State precisely what is inside the description and what is outside. Inside: the environments, accounts, networks and teams that deliver the service. Outside: corporate systems that do not touch customer data, development sandboxes, other products. The boundary decides what the auditor tests; a vague boundary leads to testing everything.

The system comprises [the production environment, the identity provider used for staff and customer authentication, the build and deployment pipeline that releases to production, the monitoring platform and the ticketing system used for change and incident records]. It excludes [corporate email and office productivity systems, the marketing website, development and test environments that hold no customer data, and products other than [System name]].

6. Relevant aspects of the control environment, risk assessment, information and communication, and monitoring

A short account of how the common criteria CC1 to CC5 are met at the organisation level. One paragraph per heading, each pointing to the kit documents and registers. Keep claims testable.

• Control environment: GOV-POL-01 establishes the steering committee, roles and reporting lines; GOV-POL-03 is the policy approved by the Chief Executive Officer; GOV-PRO-18 covers screening, terms and consequences; GOV-PRO-08 covers training.
• Risk assessment: GOV-PRO-05 is the methodology; GOV-REG-05 the register; fraud and change are considered as the methodology states; GOV-PRO-24 governs acceptances.
• Information and communication: ISMS-PLN-02 sets internal and external communication; GOV-PRO-01 controls documents; GOV-REG-23 records acknowledgements; customers are informed of commitments, changes and incidents through [channel type].
• Monitoring: GOV-PRO-02 internal audit, SOC-PRO-01 control testing, ISMS-PRO-04 measurement, GOV-PRO-03 management review; deficiencies are tracked in GOV-REG-03.
• Control activities: SOC-REG-01 lists each control with its criteria, frequency, owner and evidence.

7. Trust services categories and criteria in scope

List the categories in scope and, for any criterion that does not apply to the system, the reason. Criteria are rarely not applicable; a common case is physical access criteria for an organisation with no premises of its own, where the subservice organisation's controls are relied on.

8. Complementary user entity controls

Controls that customers must operate for the criteria to be met. List only those genuinely necessary; each one is a shared responsibility the customer's auditor will check. Phrase them as what the customer does.

9. Subservice organisations

Name each supplier whose controls are necessary to meet a criterion, the services used, the method, and the controls [Organisation] assumes the supplier operates. The auditor will check that SOC-PRO-02 reviews are on file for each one.

Method: [Organisation] uses the carve-out method for the subservice organisations below. Their controls are not included in this description or in the auditor's tests. [Organisation] monitors them as SOC-PRO-02 describes.

Monitoring: [Organisation] obtains each subservice organisation's SOC 2 Type 2 report annually, reviews it under SOC-PRO-02, maps the complementary user entity controls to SOC-REG-01 and records the result in GOV-REG-07.

10. Significant changes during the period

Type 2 only. Changes to the system, the control set, the organisation or the subservice organisations during the period that a reader needs to understand the results. Include: a new control that started partway through the period and its start date, a replaced supplier, a reorganisation, an acquisition, a migration. If nothing significant changed, say so.

11. Incidents during the period

Type 2 only. Incidents that resulted in a failure to meet a service commitment or a criterion, with nature, timing, extent and the response. Minor incidents handled under GOV-PRO-07 with no commitment missed are not described individually. If none occurred, say so in one sentence.

12. Management's assertion reference and document control

The assertion is a separate signed statement that accompanies the description. Record here which assertion version this description supports and its approval.

Trust Services Criteria control matrix

One row per Trust Services Criteria point, with a plain-words theme and an auditable control activity, then the frequency, owner, evidence, implementing documents and test method that make it real. Fill the common criteria first; add the availability, confidentiality, processing integrity and privacy rows only for the categories in your report scope.

Serves: SOC 2 CC1.1; SOC 2 A1.1; SOC 2 C1.1; SOC 2 PI1.1; SOC 2 P1.1.

Columns:

• Criterion: Trust Services Criteria point. Read the AICPA criteria for the authoritative text.
• Theme
• Control activity: What the organisation does
• Frequency: How often the control operates.
• Owner (role)
• Evidence: The artefact that shows the control operating in the period.
• Implementing documents: Kit document IDs
• Test method
• Status

Evidence calendar

One row per recurring control event, at the cadence it runs, with the criteria it serves and the evidence it produces. The backbone of a Type 2 report, because every control needs evidence for every occurrence in the observation period. Set the owner, last done and next due, and work it as a calendar.

Serves: SOC 2 CC4.1.

Columns:

• Frequency
• Event
• Criteria: Primary criterion served.
• Owner (role)
• Evidence produced
• Last done
• Next due
• Status

SOC 2 readiness checklist

One hundred checks grouped by criteria area that tell you how ready you are for a SOC 2 examination. Mark each present, partial or missing, attach the evidence, and turn every gap into an action before the observation period begins.

Serves: SOC 2 CC1.1.

Columns:

• Criteria
• Check
• Status
• Evidence
• Owner (role)
• Due
• Notes

Guide: a GDPR operating model for a product or service team

How GDPR works as a day-to-day operating model for a team that builds or runs a product handling personal data, told through the life of the data and the register each stage updates.

Serves: GDPR Article 5; GDPR Article 24; GDPR Article 25; GDPR Article 30; GDPR Article 32. Owner: Privacy Officer.

1. Accountability in four things

GDPR is built on accountability: you must not only comply but be able to show it. In practice that means four things kept current. A map of the personal data you process. The operating processes that handle it. The evidence that those processes ran. Consistent statements to the outside world. This guide shows how each stage of the data lifecycle feeds those four things.

2. The roles

A product team usually needs a privacy owner who runs the programme, an approver for external statements, an engineering owner who knows where data actually lives, a support owner who handles requests, and leadership who owns the commitments. One person can hold several of these in a small team, but each must be named.

3. The lifecycle, stage by stage

Each stage below ends with the register it updates. The discipline is simple: when something happens to personal data, a register changes.

3.1 Sign-up or contract. A new customer or user brings personal data into scope. Record the processing, its purpose and its lawful basis, and make sure a privacy notice was shown. Updates: processing inventory (PIMS-REG-01), lawful basis, notice version.

3.2 Data arrives. Documents, uploads and integrations bring data in. Record where it flows and how it is protected in transit, and classify it. Updates: data flow map (GDPR-REG-02), asset register, classification.

3.3 Processing, including any AI feature. The product does something with the data. Where the processing is high risk, or an AI feature makes automated decisions, assess it. Record retention for inputs and outputs. Updates: DPIA register (PIMS-REG-08), AI inventory where relevant, retention schedule.

3.4 Sharing and suppliers. Data goes to a processor or a third party. Confirm the Article 28 terms are in place and that any transfer outside the region has a lawful mechanism. Updates: processor register (PIMS-REG-06), transfer register (PIMS-REG-05).

3.5 A request from a person. Someone asks to see, correct or delete their data. Verify identity, start the one-month clock, act, and respond. Updates: request register (PIMS-REG-02).

3.6 An incident. Data is lost or exposed. Contain it, assess the risk to individuals, and decide within seventy-two hours of awareness whether to notify the authority and the people affected. Record it either way. Updates: breach register (PIMS-REG-03).

3.7 End of the relationship. The customer leaves or the retention period ends. Delete the data across primary storage, derived data, backups and logs, not just the front-end record. Updates: retention schedule (PIMS-REG-07).

4. The cadence

Weekly, work through requests, incidents and supplier changes, and close a few outstanding items. Monthly, export the evidence that controls ran and reconcile the retention and vendor registers. Quarterly, refresh assessments and run an exercise. Annually, review the whole programme. The no-assumption rule holds throughout: every unknown becomes a line with an owner and a due date, and every gap becomes a corrective action.

5. Safe statements

Say what is true and nothing more. You process personal data under recorded lawful bases. You keep a record of processing. You have the processes and evidence to meet your obligations. Avoid "fully compliant" and "GDPR certified"; neither is a thing you can truthfully claim, and both invite a question you do not want.

6. Related documents

• GDPR-POL-01 Data protection policy
• GDPR-PRO-01 Data mapping and records of processing
• PIMS-REG-01 Personal data processing inventory
• GDPR-REG-01 GDPR gap assessment
• PB-04 GDPR operations in ten steps

Guide: GDPR articles mapped to the kit

The operational GDPR articles, each stated in plain words with the kit documents and registers that help you meet it. Read the regulation for the authoritative text.

Serves: GDPR Article 5; GDPR Article 30. Owner: Privacy Officer.

1. How to read this

Each row names an article, the obligation in plain words, and the kit documents or registers that address it. This is a map, not the law: the authoritative wording is in the regulation, and the map covers the articles a controller or processor operates against, not the whole text.

2. Principles and lawfulness

3. Rights of the individual

4. Controller and processor duties

5. International transfers

6. HR and marketing

7. Related documents

• GDPR-GDE-01 A GDPR operating model for a product team
• GDPR-REG-01 GDPR gap assessment
• PB-04 GDPR operations in ten steps

Data protection policy

The organisation-wide rules for handling personal data lawfully, the responsibilities that make the rules work, and the records that show they are followed.

Serves: GDPR Article 5; GDPR Article 24; GDPR Article 32; ISO/IEC 27701 clause 5.2; ISO/IEC 27001:2022 Annex A 5.34. Owner: Privacy Officer.

1. Purpose

This policy states how [Organisation] handles personal data about customers, users, staff, applicants, suppliers and anyone else whose data it holds, so that every person who touches personal data knows the rules and so that the organisation can demonstrate that it meets GDPR Article 5 and Article 24.

2. Scope

It applies to every employee, contractor and temporary worker, to every system, service and paper record that holds personal data, and to every processing activity in which [Organisation] acts as a controller, a joint controller or a processor. Where [Organisation] acts as a processor, the customer's documented instructions take precedence over any statement in section 4 that would conflict with them, and PIMS-PRO-01 records which role applies.

3. Roles and responsibilities

4. Policy statements

4.1 Lawfulness, fairness and transparency. Every processing activity has one lawful basis recorded in PIMS-REG-01 before it starts, and the people concerned are told about it through a notice built from GDPR-TPL-01, GDPR-TPL-02 or GDPR-TPL-03 at the point of collection, or within one month where the data was not collected from them.

4.2 Purpose limitation. Personal data is used only for the purposes stated in the notice and the inventory. A new purpose needs the Privacy Officer's written compatibility assessment, and, where the assessment fails, a new lawful basis and an updated notice before the new use begins.

4.3 Data minimisation. Teams collect only the data fields the recorded purpose needs. Every new form, field, integration and feature is checked against this statement under PIMS-PRO-06 before release.

4.4 Accuracy. Owners of systems that hold personal data provide a way for the people concerned, or staff acting for them, to correct it, and correct or delete inaccurate data within one month of learning that it is wrong.

4.5 Storage limitation. Every category of personal data has a retention period and a trigger recorded in PIMS-REG-07 under PIMS-POL-02. Data past its period is deleted or anonymised across primary storage, derived copies, backups and logs within the windows that schedule sets, and the deletion is recorded.

4.6 Special category and criminal offence data. Data about health, ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetics, biometrics, sex life or sexual orientation, and data about criminal convictions, is processed only where the Privacy Officer has recorded a condition under GDPR Article 9 or Article 10 in PIMS-REG-01, with access limited to named roles.

4.7 Consent. Where consent is the basis, it is collected with a form built from GDPR-TPL-06, recorded in PIMS-REG-04, and withdrawable as easily as it was given. Consent is never bundled with terms of service and is never a condition of a service that does not need the data. Consent from a child is handled under PIMS-PRO-05.

4.8 Legitimate interests. Where legitimate interests is the basis, a completed GDPR-TPL-07 assessment is approved by the Privacy Officer and recorded in GDPR-REG-03 before processing starts, and the people concerned can object.

4.9 Security. Personal data is protected by the controls in GOV-POL-03 and the procedures it mandates, proportionate to the risk recorded in GOV-REG-05 and, where a data protection impact assessment exists, in PIMS-REG-08. Restricted personal data is encrypted at rest and in transit under GOV-PRO-20.

4.10 Data subject rights. Every request to exercise a right under GDPR Articles 15 to 22 is logged in PIMS-REG-02 on the day it arrives and answered under PIMS-PRO-03 within one month, using the letters in GDPR-TPL-05. No request is refused without the Privacy Officer's written reasons.

4.11 Breaches. Anyone who suspects that personal data has been lost, altered, disclosed or made unavailable reports it immediately through the channel in GOV-PRO-07. The Privacy Officer assesses the breach under PIMS-PRO-04, notifies the supervisory authority within 72 hours of awareness where the risk test is met, using GDPR-TPL-10, and records every breach in PIMS-REG-03 whether or not it is notified.

4.12 Training. Every person completes privacy training at induction and annually, and people who handle requests, breaches, HR data or special category data complete role-based training, all recorded in GDPR-REG-05 under GOV-PRO-08.

4.13 Processors and sharing. Personal data is shared with a processor only under a contract that meets GDPR Article 28, built from PIMS-TPL-02 and recorded in PIMS-REG-06, after an assessment using GDPR-TPL-09 under GOV-PRO-06. Sharing with another controller is recorded in PIMS-REG-01 with its basis.

4.14 International transfers. Personal data leaves the region only under a mechanism in PIMS-POL-03, recorded in PIMS-REG-05, and, for transfers relying on contractual safeguards, after a transfer impact assessment using GDPR-TPL-08.

4.15 Privacy by design and impact assessment. Every project, feature and procurement that processes personal data is screened under PIMS-PRO-02 and, where a trigger applies, a data protection impact assessment using PIMS-TPL-01 is completed and approved before go-live, as checked at the gate in PB-07.

4.16 Records. The Privacy Officer keeps PIMS-REG-01 as the record of processing activities required by GDPR Article 30, reviewed under GDPR-PRO-01 at least quarterly.

4.17 Consequences. Breach of this policy is handled under the disciplinary process in GOV-PRO-18. Deliberate misuse of personal data may be gross misconduct and may be reported to the authorities.

5. Records and evidence

• PIMS-REG-01 Personal data processing inventory, with lawful bases and special category conditions.
• PIMS-REG-02 Data subject request register, PIMS-REG-03 Personal data breach register, PIMS-REG-04 Consent record register.
• GDPR-REG-03 Legitimate interests assessment register, PIMS-REG-05 International transfer register, PIMS-REG-06 Processor and sub-processor register.
• PIMS-REG-07 Retention schedule and the deletion records it requires.
• PIMS-REG-08 DPIA register.
• GDPR-REG-05 Privacy training register and GOV-REG-23 Policy acknowledgement register.
• Minutes of the steering committee showing the Privacy Officer's reports.

6. Exceptions

A legal obligation, a court order or a request from a competent authority may require processing outside a statement above. The Privacy Officer records the obligation, the data disclosed and the date in PIMS-REG-01 and informs the Chief Executive Officer. No other exception applies; a team that cannot meet a statement raises it under GOV-PRO-24.

7. Review and maintenance

The Privacy Officer reviews this policy annually, after a supervisory authority decision or guidance that affects the organisation, after a reportable breach, and after a change in the services offered or the regions served. Changes follow GOV-PRO-01 and are communicated to all staff with a new acknowledgement in GOV-REG-23.

8. Related documents

• PIMS-POL-01 Privacy information management policy
• PIMS-POL-02 Data retention and disposal policy
• PIMS-POL-03 International transfer policy
• PIMS-PRO-01 Determining controller and processor roles
• PIMS-PRO-02 Privacy risk and data protection impact assessment procedure
• PIMS-PRO-03 Data subject rights handling procedure
• PIMS-PRO-04 Personal data breach assessment and notification procedure
• PIMS-PRO-05 Consent and privacy notice management procedure
• PIMS-PRO-06 Privacy by design and by default procedure
• GDPR-PRO-01 Data mapping and records of processing procedure
• GDPR-PRO-02 HR data handling procedure
• GDPR-GDE-01 Guide: a GDPR operating model for a product or service team
• GOV-POL-03 Information security policy
• GOV-PRO-06 Supplier and third party security procedure
• GOV-PRO-07 Information security incident management procedure
• GOV-PRO-08 Security and privacy awareness and training procedure

Data mapping and records of processing procedure

How the organisation discovers, records and keeps current every processing activity and every flow of personal data, so that PIMS-REG-01 and GDPR-REG-02 are a true record of processing at any moment.

Serves: GDPR Article 30; GDPR Article 5(2); ISO/IEC 27701 clause 7.2.8; ISO/IEC 27701 Annex A 7.2.8; ISO/IEC 27001:2022 Annex A 5.9. Owner: Privacy Officer.

1. Purpose

This procedure produces and maintains the two records that every other privacy process depends on: the processing inventory in PIMS-REG-01, which is the record of processing activities that GDPR Article 30 requires, and the flow and transfer map in GDPR-REG-02, which shows where each item of personal data comes from, where it goes and under what safeguard. Without them a request cannot be answered completely, a breach cannot be scoped, a retention rule cannot be applied and a notice cannot be accurate.

2. Scope

It applies to every function, system, service, supplier relationship and paper process in which [Organisation] processes personal data as a controller, joint controller or processor, including trials, internal tools, analytics, backups, support tooling and features that use machine learning.

3. Roles and responsibilities

4. Procedure

4.1 Plan the mapping round. The Privacy Officer schedules one workshop per function (for example product, engineering, sales and marketing, customer support, people, finance) in the first mapping round, and one per changed function in later rounds. Each workshop has a function representative, the owners of the systems that function uses, and the Privacy Officer. The invitation lists the questions in step 4.3 so that representatives arrive with answers.

4.2 Collect the system view first. Before the workshop the Privacy Officer exports the asset list from GOV-REG-10, the supplier list from GOV-REG-07 and the interface list from GOV-REG-25, filters each to items that hold or move personal data, and brings the filtered lists to the workshop as a prompt. A system that holds personal data and appears in no activity is a gap to resolve in the workshop, not a line to delete.

4.3 Identify activities. In the workshop the Privacy Officer walks through what the function does to people, in the people's own terms: who they are (customers, users, staff, applicants, contacts, visitors), what happens to them (sign-up, billing, support, marketing, recruitment, monitoring), and why. Each distinct purpose with its own data set is one activity. Two purposes that use the same data are two activities. The same purpose across several systems is one activity with several systems. The test is whether a reader of the notice would recognise it as a separate thing the organisation does with their data.

4.4 Record each activity. For every activity the representative supplies, and the Privacy Officer records in PIMS-REG-01: the role of [Organisation] (controller, joint controller or processor, decided under PIMS-PRO-01); the purpose; the lawful basis, and the condition where special category or criminal offence data is involved; the categories of data subjects and of data; the source; the recipients, internal and external; whether data leaves the region and the safeguard; the retention period and trigger from PIMS-REG-07; the security measures by reference; the owner; and any DPIA reference from PIMS-REG-08. A row with any of these blank is marked Incomplete in its status and given an owner and a date.

4.5 Trace the flows. For every activity the System Owners trace the data from entry to deletion: the system or party it enters from, each system it is stored in or passed to, each third party it is sent to, and where backups and logs containing it are kept. Each hop is one row in GDPR-REG-02 with the data items that move, the direction, whether the destination is internal or external, the country, the transfer method, the safeguard, the controls on the hop (encryption, authentication, access restriction) and the owner. The team draws the flow as a simple diagram during the workshop and files the diagram against the activity in the evidence folder described in PB-09.

4.6 Resolve the gaps the trace exposes. Three findings are common and each has a fixed response. A flow to a supplier not in PIMS-REG-06 goes to the Privacy Officer, who starts GOV-PRO-06 and marks the flow Under review. A flow out of the region with no safeguard goes to PIMS-POL-03 and a GDPR-TPL-08 assessment, and the flow is suspended if it carries Restricted data. An activity with no lawful basis the representative can state is suspended until the Privacy Officer records one, or records the decision to stop the activity.

4.7 Check against the external statements. The Privacy Officer compares the completed rows with the current privacy notices built from GDPR-TPL-01, GDPR-TPL-02 and GDPR-TPL-03, the cookie inventory in GDPR-REG-04 and the customer-facing processing descriptions. Any activity, recipient, retention period or transfer in the registers that the notices do not describe is raised to PIMS-PRO-05 for a notice change, with the processing recorded as Partial in GDPR-REG-01 until the notice is published.

4.8 Approve the round. The head of each function confirms in writing that the rows for their function are complete and accurate. The Privacy Officer sets the status of each confirmed row to Current, records the round date, and reports the counts (activities, incomplete rows, flows under review, transfers without safeguard) to the steering committee under GOV-POL-01.

4.9 Triggers for an update between rounds. A function representative or System Owner reports to the Privacy Officer within five working days, and the Privacy Officer updates the registers within ten working days, when any of the following happens: a new product feature, form or integration that collects or sends personal data; a new or changed supplier; a new purpose for existing data; a new country of storage, support or processing; a change in retention; a change in the role of [Organisation] for a customer; a merger, acquisition or new entity; a data subject request or breach that reveals an unrecorded activity. The go-live gate in PB-07 and the change procedure in GOV-PRO-09 both ask whether the registers were updated, so a feature cannot ship with an unrecorded flow.

4.10 Quarterly review. Each quarter the Privacy Officer samples at least ten activities, checks each against the live system (a field list, an integration configuration, a supplier console, a retention setting) and records the result. A sample that fails on a material fact (an unrecorded recipient, transfer or data category) triggers a workshop for that function within thirty days.

4.11 Annual round. Once a year the full set of workshops in step 4.1 is repeated. The annual round also retires activities that have stopped, with the stop date recorded and the deletion confirmed under PIMS-POL-02.

4.12 Producing the Article 30 record. When a supervisory authority, an auditor or a customer asks for the record of processing, the Privacy Officer exports PIMS-REG-01 filtered to the role requested (controller rows or processor rows), dated, with the version of the register, and files a copy of what was sent.

5. Records and evidence

• PIMS-REG-01 Personal data processing inventory, with a status and round date on every row.
• GDPR-REG-02 Data flow and transfer map, with a diagram per activity in the evidence folder.
• Workshop attendance notes and the function heads' written confirmations.
• Quarterly sample records and any workshops they triggered.
• Copies of every Article 30 export provided to an external party.
• GDPR-REG-01 rows for Article 30 updated with the evidence reference.

6. Exceptions

An activity may remain Incomplete for no more than sixty days while a supplier or customer supplies a fact only they hold, with the Privacy Officer's agreement noted on the row. No activity runs without a recorded lawful basis.

7. Review and maintenance

The Privacy Officer reviews this procedure annually, after an audit finding or supervisory authority enquiry about the record of processing, and after a change in the organisation's structure. Changes follow GOV-PRO-01.

8. Related documents

• PIMS-REG-01 Personal data processing inventory
• GDPR-REG-02 Data flow and transfer map
• PIMS-PRO-01 Determining controller and processor roles
• PIMS-PRO-05 Consent and privacy notice management procedure
• PIMS-POL-02 Data retention and disposal policy
• PIMS-POL-03 International transfer policy
• GDPR-TPL-08 Transfer impact assessment template
• GOV-PRO-06 Supplier and third party security procedure
• GOV-PRO-09 Change management procedure
• GOV-REG-10 Information asset register
• GOV-REG-25 Data flow and interface inventory
• PB-07 Playbook: the go-live security and privacy gate for a software project
• PB-09 Playbook: evidence management that survives an audit
• GDPR-GDE-01 Guide: a GDPR operating model for a product or service team

HR data handling procedure

How personal data about applicants, employees, contractors and former staff is collected, used, protected, retained and deleted at each stage from recruitment to after departure.

Serves: GDPR Article 5; GDPR Article 6; GDPR Article 9; GDPR Article 88; ISO/IEC 27701 Annex A 7.2.2; ISO/IEC 27001:2022 Annex A 6.1. Owner: Privacy Officer.

1. Purpose

This procedure gives the people function and line managers a single set of steps for handling the personal data of the workforce, so that recruitment, employment, monitoring, references and leaving are all done on a recorded lawful basis, with the minimum data, for a defined period, and with special category data under tighter control.

2. Scope

It applies to data about job applicants, employees, contractors, temporary workers, interns and former members of any of those groups, in every system and paper file that holds it, including the HR system, payroll, recruitment tools, email, shared drives, access control and monitoring systems, and the files that managers keep.

3. Roles and responsibilities

4. Procedure

4.1 Recruitment: collection. The HR Administrator publishes the applicant notice built from GDPR-TPL-03 on every application channel before any data is entered. Application forms ask only for the data needed to assess suitability for the advertised role. Equal opportunities monitoring questions are optional, kept separate from the application, and seen only in aggregate. Social media and public sources are searched only where the Head of People has recorded the need for the role, and the applicant is told.

4.2 Recruitment: assessment. Interviewers record their notes in the recruitment system, not in personal files, limit them to evidence against the role criteria, and are told at interview training that the candidate may obtain the notes under a request. Tests and assessments are used only where PIMS-PRO-02 screening shows no automated decision in the sense of GDPR Article 22, or where a human reviews every rejection.

4.3 Pre-employment checks. Checks are proportionate to the role and recorded in GOV-PRO-18. Identity and right to work checks are kept as the law requires. Criminal record checks are run only for roles where the law permits them and the Privacy Officer has recorded the condition in PIMS-REG-01. Reference requests are sent only after the candidate agrees to them, and references received are held on the employee file.

4.4 Unsuccessful applicants. The HR Administrator deletes the data of unsuccessful applicants [Number] months after the decision, no later than twelve, unless the applicant has agreed in writing to be kept in a talent pool for a stated period. The deletion covers the recruitment system, email folders and interviewers' notes.

4.5 Employment records. On joining, the HR Administrator creates one employee record in the HR system, gives the employee the notice built from GDPR-TPL-02 with the contract, and records in GDPR-REG-05 the induction privacy training completed under GOV-PRO-08. Managers hold no local copies of contracts, pay details, absence reasons or performance records; they work in the HR system. Emergency contact details are collected with the contact's name, relationship and number only, and the employee is asked to tell the contact.

4.6 Special category data. Health data (absence reasons, adjustments, occupational health reports), trade union membership, and any other special category data is held in a restricted section of the HR system that only the people function and the Privacy Officer can read. Managers see fitness to work and adjustments needed, not diagnoses. Such data is processed under an employment law condition recorded in PIMS-REG-01, or with explicit consent collected with GDPR-TPL-06 where the law allows and the employee is free to refuse.

4.7 Monitoring. Monitoring of email, internet, devices, access logs or location is introduced only after the Privacy Officer and the Information Security Manager approve a written purpose and scope, the screening in PIMS-PRO-02 is complete, and staff have been told through the notice and GOV-POL-02. Monitoring is targeted at the purpose (security, legal compliance, safety), is not continuous surveillance of individuals, and covert monitoring is used only for a specific suspected serious offence, authorised by the Chief Executive Officer, for a fixed period, and recorded.

4.8 Disclosures. Workforce data is disclosed outside the people function only: to processors in PIMS-REG-06; to tax, social security and other authorities where the law requires; to a prospective employer giving a reference, limited to dates, role and, where the organisation's reference policy allows, factual performance statements; to a customer or client where the contract requires named staff details, limited to name, role and qualifications; to insurers and pension providers for the scheme concerned. Any other disclosure needs the Head of People's written approval and a lawful basis recorded by the Privacy Officer.

4.9 Rights of the workforce. Requests from applicants, employees and former staff follow PIMS-PRO-03. Access requests from employees are common in grievances and disciplinary processes; the HR Administrator searches the HR system, email of the people function and the relevant managers, and shared drives, and applies the exemptions for third party data and confidential references with the Privacy Officer.

4.10 Leavers. On the last day the HR Administrator triggers the offboarding tasks in GOV-CHK-01, moves the employee record to the leaver status, and records the leaving date as the retention trigger. Within thirty days the HR Administrator removes the person from distribution lists, internal directories and any system where their account was not removed by GOV-PRO-10, and confirms to the Privacy Officer.

4.11 Retention and deletion. Each HR category has a period in PIMS-REG-07: the employee file for [Number] years after leaving as employment and tax law require, payroll records for the statutory period, recruitment records under step 4.4, health and safety records for the period the law sets, monitoring records for no more than [Number] months unless part of an investigation. The HR Administrator runs the retention report quarterly, deletes expired records in the HR system, email and shared drives, asks processors in PIMS-REG-06 to confirm their deletion, and records the run.

4.12 New HR tools and changes. A new recruitment, HR, payroll, survey, wellbeing or monitoring tool goes through GOV-PRO-06 and GDPR-TPL-09, PIMS-PRO-02 screening, and the processing inventory update in GDPR-PRO-01 before any workforce data is entered.

5. Records and evidence

• PIMS-REG-01 rows for recruitment, employment administration, payroll, benefits, performance, absence and health, monitoring and references.
• GDPR-REG-05 Privacy training register showing induction and HR handler training.
• Retention report runs and deletion records under PIMS-REG-07.
• PIMS-REG-02 entries for workforce requests.
• Monitoring approvals and, where used, covert monitoring authorisations.
• Disclosure approvals under step 4.8.
• GOV-CHK-01 completed checklists for joiners and leavers.

6. Exceptions

Records subject to a legal hold, a live grievance, disciplinary case, claim or investigation are kept until the Head of People and the Privacy Officer release the hold in writing, and the hold is recorded on the retention report. No other exception applies.

7. Review and maintenance

The Privacy Officer and the Head of People review this procedure annually, after a change in employment or data protection law affecting the workforce, after a workforce-related breach or complaint, and after the introduction of a new HR system or monitoring tool. Changes follow GOV-PRO-01.

8. Related documents

• GDPR-TPL-02 Employee privacy notice template
• GDPR-TPL-03 Job applicant privacy notice template
• GDPR-TPL-06 Consent form templates (customers and employees)
• GDPR-TPL-09 Supplier GDPR assessment questionnaire
• GDPR-PRO-01 Data mapping and records of processing procedure
• PIMS-PRO-02 Privacy risk and data protection impact assessment procedure
• PIMS-PRO-03 Data subject rights handling procedure
• PIMS-POL-02 Data retention and disposal policy
• PIMS-TPL-02 Data processing agreement template
• GOV-PRO-18 Human resources security procedure
• GOV-PRO-10 Access management procedure (joiners, movers, leavers, privileged access, reviews)
• GOV-POL-02 Acceptable use policy
• GOV-CHK-01 Onboarding and offboarding security checklist
• GOV-PRO-14 Logging, monitoring and alert handling procedure

Privacy notice template (customers and website)

The customer and website privacy notice with every element GDPR Articles 13 and 14 require, as sections with placeholders and guidance notes, maintained under PIMS-PRO-05.

Serves: GDPR Article 12; GDPR Article 13; GDPR Article 14; ISO/IEC 27701 Annex A 7.3.2; ISO/IEC 27701 Annex A 7.3.3. Owner: Privacy Officer.

Guidance notes are in italics and are removed before publication. Every section below corresponds to an element the law requires; do not delete a section, write "not applicable" with a reason instead. Write for the reader, not the regulator: short sentences, no legal citations in the body, a reading age of about twelve. Each fact in this notice must match a row in PIMS-REG-01; the Privacy Officer checks the match before publication and after every change, and records the version in GOV-REG-01. Where data is obtained from someone other than the person, the notice is provided within one month, or at first contact or first disclosure if earlier.

1. Who we are

[Organisation], [registered address], is the controller of the personal data described in this notice. If a representative is appointed under GDPR Article 27, name it here with contact details. If the organisation acts as a processor for business customers, say so and point readers to the customer who decides how their data is used.

You can contact us about anything in this notice at [contact channel]. Where a Data Protection Officer is designated, give the DPO's contact details here; they may be a role mailbox rather than a name.

2. What this notice covers

This notice explains what we do with personal data when you visit [website or application], create an account, use [Product or service], contact us, or receive marketing from us. List every audience the notice covers. Employees and applicants have their own notices built from GDPR-TPL-02 and GDPR-TPL-03. Cookies and similar technologies are covered in the notice built from GDPR-TPL-04 and may be linked from here.

3. The data we collect and where it comes from

One row per category of data. The "source" column satisfies the Article 14 requirement for data not collected from the person; include publicly available sources where used.

4. Why we use your data and the legal basis

One row per purpose. Each purpose needs exactly one basis from: performance of a contract, legal obligation, legitimate interests (state the interest), consent, vital interests, public task. Where legitimate interests is the basis, the interest named here must match the GDPR-REG-03 entry. Where consent is the basis, say how to withdraw it.

5. Automated decisions

Required where decisions with legal or similarly significant effects are made solely by automated means. If none, keep the first sentence.

We do not make decisions about you based solely on automated processing that have legal or similarly significant effects on you. [If this changes, we will tell you how the decision is made, why it matters and how to ask for a person to review it.]

6. Who we share your data with

List categories of recipients, and name them where the reader would reasonably expect it. Every processor listed here is in PIMS-REG-06. Sharing between group companies counts as sharing.

• Service providers that act on our instructions: [hosting, email delivery, payment processing, customer support tools, analytics]. They may only use your data to provide their service to us.
• [Group companies], for [purpose].
• Professional advisers, insurers and auditors, where needed.
• Authorities, regulators and courts, where the law requires or allows it.
• A buyer or successor, if our business or part of it is sold or reorganised, under confidentiality terms.

We do not sell your personal data.

7. Where your data is stored and international transfers

Your data is stored in [country or region]. State every country where data is stored, supported from or processed, including by processors; this must match PIMS-REG-05 and GDPR-REG-02.

Where we transfer your data outside [region], we rely on [an adequacy decision by the relevant authority, standard contractual clauses approved by the relevant authority, binding corporate rules, or a derogation such as your explicit consent or the performance of your contract]. You can ask us for a copy of the safeguards we use at the contact in section 1. Name the mechanism per destination; never write "appropriate safeguards" alone.

8. How long we keep your data

One row per category, matching PIMS-REG-07. Where a fixed period cannot be stated, give the criteria used to decide it.

9. Your rights

You have the right to ask us for access to your personal data, to correct it, to delete it, to restrict how we use it, to receive it in a portable format, and to object to processing based on our legitimate interests. Where we rely on your consent, you may withdraw it at any time without affecting what was done before. You may object to direct marketing at any time and we will stop.

To exercise a right, contact us at [contact channel]. We will respond within one month and tell you if we need longer. We may ask you to confirm your identity. The response process is PIMS-PRO-03; the letters are in GDPR-TPL-05.

You also have the right to complain to a supervisory authority. Ours is [name of supervisory authority]. We would appreciate the chance to resolve your concern first, but you may contact the authority at any time.

10. Whether you must provide your data

Required where data is collected from the person. State what is needed for the contract or by law and what happens if it is not provided.

To open an account and use [Product or service] you must give us [the data marked as required on the sign-up form]. Without it we cannot provide the service. All other data is optional, and we tell you when it is.

11. Children

[Product or service] is not intended for children under [Number]. We do not knowingly collect data from them. Where the service is offered to children, describe the age check and how parental consent is obtained, under PIMS-PRO-05.

12. Changes to this notice

We will post any change here, with the date, and will tell you by [channel] before a change that affects how we use data we already hold about you. Material changes follow PIMS-PRO-05 and are recorded in GOV-REG-01 with the previous versions kept.

Version [Number], effective [Date].

13. Related documents

• PIMS-PRO-05 Consent and privacy notice management procedure
• PIMS-REG-01 Personal data processing inventory
• PIMS-REG-05 International transfer register
• PIMS-REG-06 Processor and sub-processor register
• PIMS-REG-07 Retention schedule
• GDPR-REG-03 Legitimate interests assessment register
• GDPR-TPL-04 Cookie and tracking technologies notice template
• GDPR-TPL-05 Data subject request response letters
• PIMS-PRO-03 Data subject rights handling procedure

Employee privacy notice template

The notice given to employees, contractors and temporary workers with their contract, describing how [Organisation] uses workforce data under GDPR-PRO-02.

Serves: GDPR Article 13; GDPR Article 88; ISO/IEC 27701 Annex A 7.3.2. Owner: Privacy Officer.

Guidance notes are in italics and are removed before issue. Give this notice with the employment contract or engagement letter, record the issue in the employee file, and re-issue it after any material change. Each statement must match the HR rows in PIMS-REG-01 and the periods in PIMS-REG-07. Where a works council, staff association or collective agreement exists, consult it before changes to sections 5 and 7.

1. Who we are and who to contact

[Organisation], [registered address], is the controller of the personal data we hold about you as a member of our workforce. Questions about this notice go to [the people function contact channel] or to [the Privacy Officer or Data Protection Officer contact].

2. Who this notice covers

This notice applies to employees, contractors, temporary and agency workers, interns and volunteers, during your engagement and afterwards for as long as we keep your records. Applicants have a separate notice given during recruitment.

3. The data we hold

Most of this data comes from you. Some comes from your manager, from colleagues (for example in appraisals), from referees, from background check providers, and from the systems you use.

4. Why we use your data and on what basis

Where we rely on legitimate interests we have recorded an assessment and you may object; contact us at the channel in section 1.

5. Who we share your data with

• Payroll, pension, benefits, HR system, training and occupational health providers, who act on our instructions.
• Tax, social security and other authorities, where the law requires.
• Customers and clients, where a contract requires your name, role and qualifications.
• Prospective employers, for references after you leave, limited to [dates, role and factual statements].
• Professional advisers, insurers and auditors, where needed.
• [Group companies], for [purpose].

6. Special category data

Health data, trade union membership and the equality monitoring data you choose to give are held in a restricted part of the HR system that only the people function and [Privacy Officer] can read. Your manager sees what they need to support you at work, such as adjustments and fitness to work, not medical detail. We never use this data for any purpose other than the ones in section 4.

7. Monitoring

We monitor the use of our systems for security, to meet legal duties and to protect our information, as set out in the acceptable use policy. Monitoring covers [email and internet logs, system access logs, device management records, building access records, CCTV in the areas marked]. It is not continuous observation of individuals. Covert monitoring is used only to investigate a suspected serious offence, is authorised at the highest level, and is time-limited. The monitoring described here must match the approvals recorded under GDPR-PRO-02 step 4.7 and GOV-POL-02.

8. Where your data is kept

Your data is held in [country or region]. Where a provider processes it outside [region], we rely on [named transfer mechanism] and you may ask for a copy of the safeguards.

9. How long we keep it

10. Your rights

You may ask for access to your data, correct it, ask for deletion where we no longer need it, restrict or object to some uses, and withdraw any consent you gave. Contact [channel]. We respond within one month. You may complain to [supervisory authority] at any time.

11. Your obligations

You must keep your personal details current in [HR system], treat colleagues' data in line with GDPR-POL-01, and report any suspected breach at once.

12. Changes

We will tell you by [channel] before any change that affects how we use your data. Version [Number], effective [Date].

13. Related documents

• GDPR-PRO-02 HR data handling procedure
• GDPR-POL-01 Data protection policy
• GOV-POL-02 Acceptable use policy
• PIMS-REG-01 Personal data processing inventory
• PIMS-REG-07 Retention schedule
• PIMS-PRO-03 Data subject rights handling procedure

Job applicant privacy notice template

The notice shown to candidates on every application channel before they submit data, covering what [Organisation] collects during recruitment, from whom, why, who sees it and for how long.

Serves: GDPR Article 13; GDPR Article 14; ISO/IEC 27701 Annex A 7.3.2. Owner: Privacy Officer.

Guidance notes are in italics and are removed before publication. Publish this notice on the careers page, link it from every job advertisement and application form, and give it to recruitment agencies to pass to candidates they introduce. Where data is obtained from a referee, an agency, a background check provider or a public source, this notice must reach the candidate within one month, which the application step achieves. The facts must match the recruitment rows in PIMS-REG-01 and the periods in PIMS-REG-07.

1. Who we are and who to contact

[Organisation], [registered address], is the controller of the personal data we collect about you when you apply to work with us. Questions go to [recruitment contact channel] or [the Privacy Officer or Data Protection Officer contact].

2. The data we collect

3. Why we use your data and on what basis

4. Automated decisions

We do not make recruitment decisions based solely on automated means. [Where we use screening tests or tools, a member of the recruitment team reviews every decision to reject a candidate.] If this is not true, describe the automated step, its logic in plain terms, its significance and how to request human review, and complete a PIMS-PRO-02 screening first.

5. Who sees your data

The recruitment team, the hiring manager, interviewers and assessors for the role, the people function, and, after an offer, [the background check provider]. Our recruitment system is provided by [category of provider] acting on our instructions. We share your data with referees only to confirm you named them. We do not share applications with other employers.

6. Where your data is kept

[Country or region]. Where a provider processes data outside [region] we rely on [named transfer mechanism].

7. How long we keep your data

8. Your rights

You may ask for a copy of the data we hold about you, including interview notes, correct it, ask for deletion, object to processing based on our legitimate interests, and withdraw consent to the talent pool or equality monitoring at any time. Contact [channel]. We respond within one month. You may complain to [supervisory authority].

9. Whether you must provide data

You must provide the data marked as required on the application form; without it we cannot consider your application. Equality monitoring answers and talent pool consent are optional and do not affect your application.

10. Changes

Version [Number], effective [Date]. We will post changes on this page.

11. Related documents

• GDPR-PRO-02 HR data handling procedure
• GDPR-TPL-02 Employee privacy notice template
• GOV-PRO-18 Human resources security procedure
• PIMS-REG-01 Personal data processing inventory
• PIMS-REG-07 Retention schedule
• PIMS-PRO-03 Data subject rights handling procedure

Cookie and tracking technologies notice template

The public notice for cookies, local storage, pixels and software development kits, with the categories table, how consent is collected and withdrawn, and the link to the inventory in GDPR-REG-04 that keeps it true.

Serves: GDPR Article 6; GDPR Article 7; GDPR Article 13; ISO/IEC 27701 Annex A 7.2.3. Owner: Privacy Officer.

Guidance notes are in italics and are removed before publication. The ePrivacy rules require consent before any storage or reading on a device that is not strictly necessary for a service the person asked for; GDPR sets the standard of that consent. This notice is generated from GDPR-REG-04: every tracker in the inventory appears in the table below, and nothing appears here that is not in the inventory. The Privacy Officer re-runs the site scan and reconciles the table at least quarterly and before every release that adds a script, tag or SDK.

1. What this notice covers

This notice explains the cookies and similar technologies we use on [website or application], what they do, and how you can control them. "Similar technologies" means anything that stores or reads information on your device: local storage, pixels and web beacons, software development kits in our mobile applications, and scripts that read device characteristics.

2. The categories we use

3. The cookies and trackers we use

Reproduce the current GDPR-REG-04 export, one row per tracker. Keep the table under six columns; split by category if long.

Third parties that set cookies through our site act as [controllers in their own right or our processors]. Their own notices are linked in the table where they are controllers. Where a third party receives data outside [region], the transfer relies on [named mechanism], recorded in our transfer register.

4. How we ask for your consent

When you first visit, a banner asks you to choose. Nothing in the Functional, Analytics, Advertising or Social media categories is set until you accept it. The banner offers "Accept all", "Reject all" and "Choose" with equal prominence, and no category is pre-ticked. Closing the banner without choosing, scrolling or continuing to browse is not consent, and only strictly necessary technologies run.

Your choice is recorded, with the date, the version of this notice and the categories you accepted, in a strictly necessary cookie and in our consent record, so that we can show what you agreed to. Record the consent in PIMS-REG-04 or the consent platform's log, keep the log for the period in PIMS-REG-07, and keep the banner wording of each version under GOV-REG-01.

We ask again when we add a new category or a new third party, or after [Number] months, whichever comes first.

5. How to withdraw or change your choice

Open [the "Cookie settings" link in the footer] at any time, change the categories and save. Withdrawing consent stops the technologies in that category from the moment you save; data already collected is handled as described in the privacy notice. Withdrawal is as easy as giving consent: the same number of clicks, no account needed.

You can also delete cookies and block storage in your browser or device settings. If you do, our consent record is deleted too and the banner will appear again.

6. Do Not Track and similar signals

[We honour the Global Privacy Control signal from your browser as a rejection of Advertising and Social media categories.] Delete or adjust to match what the site actually does; never claim to honour a signal that is not implemented.

7. Mobile applications

Our [application name] uses software development kits from [named providers] for [crash reporting, analytics, advertising]. The application asks for the same categories of consent at first launch and in [Settings, Privacy]. Operating system permissions, such as location or advertising identifier access, are requested separately by the device and can be withdrawn in its settings.

8. Contact and complaints

Questions about this notice go to [contact channel]. You may complain to [supervisory authority]. Our full privacy notice explains your other rights.

Version [Number], effective [Date].

9. Related documents

• GDPR-REG-04 Cookie and tracker inventory
• GDPR-TPL-01 Privacy notice template (customers and website)
• GDPR-TPL-06 Consent form templates (customers and employees)
• PIMS-PRO-05 Consent and privacy notice management procedure
• PIMS-REG-04 Consent record register
• PIMS-REG-05 International transfer register

Data subject request response letters

Five letters used under PIMS-PRO-03 at the fixed points of a request: acknowledgement, identity verification, extension, response with data, and refusal with reasons and the complaint route.

Serves: GDPR Article 12; GDPR Article 15; GDPR Article 16; GDPR Article 17; GDPR Article 18; GDPR Article 20; GDPR Article 21; GDPR Article 22; ISO/IEC 27701 Annex A 7.3.9. Owner: Privacy Officer.

Guidance notes are in italics. Each letter is sent by the Privacy Officer or the person handling the request, on the day the step in PIMS-PRO-03 is reached, through the channel the requester used unless they asked for another. Record the date sent and the letter used in PIMS-REG-02. Replace every placeholder; delete the guidance; never add legal citations the requester did not ask for. The one month clock runs from the day the request is received, not from the day identity is confirmed, unless the request cannot be acted on without identification and the requester was told without delay.

1. Letter A: acknowledgement

Send within three working days of receipt. Use for every right, changing the second paragraph to name the right.

Dear [Name],

Thank you for your request, which we received on [Date]. Our reference is [PIMS-REG-02 reference]; please quote it in any further message.

We understand that you are asking us to [provide a copy of the personal data we hold about you / correct the following data / delete your personal data / restrict how we use your data / provide your data in a portable format / stop processing your data for the following purpose / review a decision made about you]. If we have misunderstood, please tell us.

We will respond by [Date, one month from receipt]. If your request is complex or you have made several requests, we may need up to two further months, and we will tell you before [Date] if that is the case, with the reason.

We do not charge for handling requests unless a request is clearly unfounded or excessive, in which case we will tell you before doing anything.

If we need to confirm your identity or to ask what data you are looking for, we will write to you separately.

Yours sincerely,

[Name], [Role] [Organisation]

2. Letter B: identity verification request

Send only when the identity of the requester cannot be confirmed from the channel used (for example a request from an authenticated account needs no further check). Ask for the least intrusive evidence that resolves the doubt. Never ask for more than the organisation already holds about the person. Tell the requester that the clock does not run while identification is outstanding only where that is the organisation's documented position.

Dear [Name],

Thank you for your request of [Date], reference [Reference].

Before we act on it we need to be sure that we are dealing with the person the data is about, so that we do not disclose or change someone's data at the request of another person.

Please [sign in to your account and resubmit the request from the request page / reply from the email address registered on your account / provide [one specific item, for example the postcode and the last four digits of the telephone number registered on the account] / provide a copy of one identity document with everything except your name, photograph and date of birth covered].

[If you are acting for someone else, please also provide the written authority of the person the data is about, or evidence of your legal authority to act for them.]

We will delete the identification evidence [Number] days after your request is closed and will not use it for any other purpose.

We will respond within one month of receiving this evidence. If we do not hear from you within [Number] days we will close the request, and you may make a new one at any time.

Yours sincerely,

[Name], [Role]

3. Letter C: extension notice

Send before the one month deadline, never after. The reason must be true and specific: volume, complexity or number of requests. "We are busy" is not a reason. Record the new date in PIMS-REG-02.

Dear [Name],

We are writing about your request of [Date], reference [Reference], which we would normally answer by [original date].

We need more time because [the request covers [Number] years of records across [Number] systems and the search must be completed and reviewed by hand / you have made [Number] separate requests which we are handling together / the request requires us to review material that includes other people's data]. We expect to respond by [new date, no more than two further months after the original date].

We have already [state what has been done]. If it would help, you may narrow the request to [a period, a system or a type of data] and we may be able to respond sooner.

We apologise for the delay.

Yours sincerely,

[Name], [Role]

4. Letter D: response with data (access request)

Attach the data as a structured export where possible, in a commonly used format, through a secure channel; never by unencrypted email. Include the supplementary information below: it is part of the right, not an optional cover note. Where the response also answers another right (correction, deletion, portability, objection), add a paragraph stating what was done and when, and keep the same structure.

Dear [Name],

Thank you for your request of [Date], reference [Reference]. We have completed our search and enclose the personal data we hold about you.

What we searched. [Named systems, email of the named functions, paper files], covering [period]. We searched using [your name, email address, account identifier, customer reference].

What is enclosed. [A file in [format] containing [Number] records, organised by [system or category].] Where a document contains information about other people, we have removed that information or the document, as the law allows; we have noted where this was done.

Why we hold this data and on what basis. [Short list of purposes and bases, matching the privacy notice.]

Where it came from. [You, and the sources named in the enclosed summary.]

Who we have shared it with. [Categories of recipients, and named recipients where known.]

How long we keep it. [The periods, or the criteria used.]

International transfers. [None / The data is processed in [country] under [mechanism], and you may ask for a copy of the safeguards.]

Automated decisions. [We do not make decisions about you by solely automated means. / A description of the logic, significance and consequences of the decision concerned.]

Your other rights. You may ask us to correct or delete this data, to restrict or object to our use of it, or to receive it in a portable format. You may complain to [supervisory authority] if you are unhappy with our response.

[Paragraph for other rights, where applicable: We have corrected [field] on [Date]. / We deleted your personal data from [systems] on [Date]; copies in backups will be removed within [Number] days under our backup cycle and cannot be restored to live use. / We have restricted [data] and will use it only for [purpose]. / We have stopped [processing] on [Date]. / We told the recipients listed above of the correction or deletion on [Date].]

Yours sincerely,

[Name], [Role]

5. Letter E: refusal with reasons and complaint route

A refusal, in whole or in part, needs the Privacy Officer's written approval in PIMS-REG-02 before it is sent. State the specific ground; the common ones are: the request is clearly unfounded or excessive (give the facts); the data is needed for a legal obligation or legal claims; deletion would conflict with a retention duty; the data is a confidential reference or concerns another person who has not agreed; the right does not apply to the lawful basis used (for example portability where the basis is legitimate interests). Where part of the request is granted, combine with Letter D and state what was and was not done.

Dear [Name],

Thank you for your request of [Date], reference [Reference], asking us to [right requested].

We have considered your request carefully, and we are not able to [act on it / act on the following part of it: [part]].

The reason is that [specific ground in plain words, for example: we are required by tax law to keep invoice records for [Number] years, and the data you have asked us to delete forms part of those records. We will delete it when that period ends on [Date]. / the records you asked for contain information about other people who have not agreed to its disclosure, and we cannot separate it from your information. / you have made [Number] requests for the same data since [Date] and we provided it on [Date]; we consider a further copy excessive. If you believe the data has changed since then, please tell us what you expect to find.]

[We have done the following instead: [what was done].]

If you disagree with this decision, you may ask us to review it by writing to [contact], and a person who was not involved in the original decision will review it within [Number] days. You also have the right to complain to [supervisory authority, contact details] and to seek a remedy through the courts.

Yours sincerely,

[Name], [Role]

6. Related documents

• PIMS-PRO-03 Data subject rights handling procedure
• PIMS-REG-02 Data subject request register
• GDPR-TPL-01 Privacy notice template (customers and website)
• GDPR-POL-01 Data protection policy

Consent form templates (customers and employees)

Two consent forms, one for customers and users and one for employees, each containing the elements that make consent valid, with the record that PIMS-REG-04 keeps for every consent given or withdrawn.

Serves: GDPR Article 7; GDPR Article 4; GDPR Article 9(2)(a); ISO/IEC 27701 Annex A 7.2.3; ISO/IEC 27701 Annex A 7.2.4. Owner: Privacy Officer.

Guidance notes are in italics and are removed before use. Consent is the right basis only when the person has a real choice and the organisation would accept a refusal; PIMS-PRO-05 records that decision before a form is used. A valid consent is freely given, specific to a stated purpose, informed, and shown by a clear affirmative act. It is never a pre-ticked box, silence, inactivity or a condition buried in terms. The form must be as easy to withdraw as to give, and the organisation must be able to show, for each person, what they consented to, when, how and under which version of the wording.

1. Customer and user consent form

Use one form per purpose, or one form with one separately tickable box per purpose. Each box is unticked by default. The service must work without the box being ticked unless the data is genuinely needed for it, in which case consent is the wrong basis.

[Organisation] would like your permission

We would like to [state the purpose in one sentence, for example: send you a monthly newsletter about new features and offers by email].

To do this we will use [the data concerned, for example: your name and email address]. We will not use it for anything else without asking you.

[Where relevant: We will share it with [named recipient] so that they can [purpose]. / We will keep it for [period] or until you withdraw your permission.]

You do not have to agree. If you do not, [state the consequence, which must be none for the core service, for example: you can still use your account exactly as before].

You can withdraw your permission at any time by [the mechanism, for example: clicking the link at the bottom of any message, or changing the setting at Account, Preferences]. Withdrawing does not affect anything we did before.

[ ] Yes, I agree that [Organisation] may [purpose] using [data]. (one box per purpose; unticked by default)

[ ] Yes, I agree that [Organisation] may share my [data] with [named recipient] for [purpose]. (only where sharing is itself consented to)

Our privacy notice at [location] explains your rights. Questions: [contact].

Where the data is special category data (for example health data in a wellbeing feature), the box must say "explicit" consent in substance: name the type of data, state the purpose and ask the person to confirm. Where the person is a child below the age set by the applicable law, obtain and verify the consent of the holder of parental responsibility under PIMS-PRO-05 and record how it was verified.

2. Employee consent form

Consent from an employee is valid only where refusal carries no detriment and the organisation can show that. Do not use consent for anything the employment contract, a legal duty or a legitimate interest already covers; use it for genuinely optional matters such as a photograph on the public website, participation in a wellbeing programme, equality monitoring, or a reference beyond the standard factual one. Collect it on paper or in the HR system, never by a reply to a group email.

Optional permission request

Name: [Name] Role: [Role] Date: [Date]

[Organisation] would like your permission to [purpose, for example: publish your name, role and photograph on the team page of our public website].

This is optional. Saying no has no effect on your employment, your pay, your development or how you are treated. If you say nothing, we will treat that as no.

The data involved is [data]. It will be seen by [recipients] and kept [for the period, or until you withdraw permission]. It will not be used for any other purpose.

You can withdraw your permission at any time by telling [the people function contact] in writing. We will [action on withdrawal, for example: remove the photograph within five working days]. Withdrawal does not affect anything done before.

[ ] I give my permission for the use described above.

[ ] I do not give my permission.

Signature: [Signature] Date: [Date]

For special category data (for example health data for a wellbeing programme or an occupational health referral beyond the legal duty), add: "I understand that this involves information about my [health / ethnic origin / other] and I explicitly agree to its use for the purpose above and no other."

3. The consent record

For every consent given or withdrawn, create or update one entry in PIMS-REG-04 with the fields below. Where consent is collected in a product, the product must capture the same fields; a boolean flag without the wording version and timestamp is not a record. Keep the wording of every version of each form under GOV-REG-01 so that the record can be read back.

4. Checks before a form is used

The Privacy Officer confirms each item and records the check in PIMS-REG-04 or the form's approval record.

1. The purpose is one the organisation would accept a refusal for.
2. One box per purpose, none pre-ticked, consent not bundled with terms.
3. The data, recipients and retention named on the form match PIMS-REG-01.
4. Withdrawal takes no more effort than giving consent, and the withdrawal action is implemented and tested.
5. The record in section 3 is captured automatically or by a defined manual step.
6. For employees, the detriment statement is true and the manager is not the person collecting the form.

5. Related documents

• PIMS-PRO-05 Consent and privacy notice management procedure
• PIMS-REG-04 Consent record register
• GDPR-TPL-01 Privacy notice template (customers and website)
• GDPR-TPL-04 Cookie and tracking technologies notice template
• GDPR-PRO-02 HR data handling procedure
• GDPR-POL-01 Data protection policy

Legitimate interests assessment template

The three-part test (purpose, necessity, balancing) completed before any processing relies on legitimate interests, with the outcome, safeguards and review date recorded in GDPR-REG-03.

Serves: GDPR Article 6(1)(f); GDPR Article 21; ISO/IEC 27701 Annex A 7.2.2. Owner: Privacy Officer.

Guidance notes are in italics. One assessment per processing activity, completed by the activity owner with the Privacy Officer, approved before the processing starts, and entered in GDPR-REG-03. Legitimate interests is not available for processing by public authorities in the performance of their tasks, and is never a substitute for a condition under Article 9 where special category data is involved. Write for a reader who was not in the room: an auditor or a supervisory authority will read this if the processing is challenged.

1. The processing

2. Purpose test: is there a legitimate interest?

Purpose test outcome: [Passed, Failed]. A failed purpose test ends the assessment; find another basis or do not process.

3. Necessity test: is the processing necessary for that interest?

Necessity test outcome: [Passed, Failed].

4. Balancing test: do the interests and rights of the people override the interest?

Consider the nature of the data, the reasonable expectations of the people, the likely impact on them, and the safeguards that reduce it. Be honest about impact; an assessment that finds no impact at all is rarely credible.

Balancing test outcome: [The interest prevails, The interest prevails with the safeguards above, The rights of the people prevail].

5. Decision