What is the Statement of Applicability and why does it matter?
The Statement of Applicability (SoA) is a document that lists every control from Annex A of ISO 27701:2025 and states whether each one is applicable to your organisation. For every applicable control, you record its implementation status. For every excluded control, you provide a justification.
It matters for three reasons:
- It defines the scope of your PIMS — The SoA tells your certification body exactly which controls you have implemented and why others are excluded. It is the foundation of your certification audit.
- It is a mandatory requirement — Clause 6.1.3 e) of ISO 27701:2025 explicitly requires a Statement of Applicability that includes the necessary controls, justification for their inclusion, whether they are implemented, and justification for excluding any Annex A controls.
- It is your audit roadmap — The auditor uses your SoA as the primary reference during the Stage 2 audit. Every control marked as applicable will be assessed for evidence of implementation.
What must the SoA contain?
Under ISO 27701:2025, your SoA must include the following for each Annex A control:
| Required element | Description | Example |
|---|---|---|
| Control reference | The Annex A control number and title | A.1.2 — Privacy notice |
| Applicability status | Whether the control is applicable to your organisation | Applicable / Not applicable |
| Implementation status | For applicable controls: whether the control is fully implemented, partially implemented, or planned | Implemented |
| Justification for inclusion | Why this control is necessary for your PIMS (typically linked to your risk assessment) | Required to address risk R-014 (inadequate transparency to data subjects) |
| Justification for exclusion | For excluded controls: why the control is not applicable to your data processing activities | Not applicable — organisation does not act as a PII processor |
How is the 2025 SoA structured differently from 2019?
If you are familiar with the 2019 edition, the SoA structure has changed significantly:
| Aspect | 2019 edition | 2025 edition |
|---|---|---|
| Control source | Clauses 6, 7 and 8 (extensions to ISO 27002) | Annex A (78 standalone controls across 3 tables) |
| Structure | SoA covered both ISO 27001 Annex A and ISO 27701 clause additions | ISO 27701:2025 has its own dedicated SoA covering Annex A only |
| Control tables | Organised by ISO 27002 clause structure | Three tables: A.1 (controller, 31 controls), A.2 (processor, 18 controls), A.3 (shared, 29 controls) |
| Relationship to ISO 27001 SoA | Combined or cross-referenced | Separate document. If you hold both certifications, you maintain two SoAs. |
Manage all your compliance, all in one place
ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.
How should you approach building the SoA?
Step 1: Determine your role(s)
ISO 27701:2025 distinguishes between PII controllers and PII processors. Your role determines which Annex A tables apply:
- PII controller only — Table A.1 (31 controls) + Table A.3 (29 controls) = 60 controls
- PII processor only — Table A.2 (18 controls) + Table A.3 (29 controls) = 47 controls
- Both controller and processor — All three tables = 78 controls
Many organisations act as both controller (for employee data) and processor (for customer data). If this applies to you, all 78 controls are in scope.
Step 2: Link controls to your risk assessment
Each applicable control should trace back to a risk identified in your privacy risk assessment. This link is what the auditor uses to verify that your control selection is risk-based rather than arbitrary. If a control addresses a risk you have identified, it should be applicable. If no risk justifies the control and your data processing does not require it, you can exclude it with a documented justification.
Step 3: Document implementation status honestly
For each applicable control, record its current status:
- Implemented — The control is fully operational with evidence
- Partially implemented — Some elements are in place; work remains
- Planned — The control is in your implementation plan but not yet operational
Be honest about partial implementation. Auditors respect transparency and will work with you on a corrective action timeline. Claiming full implementation when evidence is thin is a fast route to a major nonconformity.
Step 4: Write defensible exclusion justifications
For each excluded control, your justification must explain why it is not applicable to your specific data processing context. Generic justifications like “not relevant” are insufficient. Examples of defensible exclusions:
- “Control A.2.x is not applicable because the organisation does not act as a PII processor for any third party.”
- “Control A.1.x (direct marketing) is not applicable because the organisation does not process PII for direct marketing purposes.”
- “Control A.3.x (physical media) is not applicable because the organisation processes PII exclusively in digital form with no physical records.”
What mistakes cause audit findings on the SoA?
- Missing justifications for exclusions — The most common finding. Every excluded control needs a specific, documented reason. “Not applicable” alone is not sufficient.
- Controls marked as implemented without evidence — If you mark a control as implemented, the auditor will ask to see evidence. Ensure evidence exists and is linked before your audit.
- SoA does not match the risk assessment — If your risk assessment identifies a privacy risk but the corresponding control is excluded in the SoA, the auditor will raise this as a nonconformity.
- Using the 2019 structure — If your SoA references Clause 7/8 controller/processor additions rather than Annex A tables, it does not meet the 2025 requirements.
- No version control — The SoA is a living document. If it does not have version history showing when it was last reviewed and updated, the auditor may question whether it reflects your current state.
Get started easily with a personal product demo
One of our onboarding specialists will walk you through our platform to help you get started with confidence.
How do you keep the SoA current?
Your SoA is not a one-time document. It needs to be reviewed and updated:
- After risk assessment changes — New risks may require additional controls; retired risks may allow exclusions
- When data processing activities change — New services, new data types or new processing relationships may affect which controls are applicable
- Before each audit — Ensure the SoA accurately reflects your current implementation status
- As part of management review — Include SoA currency as a standing agenda item
A compliance platform that generates the SoA from your live control data makes this automatic rather than manual. When you update a control’s status or add a new risk, the SoA reflects the change immediately.
Why choose ISMS.online for ISO 27701:2025?
- Automated SoA generation — Build your Statement of Applicability from your control selections, with justifications and evidence links populated automatically
- All 78 Annex A controls pre-loaded — Controller, processor and shared controls are ready to assess, with guidance notes for each
- Risk-to-control traceability — Link every control to the risks it addresses, giving auditors the evidence chain they expect
- Live document — Your SoA updates automatically as you change control statuses, add risks or modify exclusion justifications
- Version history — Full audit trail of SoA changes, satisfying the version control requirement without manual tracking
- Export-ready — Export your SoA in a professional format for your certification body, customers or management review
- Multi-framework — If you maintain both ISO 27001 and ISO 27701, the platform manages both SoAs with shared controls mapped across frameworks
Ready to build your Statement of Applicability? Book a demo and see how ISMS.online makes your ISO 27701:2025 certification SoA audit-ready from day one.
Frequently Asked Questions
How many controls should be in my SoA?
Your SoA must list all 78 Annex A controls (or the subset relevant to your role as controller, processor or both). Each control is either applicable or excluded with justification. The number of applicable controls varies by organisation, but most organisations that act as both controller and processor will have 50–70 applicable controls.
Do I need a separate SoA for ISO 27701 and ISO 27001?
Yes. Under the 2025 edition, ISO 27701 has its own Annex A with privacy-specific controls, separate from ISO 27001’s Annex A. If you hold both certifications, you maintain two SoAs. A compliance platform like ISMS.online manages both and maps shared controls so you do not duplicate effort.
Can I exclude an entire Annex A table?
Yes, if your role justifies it. For example, if you are exclusively a PII processor and never act as a controller, you can exclude all Table A.1 (controller) controls with the justification that you do not determine the purposes or means of PII processing. Table A.3 (shared controls) applies to all organisations regardless of role.
What evidence should link to each control?
Evidence varies by control type but typically includes: policies (approved and acknowledged), procedures (documented and followed), records (logs, registers, meeting minutes), and technical evidence (system configurations, access controls). The key is demonstrating that the control is not just documented but operating effectively.
How often should the SoA be reviewed?
At minimum, review the SoA annually as part of your management review cycle and before each certification or surveillance audit. You should also update it whenever there is a significant change to your data processing activities, risk profile or organisational structure. A live, platform-generated SoA stays current automatically as you update your controls.
