ISO 27001 Statement of Applicability (SoA): How to Actually Write One

The Statement of Applicability (SoA) is the single document that separates a real ISO 27001 implementation from a cosmetic one. Every certification auditor opens it on page one. Every serious enterprise buyer asks to review it. And yet the SoA is the most commonly butchered artifact in the standard. Teams copy-paste a template, mark every control “applicable,” write “documented in policy” in the justification column, and hope the auditor does not read carefully. The auditor always reads carefully.

This post walks through how to actually write a Statement of Applicability for ISO 27001:2022 that survives scrutiny, demonstrates risk-driven thinking, and does not embarrass you in year two when surveillance audits ask harder questions. It assumes you are an India-based startup or mid-market company pursuing first-time certification or a 2013-to-2022 transition.

What the SoA is, in plain terms

Clause 6.1.3 of ISO 27001 requires a documented Statement of Applicability. The SoA lists every control in Annex A and, for each, records: whether it is applicable, why, whether it is implemented, and where the implementation is documented. The clause also requires you to include any controls from outside Annex A that your risk treatment needs.

The SoA is the bridge between your risk assessment (clause 6.1.2) and your operational controls. Auditors read the risk register and expect the controls selected in the SoA to reflect the risks identified. A risk of unauthorized access to production systems paired with “A.5.15 Access control: not applicable” will produce a finding in about thirty seconds.

The five columns every SoA needs

A minimal SoA has five columns. Add more if they help; do not have fewer.

Add a sixth column for control owner if you want operational clarity. Add a seventh for last review date if your ISMS maturity warrants it.

The 2022 Annex A at a glance

ISO 27001:2022 Annex A has 93 controls across four themes. A realistic SoA length for a typical Indian SaaS is 93 rows plus any external controls derived from risk treatment.

• Organizational (37 controls): Policies, roles, supplier relationships, classification, access, incident management, business continuity, cloud services.
• People (8 controls): Screening, employment terms, awareness, disciplinary process, responsibilities after termination.
• Physical (14 controls): Perimeter, entry controls, office security, equipment, disposal, clear desk.
• Technological (34 controls): Endpoint, access, authentication, encryption, backup, logging, monitoring, development lifecycle, secure coding, configuration.

Writing justifications that pass an audit

The justification column is where most SoAs go wrong. Three failure patterns:

Failure 1: The copy-paste justification

“Applicable to protect organizational assets” written for all 93 controls. The auditor will pick three at random and ask which risks each control addresses. You cannot answer because you never thought about it.

Failure 2: The policy-reference justification

“Documented in Information Security Policy.” True, but it does not explain why the control applies. The auditor will ask: why is it applicable? Answer: because we have the risk of X. So write that.

Failure 3: The “not applicable” dodge

Marking an awkward control as not applicable to avoid implementing it. For a cloud-native SaaS, marking A.8.23 Web filtering as not applicable because “we do not operate the network” is a common one. If your employees browse the web on work devices, web filtering is applicable; the question is how it is implemented, not whether it applies.

What a good justification looks like

For A.5.15 Access control: “Applicable. Addresses risks R-07 (unauthorized access to production) and R-12 (insider data theft). Implemented via SSO-backed access to AWS and corporate SaaS, quarterly access reviews, and joiner-mover-leaver workflow. Documented in Access Control Policy v2.3.”

For A.7.2 Physical entry controls: “Partially applicable. Primary operations are cloud-based; physical access is limited to the Bengaluru office. Applies to office entry, not data centre entry. Implemented via biometric access and visitor log. Documented in Physical Security Policy.”

For A.5.7 Threat intelligence (new in 2022): “Applicable. Addresses R-19 (unknown threats to cloud infrastructure). Implemented via monitoring of CERT-In advisories, cloud provider security bulletins, and threat intel from [vendor]. Documented in Threat Intelligence Procedure.”

When is a control legitimately not applicable?

The standard allows exclusions, but they must be justified by risk or by business context. Genuine examples:

• A.7.5 Protecting against physical and environmental threats for a purely remote company without any physical premises. Rare, but valid if you truly have no office or server room.
• A.8.11 Data masking if you do not store categories of data that require masking. Justify: “No production data is provided to non-production environments; data masking is therefore not implemented because production data is never used outside production.”
• A.8.24 Use of cryptography sub-elements that do not apply to your specific cryptographic use case, with clear justification.

Exclusions that will not fly: marking A.5.24 Incident management planning as not applicable because “we have not had an incident” (incidents happen; planning is preventive). Marking A.8.28 Secure coding as not applicable because “we use a low-code platform” (configuration is code). Marking A.5.23 Information security for cloud services as not applicable because “the cloud provider handles it” (shared responsibility).

The SoA must reconcile with the risk register

Every risk with a treatment decision of “mitigate” should map to at least one control in the SoA. Every “accept” decision should be explicit and approved at the right level. Auditors trace this mapping. They pick a risk, ask which controls mitigate it, and check the SoA to verify.

A practical tool is a risk-to-control matrix as an appendix to the SoA. Rows are risks; columns are controls; an X marks where a control contributes to a risk treatment. This one artifact answers 80 percent of the auditor’s risk-related questions.

External controls: the often-forgotten column

Clause 6.1.3 requires inclusion of controls beyond Annex A if your risk treatment demands them. For Indian startups, common external controls include:

• DPDP-specific controls: consent management, data principal rights intake, 72-hour breach notification workflow.
• Sector-specific controls: RBI-regulated fintechs may need controls tied to Master Directions; SEBI-regulated entities need controls tied to the Cybersecurity and Cyber Resilience Framework.
• Customer-contracted controls: some enterprise customers mandate specific controls (for example, source code escrow, specific encryption algorithms) via MSAs.

Document these as external controls with the same structure as Annex A entries: applicable, justification, implementation, evidence.

Versioning and approval

The SoA is a controlled document. It has a version number, a date, an approver, and a change history. Management review minutes should reference the current SoA version. When controls are added, removed, or re-scoped, the SoA version increments and the change is recorded.

Auditors ask: when was the SoA last reviewed? Who approved it? What changed since the last version? A clean answer signals a functioning ISMS.

Treat the Statement of Applicability as a living map of your control environment, not a checkbox document. A well-maintained SoA is the single fastest way to demonstrate ISMS maturity to an auditor or a buyer.

A practical workflow to write your first SoA

1. Complete the risk assessment and risk register. Do not start the SoA before this.
2. Open a spreadsheet with the 93 Annex A controls, pre-populated with reference and title.
3. For each control, discuss with the relevant owner: is this applicable? What risks does it address? How is it implemented?
4. Write justifications that reference specific risks and specific implementations.
5. Add external controls derived from risk treatment, legal obligations, and customer contracts.
6. Review with the ISMS lead and executive sponsor. Approve and version-control.
7. Reference the SoA from your ISMS manual, risk register, and management review agenda.

First-draft SoAs take one to two weeks of focused effort for a mid-sized startup. Expect revisions after Stage 1 audit; auditors almost always request tighter justifications on at least a handful of controls.

Related reading

• ISO 27001:2022 implementation — no-BS guide
• ISO 27001 internal audit — practitioner’s checklist
• SOC 2 readiness — 90-day playbook
• SOC 2 vs ISO 27001 vs DPDP — which first

Work with RingSafe

RingSafe runs ISO 27001 risk assessments, SoAs, and full ISMS implementations for Indian startups. Founder Manish Garg (Associate CISSP, CEH, CCNP Enterprise) and the team have written SoAs that have passed Stage 2 audits with NABCB-accredited bodies on first attempt.

If your SoA looks like a template and you need a defensible version before Stage 1, book a scoping call and we will rewrite the SoA alongside your risk register in a way the auditor cannot poke holes in.