ISO 27001 Statement of Applicability Template Guide

An ISO 27001 Statement of Applicability (SoA) is not simply a checklist of Annex A controls marked Yes or No. Under ISO/IEC 27001:2022, the SoA should identify the information security controls your organization has determined are necessary, explain why they are included, state whether they are implemented, and justify the exclusion of Annex A reference controls that are not necessary.

Copy the decision review record.

That distinction changes how you should build the template. Start with your ISMS scope, risks, legal and contractual obligations, and chosen risk treatments. Then use Annex A as a completeness check rather than assuming every control is automatically mandatory. The current ISO/IEC 27001:2022 standard defines the ISMS requirements, while ISO/IEC 27002:2022 provides implementation guidance for information security controls.

This guide shows how to structure a practical SoA template for the 2022 edition, what belongs in each field, how to write defensible inclusion and exclusion justifications, and how to keep the document connected to the risk assessment instead of letting it become spreadsheet archaeology.

What the Statement of Applicability Is Really For

The SoA sits between your information security risk process and your control environment. Your organization determines which controls are necessary to treat information security risks and satisfy relevant requirements, compares those controls against the Annex A reference set, and records the resulting decisions in the SoA.

The 2022 Annex A reference set contains 93 controls, grouped into organizational, people, physical, and technological categories. Those controls are not a menu where every item must automatically be selected. They are a reference set designed to help you check whether your risk treatment process has overlooked something important.

An ISO/IEC 27001 Auditing Practices Group note on the SoA explains this distinction particularly well: Annex A supports the organization’s control-selection process, while the organization remains responsible for determining its necessary controls. The note is useful interpretive material, although it explicitly states that it has not undergone an ISO or SC 27 endorsement process.

This is why downloading somebody else’s completed SoA and changing the company name is a poor shortcut. Their scope, risks, customers, technology, suppliers, laws, contracts, and acceptable-risk decisions are not yours.

What ISO 27001 Requires the SoA to Contain

For a practical template, separate the minimum required content from the additional fields that make the document easier to operate. ISO/IEC 27001:2022 Clause 6.1.3 requires the SoA to capture four essential ideas: the necessary controls, the justification for including them, whether those controls are implemented, and the justification for excluding Annex A controls that are considered unnecessary.

You can add further fields when they serve a real purpose, such as control source, policy reference, system scope, residual-risk reference, implementation notes, evidence location, mapped framework requirements, or remediation tickets. ISO/IEC 27001 specifies what the SoA needs to communicate, not one mandatory spreadsheet layout.

A Copyable ISO 27001 Statement of Applicability Template

A spreadsheet is often the easiest format because controls can be filtered by status, owner, risk, system, or review date. The following header is a useful starting point for Excel, Google Sheets, a GRC platform, or another controlled repository.

Copy the tab-separated header below into the first cell of a blank sheet. If your spreadsheet keeps it in one column, use its split-text or text-to-columns command and choose a tab separator. Add your organization’s own rows; this does not reproduce the licensed Annex A control text.

Control Reference	Control / Description	Source	Necessary / Applicable?	Inclusion or Exclusion Justification	Implementation Status	Risk / Legal / Contract Reference	Evidence Reference	Owner	Last Review

Use “decision pending” where the rationale has not been confirmed. Keep necessity and implementation status separate: an unfinished necessary control is not an exclusion.

The word applicable is convenient when your table is organized around Annex A, but do not let the column turn the process backwards. The important question is not merely, “Does Annex A say this control exists?” It is, “Is this control necessary for our organization, and have we checked our decisions against Annex A?”

SoA document ID / version / ISMS scope reference:
Control reference / source / organization-specific description:
Risk treatment or obligation driving the decision:
Necessary, unnecessary or decision pending / rationale:
Actual implementation state and evidence reference:
Incomplete work / owner / target date:
For proposed exclusion: specific scope condition and evidence:
Relevant dependencies, suppliers or inherited controls reviewed:
Reviewer / decision authority / approval reference:
Change trigger / next review date:
Related SoA row, risk record and treatment plan updated:

Example SoA Entries

The examples below are hypothetical. Their purpose is to demonstrate the level of reasoning a useful SoA can capture, not to tell another organization whether a particular control should be included or excluded.

Notice that “partially implemented” is different from “not applicable.” A control can be necessary even when implementation is incomplete. Calling an unfinished control “not applicable” to make the spreadsheet greener breaks the connection between the SoA and the actual risk treatment program.

Step 1: Define the ISMS Scope Before Judging Controls

A useful SoA begins with a truthful boundary. Identify the business activities, information, processes, locations, technologies, people, and important external services that fall within the ISMS scope. A control can appear irrelevant only because an important system or dependency was accidentally left outside the conversation.

For example, a SaaS company may host its application in one cloud environment while relying on a separate identity provider, source-code platform, customer-support service, monitoring platform, payroll provider, and managed security vendor. Saying “the application is in scope” does not automatically answer which of those supporting services influence information security risk.

The same scoping discipline appears in other compliance frameworks. The Kioptrix CMMC gap assessment checklist covers a different standard, but its distinction between defining a real boundary and testing controls against that boundary is useful here too. Frameworks differ; the need for accurate scope does not.

Step 2: Determine Controls From Risk Treatment, Not From the Template

Do not begin by opening Annex A and deciding which rows look familiar. Begin with the information security risks and the treatment options the organization has chosen. Determine what controls are actually necessary to make those treatment decisions work.

A risk might concern excessive administrative access, weak supplier oversight, accidental disclosure, unavailable backups, insecure application changes, insufficient logging, or a dependency that could interrupt a critical process. The necessary control should arise from what must be done about that risk, not from a desire to populate an attractive spreadsheet.

Threat modeling can help technical teams expose risks that a generic control checklist misses. For product environments, the Kioptrix guide to MVP threat modeling for startups demonstrates a practical sequence of mapping assets and trust boundaries, identifying credible failure paths, choosing treatments, assigning owners, and defining verification. Threat modeling is not a substitute for an ISO 27001 risk assessment, but it can provide useful risk input.

Step 3: Compare Your Necessary Controls With Annex A

Once necessary controls have been determined, compare them with the Annex A reference controls. The purpose of this comparison is to catch omissions. If an Annex A control points to a security need your risk-treatment process failed to recognize, go back and examine whether that control, or an equivalent control, is actually necessary.

This is also where old ISO 27001 templates become troublesome. ISO/IEC 27001:2013 used a different Annex A structure with 114 controls, while the 2022 edition uses 93. A legacy spreadsheet can still contain useful historical information, but it should not simply be relabeled “2022” without performing a proper mapping and applicability review.

You also do not have to limit your SoA to controls originating in Annex A. Necessary controls may come from organizational design, contractual requirements, regulation, other security frameworks, customer commitments, specialist standards, or internally designed safeguards. If such a control is necessary for the ISMS, the SoA should account for it.

Step 4: Write Inclusion Justifications That Explain the Decision

“Included because it is in Annex A” is weak reasoning. Annex A is the reference set you use to check your work, so simply pointing back to the list does not explain why your organization needs the control.

You do not need to write a miniature essay for every row. A short sentence can be enough when the risk or obligation reference provides the detail. The goal is traceability, not word count.

Step 5: Treat Exclusions as Decisions That Need Evidence

An exclusion rationale should explain why the security need represented by an Annex A reference control is unnecessary in the current organizational context. “Not relevant,” “N/A,” and “not used” are usually too thin to show the reasoning behind that decision.

A better justification describes the scope condition that removes the need, then points to supporting information. That might involve the absence of a particular process, technology, facility, relationship, or information-handling activity within the ISMS scope. If the condition later changes, the applicability decision should be revisited.

Do not confuse exclusion with incomplete implementation. If the organization needs a control but has not yet completed it, record the control as necessary and describe its actual implementation status. The gap belongs in the treatment or remediation process, not beneath an artificial “not applicable” label.

Step 6: Record What “Implemented” Actually Means

A policy document alone does not necessarily prove that a control operates. If your SoA says a control is implemented, your organization should be able to identify what makes that statement true: configuration, procedure, operating record, review, approval, technical test, system output, training record, supplier evidence, or another appropriate form of proof.

This policy-to-evidence distinction also appears in the Kioptrix guide to SOC 2 policies for startups. SOC 2 and ISO 27001 are different frameworks, but the operational lesson transfers cleanly: a written policy describes an expectation, a control turns it into activity, and evidence shows that the activity occurred.

Technical controls deserve the same treatment. If logging is marked implemented, for example, evidence might include current configuration, protected log destinations, test events, retention settings, review records, or alert workflows. The Kioptrix AWS CloudTrail logging checklist illustrates how a seemingly simple “logging enabled” statement expands into scope, configuration, protection, validation, and evidence questions.

Implementation Status Should Be Honest, Not Binary

ISO/IEC 27001 requires the SoA to indicate whether necessary controls are implemented. Your organization can choose status labels that make this useful operationally. A simple scheme might distinguish Implemented, Partially Implemented, Planned, and Not Implemented, provided those labels are defined consistently.

Be careful with “Implemented” when rollout is incomplete. If MFA protects 90 percent of relevant accounts but several privileged exceptions remain, a blanket implemented status may conceal the exact residual exposure management needs to understand. A status field should illuminate risk, not decorate it.

Link the SoA to the Risk Register Without Duplicating It

The SoA and risk register serve different jobs. The risk register describes risks, analysis, ownership, treatment decisions, and residual-risk information. The SoA records necessary controls and Annex A applicability decisions. They should reference one another without becoming duplicate documents that drift apart.

A simple control-to-risk field is often enough. One control may address several risks, and one risk may require several controls. Do not force a one-to-one relationship merely because it makes the spreadsheet visually tidy.

Statement of Applicability vs Risk Treatment Plan

A useful compliance workflow keeps these documents connected. If a risk treatment introduces a new necessary control, the SoA may need updating. If a supposedly unnecessary control becomes necessary because the business begins a new activity, the risk assessment and treatment documentation may need updating as well.

Do Not Exclude Clauses 4 Through 10 Through the SoA

There is an important boundary around the word “applicability.” The SoA is used to account for necessary controls and Annex A reference controls. It is not a mechanism for declaring the main ISO/IEC 27001 management-system requirements optional.

The Auditing Practices Group guidance explains that the requirements in Clauses 4 through 10 apply to the ISMS and are not treated like Annex A control exclusions. This is one reason a template should avoid mixing a Clause 4-to-10 compliance checklist into the same “Applicable / Not Applicable” column used for Annex A.

Can You Add Evidence Links to the SoA?

Yes, when doing so makes the document more useful. A compact evidence-reference column can point to a policy, procedure, configuration record, report, ticket queue, approval record, system export, or controlled evidence repository.

Avoid turning the SoA itself into a warehouse of screenshots, credentials, network diagrams, vulnerability details, or other sensitive material. A reference such as “IAM quarterly review folder” or “LOG-STD-02” is usually easier to maintain than embedding the evidence itself.

This distinction matters when compliance evidence is also used for customers. The Kioptrix guide to answering customer security questionnaires explains why evidence scope, currency, sensitivity, and permitted distribution should be checked before material is shared outside the organization. Your internal SoA can support customer assurance without becoming a document you automatically hand to every prospect.

Common Statement of Applicability Template Mistakes

• Starting with Annex A instead of risks. This converts risk treatment into a reverse-engineered checklist exercise.
• Using a 2013 template without remapping it. The Annex A structure changed substantially in the 2022 edition.
• Marking every control applicable “to be safe.” This creates unnecessary commitments and hides the organization’s actual reasoning.
• Using “N/A” as the entire exclusion justification. Record the scope, risk, or business condition supporting the decision.
• Confusing incomplete with inapplicable. A necessary control can be partially implemented or not yet implemented.
• Leaving out custom controls. A necessary organization-specific control still belongs in the SoA even when it is not an Annex A control.
• Equating a policy with implementation. Confirm what actually operates and where evidence can be found.
• Never reviewing exclusions after scope changes. A new product, supplier, office, acquisition, cloud service, regulation, contract, or workflow can change the applicability decision.

When Should the SoA Be Reviewed?

The SoA requirement does not prescribe one universal calendar interval that fits every organization. A sensible governance process reviews it when changes could affect risk treatment or control necessity, and many organizations also place it within a scheduled ISMS review cycle.

Useful triggers include a material change to ISMS scope, new systems or cloud services, significant supplier changes, acquisitions, new contractual commitments, regulatory changes, major incidents, control redesign, risk reassessment, or introduction of a new business process. A version-controlled SoA makes these changes easier to explain during an audit than a file called SoA_FINAL_v7_reallyfinal.xlsx.

A Practical SoA Review Workflow

Before approving a new version, first confirm that the ISMS scope and current risk assessment are still accurate. Then check that every necessary control appears in the SoA, including custom controls, and compare the resulting control set against the current Annex A reference controls.

Next, challenge the inclusion and exclusion rationales. Verify implementation status against current evidence, identify partially implemented controls that require treatment work, confirm ownership, and investigate controls whose evidence has become stale or contradictory.

Finally, record the version and approval in accordance with your organization’s document-control process. The goal is not a frozen compliance artifact. The goal is a current representation of how the organization has translated information security risk into controls.

Frequently Asked Questions

Does an ISO 27001 SoA have to be a 93-row spreadsheet?

No prescribed spreadsheet layout is required. The SoA must contain the required information and account for exclusions from the Annex A reference controls. An Annex A-based table is popular because it makes completeness easy to demonstrate, but the Auditing Practices Group guidance notes that other structures are possible.

Do all 93 Annex A controls have to be implemented?

No. The organization determines the controls that are necessary and compares them with Annex A to verify completeness. Annex A controls considered unnecessary require an exclusion justification in the SoA.

Can the organization create its own controls?

Yes. Necessary controls can originate outside Annex A, including organization-specific safeguards or controls derived from other relevant sources. When such a control is necessary for risk treatment, it should be represented in the SoA.

Can a necessary control be marked not implemented?

Yes. Necessity and implementation are separate questions. A control may be necessary but planned, partially implemented, or not yet implemented. The corresponding gap should then be managed through the appropriate risk-treatment and remediation process.

Can I reuse an ISO 27001:2013 SoA template?

You can reuse useful organizational information, risk references, evidence links, and historical decisions, but you should not treat the old Annex A structure as current. Perform a proper mapping and reassessment against ISO/IEC 27001:2022 rather than changing the year in the document header.

Is the SoA the same as proof that every control works?

No. The SoA records control decisions and implementation status. Auditors may still examine policies, records, technical configurations, interviews, tests, and other evidence to evaluate whether the ISMS and its controls operate as represented.

Build the SoA From the Risk Story, Not the Spreadsheet

The strongest ISO 27001 Statement of Applicability is usually not the longest one. It is the one where a reviewer can follow the logic without detective work: this is our scope, these are our meaningful risks and obligations, these are the controls we determined are necessary, this is why they are necessary, this is their real implementation state, and this is why the remaining Annex A reference controls are unnecessary.

Use the template as a container for that reasoning. Keep the risk register, treatment plan, policies, technical implementation, and evidence connected to it. When the environment changes, update the decisions rather than preserving yesterday’s green checkmarks in amber.

For implementation, work from a current licensed copy of ISO/IEC 27001:2022 and the relevant supporting standards. ISO currently lists the 2022 edition together with its published 2024 amendment, so organizations should ensure their ISMS documentation is based on the current material applicable to them.

Template usability reviewed: 2026-10-23. Added a tab-separated header and optional decision-review record, and replaced a generic exclusion example with an unresolved review prompt. The linked Auditing Practices Note was checked for context; this update is not an ISMS assessment.