ISO 27001 Statement of Applicability template
Updated
A free Statement of Applicability in Excel format for ISO/IEC 27001:2022: one row for each of the 93 Annex A controls, with columns for applicability, justification, implementation status and owner, and the Policyseed policies that document each control already filled in. Applicability and justification stay blank on purpose, because they are your decisions.
What a Statement of Applicability is, and who reads it
The Statement of Applicability (SoA) is the record that connects your risk assessment to Annex A. For every control in Annex A, it says whether the control applies to you, why, and whether it is implemented. It comes out of the risk treatment step in clause 6.1.3 of ISO/IEC 27001. Security Scientist's Statement of Applicability template guide describes that clause as asking for the necessary controls, the justification for including them, the justification for excluding any Annex A control, and whether each one is implemented. That is the shape of this workbook.
The same guide says the people who check it are auditors, who go through it line by line. In practice the certification body's auditor reads it first, and then samples the controls it lists. Inside the company, the ISMS owner, each control owner and whoever runs the internal audit work from it. Policyseed does not audit or certify anyone: this is a template to start from.
The workbook uses the 93 controls in the 2022 edition of Annex A. If you are moving from the 2013 edition, start a new SoA from this list rather than renumbering the old one.
The columns
The first sheet holds the SoA, one row per control, with a filter on every column and dropdown lists for Applicable and Implementation status. The second sheet is a short how-to with blank fields for the document owner, version, approver and next review date. The columns, in order:
| Column | What goes in it |
|---|---|
| Control, Control name, Theme | The Annex A control number and short name from the 2022 edition, and its theme: organizational, people, physical or technological. |
| What it asks | Our own one-line, plain-English paraphrase. It is not the text of the standard, so read the control in the standard itself before you decide on it. |
| Applicable | A Yes or No list. Left blank: this is your decision, made from your risk assessment, and every other column depends on it. |
| Justification | The reason for the decision, in your words. For Yes, the risk, legal duty or customer commitment behind it; for No, a specific fact about your company. Left blank. |
| Implementation status | A list: Implemented, Partly implemented, Planned or Not implemented. Left blank, because only you know what is actually running. |
| Policy reference | The Policyseed policies whose statements or procedures address the control. This is the one column we fill in for you. |
| Owner | The named person accountable for the control. Left blank. |
| Policyseed coverage note | Where a policy covers a control only in part, or the control mostly sits with your hosting provider, the note says so. |
Here is how a few rows look in the file, with the policy references already in place. Applicable, Justification, Implementation status and Owner are empty in the download.
| Control | Policy reference (pre-filled) |
|---|---|
| 5.1 Policies for information securityOrganizational | P01 Information Security Policy |
| 5.15 Access controlOrganizational | P03 Access Control Policy |
| 6.7 Remote workingPeople | P21 Physical and Remote Work Security Policy P02 Acceptable Use Policy |
| 7.6 Working in secure areasPhysical | None. No Policyseed policy documents this control. |
| 8.24 Use of cryptographyTechnological | P08 Encryption and Key Management Policy |
How to justify an exclusion
A justification is a reason that someone else can check. Security Scientist's guide advises tying each exclusion to a concrete fact about your organization and warns that an unexplained No will be challenged. Two habits help. Write the fact ("we have no premises"), not the conclusion ("not relevant"). And say what would change the answer, so the next review knows when to look again.
Below are example drafts for a company that is fully remote and runs on a cloud provider. They are editable drafts, not approved wording: replace the bracketed parts, delete any line that is not true for you, and expect your certification body to have its own view. You could instead record a control that a provider operates as applicable and delegated to the provider, rather than not applicable. Choose one approach and use it consistently, and ask your certification body which it prefers.
| Control | Draft justification (edit before use) |
|---|---|
| 7.2 Physical entry | Not applicable to our own premises: [Company] has no office or other site, and all staff work remotely. Entry controls at the hosting provider's facilities are operated by the provider and reviewed under 5.22 through its assurance report ([Fill in: report and date]). Revisit if we lease space. |
| 7.3 Securing offices, rooms and facilities | Not applicable: [Company] holds no offices, rooms or facilities. Equipment is held by staff (see 7.9) and production systems run in the provider's facilities. Revisit if we lease space. |
| 7.4 Physical security monitoring | Not applicable to premises we do not have. The provider monitors its own facilities, and we review that through its assurance report. We rely on logging and alerting for our systems (see the 8.15 and 8.16 rows), not on physical surveillance. |
| 7.6 Working in secure areas | Not applicable: [Company] operates no secure areas such as server rooms or data centers. The areas that hold production systems belong to the hosting provider. Revisit if we ever host equipment ourselves. |
| 7.12 Cabling security | Not applicable: [Company] owns no network cabling. Cabling in the provider's facilities is the provider's responsibility, and staff connect over their own home or mobile networks, covered by 6.7 and 8.20. |
Remote work moves risk rather than removing it. These controls usually stay applicable for a fully remote company, because the equipment and the information are in people's homes:
- 6.7 Remote working. Protect information that is accessed, processed or stored while working away from the office.
- 7.7 Clear desk and clear screen. Keep papers and removable media off desks and lock screens when away.
- 7.9 Security of assets off-premises. Protect laptops and other assets taken outside company premises.
- 7.14 Secure disposal or re-use of equipment. Wipe or destroy data and software on equipment before it is reused or thrown away.
The same applies to your cloud provider. A control the provider runs is still part of your risk picture, and your supplier controls (5.19 to 5.23) are where your review of its assurance report is recorded.
Pre-filled policy references from the 22 Policyseed policies
The Policy reference column draws on 22 of the 22 Policyseed policies. We read the text of each policy to decide which controls it addresses, rather than matching on topic names. 91 of the 93 controls have at least one policy. The most-cited policies:
- Endpoint and Workstation Security Policy: 11 controls
- Data Classification and Handling Policy: 10 controls
- Secure Software Development Policy: 10 controls
- Physical and Remote Work Security Policy: 10 controls
- Logging and Monitoring Policy: 9 controls
Controls with no Policyseed policy say so in the file (2): 7.6 Working in secure areas and 7.12 Cabling security. Each still needs an entry: a policy line you add, or an exclusion you justify. The full control-by-control table is on the ISO 27001 policy templates page.
A policy reference is a pointer, not proof. If you edit or drop a policy, change the reference to match. And a policy that says something is done is not evidence that it is done: the Implementation status column is where you record what is actually running. If you already have SOC 2 policies, see the SOC 2 to ISO 27001 mapping for what carries over, and SOC 2 vs ISO 27001 for how the two differ.
The Audit Kit ($59, one time) includes the same Annex A mapping as a sheet in its crosswalk.xlsx, next to the policies tailored to the tools you named. The mapping tells you where each control is documented; each control still needs its own entry in your SoA.
Keeping it current after risk assessments and changes
An SoA is a living record. Security Scientist's guide says to update it whenever the risk assessment changes and before each audit. These are the moments to reopen it:
- After each risk assessment. New or re-scored risks can switch a control from No to Yes. Run the assessment first (see the risk assessment guide and the risk register template), then update the SoA from it.
- After a change. A new hosting provider, a first office lease, a new product line or a new category of data can each make an excluded control relevant. Revisit the exclusion drafts above whenever one of their "revisit if" conditions comes true.
- After an incident or an internal audit finding. If a control failed or was missing, update its status and justification and record what changed.
- Before an audit. Check that every status still matches reality, every Planned item has an owner and a date, and every policy reference still points at a current policy.
Each time, save a new version with an approval date. The SoA is one of several records the management system needs: scope, a risk treatment plan, internal audit and management review are separate. The ISO 27001 policy templates page outlines them.
Frequently asked questions
- Is there a free ISO 27001 statement of applicability template with no signup?
- Yes. The download on this page is an Excel workbook with one row for each of the 93 Annex A controls in ISO/IEC 27001:2022. It is built in your browser, nothing is uploaded and there is no email form. The policy references are filled in; applicability, justification, status and owner are left for you.
- Is a Statement of Applicability required for ISO 27001?
- Yes. Clause 6.1.3 of ISO/IEC 27001 ties it to risk treatment: you compare your chosen controls with Annex A and record which apply, why, and whether they are implemented. A certification body assesses it as part of the audit, so treat it as a required record of your risk treatment decisions, not an optional spreadsheet.
- Do I have to implement all 93 Annex A controls?
- No. Every one of the 93 controls needs an entry, but an entry can say the control does not apply, as long as the justification is specific to your company. Cabling security for a company that owns no cabling is an example. A bare "No" with no reason is what a reviewer is likely to challenge.
- Can I use the policy reference as my justification?
- No. The policy reference shows which policy documents a control. It does not say why the control applies to you, and it does not show the control is operating. Write the justification from your risk assessment, and treat the reference as a pointer to where the control is written down.
- What should I put in Implementation status?
- Use the four values in the dropdown, or replace them with your own scale if your certification body prefers one. Planned is reasonable early on, but only when the work has an owner and a date. Change the status when the work finishes, and keep the evidence that shows it.
- How often should the Statement of Applicability be updated?
- After every risk assessment, after significant changes to your systems, suppliers or premises, after incidents that show a control is missing or weak, and before an audit. Security Scientist's guide makes the same point about risk assessment changes and audits. Record a version and an approval date each time.
- How is this different from the Annex A mapping CSV?
- The CSV on the ISO 27001 policy templates page is a reference: each control and the policies that document it. This workbook is the working document: it adds the decision columns you complete, in a form you can approve, version and keep up to date.
ISO and ISO/IEC 27001 are standards published by the International Organization for Standardization and the International Electrotechnical Commission. Policyseed is not affiliated with either. Control names are cited for reference; the summaries are our own.
Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.