What the ISO 27001 Statement of Applicability must show before an auditor will accept it
If a customer or contract asks for ISO 27001, the Statement of Applicability (SoA) is one of the first documents an auditor will ask for. It is a mandatory output under clause 6.1.3 d) of ISO/IEC 27001:2022, and it must show a comparison of the controls the organization determined as necessary against all 93 Annex A controls. Every Annex A control needs a stated decision: included or excluded, with a justification for each inclusion and each exclusion. An SoA that lists controls without reasons, or that quietly drops Annex A entries, will not survive stage 1.
The content of the SoA differs from one organization to the next, because it follows three inputs: the risk assessment and risk treatment plan, the scope of the ISMS, and the implementation status of each control. Two organizations with the same 93 controls can reasonably reach different decisions. Before drafting, confirm that each control marked as included has a named owner, a link to a treatment decision, and a status an auditor can test, such as implemented, partially implemented or planned. Confirm too that each exclusion is tied to a specific risk or scope boundary, not to a preference or a convenience.
The organization owns the SoA. Its leadership must approve the decisions in it, and the people who run the controls must be able to explain them. A consultant or implementation partner can help build the comparison against Annex A, check that the risk treatment plan and the SoA agree, and organize the evidence references. Only the accredited certification body audits the SoA, and it will test whether the stated decisions match what the organization actually does. Ask any outside helper to show how the SoA will be kept current after the initial audit, because the certification body will check that too.
How the Statement of Applicability is built from the risk treatment plan
The sequence turns the risk assessment into a Statement of Applicability that lists every necessary control, shows how each Annex A control was judged, and points to the evidence behind each one. Each step leaves a record an auditor can follow from risk to control to proof.
Confirm the risk assessment and treatment outputs
Before drafting anything, the organization confirms that its risk assessment is complete and that its risk treatment decisions are recorded. Clause 6.1.3 begins with the treatment of information security risks, so the inputs are the risk register and the decisions about which risks to modify, retain, avoid or share. The organization owns this step. An implementation partner or consultant can prepare the register, but the risk owners must accept the decisions. The step is done when every risk in scope has a documented treatment decision that a named owner has approved.
Determine the necessary controls
From the treatment decisions, the organization identifies the controls it needs to reduce the risks to its accepted level. Clause 6.1.3 c) requires the organization to determine all controls that are necessary to implement the chosen risk treatment options. Controls may come from Annex A, from other sources, or be designed by the organization. The output is a working list of necessary controls, each linked back to the risks it addresses. ISO/IEC 27005:2022 gives guidance on this link between risk treatment and controls, and ISO/IEC 27002:2022 gives implementation guidance for each Annex A control. The step is done when every treatment decision maps to at least one control.
Compare the necessary controls with Annex A
The organization compares its list of necessary controls with the 93 controls in Annex A of ISO/IEC 27001:2022, which are grouped into organizational (37), people (8), physical (14) and technological (34) themes. Clause 6.1.3 c) requires this comparison so that no necessary control is omitted by accident. IAF MD 26:2023 describes it as a check that the organization has not inadvertently left out a control it needs. The output is a mapping table that shows, for each Annex A control, whether it matches a necessary control. The step is done when the comparison has been reviewed by someone other than the author.
Update the risk treatment plan for any missing control
If the comparison finds a necessary control that is missing from the plan, the organization must act before it can finish the Statement of Applicability. IAF MD 26:2023 states that the organization must update its risk treatment plans and implement the missing control. This is the step where the document set changes: the risk treatment plan gains a new entry, the risk owner accepts it, and the control is put into operation with an owner and a target date. The output is a revised risk treatment plan with a dated change record. The step is done when no necessary control remains unplanned. Illustrative example: a team maps its risks and finds that a supplier access risk has no matching control, so it adds a supplier access control to the plan before recording the SoA entry.
Record inclusions and exclusions with justification
For each Annex A control, the organization records whether it is included or excluded in the Statement of Applicability. An included control is linked to the necessary controls and risk treatments that require it. An excluded control must have a written justification tied to the risk assessment, because excluding a control without a reason is a common audit finding. Clause 1 of ISO/IEC 27001:2022 makes clear that excluding a requirement from clauses 4 to 10 is not acceptable for a conformity claim, so exclusions apply only to Annex A controls. The output is a complete table listing all 93 controls, each marked as included or excluded with its reason. The step is done when every one of the 93 controls has an entry.
State implementation status and evidence location
For each included control, the organization records its implementation status and where the evidence of that control is kept. Status should be stated in plain terms, such as implemented, partly implemented or planned, with the owner named. The evidence location is a document, system, ticket queue or log that an auditor can open and read. Vague references such as the team's shared drive make audit sampling slow. The organization owns the content of these entries. An implementation partner may help assemble the evidence locations, but the owners must confirm them. The step is done when every included control has a status, an owner and an evidence location that a person outside the team can find.
Approve, version and control the Statement of Applicability
The completed Statement of Applicability goes to the people who own the ISMS for approval, and the approval is recorded with a version number, date and the names of the approvers. Each later change to an inclusion, exclusion, status or evidence location creates a new version, so the history shows how the document moved with the risk treatment plan. The certification body reviews this document during the initial audit, and the organization keeps it in step with the plan during each surveillance and recertification audit. The step is done when the approved version is stored under document control and the team can explain every change since the previous version.
What auditors check in the Statement of Applicability
The Statement of Applicability is the document a certification body reads first when it tests clause 6.1.3. Auditors follow a short set of checks that connect every Annex A decision to the risk assessment, the risk treatment plan and the evidence the organization actually holds. The cards below cover the checks an auditor is likely to run on the SoA before and during the audit.
Every Annex A control has a decision
Auditors compare the SoA line by line against all 93 Annex A controls: 37 organizational, 8 people, 14 physical and 34 technological. Each control must be marked as included or excluded, and included controls must name the means of implementation. A blank row, a control missing from the list or a control number from the 2013 edition signals that the comparison in clause 6.1.3 c) was not done. Ask for the comparison record, not only the final table.
Exclusions need a justification
An exclusion is acceptable only when the control is not necessary for the risk treatment, and the SoA must say why. Auditors reject reasons such as cost, inconvenience or that a tool is not yet deployed, because those do not tie to a risk. Clause 1 also bars excluding any requirement in clauses 4 to 10, so a justification for a management system requirement is not an exclusion route. Check each excluded control against the risk register for a gap.
Risk treatment plan traceability
Each included control should trace back to a risk in the risk assessment and to a treatment decision in the risk treatment plan under clause 6.1.3. Auditors pick a sample of risks and follow them to the SoA, then pick controls and follow them back to risks. If a control appears in the SoA with no risk behind it, or a high risk has no control, the link is broken. An illustrative check: a risk to privileged access should point to the access control and the logging control, and both should appear as included.
Implementation status matches evidence
A status such as implemented or planned is a factual claim that auditors test against records. They ask for the configuration, the policy approval, the access review or the training log behind each implemented control. A status recorded as implemented with no retrievable evidence, or a control described as in progress that already runs, will produce a nonconformity. Confirm with the certification body how it will sample controls before stage 2.
Version and scope consistency
The SoA carries a version, date and approval, and auditors check that it matches the current ISMS scope and the latest risk assessment. A change in scope, a new site, a new cloud account or a new supplier can alter which controls apply, so an SoA older than the last risk assessment is a common finding. Ask who approves each revision and how changes to the risk treatment plan are reflected before the next audit.
Why excluding a control needs more than a sentence
Excluding an Annex A control from the Statement of Applicability is allowed, but only the Annex A controls can be excluded. Clause 1 of ISO/IEC 27001:2022 makes clear that leaving out any requirement in clauses 4 to 10 is not acceptable for a conformity claim, so the management system clauses stay in scope regardless of what your risk assessment finds. The justification column is where an auditor tests whether an exclusion is a genuine decision or an omission. For each excluded control, the reader should be able to point to the risk assessment outcome that led to the exclusion and state the specific reason the risk does not apply to the organization's scope.
A defensible justification names the condition that makes the control unnecessary. For example, an organization that does not operate any secure development environment and builds no software could justify excluding a secure development control, but only if its risk assessment records that no in-house development takes place and its ISMS scope matches that fact. A reason such as "not applicable" or "low risk" gives the auditor nothing to verify and is a common source of nonconformities. The reason should also be checked against the scope on the certificate: if a control is excluded for a business function that sits inside the ISMS boundary, the exclusion will not hold.
Before stage 1, send the draft exclusion wording to your certification body and ask how it will be assessed, then keep the answer on file. Confirm whether the certification body expects a reference to the risk register entry, the owner who approved the exclusion, and the date of the review. Wording rules and audit practice can differ between bodies, so treat their response as the reference point rather than general guidance. Also confirm that every exclusion is also reflected in the risk treatment plan, because an exclusion that appears in one document and not the other is a finding an auditor will raise.
Columns a Statement of Applicability needs and who fills them
This table compares each column a Statement of Applicability needs, what it records, who owns the content and the evidence a reviewer will ask for. The organization owns every entry, while an implementation partner may only prepare drafts and link evidence.
| SoA element | What it records | Who owns the content | Evidence a reviewer will ask for |
|---|---|---|---|
| Control ID and title | The Annex A control reference from ISO/IEC 27001:2022, such as A.5.15, with its title, listed once for each of the 93 controls or each necessary control | Organization (ISMS owner), with a partner checking the list is complete | The Annex A comparison record showing each of the 93 controls was considered |
| Applicability decision | Whether the control is applied, and any added controls the organization determined as necessary | Organization, approved by top management or the ISMS owner | Risk assessment output linking each decision to identified risks |
| Justification | Why the control is included or excluded, in terms of the risks it treats or the context that makes it unnecessary | Organization, with the reasoning written in its own words | Risk register entries and a documented rationale for any exclusion |
| Implementation status | Whether the control is implemented, partly implemented or planned, with a short description of how | Control owner named by the organization | Procedures, configurations or records showing the control operates today |
| Linked risk treatment plan entry | The reference to the risk treatment plan item that drives the control | Organization (risk owner) | Risk treatment plan with approvals and dates matching the SoA |
| Evidence location | Where the proof sits, such as a system, repository or document location, with access rights | Control owner, with a partner able to prepare the link list | Accessible evidence the auditor can sample during stage 2 |
| Version or review date | The SoA version, its approval date and the date of the last review after risk changes | Organization (document owner) | Version history showing updates after the risk assessment or treatment plan changed |
How the Statement of Applicability changes by organization type
A small SaaS company usually has one product, one cloud account set and a single team that builds and operates it. Its risk assessment tends to centre on customer data in the application, the production cloud, the source code pipeline and the support tooling. In an illustrative case, the company's SoA includes most technological controls for access, logging, secure development and backup, while some physical controls for office premises may be marked as excluded because the company operates no data center and relies on its cloud provider's facilities. Each exclusion still needs a written justification tied to the risk assessment.
- Scope drives inclusion: A narrow product scope often means fewer locations and fewer systems, but the cloud and supplier controls still apply to every provider holding customer data.
- Exclusions need reasons: Marking a physical or hosting control as not applicable must reference where the hosting risk is treated, such as the provider's own certification.
- Remote working is in play: People and technological controls for endpoints and remote access usually appear in the SoA even for very small teams.
- Customer questionnaires feed the SoA: Commitments made to customers often reveal controls that the risk assessment should have covered.
- Implementation status must be honest: Controls marked as implemented need evidence that a sample of the work exists.
Before submitting, confirm that every Annex A control has a recorded decision and that each one links to a treatment plan entry.
A multi-site organization often runs some controls centrally, such as identity, logging and the security operations function, while local sites run their own physical and people controls. The SoA must show which controls apply to which sites, or state that they apply to the whole certified scope. Where sites share a control, the SoA should say who operates it and where its evidence sits. In an illustrative case, a central team may own the access control and cryptography controls for every site, while site managers own visitor logs and secure area controls.
- Shared control ownership: Each control entry should name the function that operates it, so a site cannot claim a central control it does not run.
- Site-specific exclusions: A physical control might apply to one data site but not to an office that holds no information assets.
- Scope consistency: The sites listed in the ISMS scope must match the sites the SoA describes.
- Risk differences by site: A high-risk site may need controls that a low-risk site does not, and the SoA should reflect that difference.
- Central evidence: Shared controls are easier to show when one register holds the evidence for all sites.
Confirm with the certification body how it plans to sample sites, because the SoA must support that sampling approach.
An organization certified to ISO/IEC 27001:2013 must move to the 2022 edition, and the 2013 certificates had to expire or be withdrawn by 31 October 2025, the end of the 36-month transition period under IAF MD 26:2023. IAF MD 26:2023 requires transition audits to cover the organization's gap analysis, the update of the Statement of Applicability and, where applicable, the update of the risk treatment plan. Because the 2013 control set was organized differently, the old SoA cannot simply be relabelled. The 2022 Annex A has 93 controls in four themes, with 11 new controls, 24 merged controls and 58 updated controls, so each old control must be mapped to its current counterpart and assessed afresh.
- Transition audit covers the SoA update: The transition audit must examine the revised SoA, not only the controls that changed.
- New controls need decisions: The 11 new controls, such as threat intelligence and cloud security, must each be marked applicable or excluded with a reason.
- Merged controls need checking: Where earlier controls were combined, the SoA must show that the merged control still covers all the earlier risks.
- Attributes and purpose: Each 2022 control carries attributes and a purpose, so the justification should use them.
- Risk treatment plan follows: A new or changed control may require an update to the treatment plan under clause 6.1.3.
Confirm with the certification body whether the transition was completed within the transition window, because the status of the old certificate determines what the SoA update must demonstrate.
Keeping the Statement of Applicability in step with the risk treatment plan
The Statement of Applicability (SoA) is only useful if it describes the organization as it is today, so the decisive point is that it must be reviewed and updated whenever the inputs behind it change. The SoA records which controls are necessary, which Annex A controls apply or are excluded, and their implementation status, and those entries depend on the risk assessment, the scope of the ISMS and the risk treatment plan under clause 6.1.3. When the risk assessment changes, when the scope changes, when a control is implemented or retired, or when a control is found to be missing, the SoA and the treatment plan have to move together. Clause 8.2 requires risk assessments at planned intervals and after significant changes, so the risk assessment cycle is the natural trigger for an SoA review.
ISO/IEC 27005:2022 gives guidance on the risk assessment and treatment that produce the controls listed in the SoA, and it is the reference most auditors expect you to follow when you explain how a risk led to a control decision. In practice, each review should answer three questions: did any risk rating change, did any new risk appear, and did any control status change (for example, from planned to implemented, or from applicable to excluded with a new justification). Record the date, the reviewer and the reason for each change so the version history shows why the document looks as it does. A simple test is to pick one changed control and trace it back through the treatment plan to the risk that drove it.
Your certification body will test the SoA at each surveillance and recertification audit, and it may also sample it earlier if the scope or controls have changed significantly. Confirm with your certification body how often it expects the SoA review to happen, what evidence of review it wants to see between audits, and whether it expects a dated revision history or a formal approval by management. Agree that cadence before your first stage 1 audit so the review rhythm, the risk assessment schedule and the internal audit programme line up with the audits you will face.
Evidence and open-source tooling that supports each SoA entry
Each Statement of Applicability entry makes a claim that an assessor will test by asking for evidence. The cards below cover the evidence types that most often support SoA entries and the self-hosted open-source tools that can store or produce them. Confirm each tool's capability against your own requirements before you rely on it for an assessment.
Policies and procedures register
Every SoA entry marked as implemented points to a policy, standard or procedure that sets out the control. Auditors check that the document is approved, has an owner, is version-controlled and is the version staff actually follow. A self-hosted wiki or document platform can hold these documents with revision history, but confirm it supports approval workflows, review dates and access records for the policy set. Link each SoA row to a stable document identifier so the reference survives edits.
Configuration exports and baselines
Technological controls such as secure configuration, network security and cryptography are usually evidenced by exports of the actual settings, not by descriptions of intended settings. Store configuration as code in a self-hosted Git server, and capture dated exports from the running systems. Ask a tool vendor to confirm which settings it can export and whether exports can be timestamped and kept unchanged for the audit period.
Access review records
SoA entries on access rights, privileged access and identity management need dated reviews showing who had access, who approved it and what was removed. Self-hosted identity platforms can export group memberships and role assignments, but the review decision and its sign-off must be recorded somewhere. Confirm that your identity platform can produce a point-in-time user and role list, and that the review record links back to it.
Logs and monitoring records
Controls on logging, monitoring and clock synchronization need logs that are complete, protected from alteration and retained for the period the SoA states. A self-hosted log platform can centralize events from servers, applications and identity systems. Confirm which sources it can ingest, whether it protects stored logs from edits, and how it handles time sources, since auditors sample log entries to test the claim.
Backup and restore test records
Backup and information continuity entries are only supported when restores have been tested, not just when backup jobs report success. Keep restore test logs with the date, scope, the person who ran the test and the result. Open-source backup tools can produce job reports, but a restore test is a separate activity that needs its own record. Confirm the tool's reporting covers restore verification before you list it as evidence.
Training and awareness records
Entries for awareness and competence depend on records showing who completed training, when, and on which version of the material. A self-hosted learning platform or LMS can hold completion data, but the training content and attendance records must match the people in scope for the ISMS. Confirm that the platform can export completion dates by user and retain them across staff changes.
Who owns the Statement of Applicability and who only prepares it
The organization owns the Statement of Applicability. Clause 6.1.3 d) of ISO/IEC 27001:2022 places the document inside the organization's risk treatment process, so the people who carry the risks, and who can accept them, must decide which controls apply. Management approval of the risk treatment decisions sits with the organization, and so does the accountability for each control that is claimed as implemented.
- Applicability decisions: Named owners decide which Annex A controls are included, which are excluded, and which necessary controls are added from outside Annex A.
- Justifications: Each inclusion and exclusion carries a reason written by the organization, not copied from a template or a vendor.
- Implementation status: Owners confirm whether each control is in place, partly in place or planned, and where the evidence sits.
- Approval and review: Leadership approves the document and its changes, and the organization records when it was last reviewed.
- Control ownership: Each control has a named internal owner who answers auditor questions about it.
Before accepting any draft, confirm that the organization's own owners can explain every line without reading from the document.
An implementation partner such as DeployOpen prepares the Statement of Applicability and the evidence behind it. The partner works from the organization's risk treatment plan and the Annex A control list, drafts the table, and maps existing evidence to each control. Where systems hold that evidence, the partner configures the tools and evidence stores so the proof can be pulled on request. The partner does not decide applicability and does not sign the document.
- Draft preparation: The partner produces a working draft for the organization to review, challenge and approve.
- Evidence mapping: Existing policies, configurations, logs and records are linked to the controls they support.
- System configuration: Self-hosted platforms are set up to generate and retain the evidence each control needs.
- Gap flagging: Controls with no evidence, or claimed controls that cannot be shown, are reported back to the organization.
- Change tracking: Updates to the risk treatment plan are reflected in drafts for the organization to approve.
DeployOpen does not issue audit reports or certificates. Ask any partner to state in writing which parts of the work it performs and which the organization signs.
The certification body, which must be an accredited ISMS certification body for the certificate to be recognized, audits the Statement of Applicability. Under ISO/IEC 27006-1:2024, which accredited bodies apply to clients, auditors plan how to test the controls using the Annex E guidance aligned to Annex A. The certification body is the only party that issues the certificate. ISO itself does not certify organizations.
- Comparison check: The auditor confirms that the organization compared its controls with Annex A and that no necessary control was left out.
- Justification review: Each exclusion is tested against the risk assessment and the organization's stated reasons.
- Evidence testing: Controls marked as implemented are sampled and checked against records and system output.
- Independence: The auditor cannot write the Statement of Applicability for the client and still audit it.
- Decision: The certification body issues or withholds the certificate based on its own findings.
Before engaging a certification body, confirm its accreditation and ask how it will test the Statement of Applicability.
Questions buyers ask about the Statement of Applicability
Is a template enough for an ISO 27001 Statement of Applicability?
No. A template gives you the layout and the list of the 93 Annex A controls, but the Statement of Applicability is only useful when each row reflects your organization. Auditors check that every control you include or exclude is justified by your risk assessment and risk treatment decisions, that the implementation status matches what they can see, and that the document is consistent with your risk treatment plan. A generic document with every control marked as applicable and the same wording for each row will not show that. Use a template as a starting point, then rewrite the justifications and status entries against your own scope, assets, suppliers and risks. Ask your certification body what level of detail it expects before you finalize the document.
How long does it take to write a Statement of Applicability?
The time depends on drivers rather than a fixed number. The main ones are the size and complexity of the scope, how many Annex A controls you already run with evidence, how mature your risk assessment is, and how many people must confirm the status of each control. A small, single-site organization with clear policies and an up-to-date risk register will move much faster than a multi-site group with many suppliers and cloud accounts. Expect the document to be revised more than once, because the risk treatment plan and the Statement of Applicability must agree. Guidance on the risk assessment and treatment work behind the document is in ISO/IEC 27005:2022, which you can review through the ISO committee page. Confirm timing expectations with your certification body and the people who own each control.
Can our own team write the Statement of Applicability without a consultant?
Yes, the organization owns the Statement of Applicability, and an internal team can write it. The document must reflect decisions the organization makes about its own risks, so the people who run the controls and the people who accept the residual risk should sign off the content. An outside implementation partner can help structure the comparison with Annex A, challenge justifications, and prepare evidence, but it should not make the decisions for you. Keep in mind that the internal auditor who reviews the ISMS should stay independent of the work they review. If your team is small, ask a partner to review the draft against your risk treatment plan, and confirm with your certification body which parts of that help it accepts.
Do we need a Statement of Applicability if we are not certified?
The requirement sits inside clause 6.1.3 of ISO/IEC 27001:2022, which applies to organizations that implement the standard. Certification is a separate step in which an accredited certification body audits the management system and issues a certificate. You can implement an ISMS and maintain a Statement of Applicability without seeking certification, and many organizations do so to support internal governance or to answer customer questionnaires. Be precise in what you tell customers: a document describing your controls is not a certificate, and you should not describe your ISMS as certified unless a certification body has issued a certificate for a defined scope. Confirm with your contracts or compliance lead whether a customer or regulator expects a certificate or a self-declared document.
What happens if an auditor finds a necessary control missing from our Statement of Applicability?
The auditor records it, and you must correct it. The comparison with Annex A exists to show that no necessary control has been inadvertently omitted. If a gap is found, IAF MD 26:2023 requires the organization to update its risk treatment plan and implement the control. In practice, you will need to decide whether the control is needed, add it to the Statement of Applicability with a justification and status, implement it, and gather evidence that it operates. Depending on how the certification body classifies the finding, it may be a nonconformity that must be closed within a set period before the certification decision. Ask the certification body how it grades such findings and what evidence it expects for closure.
Does the Statement of Applicability have to be public?
The requirement is that the document exists, is kept current, and is available to the people who need it. ISO/IEC 27001:2022 does not require you to publish it on a website. Most organizations share it with certification bodies, internal auditors and selected customers, usually under a non-disclosure agreement, because it describes security weaknesses and planned controls. Customers often ask for a summary or the document during due diligence. If you decide to share it, remove details that could help an attacker, such as internal system names or unpatched risks, and keep the full version under document control. Confirm your disclosure approach with your certification body and your legal team before sending the document outside the company.
How DeployOpen prepares the Statement of Applicability evidence
DeployOpen works inside your environment to turn the Statement of Applicability into a set of controls that are implemented, owned and evidenced. We prepare systems and documentation, while your organization keeps ownership of the decisions and the independent auditor issues any certification.
How we scope
- Engagements are fixed-scope, with the systems, Annex A controls and deliverables agreed in writing before work starts.
- We compare your determined controls against all 93 Annex A controls to confirm no necessary control is missing.
- Scope agreements state which inclusions and exclusions need written justification from your organization.
How we build
- We map each applicable control to the systems, tools and owners that operate it in your infrastructure.
- We implement self-hosted open-source tooling to produce logs, configuration records and access reviews for each control.
- We keep the implementation status of each control aligned with the risk treatment plan as risks change.
How we hand over
- You receive a Statement of Applicability draft with control status, justification and linked evidence locations.
- Documentation covers how each control is operated, reviewed and where its evidence is stored.
- Your own staff are walked through the records so they can answer assessor questions without us present.
How we support
- Ongoing support and upgrades are available as a retainer, including updates when the risk assessment changes.
- We can prepare evidence for the surveillance and recertification audits that follow the initial certification.
- Your certification body remains responsible for auditing the controls, and we do not issue reports or certificates.
