Many teams treat ISO 27701 as a controller-only framework. That is understandable — controllers bear the headline obligations under GDPR and similar laws. But Annex B exists precisely because the standard recognises that processors carry distinct, non-trivial responsibilities, and that a weak processor is a liability for every controller that depends on them. This walkthrough unpacks the seven Annex B control areas in operational detail so your team knows exactly what each requires.
Who Is This Blog For?
If your organisation processes personal data on behalf of clients — as a SaaS vendor, cloud infrastructure provider, payroll bureau, marketing platform, or any other B2B data service — you are a PII Processor under ISO 27701. And Annex B is written specifically for you.
If you are still working out which side of the line you sit on, it is worth reading our data principal vs fiduciary vs processor explainer alongside this — many organisations are both controller and processor depending on the data flow.
Why Annex B Matters More Than You Think
Under GDPR Article 28, processors can face independent fines. ISO 27701 Annex B certification provides documented, auditable evidence that your organisation takes processor obligations seriously — a genuine differentiator in enterprise sales and a meaningful reduction in regulatory exposure.
For the broader context on processor obligations under privacy law, our companion piece on ISO 27701 for data processors covers the Clause 9 management system requirements that sit alongside Annex B. Annex B controls are the operational obligations; Clause 9 is the governance scaffolding that holds them together.
Controller vs Processor — A Quick Orientation
Before diving into the controls, it helps to be clear on what distinguishes a processor from a controller — because many organisations are both, depending on the data flow.
| Dimension | PII Controller (Annex A) | PII Processor (Annex B) |
|---|---|---|
| Purpose setting | Determines why data is processed | Follows controller instructions only |
| Legal basis | Must identify and document lawful basis | Relies on controller's legal basis |
| Privacy notices | Must publish notices to individuals | Usually no direct notice obligation |
| Sub-processing | Must approve processors it engages | Must get controller approval for sub-processors |
| Subject rights | Directly handles individual requests | Supports controller in fulfilling requests |
| Data breaches | Notifies supervisory authority | Notifies controller without undue delay |
| DPA requirement | Must have DPA in place with processors | Must sign DPA with every controller |
If your role is on the controller side, the parallel companion piece is our walkthrough of ISO 27701 for data controllers, which covers the equivalent Annex A obligations.
The Seven Annex B Control Areas — Deep Dive
Annex B mirrors the thematic structure of Annex A but reframes every obligation from the processor perspective. Here is what each area requires in practice.
What it covers: Processors may only process PII under documented, lawful instructions from the controller. This control ensures there is no unauthorised, scope-creep, or purpose-limited processing — a foundational requirement that underpins everything else.
- Obtain and retain a signed Data Processing Agreement (DPA) with every controller before processing begins
- Map every processing activity to an explicit controller instruction in the DPA or written order
- Immediately flag and suspend any controller instruction you believe may be unlawful
- Do not use PII received from controllers for your own business purposes (analytics, product improvement, AI training) without explicit permission
- Ensure contractual agreements include a clear description of processing scope, duration, and categories of data
- Audit processing activities quarterly to verify alignment with documented instructions
A CRM SaaS provider receives customer data from a retail client. The provider cannot use that data to train its own AI models or enrich its own customer database — even in aggregated or anonymised form — without explicit controller authorisation and a legal basis.
What it covers: Even as a processor, you may have limited but important direct obligations toward the individuals whose data you process — particularly where you interact with them in the course of service delivery.
- Identify all touchpoints where your service interacts directly with end-users
- Ensure individual-facing communications are pre-approved and aligned with the controller's privacy notices
- Do not make independent representations about how data will be used — defer to the controller
- Support controllers in providing individuals with information about sub-processors that have access to their data
- If an individual contacts you directly with a rights request, forward it to the controller promptly and without acting on it independently
- Document your approach to individual-facing interactions in your processing records
What it covers: Processors must build privacy-protective capabilities into their products and services so that controllers can meet their own privacy-by-design obligations. Your architecture choices directly affect your clients' compliance posture.
- Conduct a Privacy Impact Assessment (PIA) for all new features that process personal data
- Default to minimum data collection in all product configurations — no opt-out required to reduce data sharing
- Provide controllers with granular retention controls so they can enforce their own policies
- Implement pseudonymisation and encryption at rest and in transit as defaults, not optional extras
- Maintain technical documentation of your privacy architecture to support client DPIAs
- Include privacy review as a mandatory gate in your software development lifecycle (SDLC)
- Make data minimisation tools and export/delete APIs available to all controllers, not just enterprise tiers
Many processors offer privacy-protective features only on premium tiers. Annex B B.4 expects these to be available as defaults or reasonable configurations, not upsell opportunities. This is a frequent finding in certification audits. For broader context on encryption defaults, see our piece on encryption at rest vs in transit.
What it covers: Controls how processors may share, transfer, or disclose personal data — whether to sub-processors, across international borders, or in response to legal demands. Unauthorised sharing is one of the highest-risk areas for processors.
- Obtain explicit, written controller approval before engaging any sub-processor
- Maintain a current, public or client-accessible sub-processor list updated with at least 30 days notice of changes
- Flow down equivalent data protection obligations to all sub-processors by contract
- Assess and document the legal transfer mechanism for every cross-border data transfer (SCCs, adequacy, BCRs)
- Establish a legal disclosure protocol: notify the controller before responding to law enforcement requests unless legally prohibited
- If legally prohibited from notifying the controller, document the prohibition and seek legal advice
- Conduct annual reviews of sub-processor compliance and transfer mechanism adequacy
Your sub-processor list is a contractual commitment to your clients. Changes should trigger a formal notification period — typically 30 days — during which the controller may object. Build a change management workflow around this, not an ad-hoc email. Our third-party risk management guide covers the operational mechanics in detail.
What it covers: Processors must operationally support controllers in fulfilling data subject rights. You cannot be the bottleneck when a controller receives a Subject Access Request, erasure demand, or correction request.
- Build APIs and admin interfaces that allow controllers to export, correct, or delete individual records on demand
- Define and document SLAs for responding to controller requests related to individual rights (target: 72 hours)
- Ensure deletion cascades to all backups, replicas, and disaster recovery stores within a documented timeframe
- Test your deletion capability end-to-end at least annually — document the test results
- Provide controllers with audit logs of data access and modification events to support SAR responses
- Train customer success and support teams to recognise and escalate rights-related requests from controllers
- Do not independently interpret or act on a rights request received directly from an individual without controller authorisation
Incomplete deletion is one of the most common processor compliance failures. Erasure must propagate beyond the live database to cover log files, backups, analytics stores, and any third-party sub-processors that received the data. Map your data flows before certifying this control. The mechanics of subject rights are covered in detail in our GDPR data subject rights walkthrough.
What it covers: Even as a processor, you need a functioning mechanism for receiving and routing privacy-related complaints — both from controllers and, in some circumstances, from individuals who contact you directly.
- Designate a named privacy contact or functional inbox (e.g., privacy@yourcompany.com) for complaints
- Log all privacy complaints in a centralised register with date received, nature, and resolution
- Forward complaints that relate to the controller's data — do not resolve them independently
- Establish escalation paths for high-severity complaints (data breaches, regulatory enquiries)
- Define response SLAs: acknowledge within 24 hours, route within 48 hours, resolution timeline communicated to controller
- Review complaint trends quarterly to identify systemic processing issues
- Train frontline support staff to recognise privacy complaints and route them correctly
What it covers: Processors must proactively monitor and assess their own legal and contractual privacy obligations. The regulatory landscape is not static — new jurisdictions adopt data protection laws, guidance evolves, and your service footprint may grow into new markets.
- Maintain a legal obligations register covering every jurisdiction in which you process personal data
- Assign ownership of regulatory monitoring to a named individual or function — not just the DPO
- Subscribe to regulatory update services for key jurisdictions (EU, UK, US state laws, APAC)
- Conduct an annual review of your DPA obligations across all active controller relationships
- Assess whether your technical and organisational controls remain adequate after regulatory or contractual changes
- Document the outcome of all obligation assessments and track remediation actions to closure
- Ensure your procurement process screens new controller contracts for unusual or non-standard processor obligations
ISO 27701 certification requires an existing ISO 27001 ISMS in scope — you cannot certify to 27701 as a standalone. If your organisation is starting from scratch, plan for both standards in parallel since the overlapping controls make this far more efficient than sequential certification. We cover this in detail in how to extend your ISMS into a PIMS.
The Certification Pathway for Processors
ISO 27701 certification for processors follows a structured path. Here is a practical view of the journey.
Map your current controls against each Annex B requirement. Use a RACI to assign ownership. Identify which controls are fully implemented, partially implemented, or absent. Quantify the gap.
ISO 27701 extends your ISO 27001 ISMS. If you do not have 27001 in place, you need it first. The Privacy Information Management System (PIMS) adds privacy-specific policies, procedures, and records on top of your security management system.
Auditors require documented evidence for every control — policy documents, procedure records, DPA registers, training logs, DPIA records, deletion test results, and sub-processor registers. Build evidence collection into day-to-day operations, not pre-audit sprints.
Conduct a structured internal audit against Annex B before engaging an external certification body. This surfaces non-conformities in a low-risk environment and allows you to remediate before the formal audit.
Stage 1 is a documentation review — the auditor assesses your PIMS documentation for completeness. Stage 2 is the on-site audit, testing whether your controls operate as documented. Successful completion results in certification, typically valid for three years with annual surveillance audits.
For the broader implementation roadmap that runs parallel to this certification pathway, see our building a PIMS implementation roadmap.
Five Common Annex B Pitfalls — And How to Avoid Them
1. Treating DPAs as a Legal Formality
DPAs are live operational documents, not sign-and-file contracts. The processing description, retention periods, sub-processor lists, and security measures in your DPA must reflect reality. Outdated DPAs that do not match your actual processing are a significant audit risk.
2. Incomplete Sub-Processor Visibility
Many processors underestimate how many sub-processors they actually use. Cloud providers, analytics tools, monitoring platforms, and support ticketing systems may all touch personal data. Conduct a full data flow mapping exercise before finalising your sub-processor register.
3. Deletion Without Verification
Saying you can delete data is not the same as proving it. Regulators and auditors expect documented deletion procedures, technical evidence of deletion, and confirmation that deletion cascades to backups and sub-processors. Build deletion testing into your compliance calendar.
4. Siloed Privacy Teams
Annex B controls touch engineering (B.4), legal (B.2, B.5), support (B.7), and operations (B.6). Treating privacy as a legal or compliance function in isolation guarantees gaps. Embed privacy responsibility into engineering team OKRs and product roadmaps.
5. Static Obligations Registers
Privacy law is not static. US state laws, UK GDPR divergence, India's Digital Personal Data Protection Act, and other frameworks continue to evolve. An obligations register that was accurate two years ago may now be materially incomplete. Review it annually at minimum.
Quick Reference — Annex B Controls at a Glance
| Control | Topic | Primary Owner | Key Evidence Item |
|---|---|---|---|
| B.2 | Conditions for Collection & Processing | Legal / DPO | Signed DPAs & processing register |
| B.3 | Obligations to PII Principals | DPO / Product | Touchpoint inventory & comms policy |
| B.4 | Privacy by Design & Default | Engineering / DPO | DPIA records & SDLC privacy gate |
| B.5 | Sharing, Transfer & Disclosure | Legal / Procurement | Sub-processor register & SCCs |
| B.6 | Access, Correction & Erasure | Engineering / CS | Deletion test records & SAR SLA logs |
| B.7 | Complaints & Enquiries | DPO / Support | Complaints register & response logs |
| B.8 | Assessment of Obligations | Legal / Compliance | Obligations register & review minutes |
ISO 27701 Annex B does not ask processors to do the impossible. It asks you to do what good data stewardship already demands: process only what you are authorised to process, document everything, support your clients in meeting their obligations, and build privacy into your products from the start.
The organisations that will thrive in the next decade of privacy regulation are those that treat processor obligations not as a compliance burden, but as a product quality standard. Annex B certification is increasingly a procurement prerequisite for enterprise clients — getting ahead of it now is a commercial as much as a compliance decision. If you want to see how the controller-side controls map against this, our Annex A walkthrough covers the parallel set in equivalent depth.
Frequently Asked Questions
ISO 27701 Annex B contains the controls that apply specifically to PII processors — organisations that process personal data on behalf of a controller. It mirrors the structure of Annex A but reframes every obligation from the processor's perspective. The seven control areas (B.2 to B.8) cover lawful processing, obligations to individuals, privacy by design, data sharing, subject rights, complaints handling, and ongoing assessment of obligations.
A PII processor is any organisation that processes personal data on behalf of another organisation (the controller) under documented instructions. Typical processors include SaaS vendors, cloud infrastructure providers, payroll bureaus, marketing platforms, analytics services, and B2B data services. Many organisations are both controller and processor, depending on the data flow.
No. ISO 27701 is an extension of ISO 27001 — you cannot certify to 27701 as a standalone standard. Your organisation must have an existing ISO 27001 ISMS in scope before pursuing 27701 certification. If you are starting from scratch, plan for both standards in parallel since the overlapping controls make this more efficient than sequential certification.
Annex A applies to PII controllers — organisations that determine the purposes and means of processing. Annex B applies to PII processors — organisations that process data on a controller's behalf. The two annexes mirror each other thematically but contain different operational obligations. Many organisations are both, and need to evaluate both annexes against their data flows.
Incomplete deletion is consistently one of the most common processor compliance failures. Erasure must propagate beyond the live database to cover log files, backups, replicas, analytics stores, and any sub-processors that received the data. Auditors expect documented deletion procedures, technical evidence that deletion has occurred, and confirmation that deletion cascades downstream.
For an organisation with an existing ISO 27001 ISMS in place, ISO 27701 certification typically takes 4–6 months — including gap analysis, PIMS build, internal audit, and the Stage 1/Stage 2 certification audit. For organisations starting without ISO 27001, allow 9–12 months for combined certification. Running both in parallel is generally more efficient than sequential certification.
Annex B operationalises many of the obligations that GDPR Article 28 places on processors — including documented instructions, sub-processor consent, breach notification, and supporting controllers in meeting subject rights. Achieving Annex B certification provides documented, auditable evidence of Article 28 alignment, which is a meaningful differentiator in enterprise sales and reduces regulatory exposure.