Statement of Applicability (SoA) | ComplyJet Help Center

Purpose	Guide the ISMS owner through building and maintaining a Statement of Applicability (SoA) that will hold up under audit.
Applies to	ISO/IEC 27001:2022 Annex A controls (93 controls, 4 themes).
Audience	ISMS Manager / Information Security Lead, and anyone preparing or updating the SoA.
Owner	ISMS Manager / Information Security Lead
Approved by	Chief Executive Officer (CEO), or designated Management Representative
Review cycle	Annually, or upon significant change to scope, infrastructure, premises, or risk profile

1. Purpose

This SOP describes how to build and maintain a Statement of Applicability (SoA) for an ISO/IEC 27001:2022 Information Security Management System (ISMS). It sets out the step-by-step process for working through the Annex A control set, deciding applicability, writing justifications, and assigning implementation status — and gives concrete rules for two scenarios that come up often when scoping a smaller or service-only organization.

2. What the SoA Is (Brief Overview)

The Statement of Applicability is a mandatory ISMS document (ISO/IEC 27001:2022, Clause 6.1.3d). For every control in Annex A, it records:

Whether the control is applicable to the organization's ISMS (Y/N);
The justification for including or excluding it;
The organization's documentation/evidence that implements it; and
Its current implementation status.

Annex A groups all 93 controls into four themes:

Theme	Covers	Reference range	Count
Annex A 5	Organizational controls	5.1 – 5.37	37 controls
Annex A 6	People controls	6.1 – 6.8	8 controls
Annex A 7	Physical controls	7.1 – 7.14	14 controls
Annex A 8	Technological controls	8.1 – 8.34	34 controls

Each row of the SoA typically captures the following columns:

Column	What it captures
Ref	The Annex A clause number (e.g. 5.1, 7.3, 8.20).
Annex A Control	The control title as written in ISO/IEC 27001:2022 Annex A.
Applicable (Y/N)	Whether the control applies to this organization's ISMS scope.
Justification for Inclusion / Exclusion	The specific, auditable reason the control is included or excluded — tied to the organization's actual scope, assets, and activities.
Related Documentation / Evidence	The policy, procedure, or record that implements the control (or governs the vendor that does).
Implementation Status	Implemented, Partially implemented, or Not applicable — see legend below.

Implementation status is recorded against a fixed legend:

Status	Meaning
Implemented	Control is fully in place and operating, supported by a documented policy/procedure and evidence.
Partially implemented	Control is partly in place; further work, rollout, or formal documentation is planned and tracked.
Not applicable	Control is excluded from the ISMS scope; a specific justification is recorded in the Justification column.

3. Step-by-Step Procedure

Confirm the ISMS scope statement first. The SoA must align to it — know the organization's legal boundaries, locations, people, services, and any technology/infrastructure it owns or operates before marking anything applicable or not.
Work through Annex A control by control, theme by theme (Organizational → People → Physical → Technological). Do not skip controls — every one of the 93 needs an explicit Y/N decision.
Decide applicability (Y/N) for each control using the decision rule in Section 4.
Write a specific justification for each decision. Tie it to the organization's actual scope, assets, and activities — generic text such as “N/A” or “not needed” will not withstand audit scrutiny.
Map related documentation/evidence — the policy, procedure, or record that implements the control (or that governs oversight of a vendor delivering it).
Assign an implementation status (Implemented / Partially implemented / Not applicable) consistent with the Y/N decision.
Route the completed SoA for review and approval by the document owner (e.g. CEO or ISMS Manager) before it is used as an audit record.
Set the review cadence: at minimum annually, and immediately after any significant change to scope, premises, infrastructure, risk profile, or organizational structure.

4. Applicability Decision Rules

4.1 General rule

The default posture is that a control applies. Exclusion is the exception, not the norm, and must be defensible at audit. Use this test for every control:

Does the activity, asset, or environment the control governs genuinely not exist in the organization, and is it not planned? → Mark Not Applicable (N), with a specific reason.
Does the activity/asset exist but is delivered or hosted by a third party (e.g. a cloud provider)? → The control is still Applicable (Y). Record that it is inherited from the vendor, and rely on the supplier-management controls (5.19–5.22) to provide oversight — do not mark it N just because a vendor performs it.

4.2 Scenario A — No physical office / physical security out of scope

Applies to fully remote organizations with no company-owned or leased premises. In this case, mark the premises-specific controls under Annex A 7 (Physical controls) as Not Applicable, with a justification along the lines of:

“The organization has no physical premises; staff operate remotely from locations not owned, leased, or managed by the organization. Physical security perimeter, entry, and monitoring controls are therefore not applicable to the ISMS scope.”

This does not mean every Physical control can be blanket-excluded — several still apply through the remote working / asset management policies even without an office:

Ref	Control	Typical treatment*	Why
7.1	Physical security perimeters	Typically N	No owned/leased premises to define a perimeter for.
7.2	Physical entry	Typically N	No office entry points to control.
7.3	Securing offices, rooms and facilities	Typically N	No offices, rooms, or facilities exist.
7.4	Physical security monitoring	Typically N	No premises to monitor (CCTV, alarms, etc.).
7.5	Protecting against physical & environmental threats	Often still Y	May still apply to home/remote workspaces, or be inherited from a cloud/coworking provider.
7.6	Working in secure areas	Typically N	No designated secure areas exist.
7.7	Clear desk and clear screen	Often still Y	Applies to remote/home workspaces via the remote working policy, even with no office.
7.8	Equipment siting and protection	Typically N	No company-sited equipment to protect.
7.9	Security of assets off-premises	Often still Y	Applies whenever staff use laptops/devices remotely.
7.10	Storage media	Often still Y	Applies if any physical or removable media is used or issued to staff.
7.11	Supporting utilities	Typically N	No premises with power/cooling/utilities to protect.
7.12	Cabling security	Typically N	No office cabling to secure.
7.13	Equipment maintenance	Often still Y	Applies if the organization issues and maintains any equipment (laptops, phones).
7.14	Secure disposal or re-use of equipment	Often still Y	Applies whenever company-owned equipment is retired or reassigned.

* Confirm each “typical” treatment against the organization's actual facts (e.g. a coworking membership, storage of physical files, or company-issued hardware can bring a control back into scope).

4.3 Scenario B — No infrastructure / service-only organization

Applies to organizations that do not own, build, or operate any IT infrastructure, network, or production systems — e.g. a services/consulting business that runs entirely on third-party SaaS tools and does no software development. In this case, mark the infrastructure- and network-specific controls under Annex A 8 (Technological controls) as Not Applicable, with a justification along the lines of:

“The organization does not own, operate, or host any IT infrastructure, network, or production systems, and does not develop software. Infrastructure- and development-related controls are therefore not applicable to the ISMS scope.”

Ref	Control	Why it is typically Not Applicable
8.6	Capacity management	No owned infrastructure/systems whose capacity needs monitoring.
8.9	Configuration management	No systems or servers to configure or harden.
8.14	Redundancy of information processing facilities	No processing facilities exist to make redundant.
8.16	Monitoring activities	No systems/network to monitor for anomalous behaviour.
8.17	Clock synchronization	No systems generating logs that need synchronized clocks.
8.18	Use of privileged utility programs	No systems with utility programs to restrict.
8.19	Installation of software on operational systems	No operational systems onto which software is installed.
8.20	Networks security	No organization-operated network to secure.
8.21	Security of network services	No network services are provided or operated.
8.22	Segregation of networks	No network environment to segregate.
8.27	Secure system architecture and engineering principles	No systems are architected or engineered by the organization.
8.28	Secure coding	No software is developed in-house.
8.29	Security testing in development and acceptance	No development activity to test.
8.31	Separation of development, test and production environments	No such environments exist.
8.34	Protection of information systems during audit testing	No information systems exist to protect during audit/testing.

Endpoint, identity, and data-handling controls almost always remain applicable even in this scenario, because staff still use devices and handle business data:

Ref	Control	Why it usually stays Applicable
8.1	User endpoint devices	Staff still use laptops/phones to deliver the service.
8.2 / 8.3	Privileged access rights / Information access restriction	Staff still hold accounts and access to SaaS tools and business data.
8.5	Secure authentication	Login/MFA to email, SaaS, and business systems still applies.
8.7 / 8.8	Malware protection / Vulnerability management	Endpoint devices still need protecting and patching.
8.10 – 8.13	Information deletion, data masking, DLP, backup	Business data still exists and is still processed, stored, and needs protecting.
8.24	Use of cryptography	Data in transit/at rest on endpoints and SaaS tools still needs encrypting.
8.32	Change management	Still applies to any change affecting information or access, even without owned infrastructure.

5. Common Pitfalls

Excluding a control without a specific, auditable reason — “not needed” or “N/A” alone will not pass the audit.
Treating a vendor-delivered control as Not Applicable instead of Applicable-with-inherited-implementation (governed via supplier oversight controls).
Blanket-excluding an entire Annex A theme (e.g. all of Annex A 7 or all of Annex A 8) instead of assessing each control on its own facts.
Leaving the SoA out of sync with the ISMS scope statement and risk assessment — all three must tell the same story.
Forgetting to re-review the SoA when the organization opens/closes an office, adopts or drops infrastructure, or changes its service model.

6. Review, Approval and Maintenance

The SoA is a controlled ISMS record. It must be reviewed and formally approved by the document owner (typically the CEO or ISMS Manager) before being relied on as an audit record, and re-reviewed at least annually or whenever scope, infrastructure, premises, or risk materially change. Version history and approval dates should be tracked in the document header, consistent with the organization's document control procedure.

Related Articles