ISO 27001 SoA Failures: Why 40% of First-Time Audits Fail and How to Fix Your 93-Control Statement

The Statement of Applicability Problem

Every ISO 27001 certification hinges on a single artifact: the Statement of Applicability (SoA). This document declares which of the 93 Annex A controls are applicable to the organization's ISMS scope, the justification for inclusion or exclusion, and the implementation status of each applicable control.

The SoA is not a checklist — it's a risk-driven declaration that must demonstrably trace back to the risk assessment (Clause 6.1.3). When auditors find that SoA decisions cannot be traced to identified risks, or when implementation claims cannot be evidenced, the result is a major nonconformity. And major nonconformities mean failed audits.

Analysis of certification audit outcomes reveals that 40% of first-time audits result in at least one major finding related to the SoA. These are not marginal failures — they represent fundamental disconnects between what the organization claims and what evidence supports.

The 2022 Restructure: What Changed

ISO 27001:2022 consolidated the previous 114 controls (across 14 domains) into 93 controls across 4 themes:

• A.5 Organizational Controls (37 controls) — Policies, roles, asset management, access control, supplier relations, business continuity, compliance
• A.6 People Controls (8 controls) — Screening, terms, awareness, disciplinary, post-employment, remote working, event reporting
• A.7 Physical Controls (14 controls) — Perimeters, entry, offices, monitoring, utilities, cabling, equipment, storage media, facilities
• A.8 Technological Controls (34 controls) — Endpoints, access rights, source code, authentication, capacity, malware, vulnerabilities, logging, networks, web filtering, cryptography, SDLC, testing, change management

Additionally, 11 new controls were introduced: threat intelligence (A.5.7), information security for cloud services (A.5.23), ICT readiness for business continuity (A.5.30), physical security monitoring (A.7.4), configuration management (A.8.9), information deletion (A.8.10), data masking (A.8.11), data leakage prevention (A.8.12), monitoring activities (A.8.16), web filtering (A.8.23), and secure coding (A.8.28).

The Five SoA Failure Patterns

Pattern 1: Risk-SoA Disconnect

The most common failure. The organization's risk assessment identifies certain risks, but the SoA control selection doesn't logically address those risks. Or conversely, controls are marked applicable without a traceable risk that justifies their inclusion. ISO 27001 requires that control selection be driven by the risk assessment — not by a desire to check every box.

The fix: build a formal risk-to-control mapping that shows, for each identified risk, which Annex A controls address that risk and why. For excluded controls, document why the risk assessment doesn't require them.

Pattern 2: Implementation Evidence Gaps

The SoA claims controls are "implemented" but the audit finds no supporting evidence. This is especially common for the 11 new controls introduced in 2022, where organizations claim implementation of threat intelligence (A.5.7) or data leakage prevention (A.8.12) without operationalizing the capability.

The fix: for each "implemented" control, pre-assemble the evidence pack an auditor would expect — policy documents, configuration screenshots, process records, review meeting minutes, test results.

Pattern 3: Scope Boundary Confusion

Controls are excluded because they "don't apply" when they actually do within the ISMS scope. Physical controls (A.7) are frequently excluded by technology companies that forget their scope includes office premises. Cloud service controls (A.5.23) are excluded by organizations that use IaaS/PaaS platforms extensively.

The fix: review every exclusion against the actual operational reality of the scoped environment. Have someone unfamiliar with the SoA challenge each exclusion.

Pattern 4: Stale SoA

The SoA was prepared months before the audit and doesn't reflect current status. New systems were deployed, organizational changes occurred, or previously planned controls were implemented but the SoA wasn't updated. Auditors check dates and version history — a stale SoA suggests a stale ISMS.

Pattern 5: Generic Justifications

Every control justification reads the same: "Required for information security" or "Addresses organizational risk." Auditors look for specific, contextual justifications that demonstrate understanding of why a control is needed in this particular organization's context.

The 93-Control Audit-Ready Approach

Building an audit-ready SoA requires a systematic approach across all 93 controls. Here's how practitioners should approach each theme:

A.5 Organizational Controls — The Policy Foundation

The 37 organizational controls span the broadest range of ISMS concerns. Key areas where auditors focus:

• A.5.1 (Policies) — Not just existence but review cycle evidence with management approval
• A.5.7 (Threat Intelligence) — NEW control. Requires evidence of threat intel collection, analysis, and use in decision-making. Not just subscribing to a feed — acting on it
• A.5.23 (Cloud Services) — NEW control. Cloud security responsibilities, provider assessments, data location, and exit strategy documentation
• A.5.30 (ICT Readiness for BC) — NEW control. Bridging information security with business continuity planning at the technology level

A.6 People Controls — Beyond HR Onboarding

Only 8 controls, but frequently under-evidenced. Auditors verify:

• A.6.1 (Screening) — Background verification records with defined criteria per role sensitivity
• A.6.3 (Awareness) — Training records showing topic coverage, completion rates, and competency assessment
• A.6.7 (Remote Working) — Security controls specific to remote/hybrid work environments

A.7 Physical Controls — The Overlooked Theme

14 controls covering physical security. Technology companies frequently under-invest here:

• A.7.4 (Monitoring) — NEW control. Physical security monitoring evidence (CCTV, access logs, intrusion detection)
• A.7.10 (Storage Media) — Lifecycle management including disposal evidence with certificates

A.8 Technological Controls — The Evidence Challenge

34 controls generating the highest volume of audit evidence. Critical focus areas:

• A.8.8 (Vulnerability Management) — Scan reports, patch status, remediation timelines with closure evidence
• A.8.9 (Configuration Management) — NEW control. Hardening standards, baseline configurations, drift detection
• A.8.10 (Information Deletion) — NEW control. Defensible deletion procedures with evidence trails
• A.8.11 (Data Masking) — NEW control. Where and how masking/anonymization is applied
• A.8.12 (Data Leakage Prevention) — NEW control. DLP strategy, tool deployment, policy enforcement evidence
• A.8.16 (Monitoring Activities) — NEW control. Comprehensive monitoring strategy beyond just SIEM
• A.8.23 (Web Filtering) — NEW control. Internet access policy and filtering implementation
• A.8.28 (Secure Coding) — NEW control. SDLC security practices, code review evidence, SAST/DAST results

The SoA Building Process: A 6-Week Methodology

• Week 1: Risk assessment review. Ensure all risks are current and properly assessed. Each risk must map to at least one treatment option
• Week 2: Control-risk mapping. For each of the 93 Annex A controls, identify which risks it addresses. Mark controls as Applicable (with risk reference) or Excluded (with justification)
• Week 3: Implementation assessment. For each applicable control, assess current implementation: Not Started, Planned, Partially Implemented, Fully Implemented. Be honest — auditors verify
• Week 4: Evidence compilation. For each "Fully Implemented" control, assemble the evidence pack. For "Partially Implemented," document the gap and remediation plan
• Week 5: SoA drafting. Compile the formal SoA document with justifications, implementation status, evidence references, and responsible owners
• Week 6: Management review and approval. Present SoA to management, obtain formal approval, establish ongoing review schedule

Post-Certification: Keeping the SoA Alive

Certification is not the finish line — it's the start of a three-year surveillance cycle. Auditors return annually and expect the SoA to evolve as the organization and its risk landscape change. Common surveillance audit findings include:

• New systems/processes deployed without SoA impact assessment
• Risk register unchanged despite business changes
• Training records showing declining participation over time
• Incident management evidence showing process degradation
• Internal audit findings without completed corrective actions

Build a quarterly SoA review cadence triggered by: major organizational changes, new threat intelligence, incident patterns, internal audit findings, and regulatory updates. The SoA is a living document — treat it as one.