The SoA isn’t written first; it falls out of risk treatment. You assess risks, decide how to treat them, and the treatments map to controls from Annex A, plus any you add from other sources. Each control then gets one of two verdicts: applicable, with a note on how it’s implemented, or excluded, with a justification an auditor will probe. A fully remote company might legitimately narrow some physical-security controls — but “we didn’t get around to it” is not a justification.
Certification auditors treat the SoA as the index of your ISMS: during stage 2 they walk it line by line, asking for evidence that each applicable control operates the way the document claims. That makes it the single highest-leverage artifact in an ISO 27001 program — every overstated row is a finding waiting to happen, and every version-control lapse invites scope confusion during fieldwork.
The classic failure mode is a template SoA describing a company that doesn’t exist — controls marked applicable because the template shipped that way. The fix is boring and effective: revisit the document whenever risk changes, when new systems enter scope, and before each audit, and make one named person accountable for keeping it synchronized with what actually runs.
