Auditing ISO 27001 Annex A 5.34 is the technical verification of an organization’s governance over personal data to ensure regulatory compliance. The Primary Implementation Requirement is a functional Record of Processing Activities, providing the Business Benefit of mitigated legal risks and enhanced data subject trust through transparent handling.
This technical verification tool is designed for lead auditors to confirm the integrity of the organisation’s privacy governance and data handling practices. Use this checklist to validate compliance with ISO 27001 Annex A 5.34 (Privacy and protection of PII).
1. Privacy Policy and PII Handling Procedure Verified
Verification Criteria: A documented policy exists that defines the organisation’s requirements for the protection of Personally Identifiable Information (PII) in accordance with applicable laws.
Required Evidence: Approved Privacy Policy and PII Handling Procedure with explicit version control and management sign-off.
Pass/Fail Test: If the organisation lacks a formalised policy that specifically addresses the protection of PII, mark as Non-Compliant.
2. Personal Data Inventory and RoPA Confirmed
Verification Criteria: A Record of Processing Activities (RoPA) is maintained, identifying all PII categories, purposes of processing, and data flows.
Required Evidence: A current RoPA or Data Inventory mapping PII across internal systems and third-party processors.
Pass/Fail Test: If the organisation cannot identify where PII is stored or the legal basis for processing specific data categories, mark as Non-Compliant.
3. Data Protection Impact Assessment (DPIA) Execution Validated
Verification Criteria: High-risk processing activities are subjected to a formal DPIA to identify and mitigate privacy risks before processing begins.
Required Evidence: Signed DPIA reports for all major technical projects or high-risk data processing operations initiated in the current cycle.
Pass/Fail Test: If a new high-risk system (e.g., automated profiling or large-scale health data) was launched without a completed DPIA, mark as Non-Compliant.
4. Data Subject Rights Request (DSRR) Mechanism Verified
Verification Criteria: A functional process exists for data subjects to exercise their rights, including access, rectification, and erasure of their PII.
Required Evidence: DSRR Log showing timestamps for request receipt, verification, and resolution within statutory timeframes (e.g., 30 days).
Pass/Fail Test: If a sampled DSRR was not fulfilled within the legally mandated timeframe without a documented extension, mark as Non-Compliant.
5. Privacy by Design and Default Implementation Confirmed
Verification Criteria: Technical controls are implemented to ensure that only the minimum necessary PII is processed and that privacy is a default setting.
Required Evidence: Product specification documents, database schemas showing minimised data fields, or default “Opt-In” configuration screenshots.
Pass/Fail Test: If systems are found to collect PII that is not required for the stated purpose (“data hoarding”), mark as Non-Compliant.
6. Secure PII Disposal and Anonymisation Procedures Verified
Verification Criteria: PII that has reached its retention limit is securely deleted or anonymised using irreversible technical methods.
Required Evidence: Secure erasure logs or technical documentation of anonymisation/pseudonymisation algorithms (e.g., salt-hashing, k-anonymity).
Pass/Fail Test: If PII persists in production databases after its retention period has expired without a legal hold, mark as Non-Compliant.
7. Data Transfer Agreements (DTA) and SCCs Validated
Verification Criteria: Transfers of PII to third parties or across borders are governed by formal agreements that ensure equivalent levels of protection.
Required Evidence: Signed DTAs, Standard Contractual Clauses (SCCs), or International Data Transfer Agreements (IDTAs) for sampled vendors.
Pass/Fail Test: If PII is transferred to a third-country processor without a valid legal transfer mechanism or adequacy decision, mark as Non-Compliant.
8. PII Access Restriction and Least Privilege Verified
Verification Criteria: Access to systems containing PII is strictly limited to authorised personnel whose job function requires such access.
Required Evidence: Access Control Lists (ACLs) or Role-Based Access Control (RBAC) reports for primary PII repositories.
Pass/Fail Test: If “Read” or “Export” access to the PII database is granted to general IT staff who do not have a defined data-handling role, mark as Non-Compliant.
9. Privacy Awareness Training Records Identified
Verification Criteria: Personnel with access to PII receive regular training on their privacy obligations and the technical handling of personal data.
Required Evidence: Training logs showing >95% completion of privacy-specific modules (e.g., GDPR awareness) for relevant staff.
Pass/Fail Test: If staff members handling PII have not completed a privacy training module within the last 12 months, mark as Non-Compliant.
10. PII Breach Notification Procedure and Logging Confirmed
Verification Criteria: A specific process exists for detecting and notifying authorities and data subjects of PII breaches within statutory windows.
Required Evidence: Incident Management Plan with a specific “PII Breach” annex and logs of any past notifications sent to regulators (e.g., ICO).
Pass/Fail Test: If the incident procedure lacks binary criteria for determining when a PII breach must be reported to the regulator, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| PII Inventory | Tool identifies “PII” based on file names or folder titles. | The auditor must verify content. Automated tools miss PII buried in unstructured data or custom database fields. |
| Legal Basis | GRC tool assumes “Legitimate Interest” for all processing. | Verify the Legitimate Interest Assessment (LIA). If the balancing test isn’t documented, the legal basis is invalid. |
| Data Minimisation | Tool checks if a “Minimisation Policy” exists. | Inspect the database schema. If the system asks for “Date of Birth” but only needs “Age > 18,” it is not minimised. |
| Transfers | SaaS tool verifies the vendor has an ISO 27001 certificate. | The auditor must verify the Transfer Risk Assessment (TRA). A certificate is not a legal mechanism for cross-border PII flow. |
| DSRR Fulfillment | Tool records that a “Request Portal” is active. | Verify the outcome. Did the person actually receive all their data, or just a generic profile summary? |
| Retention | Tool marks a task “Done” for annual data cleanup. | Check the backups. PII is often deleted from production but remains indefinitely in unencrypted, unmanaged backup sets. |
| Breach Window | Platform logs a breach as “Notified” based on a manual date. | Cross-reference the Discovery Timestamp with the Notification Timestamp. 72 hours starts at discovery, not at “Management Approval.” |
About the author
