ISO 27701 is ISO 27001's privacy-focused sibling. Where 27001 governs information security broadly, 27701 zooms in on how organisations handle Personally Identifiable Information. Annex A is where the rubber meets the road — it translates high-level privacy principles into concrete, auditable controls. One set for controllers (A.2-A.8), another for processors (B.2-B.8).
The Structure — Annex A at a Glance
Annex A is split into two parts reflecting the two primary roles in the PII ecosystem:
- Annex A (A.2-A.8): Controls for PII Controllers — organisations that determine the purpose and means of processing
- Annex B (B.2-B.8): Controls for PII Processors — organisations that process data on behalf of a controller
Many organisations act as both controller and processor depending on the data flow. Each set groups requirements into eight thematic areas mirroring each other.
Controller Controls — A.2 through A.8
A.2 — Conditions for Collection and Processing
Defines the legal basis and purposes for which PII may be collected, used, and retained. Document lawful basis for each processing activity in your RoPA. Capture consent at collection with clear audit trails. Tie every data collection field to a stated purpose. Restrict processing to declared purposes only.
A.3 — Obligations to PII Principals
Sets out transparency and notice obligations. Publish a clear, layered privacy notice at every data touchpoint. Ensure notices are in plain language. Keep notices updated when processing activities change. Train customer-facing staff on what to tell individuals.
A.4 — Privacy by Design and Default
Privacy must be embedded from the outset, with the most privacy-protective settings as default. Include a PIA/DPIA gate in your SDLC. Default to minimum data collection. Pseudonymise or minimise data at the architecture level. Review legacy systems and retrofit privacy-by-design principles.
A.5 — PII Sharing, Transfer, and Disclosure
Governs sharing with third parties, international transfers, and legal disclosures. Maintain a sharing register with DPAs. Assess transfer mechanisms for cross-border flows (SCCs, adequacy decisions). Document the legal basis before sharing with any third party.
A.6 — Access, Correction, and Erasure
Operationalises data subject rights. Build a SAR intake and fulfilment workflow. Set SLAs for responding (e.g., 30 days). Implement technical capability to export, correct, or delete user data. Test your erasure process end-to-end.
A.7 — Privacy Complaints and Enquiries
Defines how complaints are received, tracked, and resolved. Designate a named DPO or privacy contact. Log all complaints in a centralised register. Establish escalation paths for high-risk complaints. Track resolution times and perform root cause analysis.
A.8 — Assessment of Controller Obligations
Requires ongoing assessment of privacy obligations — legal, regulatory, and contractual. Subscribe to regulatory update services. Conduct annual reviews against current law. Maintain a legal register mapping obligations to internal controls.
Processor Controls — B.2 through B.8
B.2 — Conditions for Collection and Processing
Never process PII outside the documented scope of controller agreements. Maintain a processing register mapped to controller instructions. Flag and escalate any instruction you believe is unlawful. Audit sub-processors to the same standard.
B.3 — Obligations to PII Principals
Understand where your product touches end-users directly. Ensure individual-facing communications are coordinated with the controller. Avoid privacy representations that conflict with controller notices.
B.4 — Privacy by Design and Default
Build privacy into services so controllers can meet their own obligations. Offer data minimisation features. Provide tools for controllers to configure retention and deletion. Include privacy-protective defaults. Document privacy architecture for controller DPIAs.
B.5 — PII Sharing, Transfer, and Disclosure
Obtain written controller approval before engaging sub-processors. Flow down data protection obligations by contract. Notify controllers promptly of sub-processor changes. Maintain a record of all international transfers.
B.6 — Access, Correction, and Erasure
Build APIs or interfaces enabling controllers to extract or delete data on request. Respond promptly. Ensure deletion propagates to backups and replicas. Test deletion capability regularly.
B.7 — Privacy Complaints and Enquiries
Set up a dedicated privacy contact for controller escalations. Forward complaints to the relevant controller without delay. Do not resolve complaints on behalf of the controller without authorisation.
B.8 — Assessment of Processor Obligations
Conduct annual reviews of DPA obligations across all controller relationships. Monitor changes to processor liability under applicable law. Maintain records of processing activities per GDPR Article 30(2).
Practical Tips — For Implementation
- Do not treat this as a legal-only exercise. Engineering, product, and DevOps all have a role in controls like A.4 (Privacy by Design) and A.6 (Access and Erasure). Build a cross-functional privacy working group early.
- Map to existing processes first. Many controls will have partial coverage through your existing ISMS, GDPR programme, or security policies. Gap analysis before building net-new procedures.
- Evidence is everything for certification. Auditors will ask for documented evidence: meeting minutes, policy version history, completed DPIAs, training logs, SAR completion records. Centralise evidence in a GRC tool.
- Review controls annually. Privacy obligations evolve. GDPR guidance changes, new jurisdictions adopt laws, your product evolves. Schedule an annual Annex A review as part of your PIMS management review.
- Use a RACI for each control. Each control should have a named Responsible, Accountable, Consulted, and Informed party. Without clear ownership, controls drift.
Organisations have controls in place but cannot produce evidence they were followed. Build documentation habits into your processes from day one — not just before an audit. An undocumented process is treated as an absent process.
Quick Reference — All Controls at a Glance
| Control | Topic | Primary Stakeholder |
|---|---|---|
| A.2 | Conditions for Collection & Processing | Legal / DPO / Engineering |
| A.3 | Obligations to PII Principals | Legal / DPO / Marketing |
| A.4 | Privacy by Design & Default | Product / Engineering / DPO |
| A.5 | PII Sharing, Transfer & Disclosure | Legal / Procurement / DPO |
| A.6 | Access, Correction & Erasure | Engineering / Customer Success / DPO |
| A.7 | Privacy Complaints & Enquiries | DPO / Customer Success |
| A.8 | Assessment of Controller Obligations | Legal / DPO / Compliance |
| B.2 | Processor: Collection & Processing | Legal / DPO / Engineering |
| B.3 | Processor: Obligations to Principals | DPO / Product |
| B.4 | Processor: Privacy by Design | Engineering / Product |
| B.5 | Processor: Sharing & Transfer | Legal / Procurement |
| B.6 | Processor: Access & Erasure | Engineering / DPO |
| B.7 | Processor: Complaints | DPO / Support |
| B.8 | Processor: Assessment of Obligations | Legal / DPO / Compliance |
Frequently Asked Questions
Annex A (A.2-A.8) contains controls for PII Controllers — organisations that determine the purpose and means of processing. Annex B (B.2-B.8) contains controls for PII Processors — organisations that process data on behalf of controllers. Many organisations implement both because they act as controller for some data and processor for other data.
Annex A has 7 thematic control areas (A.2-A.8) for controllers and Annex B mirrors these with 7 areas (B.2-B.8) for processors. The total number of individual sub-controls varies but typically totals 49 controller controls and 25+ processor controls.
It depends on your role. If you are only a controller, implement Annex A. If you are only a processor, implement Annex B. If you are both (common for SaaS companies), you need controls from both annexes. Your Statement of Applicability documents which apply and why.
Evidence of controls being followed rather than merely documented. Organisations frequently have policies and procedures in place but cannot produce evidence they were executed — SAR completion logs, DPIA records, training completion certificates, or consent audit trails. Build documentation habits from day one.
Annex A controls map directly to GDPR obligations. A.2 maps to lawful basis (Article 6), A.3 to transparency (Articles 12-14), A.4 to Privacy by Design (Article 25), A.5 to cross-border transfers (Chapter V), A.6 to data subject rights (Articles 15-22), and A.7 to complaint handling (Article 77). ISO 27701 operationalises these GDPR requirements in an auditable framework.