Annex A 5.34: Privacy and Protection of PII

To meet the annex a 5.34: privacy and protection of pii requirement, you must define and operate controls that ensure personal data is handled lawfully and securely across its full lifecycle, and you must be able to prove it with repeatable evidence. Operationalize it by mapping where PII exists, assigning accountability, implementing privacy-by-design safeguards, and capturing audit-ready records.

Key takeaways:

• Scope the control by mapping PII processing end-to-end (systems, third parties, and data flows), not by writing a policy first.
• Operational proof matters: maintain recurring evidence of access control, retention/disposal, incident response, and third-party privacy controls.
• Treat privacy obligations as a set of enforceable requirements (purpose, minimization, retention, disclosure controls) embedded in engineering and operations.

Annex A 5.34 sits at the intersection of information security and privacy operations: you’re expected to protect personally identifiable information (PII) with appropriate technical and organizational measures and align handling with applicable privacy obligations. ISO/IEC 27001 does not replace privacy law; it expects your ISMS to consistently implement whatever privacy and PII requirements apply to your organization and to demonstrate that implementation during audits. ¹

For a Compliance Officer, CCO, or GRC lead, the practical challenge is rarely “do we care about privacy?” It’s: Can we point to where PII lives, why we have it, who can access it, how long we keep it, what we share with third parties, and how we respond when something goes wrong? Auditors test those questions with evidence.

This page gives requirement-level implementation guidance you can put into motion quickly: who owns what, what artifacts to create, how to structure recurring evidence, and what audit teams typically challenge. Control 5.34 also tends to expose gaps in third-party risk management, because PII processing almost always extends beyond your perimeter. ²

Regulatory text

Provided excerpt: “ISO/IEC 27001:2022 Annex A control 5.34 implementation expectation (Privacy and Protection of PII).” ¹

What the operator must do:
You must implement and maintain controls that protect PII and align PII handling with applicable privacy requirements across the PII lifecycle (collection, access, use, sharing, storage, retention, and disposal). You also need to demonstrate that these controls operate in practice through documented processes and recurring evidence capture. ²

Plain-English interpretation (what auditors expect)

Annex A 5.34 expects a working privacy control system, not a standalone “privacy policy.” In plain terms:

• You know where PII is and why you have it.
• You restrict access and sharing to what’s needed for the stated purpose.
• You apply security controls appropriate to the sensitivity and risk.
• You keep PII only as long as required, then delete or destroy it defensibly.
• You manage third parties that touch PII with contractual and operational controls.
• You can show evidence that these practices are followed consistently. ²

Who it applies to (entity and operational context)

This control applies to service organizations and any organization implementing ISO/IEC 27001 where:

• PII is processed in business systems (HR, CRM, support tooling, analytics, billing).
• PII is handled by staff, contractors, or support teams (including remote access).
• PII is shared with third parties (payroll providers, cloud platforms, customer support tooling, marketing platforms, subprocessors). ¹

Operationally, Annex A 5.34 touches:

• Security: access control, encryption, monitoring, incident response.
• Privacy: lawful basis/notice/consent where applicable, purpose limitation, minimization, retention.
• GRC: policy, risk assessment, internal audit, evidence management.
• Legal/Procurement: data processing terms, subprocessor controls, breach notification clauses.
• Engineering/Data: system design, logging, data deletion, data exports, data classification.

What you actually need to do (step-by-step)

Use the sequence below to operationalize quickly and avoid “policy-first” failure.

Step 1: Define scope and accountability for PII processing

1. Name an executive owner for privacy risk within the ISMS (often the CCO/GC/CISO depending on your model).
2. Assign an operational owner for the PII inventory and evidence collection (GRC, Privacy Ops, or Security Compliance).
3. Define what you treat as PII for your environment (include employee, customer, and end-user PII; document edge cases like device IDs if you treat them as PII).
   Deliverable: RACI for PII protection and privacy controls; written PII definition for the ISMS. ¹

Step 2: Build a PII inventory and data flow map you can defend

1. Identify systems of record and major processing systems (SaaS and internal).
2. For each system, capture: PII categories, data subjects, purpose, access roles, storage location, retention, transfers, and third parties involved.
3. Document key data flows (collection → processing → sharing → storage → deletion).
   Deliverable: PII inventory + high-level data flow diagrams suitable for audit walkthroughs.

Practical tip: auditors accept “good enough” flow maps that match reality. They reject aspirational diagrams that omit key tools (support platforms, spreadsheets, BI exports).

Step 3: Translate privacy obligations into enforceable control requirements

Annex A 5.34 is easier to operate if you convert privacy concepts into testable controls. Define requirement statements such as:

• “Access to PII is role-based and approved.”
• “PII is encrypted in transit; sensitive PII is encrypted at rest where feasible.”
• “Retention schedules exist and deletion is performed and logged.”
• “PII sharing with third parties requires due diligence and contract terms.”
  Deliverable: A PII controls matrix mapping requirements to owners, systems, and evidence. ²

Step 4: Implement technical and operational safeguards (baseline set)

At minimum, ensure you can show these are in place where PII exists:

• Access control: least privilege, joiner-mover-leaver workflow, periodic access review for key PII systems.
• Logging/monitoring: administrative access logs for PII systems; alerting for unusual access where available.
• Secure disposal: deletion methods for SaaS and internal systems; process for backups/archives where deletion is constrained.
• Secure transfer: approved mechanisms for exporting or transmitting PII; controls over ad hoc sharing.
• Incident response: playbooks covering privacy incidents (misdirected emails, unauthorized access, third-party exposure) and escalation to legal/privacy.
  Deliverable: configuration evidence and runbooks that map back to your PII inventory. ¹

Step 5: Operationalize third-party controls for PII processors

For each third party that processes PII:

1. Classify the third party’s PII exposure (what categories, volume, sensitivity, and whether they are a processor/subprocessor in your model).
2. Perform due diligence appropriate to the risk (security questionnaire, SOC reports where available, contract review).
3. Contract for privacy/security requirements: permitted purposes, confidentiality, breach notification, subprocessor controls, return/deletion at termination.
4. Track subprocessors and material changes (new regions, new processing purposes).
   Deliverable: third-party register annotated for PII processing + contract clause checklist + completed reviews.

Step 6: Set up recurring evidence capture (make audits boring)

Annex A 5.34 often fails on “we do it, but can’t prove it.” Build recurring evidence capture around:

• Access reviews for PII systems (approvals, results, remediation tickets).
• Retention/deletion execution (logs, deletion tickets, system reports).
• Third-party due diligence completion and renewals.
• Incident tabletop exercises or post-incident reviews involving PII.
  Deliverable: an evidence calendar and a central evidence repository organized by system and control. ²

Where Daydream fits: Daydream is useful as the system of record for mapping Annex A 5.34 requirements to control operations and recurring evidence capture, so audits validate operation instead of debating document completeness. ²

Required evidence and artifacts to retain (audit-ready list)

Use this as your “PII evidence pack” checklist:

Artifact	What it proves	Common reviewer expectation
PII inventory (systems, categories, purposes, retention)	You understand scope and processing	Updated on a defined cadence; reflects real tools
Data flow diagrams (high level)	You understand transfers and sharing	Includes third parties and regions where relevant
PII controls matrix	Requirements mapped to operations	Clear owners and evidence pointers
Access control procedure + samples	Least privilege is enforced	Tickets/approvals, JML records, access review outputs
Retention schedule + deletion records	Storage limitation and disposal	Evidence of execution, not just a schedule
Third-party register + DPAs/contract clauses	Processor governance	Clause coverage and review artifacts
Incident response playbook (privacy-specific) + incident records	Ability to manage PII incidents	Escalation path to Legal/Privacy; post-incident actions
Training records (privacy/security handling)	Staff awareness	Role-specific training for high-risk teams

Common exam/audit questions and hangups

Auditors and internal assessors tend to probe these areas:

• “Show me your PII inventory. How do you know it’s complete?”
• “Which systems contain sensitive PII and what extra controls apply?”
• “Who can export PII from your CRM/support platform? Prove approvals and logs.”
• “What is your retention schedule for customer records and backups? Show deletion evidence.”
• “Which third parties process PII, and where do they process it?”
• “Show a privacy incident workflow and one example of how it was handled.” ¹

Frequent implementation mistakes and how to avoid them

1. Mistake: Policy-only compliance.
   Avoid: build the PII inventory and evidence calendar first; write policies to match actual operations.

2. Mistake: Treating “PII” as a single risk tier.
   Avoid: define sensitivity tiers (for example: basic contact vs government ID vs health data) and apply stronger controls where needed.

3. Mistake: Ignoring spreadsheets, exports, and support tooling.
   Avoid: include BI tools, ticket attachments, and ad hoc exports in your data flows and access review scope.

4. Mistake: Third-party contracts signed without privacy/security terms.
   Avoid: require a contract checklist gate for any tool that stores or accesses PII, even for “free trials.”

5. Mistake: Retention schedules that never execute.
   Avoid: implement deletion runbooks per system with named owners and evidence logs.

Enforcement context and risk implications

No public enforcement sources are provided in the source catalog for this requirement, so this page does not list enforcement cases. Practically, gaps in PII protection drive regulatory exposure under applicable privacy laws and increase breach impact, customer notification obligations, and contractual liability. ISO/IEC 27001 assessment risk is more immediate: assessors frequently record nonconformities where organizations cannot demonstrate evidence of PII control operation across systems and third parties. ¹

Practical 30/60/90-day execution plan

Use this plan as an operator’s runbook. Timing depends on system complexity and resourcing; treat phases as sequencing, not duration guarantees.

First 30 days (stabilize scope and ownership)

• Assign control owner(s) and publish RACI for PII handling.
• Stand up a PII inventory template and complete it for your highest-risk systems first (HR, CRM, support).
• Identify all third parties that store or access PII; flag missing contracts/DPAs.
• Define the evidence repository structure and evidence naming conventions.

Days 31–60 (implement controls and make them testable)

• Finalize the PII controls matrix: requirement → control activity → system → owner → evidence.
• Implement or tighten access controls for top PII systems (role definitions, approval workflow, logging).
• Draft and approve retention schedules; implement deletion runbooks for at least the top systems.
• Roll out third-party contract checklist and update procurement intake to capture PII processing details.

Days 61–90 (prove operation and close audit gaps)

• Run the first access reviews for top PII systems; track remediation to closure.
• Execute at least one retention/deletion cycle and retain logs/tickets.
• Perform a privacy incident tabletop and capture notes, decisions, and action items.
• Internal test: pick one PII system and do an end-to-end walkthrough (inventory → access → sharing → retention → third party → evidence). Fix what breaks.

Frequently Asked Questions

Do we need a separate privacy program to satisfy Annex A 5.34?

You need privacy requirements translated into operational controls inside your ISMS, with evidence. A standalone program can work, but auditors still expect system-level implementation and proof. ¹

How detailed does the PII inventory need to be?

Detailed enough that you can answer: what PII, why you have it, where it flows, who can access it, and how long you keep it. Start with key systems, then expand until “shadow” tools stop surprising you during walkthroughs.

What’s the minimum evidence set to avoid a finding?

Maintain the PII inventory, control mapping, access control evidence (including reviews for key systems), retention/deletion evidence, third-party due diligence and contract artifacts, and incident response records tied to PII. ²

How do we handle PII in backups where deletion is hard?

Document the technical constraint, set a bounded retention period for backups, restrict access, and ensure backups are encrypted and monitored. Auditors focus on whether you control access and have a defensible retention/disposal approach, not whether every backup is instantly purgeable.

Does Annex A 5.34 require a DPO or specific privacy role?

ISO/IEC 27001 does not mandate a specific title in the provided excerpt; it expects accountability and operational ownership. Assign clear owners and show how decisions and escalations happen in practice. ¹

How do we operationalize this across third parties without slowing procurement to a halt?

Create a lightweight intake that flags PII processing, then route only PII-touching third parties into deeper due diligence and required contract terms. Keep a register so renewals and changes trigger review rather than relying on memory.

Footnotes

1. ISO/IEC 27001 overview

2. ISMS.online Annex A control index