Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →The SoA is the first document a certification body reads and the one it returns to all week. This is what it has to contain, how each decision has to be justified, and where they fail.
The Statement of Applicability is the document required by ISO/IEC 27001 clause 6.1.3 d). It lists the controls you determined were necessary, gives a justification for including each one, states whether each is implemented, and gives a justification for every Annex A control you excluded. Annex A in the 2022 edition holds 93 controls across four themes. The SoA is not a checklist you fill in at the end; it is the output of the risk treatment step, and it only survives an audit if every line traces back to a risk in your register and forward to something the auditor can see running. Most SoA findings are not about the controls themselves. They are about justifications that say nothing, a version that does not match the risk treatment plan, or an implementation status that the evidence contradicts.
The Statement of Applicability is a controlled document that states, for every control in Annex A of ISO/IEC 27001, whether that control applies to your information security management system, why you reached that decision, and whether it is currently implemented. It also has to account for any control you determined was necessary that is not in Annex A at all, because the standard lets you take controls from anywhere as long as you then check your set against Annex A to confirm you have not left something out.
Think of it as the boundary agreement between you and the auditor. Once the SoA is issued, it defines what will be audited. A control marked applicable and implemented is a control the auditor is entitled to ask for evidence of. A control marked excluded is a control they will not test, provided your justification holds. That asymmetry is why the SoA is worth writing carefully rather than generating from a tool and never reading.
It is also the document that gets shared outside the audit. Enterprise buyers who understand ISO 27001 ask for the SoA alongside the certificate, because the certificate tells them only that you are certified and the scope statement tells them only what is inside the fence. The SoA tells them what you actually do. Write it knowing a customer's security team will read it.
Clause 6.1.3 is the risk treatment clause, and the SoA is one of several things it demands. The sequence inside the clause matters, because writing the SoA out of order is the single most common structural mistake and it is visible to an experienced auditor within ten minutes.
First you define and apply a risk treatment process. Second, for each risk you have assessed under 6.1.2, you select a treatment option: modify the risk, avoid it, share it, or retain it. Third, you determine the controls necessary to implement the treatment you chose. Fourth, you compare that set of controls against Annex A to verify no necessary control has been omitted. Fifth, you produce the Statement of Applicability. Sixth, you formulate the risk treatment plan. Seventh, you obtain risk owner approval of the plan and acceptance of the residual risk.
The point of step four is that Annex A is a checklist used to catch omissions, not a menu you shop from. The standard does not require you to use Annex A controls. It requires you to determine what is necessary from your own risk analysis and then use Annex A to make sure you did not forget anything. In practice almost everyone ends up with a control set that maps neatly onto Annex A, which is fine, but the direction of travel has to be from risk to control, not from control list to risk.
Teams that work backwards, meaning they take the 93 controls, mark most of them applicable, and then reverse-engineer risks to justify the decision, produce an SoA where the risk register and the SoA do not reference each other. That is exactly what a stage 2 auditor is looking for when they pick a control and ask which risk it treats.
The standard states the required content rather than a required format. You need the necessary controls, the justification for including each, whether each is implemented, and the justification for excluding any Annex A controls. Nothing says it has to be a spreadsheet, but a spreadsheet with one row per control is the format every certification body expects and the one that is fastest to audit.
The columns below are the working minimum. Everything beyond them is optional, but two additions earn their keep: a reference back to the risk identifiers being treated, and a reference forward to the policy or procedure that carries the control. Those two columns are what turn an SoA from a claim into something traceable, and they are what stop you rebuilding the argument from memory in the audit room.
Keep the implementation status honest and use more than two values. A binary implemented or not implemented forces you to lie about controls that are partially in place. Implemented, partially implemented with a target date, and planned with a target date is a three-value scale that auditors accept and that matches how work actually lands. A partially implemented control with a date in the risk treatment plan is a normal finding-free state at certification. A control claimed as implemented that turns out not to be is a nonconformity.
The weakest justification in circulation is a restatement of the control title. Against A.8.8, management of technical vulnerabilities, an SoA that says "to manage technical vulnerabilities" has justified nothing. It tells the auditor you copied the column across.
A justification for inclusion should name a driver. There are only four kinds worth writing, and most controls are included for more than one. The first is risk: name the risk identifiers from your register that this control treats, for example "treats R-014 unpatched internet-facing infrastructure exploited". The second is a legal, regulatory or contractual requirement: name it, for example "required by the security schedule in the enterprise MSA template, clause 7.2". The third is a business requirement of your own, for example an availability commitment you make in a service level agreement. The fourth is that Annex A comparison itself, where you kept a control because dropping it would leave an obvious gap even though no single risk drove it.
One sentence per control is enough. Two clauses, a driver and a reference. The auditor is not grading prose, they are checking that a real decision happened and that it points somewhere they can follow. An SoA where 93 rows carry 93 distinct, specific sentences is unusual and it visibly changes how the rest of the audit goes.
Where a control is included because a customer contract demands it rather than because your own risk analysis surfaced it, say so explicitly. That is a legitimate and common reason, and it also protects you later: when the contract goes away, you have a written record of why the control was there and can make a deliberate decision rather than carrying it forever.
Excluding Annex A controls is allowed, expected, and not a mark against you. What is a mark against you is excluding a control for a reason that does not survive a follow-up question.
Justifications that hold: the control addresses an activity you do not perform, the asset type does not exist in your environment, or the responsibility sits wholly with a third party under an arrangement you can evidence. A pure SaaS company with no data centre of its own legitimately reduces much of the A.7 physical set to reliance on the cloud provider and the office landlord. A company that writes all its own software legitimately excludes A.8.30, outsourced development, until the day it engages an outside development shop.
Justifications that do not hold: that the control is expensive, that you have not got to it yet, that it is planned for next year, or that it is "not applicable at our size". None of those are applicability statements. They are risk acceptance decisions wearing the wrong hat. A control you need but have not built is applicable and not yet implemented, with a date in the risk treatment plan. Marking it excluded to keep the SoA tidy is the fastest way to turn a scheduling matter into a nonconformity.
The other failure mode is excluding by delegation without evidence. Saying that physical security is handled by the cloud provider is fine if you hold their current certification or attestation report and you have read it. Saying it while never having downloaded the report is an unsupported exclusion, and it collides with your supplier controls under A.5.19 through A.5.23, which the auditor will also be looking at. If you lean on a provider in the SoA, be ready to produce the document you leaned on.
Watch the controls that people exclude out of habit rather than analysis. A.5.7 threat intelligence, A.8.11 data masking, A.8.12 data leakage prevention, A.8.23 web filtering and A.7.4 physical security monitoring are the usual candidates. Each of them can be legitimately excluded or legitimately scaled down to something small, but the justification has to describe your environment rather than assert that the control belongs to larger companies.
The 2022 edition of Annex A contains 93 controls arranged in four themes: A.5 organizational controls, 37 of them; A.6 people controls, 8; A.7 physical controls, 14; and A.8 technological controls, 34. This replaced the 114 controls in 14 clauses of the 2013 edition. If your SoA still has 114 rows or references clause numbers like A.9 or A.12, it is built on the withdrawn edition and that alone will be raised.
The themes are not a workload distribution. For a cloud-hosted software company the A.8 technological block is largely already true in your infrastructure and the work is evidencing it, while the A.5 organizational block is where the writing happens: policies, supplier management, incident management planning, classification, legal and contractual requirements. Budget your time accordingly rather than by row count.
Eleven of the 93 were new in 2022 and they are the ones most often handled thinly, because pre-2022 templates do not cover them well. They are threat intelligence, information security for use of cloud services, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering, and secure coding. Auditors know which controls are new and they sample them. Give each of those eleven a justification you wrote yourself.
Note also that the 2024 amendment to the standard added a climate change consideration to the context clauses, 4.1 and 4.2. It did not change Annex A. If someone hands you an SoA with a climate control row in it, that row is invented.
An auditor tests the SoA mostly by pulling on threads that leave it. The commonest thread is backwards, into the risk register. They pick three or four applicable controls, ask which risks drove them, and then open the register to see whether those risks exist, have a named owner, and carry scores that were evaluated against your stated acceptance criteria.
This is why the risk identifier column is worth having. Without it, the answer to "why is A.8.24 use of cryptography applicable" has to be reconstructed live by whoever is in the room, and the reconstruction rarely matches what the register says. With it, the answer is a cell reference and the conversation takes twenty seconds.
The reverse thread is just as common and catches more people out. The auditor opens the risk register, picks a high risk, and asks which controls treat it. If the risk is real and significant and the SoA has nothing pointed at it, you have a risk you accepted without saying so. That is a treatment gap, and depending on how large the risk is it can be raised as a nonconformity rather than an observation.
The house view we take with clients is that a risk register of 25 to 50 genuine risks with named owners is the right size for a company under a few hundred people. Fewer than that and the register is not covering the estate. Many more and the mapping to controls becomes something nobody maintains, which shows up two audits later as an SoA that has drifted away from the register entirely.
The SoA and the risk treatment plan are two different documents and conflating them is a recurring problem. The SoA says what applies and whether it is in place. The risk treatment plan says what work is outstanding, who owns it, when it is due, and what resources it needs. One is a statement of position, the other is a schedule.
The rule that keeps them consistent is simple: every control in the SoA that is not fully implemented must have a corresponding line in the risk treatment plan with an owner and a target date. If an auditor finds a partially implemented control in the SoA with nothing in the plan, they have found an item that nobody is going to do, and they will say so.
The inverse check is worth running yourself before every audit. Take the treatment plan, and for each line confirm the SoA status matches. Plans get worked and closed without anyone going back to flip the SoA row from planned to implemented. An SoA that understates you is less damaging than one that overstates you, but it still reads as a document nobody maintains.
Treatment plans with visible slippage and written explanations are more credible than plans that are entirely green. An auditor who sees a plan where every item closed on its original date generally starts checking whether the dates were set after the work was done.
The SoA is documented information under clause 7.5, so it needs the controls that clause requires: identification, format, review and approval, version, and control of changes. In practice that means a version number, an issue date, a named author, a named approver, an approval date, and a change log with one line per revision saying what changed and why.
Who approves it depends on how you have written your own ISMS documentation. There is no clause naming an approver for the SoA specifically. What clause 6.1.3 does require is documented approval of the risk treatment plan and acceptance of residual risk by risk owners, and in most organizations the practical answer is that the person accountable for the ISMS, typically the CISO or the executive who owns security, approves the SoA, and the risk owners sign the residual risk acceptance that sits behind it.
Do not let the SoA live as a shared spreadsheet that anyone can edit in place with no history. If it does live in a spreadsheet, export and archive a dated PDF at each approval. The auditor will want to see the version that was in force during the period they are auditing, and at a surveillance audit they will want to see the difference between this year's version and last year's.
Reissue the SoA whenever the risk assessment is re-run, whenever a control changes applicability, and whenever the ISMS scope changes. Once a year at minimum, tied to the annual risk assessment cycle, is the cadence most certification bodies expect to see. An SoA with an approval date more than twelve months old at the time of audit invites a question you do not want to spend time on.
At stage 1, the SoA is one of the core documents the auditor reads before they come anywhere near your systems. Stage 1 is a documentation and readiness review, and its main output is a decision about whether you are ready for stage 2 plus a list of areas of concern. The auditor reads the scope statement, the SoA, the risk assessment methodology, the risk register, the internal audit report and the management review minutes, and they check those documents against each other. An SoA that does not match the scope statement is caught here.
They also use the SoA to plan stage 2. The audit plan you receive before stage 2 is effectively a sampling schedule drawn from your applicable controls. This is the practical consequence of a bloated SoA: if you mark everything applicable to look thorough, you have handed the auditor a longer list to sample from and given yourself more evidence to produce, for no benefit.
At stage 2 the SoA is the index. The auditor works through samples of applicable controls, asks for the evidence, and compares what they find to the implementation status you claimed. They will also test a handful of exclusions by asking a question designed to find the excluded activity happening anyway. If you excluded A.8.30 outsourced development and they find a contractor in your commit history, that is where the conversation goes.
At surveillance audits in years two and three, the SoA is where they start to check the ISMS is alive. They compare this year's version to the version they saw at certification. Zero changes across a year in a growing company is itself a signal, because environments change and risk registers change with them. An SoA that has not moved suggests the risk assessment has not been re-run.
The nonconformities and observations that come out of the SoA cluster into a small number of shapes, and almost all of them are avoidable in an afternoon of honest editing.
Justifications that restate the control title. Not a nonconformity on its own in every auditor's hands, but it is raised as an observation constantly, and it changes their opinion of the rest of your documentation.
Implementation status contradicted by evidence. The SoA says A.8.15 logging is implemented; the sample shows logging is on in production but not in the environment holding a copy of customer data. This is a real nonconformity because the record is inaccurate, and inaccuracy in the SoA is a clause 6.1.3 problem rather than a logging problem.
Exclusions with no justification, or a justification of "N/A". A blank cell against an excluded control is a direct failure of the explicit requirement in 6.1.3 d) to justify exclusions.
The SoA and the risk treatment plan disagreeing about the same control. Two documents in the same management system giving different answers is a documented information problem as well as a risk treatment one.
The SoA built on the 2013 edition, with 114 controls or old clause numbering. Straightforward and fatal to a smooth stage 1.
An SoA with no approval, no version, or a version that does not match the one referenced in the management review minutes. Small, avoidable, and it wastes audit time you would rather spend on substance.
If you are starting from nothing, build it in this order and it will take days rather than weeks. One: finish the risk assessment first, with named owners and scores evaluated against a written acceptance threshold. Two: decide a treatment option for every risk above threshold and write down the controls that deliver it, in your own words, before you look at Annex A. Three: lay your control set against the 93 Annex A controls and mark the matches. Four: for each Annex A control with no match, decide applicable or excluded and write the justification then and there, while you still remember why.
Five: fill in implementation status honestly using three values. Six: every row that is not fully implemented becomes a line in the risk treatment plan with an owner and a date. Seven: get residual risk accepted by the risk owners in writing. Eight: version, approve, date, and archive a copy.
Expect the fourth step to take the longest and to surface two or three controls you genuinely had not thought about. That is the step doing its job. The controls it surfaces are usually in supplier management, information deletion, or secure development, because those are the areas where practice exists informally and has never been written down.
If you want a starting point for how each control reads in practice, our free ISO 27001 gap assessment walks the same control set and tells you what evidence each one needs.
| Column | What goes in it | What the auditor checks |
|---|---|---|
| Control reference | The Annex A identifier, 2022 numbering: A.5.1 through A.8.34, all 93 rows present. | That the list is complete and on the current edition. Missing rows and 2013 numbering are caught immediately. |
| Control name | The control title as written in the standard, not a paraphrase. | Nothing directly, but paraphrased titles suggest the document was assembled from a template of unknown provenance. |
| Applicable | Yes or no. No third option. | That the balance is plausible for your business, and that nothing obviously core to your operation is marked no. |
| Justification | One sentence naming the driver: risk identifier, contract clause, statute, or business requirement. For exclusions, why the activity or asset does not exist in your environment. | That it says something specific. Restated control titles and blank cells are the two most raised issues on this column. |
| Risk reference | The identifiers of the risks this control treats, straight from the register. Optional in the standard, decisive in the audit room. | They pick two or three and open the register to see the risks exist, are owned, and are scored. |
| Implementation status | Implemented, partially implemented, or planned. Partial and planned carry a target date. | They sample controls marked implemented and test whether the evidence supports the claim. An overstated status is a nonconformity. |
| Control owner | A named person, not a team or a job family. | That the named person exists, knows they own it, and can describe the control when asked. |
| Reference to policy or procedure | Where the control is written down: policy name and section, runbook, or ticket queue. | They follow the link. A reference to a document that does not exist is worse than no reference. |
| Version, date, approver | Document header: version number, issue date, author, approver, approval date, plus a change log. | That the version in force during the audit period is retrievable, and that it matches the version cited in management review minutes. |
Yes. Clause 6.1.3 d) requires the organization to produce a Statement of Applicability containing the necessary controls, the justification for their inclusion, whether they are implemented, and the justification for excluding any Annex A controls. It is one of the documents a certification body will not proceed without.
All 93 of them in the 2022 edition, across the four themes: 37 organizational, 8 people, 14 physical, and 34 technological. Every one gets an applicability decision and a justification, including the ones you exclude. If your SoA has 114 rows it was built on the withdrawn 2013 edition.
Yes, and most organizations do. Exclusion is legitimate where the activity is not performed, the asset type does not exist in your environment, or the responsibility genuinely sits with a third party you can evidence. What fails is excluding a control because it is expensive, not yet built, or planned for later. Those are risk decisions, not applicability decisions, and the control should be marked applicable and not yet implemented instead.
The SoA is a statement of position: which controls apply, why, and whether they are in place. The risk treatment plan is a schedule: what outstanding work exists, who owns it, and when it is due. Every control in the SoA that is not fully implemented should appear as a line in the treatment plan, and the two documents must not disagree about the same control.
At minimum annually, tied to the risk assessment cycle, and additionally whenever a control changes applicability, the ISMS scope changes, or a significant change triggers a reassessment. At surveillance audits the certification body compares this year's version to last year's, and an SoA that has not moved in a growing company raises the question of whether the risk assessment was re-run.
The standard does not name a specific approver for the SoA itself. What clause 6.1.3 requires is documented approval of the risk treatment plan and acceptance of residual risk by the risk owners. In practice the executive accountable for the ISMS approves the SoA, and the risk owners sign off the residual risk that sits behind it, with both records dated and retained.
You are not obliged to, but buyers who understand ISO 27001 routinely ask for it alongside the certificate, because the certificate and the scope statement together still do not say what controls you operate. Many organizations share the SoA under NDA or publish a summarized version in a trust centre. Write it assuming a customer security team will read it.
Justifications that restate the control title and say nothing about your environment, followed closely by an implementation status the evidence contradicts. The first is usually raised as an observation, the second as a nonconformity, because an inaccurate record is a failure of clause 6.1.3 in its own right regardless of how the underlying control is performing.
traztech Workspace has every control of whichever frameworks apply to you, written in plain English, with somewhere to attach the proof. Free to use, with no card and no trial clock.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | $11,000 off a five-figure quote on one engagement, for a documented readiness position | Nothing. The audit firm prices your readiness, not your tooling |
Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.
We build the risk register, the treatment plan and the Statement of Applicability as one connected set, so every line traces to a risk and every status matches the evidence.
Book a strategy callWant the human version?
Jacob sends a few short, practical notes on getting security and compliance right without the months of pain. No fluff, unsubscribe in one click. Reply anytime; it reaches him directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.
Track record
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.