Documentation & SoA

SoA Mistakes That Will Derail Your Certification Audit

Alex Fuerst

17 Nov 2025 — 7 min read

The Copy-Paste Disaster: When Templates Trump Reality

The Statement of Applicability is where most certification audits succeed or fail. I've watched more organizations stumble here than on any other ISMS component—not because they don't understand the SoA's importance, but because they fundamentally misunderstand what auditors are actually evaluating when they open that document.

After conducting hundreds of certification audits, I can tell you that SoA failures follow predictable patterns. These aren't subtle technical violations or edge cases in the standard's interpretation. They're fundamental errors that signal to an experienced auditor that the organization has either misunderstood ISO 27001's core requirements or, worse, has constructed a documentation-only ISMS that exists primarily on paper.

Let me walk you through the five most damaging mistakes I encounter, why they occur, and what auditors are really looking for when they review your Statement of Applicability. Each of these errors can trigger major nonconformities that derail your certification timeline.

Generic Templates That Don't Reflect Your Reality

The most catastrophic mistake I see is treating the SoA as a template completion exercise. Last year, I audited a software development company with a beautifully formatted SoA—every control had a justification, every implementation status was clearly marked. The problem became apparent within the first hour of sampling.

Their justification for Control 7.2 (Physical entry) referenced "manned security reception and visitor escort procedures." They operated entirely from a co-working space with no reception area under their control. When I asked about visitor management, their information security manager admitted they'd purchased an SoA template online and "customized it" for their organization—which apparently meant changing the company name in the header.

This isn't just embarrassing during an audit. It indicates that the entire ISMS might be built on generic foundations rather than actual risk assessment results. Under Clause 6.1.3(b), your SoA must be produced based on the results of your risk assessment and risk treatment process. If your control justifications don't reflect your specific identified risks and actual operating environment, you've failed to meet this fundamental requirement.

What the auditor looks for: I test SoA entries against the organization's actual environment. For physical controls, I take a facility walk-through. For technical controls, I examine actual configurations. For organizational controls, I interview relevant staff. Misalignment between documented justifications and operational reality is an immediate red flag.

This issue has become more pronounced since the 2022 revision of ISO 27001. The restructured Annex A controls require more precise justifications, particularly for controls like 5.23 (Information security for use of cloud services) and 8.28 (Secure coding) that are specific to modern technology environments.

Exclusion Justifications That Justify Nothing

Exclusion justifications reveal an organization's understanding of both their risk landscape and the standard itself. Poor exclusions are where I can immediately identify organizations that haven't performed genuine risk assessment or don't understand their own technology environment.

I recently audited a financial services firm that excluded Control 5.23 (Information security for use of cloud services) with the justification "We don't use cloud services." A brief conversation revealed they used Microsoft 365 for email and document management, Salesforce for customer relationship management, and AWS for backup storage. They genuinely didn't recognize Software-as-a-Service applications as "cloud services."

This exclusion was invalid and cascaded into a major nonconformity because they had no cloud security controls documented, no cloud service risk assessments, and no supplier security management for their most critical business applications.

Valid exclusion justifications must address two elements per Clause 6.1.3(d): that the control is genuinely not applicable to your organization, and demonstrate your reasoning. "Not applicable" isn't a justification—it's a conclusion without supporting evidence.

Weak example: "Control 7.4 Physical security monitoring - Not applicable"

Acceptable example: "Control 7.4 Physical security monitoring - Our organization operates entirely remotely with no physical premises under organizational control. All 23 employees work from home offices or client sites. Information assets are limited to company laptops covered under Control 7.9. Physical security monitoring has no application in our operational context as we control no physical spaces requiring monitoring."

What the auditor looks for: I verify that excluded controls genuinely don't apply by examining the organization's actual operations, technology stack, and business model. I pay particular attention to exclusions of security controls that are commonly misunderstood—cloud security, mobile device management, and cryptographic controls. Invalid exclusions often indicate broader gaps in risk understanding.

The Implementation Status Fiction

Many SoA templates include implementation status columns with options like "Fully Implemented," "Partially Implemented," or "Planned." This is where organizations engage in the most creative fiction writing, and where auditors can quickly assess the gap between documented claims and operational reality.

I audited a healthcare technology company whose SoA showed 89 out of 93 applicable controls as "Fully Implemented." Impressive on paper, but control sampling revealed significant discrepancies:

Control 8.8 (Management of technical vulnerabilities) was marked "fully implemented" but they had purchased a vulnerability scanner that remained unconfigured after six months. No scans had been performed, no vulnerability registers maintained, no remediation timelines established.
Control 5.25 (Assessment and decision on information security events) was "fully implemented" but they had no documented criteria for escalating events to incidents. Their IT team made subjective decisions during each security event.
Control 8.16 (Monitoring activities) was "fully implemented" but their SIEM had been in "pilot deployment" for 18 months with no production monitoring rules configured.

The pattern revealed an organization that confused purchasing security tools with implementing security controls. Control 5.1 (Information security policies) requires that controls be "implemented and operated" effectively. Having a policy document or purchasing a security tool doesn't constitute implementation without corresponding operational procedures and evidence of effectiveness.

For organizations seeking certification, implementation status should reflect genuine operational capability, not aspirational goals or partially deployed technologies. I typically ask to see evidence of control effectiveness—incident response records for security controls, vulnerability scan reports for technical controls, training completion records for awareness controls.

Risk Assessment Misalignment

The SoA must demonstrate clear linkage between your risk assessment results and your control selection. This is where organizations often reveal they've performed risk assessment as a documentation exercise rather than a genuine business analysis.

I audited a manufacturing company whose risk assessment identified "unauthorized access to production control systems" as their highest risk. Their SoA showed strong implementation of physical access controls and network security measures. However, when I examined their actual production environment, I found that critical manufacturing systems were accessible via unmanaged remote connections with default passwords, addressing none of their identified high-risk scenarios.

The disconnect between risk assessment and control selection indicated that either their risk assessment was generic and didn't reflect actual threats, or their control selection process ignored their risk assessment results. Both scenarios represent fundamental ISMS failures under Clause 6.1.3.

What the auditor looks for: I trace control selections back to specific risks in the organization's risk register. High-risk scenarios should have corresponding controls in the SoA. Controls addressing low-priority risks shouldn't be over-implemented while high-priority risks remain inadequately addressed. This alignment is fundamental to demonstrating a risk-based approach.

Incomplete Control Context and Dependencies

Modern information security controls rarely operate in isolation. A sophisticated auditor looks for organizations that understand control interdependencies and have documented how controls work together to address complex risk scenarios.

Many SoAs treat each control as an independent checkbox rather than part of an integrated security architecture. For example, Control 8.24 (Use of cryptography) is meaningless without corresponding key management procedures under organizational controls, appropriate technical implementation under system security controls, and staff competency under human resource security controls.

I frequently find organizations that have implemented individual controls effectively but haven't considered how they integrate. Their incident response procedures don't reference their vulnerability management process. Their access control implementation doesn't align with their business continuity requirements. Their supplier security assessment doesn't consider cloud service dependencies documented elsewhere.

This integration becomes critical when evaluating controls like 5.19 (Information security in supplier relationships), which must be implemented consistently across traditional suppliers, cloud service providers, and business partners. Organizations following ISO 27036 series standards for supplier relationship security often demonstrate more mature integrated approaches.

What the Auditor Really Looks For

When I open an organization's SoA during a certification audit, I'm not just checking compliance boxes. I'm evaluating whether the organization understands their risk environment, has implemented appropriate treatments, and can demonstrate ongoing effectiveness.

Specifically, I look for evidence that:

Control justifications reflect actual organizational context rather than generic template language
Exclusions are based on genuine business analysis rather than convenience or cost avoidance
Implementation claims can be verified through documentation, observation, and testing
Control selection addresses identified risks rather than following generic industry practices
Related controls integrate effectively to address complex risk scenarios

The SoA serves as a roadmap for the entire certification audit. Controls marked as implemented will be sampled and tested. Excluded controls will be validated against actual operations. Justifications will be compared to risk assessment results and organizational context.

Organizations that understand their SoA as a strategic document—demonstrating their risk-based approach to information security—consistently perform better in certification audits than those treating it as a compliance checkbox exercise.

Building an Audit-Ready SoA

Your Statement of Applicability should tell the story of your organization's approach to information security risk management. It should demonstrate clear thinking about your risk environment, thoughtful control selection, and honest assessment of implementation status.

Start with your actual risk assessment results, not industry templates. Reference specific business processes, technology environments, and organizational characteristics. Document control interdependencies and integration points. Be honest about partial implementations and planned improvements.

Remember that auditors have significant experience across different organizational types. Generic justifications and template language are immediately recognizable. Authentic documentation that reflects genuine organizational analysis and decision-making creates confidence in your overall ISMS approach.

The organizations that succeed in certification audits treat their SoA as a living document that evolves with their risk landscape and business environment. Those that treat it as a static compliance requirement often struggle not just with certification, but with building effective information security management capabilities.

Need guidance on developing an effective Statement of Applicability for your certification audit? The IX ISO 27001 Info Hub provides practical implementation guidance, or consider a consultation to review your current approach against auditor expectations.

Need personalized guidance? Reach our team at ix@isegrim-x.com.