ISO 27001 Annex A 5.34: privacy and protection of PII

The enterprise due-diligence questionnaire asks who owns privacy and where your processing inventory lives. You have a website notice and a folder of policies, and the deal is waiting.

This guide explains what ISO 27001 Annex A 5.34 requires, what counts as PII in a UK B2B firm, how to implement the control without an enterprise privacy programme, and how auditors test it. It is written for security and compliance leads at 25–250-person firms, and it ends with the automated route to evidence.

What does ISO 27001 Annex A 5.34 privacy and protection of PII require?

ISO 27001 Annex A 5.34 asks you to work out which privacy laws and contracts bind you, then meet them. In practice that means a policy staff can see, a named privacy owner, and technical and organisational safeguards behind the paperwork. It is a preventive bridging control that connects A.5.31's legal obligations to ISMS practice.

ISO 27002 classes it as preventive: it works before personal data is mishandled, by fixing obligations, ownership and safeguards in advance. It also carries all three security properties. Confidentiality is the obvious one, but privacy law also demands accurate data (integrity) and data you can retrieve when a person exercises their rights (availability).

For a UK regulated service provider, this is one of the few Annex A controls with a regulator attached directly to it. UK GDPR fines scale with turnover, and an ICO investigation is public in a way most security failures are not.

The commercial exposure usually arrives sooner. Enterprise clients now put data protection schedules in every contract. Diligence stalls when it finds no processing inventory, no DPAs with your sub-processors, or no tested route for a subject access request.

A weak A.5.34 also drags A.5.31 down with it. Auditors treat privacy as a legal-compliance control, so a missing privacy owner signals that the firm does not know what it is obliged to do.

Three neighbouring controls carry the rest of the load:

• A.5.31 supplies the legal register of obligations that A.5.34 acts on.
• A.5.33 enforces retention limits on personal data.
• A.5.20 binds the processor chain through supplier agreements.

The boundary matters. Certification does not make you UK GDPR compliant, and an auditor will not certify that claim. The certificate says your ISMS identifies privacy obligations and manages the security side of them. If clients start asking for full privacy assurance, ISO 27701 extends the ISMS into that territory.

What counts as PII in scope for a UK B2B organisation?

Under UK GDPR, personal data — the PII that A.5.34 protects — is any information relating to an identifiable person, directly or indirectly. For a B2B firm that means CRM contacts, work email addresses, IP addresses, employee records and indirect identifiers. A name in a sales pipeline is personal data, so A.5.34 applies.

The assumption "we only hold business contacts" is the commonest way firms talk themselves out of scope. B2B obligations are lighter in practice than a consumer business's, but the inventory, lawful basis and safeguards are still required.

Typical personal data in a 25–250-person B2B firm:

• CRM and marketing records: contact names, job titles, work emails, call notes and email engagement history.
• Online identifiers: IP addresses and device or cookie identifiers captured by your website, product logs and analytics tools.
• Employee and contractor data: payroll, HR files, right-to-work checks and monitoring logs.
• Support and product-user data: ticket archives, user accounts and screenshots that show names.
• Indirect identifiers: a job title plus an employer, or a user ID that links back to one person, even with no name attached.

PII stands for personally identifiable information, the term ISO standards use. UK GDPR says "personal data". State in your policy that the two mean the same thing for A.5.34, and apply the identifiability test to every system in the inventory.

How do you implement ISO 27001 Annex A privacy and protection of PII?

Implement it in sequence: build the processing inventory first, then name a privacy lead, put DPAs in place with every processor and sub-processor, write a short staff privacy policy, match safeguards to the data, and rehearse your workflows. A typical B2B data footprint takes two to three weeks of effort, once A.5.31 and A.5.20 exist.

The legal register from A.5.31 is the foundation, not a step. Anchor it on UK GDPR and your contracts, then add EU GDPR, sector rules or US state laws only where you genuinely process in-scope data. Listing regulations that do not apply is noise auditors query. Steps one to five below are governance and paperwork; the safeguards and rehearsals have their own section.

1. Build the processing inventory (RoPA). Record what personal data you hold, where it lives, your lawful basis, who it flows to, and any transfers outside the UK with their legal mechanism. For most B2B processing the lawful basis is contract or legitimate interests rather than consent, so record which one applies and why. Keep it small and true: a spreadsheet with fifteen honest rows outperforms a stale 200-row export from a tool. Then hunt the shadow data. The marketing list, the support-ticket archive and the analytics tool are the usual omissions, and they surface during audit sampling.
2. Name a privacy lead. Most firms of this size do not legally need a formal DPO. The UK GDPR triggers are public-authority status, large-scale monitoring and large-scale special-category processing. The control still expects a privacy lead who answers staff questions, reviews new processing and reports to leadership. Half a role, clearly assigned, beats a grand title nobody resources. A nominal DPO with no time, sitting on a 40-document framework, buries the real obligations in unmaintained paper.
3. Sign a DPA with every processor and sub-processor. This is usually a matter of checking and countersigning the vendor's standard terms. Record the breach-notification and audit clauses in your supplier register. Cross-reference every DPA to the register so the processor list and the signed agreements match.
4. Write a short staff privacy policy. Cover what personal data the firm handles, the rules for using it and who to ask. This is distinct from your website privacy notice. The notice is the public statement, whereas A.5.34 wants the internal machinery, so a notice alone does not satisfy the control.
5. Add DPIA screening to your change process. A data protection impact assessment comes before high-risk processing such as new profiling, large-scale sensitive data or novel tracking. Keep the write-ups. They are the evidence that privacy thinking happens before launch, not after.

A record of processing that nobody updates is a historical document, not a record.

Read the ICO documentation guidance for records of processing activities before you design the review cycle. It says to treat the record as a living document, updated as and when necessary, with regular reviews of the information you process. Tie the review to your change process, so a new system or a new vendor triggers an update rather than waiting for an annual sweep.

Which technical safeguards and rehearsed workflows does A.5.34 expect?

A.5.34 needs safeguards that match the data: encryption at rest and in transit, role-based access with MFA, masked or synthetic data in non-production, and a leaver process that provably cuts access. Two workflows must be rehearsed too: subject access requests inside one calendar month, and breach response inside the ICO's 72-hour clock.

The safeguards are what an auditor checks against your inventory. For each system the inventory says holds personal data, expect to show configuration evidence:

• Encryption: settings showing personal-data stores are encrypted at rest and connections use TLS.
• Access: role definitions, MFA enforcement and a periodic access review.
• Non-production: proof that staging and test environments run on masked or synthetic data.
• Leavers: a leaver record showing access removed promptly, contractors included.

The leaver bullet hides two failures: departed contractors who still hold access to systems full of client personal data, and ex-staff records kept with no end date. Both are cheap to fix and expensive to explain in an audit.

The ICO guide to subject access requests says you must respond without undue delay and within one month of receipt. The workflow is verify the requester, search, redact, respond.

A subject access procedure nobody has rehearsed is a plan to miss the deadline.

Run a mock request from a colleague's personal email and time every step. Unrehearsed, a real request can burn three of its four statutory weeks in an inbox before anyone searches a system.

The ICO guidance on responding to a personal data breach within 72 hours says a reportable breach goes to the ICO without undue delay and within 72 hours. The clock runs from when you discover the breach, not when it happened.

Wire personal-data breach response into your incident process, with a discovery timestamp on every record. The person who triages an alert must know the clock exists and who decides whether the reporting threshold is met.

How do auditors test A.5.34, and what grades as a major nonconformity?

Auditors cross-check your processing inventory against the asset register and pick the mismatch, usually a CRM or analytics tool holding personal data that appears in neither the RoPA nor the DPA list. They also trace a recent DSAR against the statutory timeline. Absence of obligations, owner or inventory grades major; staleness grades minor.

Questions to expect in the room:

• "Which privacy laws and contractual commitments apply to you, and where is that recorded?"
• "Who owns privacy here, and what do they actually do month to month?"
• "Show me your processing inventory. When was it last updated, and does it cover this system I saw in your asset register?"
• "A customer emails asking for everything you hold on them. Walk me through what happens and who is counting the days."
• "This sub-processor is in your supplier list. Where is the DPA, and does it cover the breach-notification clock?"

Run the cross-check yourself before the auditor does. Export the asset register, mark every system that holds personal data, and confirm each appears in the RoPA and, if it is a third party, on the DPA list. Any system that fails the test is a finding in waiting.

If you have received a DSAR, expect the auditor to trace it end to end: date received, identity check, search, redaction and response date. If you have received none, show the rehearsal record instead.

Have this evidence ready, as dated system exports rather than screenshots, because an export shows when the evidence was true:

• The staff-facing privacy policy, with approval and communication records, plus the privacy lead's appointment or role description.
• The RoPA, showing storage locations, lawful bases and transfer mechanisms, with a recent review date.
• Executed DPAs for the processor list, cross-referenced to the supplier register.
• The DSAR log with response timings, and DPIA records for anything high-risk launched recently.
• Configuration evidence for encryption, access control and non-production masking on the systems the inventory names.

Grading follows certification-body practice. No identified obligations, no owner, or no processing inventory at all is the absence case, because it shows the legal-requirements machinery is not operating. A stale inventory, one missing DPA or an undocumented DSAR response grades minor, though minors aggregate to major as a pattern. Demonstrable mishandling of personal data escalates.

How can GRC engineering automate A.5.34 evidence?

Automation turns A.5.34 from annual archaeology into by-products of normal work: a RoPA held as structured records linked to the asset register, DSAR tickets with statutory timers and day-21 escalation, scheduled encryption, RBAC and masking checks, and an incident flag that starts the 72-hour breach clock and pre-populates the ICO notification decision record.

Start with the RoPA, because every other check keys off it. The encryption, access and masking jobs need to know which systems hold personal data, and the link to the asset register is what tells them. The DSAR ticket and the incident record then carry their own timestamps, so the auditor's end-to-end trace takes minutes rather than days.

The commercial upside shows at diligence. A questionnaire asking for your processing inventory, DPA list and breach process is answered from live records instead of a scramble.

Not every firm has the capacity to build this. A Fractional CISO can work out which obligations bite, carry the privacy lead role as virtual DPO scope, and defend the approach to auditors and enterprise diligence teams. GRC engineering support builds the RoPA-as-data model, the DSAR timers and the continuous masking and access verification.

Frequently asked questions