How to Implement ISO 27001 Annex A 5.34

Implementing ISO 27001 Annex A 5.34 is a strict data governance mandate requiring the identification, classification, and cryptographic protection of Personally Identifiable Information (PII) throughout its lifecycle. This control forces organizations to move beyond policy documents to enforce technical privacy controls, ensuring the business benefit of regulatory compliance with GDPR and reduced legal liability from data breaches.

ISO 27001 Annex A Privacy and Protection of PII Implementation Checklist

Use this implementation checklist to achieve compliance with ISO 27001 Annex A 5.34. This control demands a rigorous technical and legal framework to ensure the privacy and protection of Personally Identifiable Information (PII), going far beyond simple policy declarations to require hard-coded data governance.

1. Conduct Forensic Data Discovery

Control Requirement: Identify and classify all PII held within the organisation’s systems. Required Implementation Step: Ignore user surveys. Run automated data discovery tools (using regex patterns for NI numbers, emails, credit cards) across all unstructured file servers, S3 buckets, and database schemas to locate “shadow” PII. Map these findings to your asset register.

Minimum Requirement: A scan report confirming the physical location of all PII, reconciled against the stated inventory.

2. Construct a Granular Record of Processing Activities (RoPA)

Control Requirement: Document the legal basis and purpose for processing PII (alignment with GDPR/DPA 2018). Required Implementation Step: Create a detailed register that maps specific database tables and columns to a legal basis (e.g., Consent, Contract, Legitimate Interest). Ensure this document explicitly lists the “Who, What, Where, Why, and When” for every PII data set.

Minimum Requirement: A RoPA document that references specific system identifiers (Table IDs/API endpoints) rather than vague business processes.

3. Implement Automated Data Retention Policies

Control Requirement: Ensure PII is not kept for longer than necessary. Required Implementation Step: Configure database-level retention policies (e.g., TTL indices in MongoDB, Retention Policies in SQL) to automatically purge or anonymise user data once the retention period expires. Do not rely on manual administrative deletion.

Minimum Requirement: Verified scripts or configuration settings that auto-delete PII after the defined retention period.

4. Enforce Pseudonymisation and Anonymisation

Control Requirement: Reduce risk to data subjects by obscuring their identity. Required Implementation Step: Apply dynamic data masking or tokenisation to PII fields in non-production environments (staging/dev). Ensure developers work with sanitised data sets, not live customer data.

Minimum Requirement: Technical proof that Lower Environments (Dev/Test) do not contain raw, identifying PII.

5. Secure PII with Column-Level Encryption

Control Requirement: Protect PII confidentiality against unauthorised access. Required Implementation Step: Beyond full-disk encryption, implement application-layer or database column-level encryption for highly sensitive PII (e.g., health data, financial identifiers). Manage the decryption keys strictly via a Hardware Security Module (HSM) or Key Management Service (KMS).

Minimum Requirement: Database schema showing sensitive columns are encrypted at rest.

6. Operationalise Subject Access Requests (DSARs)

Control Requirement: Facilitate the rights of data subjects (access, rectification, erasure). Required Implementation Step: Develop and test scripts that can query all systems to extract or delete a specific user’s data upon request. Ensure this process handles “hard deletes” across backups and third-party SaaS integrations where possible.

Minimum Requirement: A tested procedure (runbook) that executes a “Right to be Forgotten” request within 72 hours.

7. Validate Cross-Border Data Transfers

Control Requirement: Ensure PII remains protected when transferred internationally. Required Implementation Step: Audit cloud configuration regions. Ensure data is pinned to specific geographic regions (e.g., “UK South” or “EU West”) and does not replicate to non-adequate jurisdictions without Standard Contractual Clauses (SCCs) and a Transfer Risk Assessment (TRA).

Minimum Requirement: Network diagrams and cloud configs proving data residency is restricted to approved jurisdictions.

8. Integrate Privacy by Design into SDLC

Control Requirement: Consider privacy at the earliest stage of system development. Required Implementation Step: Update the change management process. Require a Data Privacy Impact Assessment (DPIA) trigger for any code commit or schema change that introduces new PII fields. Block deployment pipelines until privacy risks are mitigated.

Minimum Requirement: Jira/Git history showing privacy reviews attached to feature branches involving PII.

9. Audit Sub-Processor Compliance

Control Requirement: Ensure third-party vendors protect your PII data. Required Implementation Step: Review every SaaS tool and vendor processing your PII. Enforce signed Data Processing Agreements (DPAs) that mandate security controls equivalent to your own. Periodically audit their SOC 2 reports or ISO certificates specifically for privacy controls.

Minimum Requirement: A central repository of signed DPAs for every external PII handler.

10. Establish Breach Notification Protocols

Control Requirement: Promptly notify authorities and subjects of PII compromises. Required Implementation Step: Draft specific templates for notifying the ICO (or relevant authority) and affected individuals. Integrate these into the Incident Response Plan. Test the communication chain to ensure notifications can be issued within the statutory 72-hour window.

Minimum Requirement: Pre-approved legal notification templates and a tested call tree for privacy incidents.

ISO 27001 Annex A 5.34 SaaS / GRC Platform Implementation Failure Checklist

Control RequirementThe ‘Checkbox Compliance’ TrapThe Reality Check
Data InventoryManually entering “Customer Data” as a line item in a GRC tool.Without regex scanning, you have Excel files full of CC numbers on a forgotten marketing server. GRC tools don’t scan disks.
Right to be ForgottenA policy document saying “We will delete data on request.”If you don’t have a SQL script to cascade-delete a UserID from 15 tables, you cannot comply. A policy is not a deletion tool.
RetentionSetting a calendar reminder to “review data”.Human memory fails. Unless the database auto-purges old records, your liability grows every day.
Consent ManagementStoring a PDF of a consent form.Consent must be granular and revoked easily. If your database doesn’t track consent_timestamp and scope, you are exposed.
AnonymisationDevelopers promising they “don’t look at live data”.If your staging environment is a restore of Prod, you are breaching privacy laws. You must use masking tools.
Vendor ManagementSending a questionnaire to a vendor.Did you read their DPA? Did you check their cloud region settings? Questionnaires are often filled out by sales reps, not engineers.
Privacy NoticesCopy-pasting a generic template to the website footer.If the notice doesn’t match the actual cookies and scripts running on your site, it’s evidence of non-compliance, not compliance.
Fay Barker - High Table - ISO27001 Director

About the author

Stuart Barker
🎓 MSc Security 🛡️ Lead Auditor 30+ Years Exp 🏢 Ex-GE Leader

Stuart Barker

ISO 27001 Ninja

Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management. Holding an MSc in Software and Systems Security, he combines academic rigor with extensive operational experience, including a decade leading Data Governance for General Electric (GE).

As a qualified ISO 27001 Lead Auditor, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. His toolkits represent an auditor-verified methodology designed to minimise operational friction while guaranteeing compliance.

Shopping Basket
Scroll to Top