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.
Table of contents
- 1. Privacy Policy and PII Handling Procedure Verified
- 2. Personal Data Inventory and RoPA Confirmed
- 3. Data Protection Impact Assessment (DPIA) Execution Validated
- 4. Data Subject Rights Request (DSRR) Mechanism Verified
- 5. Privacy by Design and Default Implementation Confirmed
- 6. Secure PII Disposal and Anonymisation Procedures Verified
- 7. Data Transfer Agreements (DTA) and SCCs Validated
- 8. PII Access Restriction and Least Privilege Verified
- 9. Privacy Awareness Training Records Identified
- 10. PII Breach Notification Procedure and Logging Confirmed
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.
ISO 27001 TOOLKIT: CONSULTANT EDITION
THE ULTIMATE PROFESSIONALS ISO 27001 TOOLKIT.
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
