A.5.34
Privacy and protection of PII
ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026
Objective
Protect privacy and personally identifiable information as required by applicable law, regulation, and contractual obligations.
Points of focus
- Data subject request process (access, deletion, correction) is defined with an SLA and a named owner
- Retention and deletion schedules are enforced technically, not just documented
- A DPIA or equivalent risk assessment is triggered before high-risk personal data processing goes live
- Privacy notices are kept current with what's actually collected and processed
Implementation notes
Build the data subject request process around a real intake channel, such as a form or dedicated inbox with a tracked queue, and a defined SLA, and log every request even if most turn out to be duplicates or spam. Enforce retention and deletion technically where possible, using scheduled jobs or TTLs on data stores, rather than relying on someone remembering to run a manual purge, and keep a sample record of what was deleted and when. Trigger a DPIA or lightweight privacy risk review before any new feature or vendor starts processing personal data at meaningful scale, especially anything involving profiling, AI or ML scoring, or sensitive categories of data. Keep privacy notices synchronized with actual data flows by tying notice updates to the same change process that ships new data collection, rather than an annual calendar reminder.
Audit tip: Ask to see one closed data subject request end to end: the ticket, what was searched, what was deleted or provided, and the completion date against your stated SLA. A written procedure with no example request is the typical gap.
Evidence auditors typically request:
- DSR ticket log showing request date, type, and completion date against SLA
- Retention or deletion job logs and configuration showing automated enforcement, with a sample of deleted records
- DPIA records for a recent feature or vendor that processes personal data at scale, such as a new analytics tool or AI feature
- Privacy notice version history correlated with product or data changes
Common gaps
- DSR requests are handled manually via email with no SLA tracking, and some requests are missed entirely
- The retention policy specifies deletion timelines that engineering doesn't actually enforce in the database or backups
- A new feature, such as analytics or AI-based scoring, started processing personal data without a DPIA or documented risk review
- The privacy notice hasn't been updated since a new data collection point, such as a new integration or tracking pixel, went live
Cross-Framework Mapping
| Framework | Requirement | Implementation note |
|---|---|---|
| ISO 27001 | A.5.34 | This control |
| GDPR | Article 12, Article 17, Article 35 | Articles 12, 17, and 35 map to DSR handling, the right to erasure, and DPIAs respectively — this is one of the few controls where the ISO and GDPR evidence genuinely overlap rather than just resembling each other. |
| HIPAA | 164.308(a)(1) | 164.308(a)(1) is the general security management process; if PHI is in scope, coordinate this control with a formal HIPAA risk analysis rather than assuming ISO certification substitutes for one. |
Primary sources
- ISO/IEC 27001:2022 Annex A: ISO/IEC 27001:2022 Annex A (A.5.34)