ISO 27001 Statement of Applicability: Why 40% of Indian BFSI Audits Fail at the SoA Stage

Forty percent of Indian organisations attempting ISO 27001 certification fail on their first attempt. The most common reason is not a weak security posture — it is a poorly constructed Statement of Applicability. Auditors from NABCB-accredited certification bodies consistently cite SoA deficiencies as the #1 reason for non-conformance findings at Stage 2 audits.

For BFSI organisations — where ISO 27001 is increasingly expected by SEBI, RBI, and enterprise clients — a failed certification attempt costs not just the ₹15–40 lakh in consultant and audit fees, but months of remediation time and regulatory credibility.

What Is the Statement of Applicability?

The Statement of Applicability is a mandatory document required by ISO 27001 Clause 6.1.3(d). It lists all 93 controls from ISO 27001:2022 Annex A and for each one declares:

• Whether the control is applicable — and if so, the implementation status (implemented, in progress, planned)
• If excluded, the justification — referencing the risk treatment decision that supports the exclusion
• Linkage to the risk treatment plan — which risk(s) each selected control addresses

The SoA is not a checklist. It is a risk-based argument — a live document that traces every control decision back to the organisation's risk register and treatment choices. Auditors read it as evidence that management has made deliberate, documented choices about which risks to treat and how.

The 7 SoA Failure Patterns Auditors Find Most Often

1. Blanket Exclusions Without Risk Evidence

The most common finding: entire control categories marked "not applicable" with no supporting risk treatment rationale. "We don't have physical offices" is not a justification for excluding all physical security controls (A.7) if staff work from client sites or shared co-working spaces. Every exclusion requires a documented risk decision — typically a risk acceptance — in the risk register.

2. Copy-Paste SoA From a Template

Auditors recognise template SoAs immediately. Generic justifications like "not relevant to our business" or "managed by parent company" without evidence of review are instant red flags. A payment gateway that has excluded A.8.23 (web filtering) and A.8.22 (network segregation) as "not applicable" — despite running customer-facing internet services — will face a major non-conformance.

3. Controls Marked "Implemented" Without Evidence

The SoA is cross-referenced during the audit against actual evidence of implementation. If A.8.15 (logging) is marked "implemented" but the audit reveals no centralised SIEM, no log retention policy, and no log review process — the SoA statement is inaccurate and constitutes a major finding.

4. No Linkage Between Risk Register and SoA

ISO 27001 requires a direct traceability chain: asset → threat → vulnerability → risk → treatment decision → control selection → SoA. Auditors will ask to trace a specific risk from the risk register through to its corresponding SoA entry. If this chain cannot be demonstrated, the entire ISMS foundation is questioned.

5. Outdated SoA Not Reflecting New Digital Channels

A bank's SoA certified in 2021 that has not been updated to reflect the addition of UPI P2M flows, API banking integrations, or cloud infrastructure migration is non-conformant. ISO 27001 Clause 6.1.3 requires the SoA to be updated when the ISMS scope changes. New digital channels introduce new attack surface — the SoA must reflect this.

6. No Version Control or Change History

The SoA must demonstrate management review and approval, with a clear version history. Auditors look for: who authored the SoA, who reviewed it, when it was approved by management, and what changed since the last version. A single-version document with no change log suggests the SoA was never maintained after initial certification.

7. Scope Creep — SoA Covers Undefined Boundaries

The SoA must be bounded by the ISMS scope defined in Clause 4.3. Organisations frequently write scope statements so broadly ("all information assets of the organisation") that the audit becomes unmanageable, or so narrowly ("only the core banking application") that critical supporting systems are excluded without justification. The scope and SoA must be internally consistent.

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

While every control decision must be risk-based, certain Annex A controls are effectively non-excludable for any Indian bank, NBFC, payment gateway, or broker-dealer. Attempting to exclude these will trigger a major non-conformance at any competent certification audit:

Controls Commonly — and Wrongly — Excluded

Two Annex A controls are routinely excluded without adequate justification in Indian BFSI SoAs, and both consistently generate audit findings:

A.5.23 — Information security for use of cloud services. Organisations claim "we don't use cloud" while their email is on Microsoft 365, their SIEM is on a cloud SIEM platform, and their disaster recovery is on AWS. Any SaaS, PaaS, or IaaS dependency makes this control applicable.

A.8.34 — Protection of information systems during audit testing. Often excluded as "VAPT is managed by a vendor." But the control is about ensuring audit and testing activities don't disrupt production systems — it applies to every organisation that conducts VAPT, penetration testing, or vulnerability scanning, regardless of who performs it.

Building the Right SoA: The Three-Step Process

Step 1 — Risk Treatment Plan First

Complete your risk assessment and risk treatment plan before touching the SoA. Every control selected in the SoA must link to a specific risk being treated. The risk treatment plan is the source of truth; the SoA is derived from it, not the other way around.

Step 2 — Applicability Decision Tree for Each Control

For each of the 93 controls, work through three questions: (1) Is this control required by our regulatory obligations? (2) Does our risk assessment identify risks that this control addresses? (3) Are there contractual or client requirements that mandate this control? If "yes" to any — the control is applicable. Only if "no" to all three, and you can document a risk acceptance, is exclusion justified.

Step 3 — Evidence Mapping Before the Audit

For every control marked "implemented," prepare the evidence reference before the audit. Auditors will sample 20–30 controls during Stage 2 and ask to see implementation evidence. A column in the SoA that lists the evidence document, system, or log that demonstrates implementation will save hours of audit time and project confidence.