The Statement of Applicability (SoA): what it is and how to write one

For the certification audit, the SoA is the map the auditor works from. It tells them what you claim to have in place, which means it tells them what to verify: the document review checks that your SoA, risk assessment and policies hang together, and the implementation audit then tests that reality matches what the SoA says. Every mismatch between the two is a finding waiting to be written.

Outside the audit, a well-kept SoA earns its keep as the honest one-page answer to "what do you actually do about security?": for new leadership, for internal audits, and for customers doing due diligence.

The SoA walks through all 93 Annex A controls (plus any additional controls you have adopted from other sources) and for each one records:

• The control itself, by code and name, so the row is unambiguous.
• Whether the control is applicable to your organization.
• The justification: why the control is included (typically which risks it treats or which obligation demands it) or, for exclusions, why it legitimately does not apply.
• The implementation status: implemented, partially implemented, or planned. State it honestly, since the auditor will test it.

Excluding a control is entirely legitimate when the justification holds. An organization that develops no software can reasonably exclude development-lifecycle controls; one with no physical offices of its own will scope several physical controls accordingly. The test is whether the exclusion traces to your scope and your risk picture.

What does not survive an audit is excluding a control because it is expensive, inconvenient, or not done yet. "Not implemented" and "not applicable" are different rows in the SoA, and swapping one for the other is the fastest way to turn a gap into a nonconformity.

The SoA is not written from intuition; it is the documented outcome of your risk work. The order runs: assess the risks, choose how to treat them, derive the controls the treatment requires, and then compare those necessary controls against Annex A to confirm nothing essential was overlooked. The SoA records the result of that comparison.

This is also where auditors probe for contradictions. If your risk register identifies a risk that a control plainly treats, and your SoA marks that control not applicable, one of the two documents is wrong, and now it is written down. Keeping the SoA and the risk assessment in step matters more than either document's polish.

An SoA describes your organization on the day it was written, and organizations do not hold still. New systems, new suppliers, a changed scope or an incident that shifts your risk picture: each can change which controls are necessary and how far implementation has come. The SoA should be versioned, reviewed on a cadence, and updated when the risk assessment moves.

The classic failure is the spreadsheet SoA that quietly diverges from reality until the weeks before an audit become archaeology: reconstructing what changed, when, and why. More discipline around the spreadsheet will not fix that. The fix is keeping the SoA where the assessment work actually happens.

In Aquil's Compliance Assistant, the assessment you maintain is the SoA's living source. Every control carries a status (including not applicable) with a written justification, an approval step so each answer is signed off by a named person with a timestamp, and links to the documents and processes that evidence it. Because the assessment is where the daily compliance work happens, the SoA data stays current as a by-product instead of as a separate chore.

When the auditor asks for the document, you export the Statement of Applicability straight from the assessment as a spreadsheet: every control with its domain, status, justification, approval state and attribution. The week of frantic assembly before the audit becomes a download.