ISO 27001 Statement of Applicability Template: Free SoA Excel Download

Photo: Unsplash

ISO 27001 Statement of Applicability template: free SoA Excel download

The ISO 27001 Statement of Applicability (SoA) is the document auditors use to decide which Annex A controls are in scope, why exclusions are defensible, and whether your implementation claims match real evidence. This free template gives you all 93 ISO 27001:2022 controls pre-loaded with the columns auditors expect—so you can focus on decisions and ownership instead of rebuilding the spreadsheet from scratch.

This guide covers:

• What the SoA is, why ISO 27001 requires it, and how it fits your ISMS
• A before-you-start checklist (scope, risk assessment, owners)
• Tab-by-tab instructions for the Excel workbook
• A practical 90-day workflow to complete the SoA before Stage 1
• Theme-by-theme guidance for Organisational, People, Physical, and Technological controls
• Sample justifications for common Not Applicable scenarios (remote SaaS, cloud-only)
• Stage 1 vs Stage 2 auditor expectations and evidence mapping

GIF via GIPHY

Related guides:

• How to write an ISO 27001 Statement of Applicability (SoA)
• ISO 27001 internal audit checklist template
• ISO 27001 preparation: Stage 1 readiness
• Your guide to ISO 27001 Annex A controls
• Risk assessment template

Key takeaways

• The Statement of Applicability (SoA) is mandatory documented information under ISO 27001 Clause 6.1.3(d)—auditors review it line by line at Stage 1 and Stage 2.
• This template includes all 93 ISO 27001:2022 Annex A controls across four themes: 37 Organisational, 8 People, 14 Physical, and 34 Technological.
• Each row tracks applicability, justification, implementation status, evidence link, owner, and last review date—the fields certification bodies commonly sample.
• The SoA must align with your risk assessment and risk treatment plan; mismatches between documents are a frequent source of nonconformities.
• Treat the SoA as a living document—update it after scope changes, new products, acquisitions, or major vendor shifts.
• SecureSlate maps Annex A controls to automated evidence, tracks gaps, and exports audit-ready packages.

---

What is the ISO 27001 Statement of Applicability?

ISO 27001 does not require you to implement every Annex A control. It requires you to select controls that address your information security risks, document which controls apply, explain exclusions, and show how applicable controls are implemented.

That documented selection is the Statement of Applicability (SoA).

Under ISO 27001:2022 Clause 6.1.3(d), the SoA must include:

• The necessary controls from Annex A (or justification for excluding them)
• Whether each control is implemented
• Justification for inclusions and exclusions

In practice, auditors use the SoA as a map: they pick controls from your applicable list, ask for evidence, and verify that your risk treatment decisions are coherent. A weak SoA slows every audit conversation; a strong one makes fieldwork predictable.

For SaaS and cloud-native teams, the SoA is also a sales artifact. Enterprise security questionnaires often ask how you map to ISO 27001 Annex A—even before you pursue certification.

---

Before you start

Do not fill the template row by row on day one. The SoA reflects decisions you have already made about scope and risk. Complete this prep first:

SoA preparation checklist

• Confirm your ISMS scope (locations, systems, teams, data types, and explicit exclusions)
• Finish or refresh your risk assessment and risk treatment plan
• Assign a SoA owner (typically ISMS lead or GRC manager) and control owners per theme
• Gather existing policies, procedures, and technical evidence links before marking anything Implemented
• Decide your implementation status definitions (see workflow section below) and communicate them to owners
• Block working sessions with HR (People controls), facilities or office manager (Physical), engineering (Technological), and leadership (Organisational)
• Set a target Stage 1 date and work backward—most first-time teams need 6 to 12 weeks to complete a defensible SoA

Owners and links (fill these in)

• SoA owner: [Name / Role]
• Target completion date: [Date]
• Links:
  • [ISMS scope statement]
  • [Risk register]
  • [Risk treatment plan]

---

SoA vs risk register vs risk treatment plan

These three documents work together. Auditors expect consistency across all of them.

Document	Primary purpose	Typical owner	SoA connection
Risk register	Lists assets, threats, likelihood, impact, and inherent/residual risk	Risk owner / security	Identifies which risks need treatment
Risk treatment plan	Records treatment decisions (mitigate, accept, transfer, avoid) and selected controls	Risk owner / ISMS lead	Explains why specific Annex A controls were chosen
Statement of Applicability (SoA)	Declares which Annex A controls apply, implementation status, and evidence	ISMS lead / GRC	Operational map auditors test against

Rule of thumb: If a control appears as Implemented in the SoA, your risk treatment plan should show why it was selected, and your evidence library should contain proof it operates.

---

What makes this template useful

• Complete ISO 27001:2022 control list: All 93 Annex A controls with Control ID, name, and theme pre-filled.
• Applicability + justification columns: Required for both included and excluded controls—auditors challenge weak N/A justifications first.
• Implementation status tracking: Dropdown-friendly values (Not Started, In Progress, Implemented) with a Summary dashboard per theme.
• Evidence and ownership fields: Link each control to a policy, procedure, config export, or ticket—and name a real owner.
• Last Reviewed column: Supports surveillance audit expectations that the SoA stays current.
• Version & Approval tab: Document control and management sign-off, which Stage 1 auditors typically request.

---

Download the template

• Download (Excel): ISO 27001 Statement of Applicability (XLSX)
• Download (CSV): ISO 27001 SoA template (CSV) — lightweight alternative if you import into a GRC tool

Complete document control on the Overview tab and obtain management approval on Version & Approval before your Stage 1 audit.

---

Tab-by-tab walkthrough

Overview

Document control header: organization name, department, document owner, author, version, and effective date. This tab establishes the SoA as controlled documented information—not an ad hoc spreadsheet.

Fill this in before sharing the workbook with control owners.

Version & Approval

Version history and management sign-off. ISO 27001 expects leadership to approve the ISMS scope and supporting artifacts. Record approver name, role, date, and version number here.

Auditors commonly ask: Who approved this SoA, and when was it last updated?

Summary

Auto-calculated dashboard by theme:

Theme	Controls in template
Organisational	37
People	8
Physical	14
Technological	34

Columns track total controls, applicable count, implemented, in progress, not started, and % complete. Use this tab in steering committee or management review updates.

Statement of Applicability

The main working tab. Columns:

Column	What to enter
Control ID	Pre-filled (e.g., 5.1, 8.24)
Control Name	Pre-filled from Annex A
Theme	Organisational, People, Physical, or Technological
Applicable (Yes/No)	Whether the control applies to your ISMS scope
Justification for Inclusion/Exclusion	Required for every row—explain why the control applies or why it does not
Evidence / Policy Link	URL or file path to policy, procedure, screenshot, or ticket
Owner	Named person accountable for the control
Implementation Status	Not Started, In Progress, or Implemented
Last Reviewed	Date the row was last validated
Notes	Audit comments, remediation tickets, or scope caveats

Work theme by theme. Assign each theme to the function that owns it day to day—do not let one person guess across HR, facilities, and engineering.

---

90-day SoA completion workflow

Most first-time certification teams can complete a defensible SoA in roughly 90 days when risk assessment work is already underway.

Weeks 1–2: Scope and risk alignment

• Finalize ISMS scope statement
• Complete risk assessment and risk treatment plan
• Import or open the template; fill Overview and Version & Approval
• Mark all controls Applicable = Yes by default, then challenge exclusions

Weeks 3–4: Organisational controls (A.5)

• Schedule session with leadership and ISMS owner
• Map governance controls (policies, roles, supplier management) to existing documents
• Mark status honestly—In Progress is acceptable before Stage 1 if remediation plans exist

Weeks 5–6: People controls (A.6)

• Work with HR on screening, employment terms, awareness training, and disciplinary process
• Link to HRIS exports, training completion reports, and signed policies

Weeks 7–8: Physical controls (A.7)

• For remote or cloud-only orgs, document N/A justifications with scope rationale (see sample section)
• For office-based teams, involve facilities on perimeters, entry, equipment, and clear desk

Weeks 9–10: Technological controls (A.8)

• Engineering and IT own this block—access, logging, vuln management, SDLC, backup, crypto
• Link to IAM configs, SIEM dashboards, pentest reports, and change tickets

Weeks 11–12: Review, approve, and dry-run

• SoA owner validates every Implemented row has a working evidence link
• Cross-check against risk treatment plan for consistency
• Run an internal audit dry-run using the ISO 27001 internal audit checklist
• Obtain management approval and freeze version for Stage 1

Implementation status definitions (use consistently)

Status	Meaning	Acceptable at Stage 1?
Not Started	Control is applicable but no implementation work has begun	Usually not—shows a gap
In Progress	Policy, tooling, or process exists but is incomplete	Often acceptable with a remediation plan
Implemented	Control operates as designed with linked evidence	Required for Stage 2 sampling

---

Theme-by-theme guidance (Annex A)

Organisational (37 controls)

Covers governance: policies, roles, asset management, access control policy, threat intelligence, incident management, business continuity, supplier relationships, and legal requirements.

Typical owners: ISMS lead, CISO, legal, procurement.

Evidence examples: Information security policy, org chart with security roles, vendor inventory, incident response plan, BCP/DR test results.

Common pitfall: Marking policy controls Implemented when policies exist but were never approved or communicated.

People (8 controls)

Covers screening, employment terms, security awareness, disciplinary process, and responsibilities after termination or role change.

Typical owners: HR with security oversight.

Evidence examples: Background check policy, onboarding checklist, annual training completion report, offboarding ticket template.

Common pitfall: Awareness training marked Implemented without completion metrics.

Physical (14 controls)

Covers physical perimeters, entry controls, equipment protection, clear desk, and secure disposal.

Typical owners: Facilities, office manager, or IT for endpoint controls.

Evidence examples: Office access logs, visitor policy, asset disposal records, laptop cable-lock policy.

Common pitfall: Marking all Physical controls N/A for remote companies without documenting that the ISMS scope excludes owned physical sites.

Technological (34 controls)

The largest block: endpoint security, access management, logging, vulnerability management, configuration, backup, cryptography, and secure SDLC.

Typical owners: Engineering, IT, DevOps, security.

Evidence examples: MFA enforcement screenshot, vulnerability scan report, code review policy, production access review export, backup restore test ticket.

Common pitfall: Listing a policy link as evidence when auditors expect operational proof (logs, configs, tickets).

---

Sample justifications for Not Applicable controls

Excluding a control is valid when it truly falls outside your ISMS scope—but the justification must be specific and tied to scope, not convenience.

Control area	Scenario	Sample justification
A.7 Physical security	Fully remote SaaS, no company-owned offices	Not applicable. ISMS scope excludes physical premises; all infrastructure is hosted in [cloud provider] data centers covered under supplier controls (A.5.19–A.5.23).
A.7.2 Physical entry	Co-working day passes only, no dedicated office	Not applicable. Organization does not operate dedicated facilities; co-working access is personal employee arrangement outside ISMS scope.
A.8.11 Data masking	No production use of PII requiring masking	Not applicable. Risk assessment identified no systems processing data requiring masking; test environments use synthetic data per A.8.33.
A.8.14 Redundancy	Single-region SaaS with provider SLA	Partially applicable. Application redundancy is managed by [cloud provider]; organizational BCP addresses RTO/RPO at service level (see BCP link).
A.5.29 Information security during disruption	Early-stage startup	Applicable. Do not mark N/A—auditors expect a disruption plan even for small teams.

If you mark a control Not Applicable, be prepared for the auditor to ask: Show me where this is reflected in your scope statement and risk assessment.

---

What auditors expect at Stage 1 vs Stage 2

Audit stage	SoA focus	What "good" looks like
Stage 1 (readiness)	Document review: scope, SoA structure, risk alignment, management approval	SoA exists, justifications are present, statuses are honest, version control is clear
Stage 2 (certification)	Operational effectiveness: sample Implemented controls for evidence	Evidence links work, controls operate over the audit period, owners can explain their rows
Surveillance (years 1–2)	Changes since last audit: new products, vendors, scope shifts	SoA updated with Last Reviewed dates; change history in Version & Approval

Stage 1 is not a pass/fail on every control being Implemented—but unexplained gaps, missing justifications, or SoA/risk register contradictions commonly delay Stage 2 scheduling.

For deeper context on what auditors test, see ISO 27001 audit: how controls are tested.

---

How to use it as audit evidence

Certification requirement (ISO 27001)	Template field	Auditor question it answers
List of necessary controls (Clause 6.1.3 d)	Applicable column + Justification	Which controls apply and why?
Implementation status	Implementation Status column	Is this control designed and operating?
Evidence of operation	Evidence / Policy Link column	Show me proof for this control.
Ownership and accountability	Owner column	Who is responsible if this fails?
Management approval	Version & Approval tab	Did leadership sign off on control selection?
Continual improvement	Last Reviewed + version history	How do you keep the SoA current?

Practical tip: Export a PDF snapshot of the SoA before Stage 1, after remediation sprints, and before each surveillance audit. Store it alongside your risk register and treatment plan as a versioned set.

---

Common mistakes

• Implemented without evidence: Status says Implemented but the Evidence column is empty or links to a draft policy
• Copy-paste justifications: Every N/A row says "not applicable to our business" with no scope reference
• SoA disconnected from risk treatment: Controls selected in the SoA do not appear in the risk treatment plan
• One person fills every row: Control owners were never consulted; audit interviews expose gaps immediately
• Physical controls ignored for remote teams: Blanket N/A without scope documentation
• SoA frozen after Stage 1: New product launch or vendor added but SoA not updated before Stage 2
• 114 vs 93 control confusion: Using ISO 27001:2013 control references in a 2022 certification audit
• Evidence links that break: Shared drive permissions or expired URLs during audit week

---

How SecureSlate helps

Spreadsheets work for your first SoA draft. They break down when you need continuous evidence, owner reminders, and audit exports across dozens of controls.

SecureSlate helps teams:

• Map ISO 27001:2022 Annex A controls to automated evidence from cloud, identity, HR, and ticketing systems
• Track implementation gaps with owners, due dates, and remediation workflows
• Keep the SoA aligned with your risk register and risk treatment plan in one platform
• Export Stage 1 and Stage 2 audit packages with timestamps and audit trails
• Maintain readiness between surveillance audits without rebuilding spreadsheets each quarter

Get started for free

---

FAQ

Is the SoA required for ISO 27001 certification?
Yes. Clause 6.1.3(d) requires a Statement of Applicability as documented information. Certification audits review it at Stage 1 and test controls from it at Stage 2.

How is the SoA different from a risk register?
The risk register identifies and scores information security risks. The SoA declares which Annex A controls apply to your organization and documents implementation status and evidence for each.

Do we need to implement all 93 Annex A controls?
No. You implement controls that address your risks and scope. You must still list all controls, mark applicability, and justify exclusions.

When should we finalize the SoA?
Before Stage 1, with a stable version approved for the audit. Update it whenever scope, products, vendors, or infrastructure change—and again before Stage 2.

Can we mark controls In Progress at Stage 1?
Often yes, if gaps are documented with remediation plans and timelines. Stage 2 typically requires Implemented controls with operational evidence.

What is the difference between ISO 27001:2013 and 2022 SoA formats?
ISO 27001:2022 reorganized Annex A into four themes with 93 controls (down from 114 in 2013). Use the 2022 control IDs (5.x, 6.x, 7.x, 8.x) for current certifications.

Who should own the SoA?
Typically the ISMS lead or GRC manager. Individual control owners validate rows for their domain (HR, facilities, engineering, IT).

How often should we review the SoA?
Many teams review quarterly and after significant changes. Surveillance auditors expect Last Reviewed dates and version history that reflect ongoing maintenance.

Can this template replace a GRC platform?
It is a strong starting point for first-time certification. As control count and evidence volume grow, teams commonly move to a platform for automation and continuous monitoring.

Does the CSV version include the Summary dashboard?
No. The CSV is a flat control list for import into other tools. Use the XLSX for the full workbook with Summary and Version & Approval tabs.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory, or professional advice. Requirements vary by framework, industry, and jurisdiction. Consult qualified advisors for your specific obligations.