What Is the Statement of Applicability?
The Statement of Applicability (SoA) is a mandatory document under ISO 27001 Clause 6.1.3(d). It is the single document that lists all 93 controls from Annex A and, for each, records three things: whether the control is applicable and its current implementation status; if excluded, a documented justification tied to a risk decision; and linkage to the risk treatment plan that drove the applicability decision.
What makes the SoA uniquely important is what it is not. It is not a checklist an organisation fills in after building its ISMS. It is a risk-based argument — a formal assertion that management has looked at every control, understood the threat landscape, and made deliberate, traceable decisions about which safeguards are proportionate to the organisation's risk exposure. Certification auditors read the SoA this way: as evidence of deliberate management choices, not administrative compliance.
This distinction is why so many BFSI organisations struggle. Compliance teams treat the SoA as a form to complete. Auditors arrive expecting a reasoned document. The gap between those two interpretations is where first-attempt failures are born.
The 7 SoA Failure Patterns Auditors Find Most Often
Based on patterns observed across ISO 27001 certification engagements in Indian BFSI, the following seven issues consistently result in major non-conformances at Stage 2 audit. Each represents a structural problem with how the SoA was built — not a gap in the underlying security programme.
Blanket Exclusions Without Risk Evidence
Entire categories of controls — commonly the physical security section (A.7.x) or cryptography (A.8.24) — are marked "not applicable" with no supporting rationale beyond a single line note. ISO 27001 does not prohibit exclusions. It requires every exclusion to be justified through the risk treatment plan. When an auditor challenges an exclusion, the only valid response is a documented risk treatment decision in the risk register showing the risk was assessed and accepted. Organisations that exclude controls because a consultant suggested it, or because a template had them pre-excluded, almost always receive a major non-conformance at this point.
Copy-Paste SoA From a Template
Experienced auditors recognise template SoAs immediately. The giveaway is generic justification language — "not relevant to our business," "covered by vendor," or "low risk" appearing uniformly across multiple controls regardless of the organisation's actual operating context. A payment gateway that excludes A.8.23 (Web filtering) and A.8.22 (Restriction of software installation) despite running internet-facing services will face a major non-conformance. The SoA must reflect the organisation's specific technology stack, threat environment, regulatory obligations, and contractual requirements — it cannot be generic.
Controls Marked "Implemented" Without Audit Trail
The SoA is cross-referenced against actual evidence during Stage 2 audit. Auditors sample 20–30 controls and request supporting evidence for each one marked "implemented." A.8.15 (Logging) marked "implemented" with no centralised SIEM, no log retention policy, and no evidence of log review process is an immediate major finding. Every "implemented" marking in the SoA should have a corresponding evidence reference — the policy document, system configuration record, or operational log — that an auditor can inspect. The absence of evidence mapping is itself a systemic SoA failure, not a one-off gap.
No Linkage Between Risk Register and SoA
ISO 27001 requires a direct traceability chain: asset → threat → vulnerability → risk → treatment decision → control → SoA entry. When auditors find SoA entries that have no corresponding entry in the risk register, or when risk treatment decisions reference controls using different numbering or terminology, the SoA fails the traceability test. This is particularly common when the risk assessment and the SoA are built by different consultants, or when the risk register is updated after the SoA is finalised. The SoA must be derived from the risk treatment plan — not constructed independently and then reconciled.
Outdated SoA Not Reflecting New Digital Channels
An SoA certified in 2021 that has not been updated to reflect UPI P2M flows, API banking integrations, migration to cloud infrastructure, or new remote-working arrangements is non-conformant under ISO 27001 Clause 6.1.3, which requires the SoA to be updated whenever the ISMS scope changes materially. In practice, Indian BFSI organisations have undergone significant digital transformation since 2020. Any SoA that predates the introduction of material new digital assets, channels, or processing environments and has not been formally reviewed and updated will fail this test at surveillance audit.
No Version Control or Change History
The SoA is a controlled document. It must demonstrate that it has been formally authored, reviewed, and approved by management — and that a change history exists. Auditors look for: who authored the document, who reviewed it, the management approval signature with date, version number, and a change log showing what changed between versions and why. An SoA without version history signals to the auditor that the document was produced for the audit rather than maintained as a living ISMS artefact. This triggers scrutiny of every other ISMS document for the same issue.
Scope Creep — Inconsistency Between Scope and SoA
The ISMS scope statement and the SoA must be internally consistent. If the scope document covers "all information assets supporting the retail banking platform," the SoA cannot exclude controls that clearly apply to retail banking operations. Equally, if the scope is narrow — for example, limited to a single data centre — the SoA should not include applicability decisions for assets outside that scope. Scope creep in either direction creates audit exposure: too broad a scope means the organisation is committing to controls it cannot evidence; too narrow a scope means auditors will challenge whether material assets are being omitted.
"An SoA is not a checklist — it is a risk-based argument for why each control is or is not implemented. Auditors read it as a reflection of management intent."
Controls That Are Always Applicable in Indian BFSI
Some organisations attempt to narrow the SoA by excluding controls that appear optional in the standard's text. In the Indian BFSI regulatory context, a number of Annex A controls are effectively non-excludable — because they are required by one or more of RBI, SEBI, CERT-In, or the DPDP Act, regardless of the organisation's own risk assessment outcome.
| Control | Theme | Why Always Applicable in Indian BFSI |
|---|---|---|
| A.5.1 | Organisational | Information security policies — foundational to every Indian regulatory framework: RBI IT Framework, SEBI CSCRF, CERT-In, and DPDP Act all require documented policies. |
| A.5.19 | Organisational | Supplier relationships — required under SEBI CSCRF ID.2 third-party risk controls and RBI outsourcing guidelines. No financial institution can exclude vendor security governance. |
| A.6.8 | People | Information security event reporting — mandatory under CERT-In 2022 (6-hour breach reporting mandate) and RBI cyber incident reporting requirements. Internal event reporting pipelines must exist. |
| A.8.15 | Technological | Logging — mandatory under CERT-In 2022 (180-day log retention) and RBI DPSC. Centralised log management with defined retention is a direct regulatory requirement, not optional. |
| A.8.20 | Technological | Network security controls — no financial institution, regardless of size, can exclude network security. Applies to every organisation with a network, which is every organisation in scope. |
| A.8.23 | Technological | Web filtering — applicable to any organisation running internet-facing systems or providing employees internet access. Payment gateways, banking apps, and trading platforms cannot exclude this. |
| A.8.24 | Technological | Use of cryptography — mandatory for protecting PAN data, Aadhaar-linked data, and financial transaction data under DPDP Act and RBI encryption guidelines. |
| A.8.28 | Technological | Secure coding — required under SEBI CSCRF PR.4 and expected by RBI for any institution running proprietary software. SAST/DAST evidence is increasingly requested at Stage 2 audit. |
| A.5.23 | Organisational | Information security for use of cloud services — non-excludable if any SaaS, IaaS, or PaaS is in use. This covers M365, cloud-based SIEM, DR on AWS, or any managed cloud service. |
Controls Commonly — and Wrongly — Excluded
Beyond the always-applicable set, two controls generate a disproportionate share of audit disputes in Indian BFSI because the exclusion rationale sounds plausible but does not hold up to scrutiny.
A.5.23 — Information security for use of cloud services. Organisations claim "we don't use cloud" — and then auditors find that email runs on Microsoft 365, the SIEM is cloud-hosted, AWS is used for disaster recovery, or the core banking system vendor runs the production environment in a data centre that is, contractually, a cloud tenancy. In 2025, any organisation using SaaS, PaaS, or IaaS — no matter how peripheral — cannot exclude A.5.23. The obligation is to manage the security of cloud usage, not to avoid it.
A.8.34 — Protection of information systems during audit testing. Organisations exclude this on the basis that VAPT is conducted by an external vendor. The control's intent is not about who performs the testing — it is about ensuring that audit and penetration testing activities do not inadvertently disrupt production systems. This applies to every organisation that undergoes VAPT regardless of whether it is performed by internal staff or an external party. Excluding A.8.34 while simultaneously conducting VAPT will be flagged as a non-conformance.
Building the Right SoA: The Three-Step Process
Building an SoA that survives audit scrutiny requires a specific sequencing of activities. Most organisations get into difficulty because they start with the SoA template and work backward to the risk assessment. The correct sequence is the reverse.
Complete the risk assessment and risk treatment plan in full before opening the SoA document. The SoA is a derived output of the risk treatment plan — it records the controls selected in the treatment plan and the rationale for each. Building the SoA first and then reverse-engineering a risk register to match it produces a document that looks internally consistent but fails under audit interrogation. Auditors ask: "Show me the risk register entry that drove this control selection." If that entry was written after the SoA, the traceability chain breaks.
For each of the 93 Annex A controls, apply three sequential questions: (1) Is this control required by a regulatory, legal, or contractual obligation — RBI, SEBI, CERT-In, DPDP, or client contract? (2) Does the risk assessment identify risks that this control would address? (3) Are there contractual or client-mandated requirements that make this control applicable? If the answer to any one of the three is "yes," the control is applicable. Only when all three answers are genuinely "no" — and that negative position is documented as a deliberate risk acceptance decision — can the control be excluded with a defensible justification.
For every control marked "implemented" in the SoA, prepare an evidence reference before the audit engagement begins. Add a column to the SoA spreadsheet that identifies the specific document, system configuration record, log file, or policy that evidences implementation. Auditors sample 20–30 controls at Stage 2 — having evidence references pre-mapped eliminates the scramble that typically characterises unprepared audits and signals to the auditor that the ISMS is operationally mature rather than document-ready. This one step alone reduces Stage 2 audit duration significantly and prevents minor findings from escalating into major ones.
Build Audit-Ready SoA Documentation — Without Starting From a Blank Spreadsheet
Practitioner Toolkit includes pre-built control mapping templates, evidence tracking, and export-ready SoA documentation aligned to ISO 27001:2022 Annex A — with cross-mapping to SEBI CSCRF, RBI IT Framework, and CERT-In requirements. Evidence tracking columns, applicability decision templates, and version control built in from day one.
Explore Practitioner Toolkit →