Statement of Applicability
Internal Audit
Certification Readiness

How to Audit the ISO 27001 Statement of Applicability for Accuracy, Justification, and Real Control Use

Learn how to audit the ISO 27001 Statement of Applicability for accuracy, control justification, applicability decisions, implementation status, evidence mapping, risk treatment alignment, and certification readiness.

Quick Answer

How do you audit the ISO 27001 Statement of Applicability?

To audit the ISO 27001 Statement of Applicability, internal auditors should test whether each control decision is accurate, justified, linked to risk treatment, assigned to an owner, and supported by evidence.

A strong SoA should show which controls apply, why they apply, which controls are excluded, why they are excluded, whether controls are implemented, and what evidence proves real control use.

The goal is simple: confirm that the SoA reflects the real ISMS, not just a checklist.

The SoA Is Not Just an ISO 27001 Checklist

The Statement of Applicability is one of the most important ISO 27001 documents.

It is also one of the easiest documents to get wrong.

Many organizations mark controls as applicable, add short justifications, mark controls as implemented, and move on.

However, during an ISO 27001 internal audit, the auditor should test whether the SoA reflects real risks, real controls, real owners, and real evidence.

Practical rule: the Statement of Applicability should be a control decision record, not a static checklist.

The Main SoA Audit Question

The strongest SoA audit question is not, “Does the Statement of Applicability exist?”

A better question is:

Does the Statement of Applicability accurately reflect the organization’s real risks, control decisions, implementation status, exclusions, evidence, and actual control use?

Statement of Applicability Audit Snapshot

SoA Audit Area What Internal Audit Should Test
Accuracy Does the SoA match the real scope, risks, systems, vendors, and controls?
Applicability Are controls correctly marked applicable or not applicable?
Justification Are inclusion and exclusion decisions clearly explained?
Risk Alignment Does the SoA align with the risk register and risk treatment plan?
Implementation Status Are controls marked implemented only when evidence supports that status?
Evidence Mapping Is there current evidence for each implemented control?

Why the Statement of Applicability Matters

The SoA connects risk decisions to controls.

It explains which controls were selected, which controls were excluded, why those decisions were made, and whether selected controls are implemented.

A weak SoA can create serious certification readiness problems.

Controls marked implemented without evidence.
Controls marked not applicable without justification.
SoA not aligned with the risk register.
Cloud, vendors, or AI tools missing from control decisions.

What a Strong Statement of Applicability Should Show

A useful SoA should help an auditor understand the control decision and find the evidence quickly.

Control ID and control name.
Applicability status.
Applicability justification.
Non-applicability justification.
Implementation status.
Control and evidence owner.
Risk and treatment links.
Evidence links and review date.

1. Test Whether the SoA Matches the ISMS Scope

The Statement of Applicability must match the ISMS scope.

When the scope includes cloud services, remote workers, vendors, support workflows, or AI-enabled features, the SoA should reflect those realities.

Audit Questions

  • Does the SoA match the approved ISMS scope?
  • Are in-scope systems reflected?
  • Are cloud platforms and SaaS tools considered?
  • Are vendors and outsourced processes considered?
  • Are AI tools considered where relevant?

Common finding: the SoA does not reflect the actual ISMS scope because key supporting systems, vendors, or cloud tools are missing from control decisions.

2. Test Whether Applicability Decisions Are Accurate

A control should be marked applicable when it is relevant to the organization’s risks, scope, obligations, processes, systems, or services.

The auditor should test why the control applies.

Audit Questions

  • Why is this control applicable?
  • Which risk does it help treat?
  • Which system, vendor, or process does it protect?
  • Is the control used in practice?
  • Is the control required because of client, legal, cloud, vendor, or data handling needs?

Weak Justification

Applicable because required.

Stronger Justification

Applicable because the organization uses Microsoft 365, cloud hosting, and third-party SaaS platforms to process customer and business information. Access control, identity management, privileged access review, logging, and supplier security controls are required to reduce unauthorized access and supplier dependency risks.

Need to Test Your Statement of Applicability Before Certification?

Canadian Cyber helps organizations audit the ISO 27001 Statement of Applicability for accuracy, justification, evidence mapping, control ownership, risk treatment alignment, and certification readiness.

We help turn checklist-style SoAs into evidence-backed control decision records.

3. Test Whether Non-Applicability Decisions Are Justified

Not every control applies to every organization.

However, every non-applicable control should be justified, risk-aware, and aligned with scope.

Audit Questions

  • Why is this control not applicable?
  • Does the organization truly not perform this activity?
  • Is the exclusion supported by the scope statement?
  • Could the excluded control still affect customer data, vendors, or operations?
  • Was the exclusion approved and reviewed after business changes?

Weak Exclusion

Not applicable.

Stronger Exclusion

Not applicable because the organization does not develop software, maintain source code repositories, or operate a software development lifecycle within the ISMS scope. This decision was reviewed against the current service catalogue, system inventory, and scope statement.

Practical rule: non-applicable does not mean ignored. It means justified.

4. Test Whether the SoA Aligns With the Risk Register

The SoA should reflect risk treatment decisions.

If the risk register identifies unauthorized access, vendor dependency, cloud misconfiguration, or AI tool misuse, related control decisions should appear clearly in the SoA.

Audit Questions

  • Does each major risk have related control decisions in the SoA?
  • Do applicable controls link to risk treatment decisions?
  • Are high risks supported by appropriate controls?
  • Are accepted risks reflected clearly?
  • Are new risks reflected in the SoA?

Common finding: the risk register and SoA do not align, making it unclear why certain controls were selected or excluded.

5. Test Implementation Status

Implementation status is where many SoAs become misleading.

A control marked “implemented” should have evidence.

Suggested Status Meaning
Implemented Evidence shows the control is operating.
Partially Implemented Some evidence exists, but gaps remain.
Planned The control is planned but not yet operating.
Implemented by Vendor A vendor performs the control, but oversight evidence is needed.
Requires Evidence Update The control may operate, but current evidence is missing or outdated.

Practical rule: implementation status should be evidence-based, not optimistic.

6. Test Real Control Use

The SoA should not only describe controls.

It should reflect controls that operate in real life.

Audit Questions

  • Does the control actually operate?
  • Who performs it?
  • How often is it performed?
  • What evidence is created?
  • What happens when exceptions occur?

Common finding: the SoA lists controls, but interviews and samples show that the controls are not operating consistently.

7. Test Control Ownership

Each applicable control needs an owner.

Without ownership, evidence becomes difficult to maintain.

Audit Questions

  • Who owns this control?
  • Does the owner understand the control?
  • Who provides evidence?
  • Who reviews exceptions?
  • Who owns corrective actions?

Practical rule: a control without an owner is difficult to prove and harder to improve.

8. Test Evidence Mapping

A strong SoA should link controls to evidence.

The auditor should not need to search through scattered folders to verify implementation.

SoA Control Area Evidence Examples
Access Control Access reviews, MFA report, offboarding tickets, admin role review.
Supplier Security Vendor register, vendor risk ratings, contracts, security reviews.
Incident Management Incident log, tabletop report, lessons learned, escalation record.
Backup and Restore Backup report, failure tickets, restore test report.
AI Governance AI tool inventory, approved use cases, vendor reviews, risk entries.

9. Test Vendor and Shared Service Controls

Some controls may be performed by vendors, parent companies, or shared services.

That can be acceptable, but the SoA should make the dependency clear.

Audit Questions

  • Is the control implemented internally, by a shared service, or by a vendor?
  • Who owns oversight?
  • What evidence is available?
  • Are vendor reports reviewed?
  • Who handles findings?

Practical rule: vendor-performed controls still need internal ownership and oversight evidence.

10. Test SoA Updates After Business Change

The SoA should not remain static.

It should be updated when risks, systems, vendors, processes, services, or legal obligations change.

New cloud platform.
New SaaS tool.
New AI tool.
New vendor.
New client requirement.
New audit finding.

Common finding: the SoA has not been updated after new systems, vendors, AI tools, or business services were introduced.

Statement of Applicability Audit Matrix

SoA Area Strong Evidence Weak Evidence
Applicability Clear link to scope, risk, or obligation. Generic “applicable” note.
Non-Applicability Justified, approved, and risk-aware. “Not applicable” with no reason.
Implementation Status Supported by current evidence. Marked implemented without proof.
Ownership Named control and evidence owners. No owner or all assigned to ISMS Manager.
Evidence Mapping Direct links to controlled evidence. Scattered folders or broken links.

Sample SoA Internal Audit Finding

Weak Finding

The SoA is not accurate.

Stronger Finding

The Statement of Applicability marks supplier security controls as implemented, but three sampled critical vendors did not have documented security review conclusions, risk ratings, or next review dates. The risk register identifies supplier dependency as a medium-high risk, and the risk treatment plan requires annual review of critical vendors. Because SoA implementation status is not supported by vendor review evidence, the supplier security control status is overstated and should be updated until treatment evidence is complete.

How SharePoint Can Help Audit the SoA

A SharePoint ISMS workspace can make the Statement of Applicability easier to maintain and audit.

It can connect control decisions to risks, evidence, owners, actions, review dates, and management decisions.

Statement of Applicability
Track applicability, justification, and status.
Risk Register
Link controls to risks and treatment decisions.
Evidence Matrix
Map evidence to Annex A controls.
Control Owner Matrix
Assign control and evidence owners.
Corrective Action Tracker
Track open SoA and evidence gaps.
Certification Dashboard
Show controls missing evidence or owners.

When Your SoA Needs Support

Organizations may need professional support when these problems appear:

The SoA is outdated.
The SoA does not match the risk register.
Controls are marked implemented, but evidence is weak.
Non-applicable controls are not justified.
Cloud, vendors, or AI tools are missing.
Certification audit is coming soon.

How Canadian Cyber Helps

Canadian Cyber helps organizations audit the ISO 27001 Statement of Applicability for accuracy, justification, control use, evidence mapping, and certification readiness.

We help teams move from checklist-style SoAs to evidence-backed control decision records.

Our support includes SoA accuracy review, applicability testing, non-applicability justification review, risk register alignment, risk treatment plan alignment, control owner mapping, Annex A evidence mapping, SharePoint dashboards, corrective action tracking, and management review preparation.

Senior Advisory Support

Canadian Cyber also provides senior advisory support for ISO 27001 internal audits, SoA reviews, Annex A evidence mapping, SharePoint ISMS dashboards, corrective action tracking, management review preparation, and vCISO guidance.

View Waqar Mehboob’s Profile

Frequently Asked Questions

What is the ISO 27001 Statement of Applicability?

The Statement of Applicability identifies which controls are applicable, which controls are not applicable, why those decisions were made, and the implementation status of selected controls.

Why is the Statement of Applicability important?

The SoA connects the organization’s risk treatment decisions to selected controls. It helps auditors understand why controls apply and whether implementation is supported by evidence.

What is a common SoA internal audit finding?

A common finding is that controls are marked implemented, but supporting evidence is missing, outdated, incomplete, or not mapped to the SoA.

Can a control be marked not applicable?

Yes. However, the organization should provide a clear, risk-based justification that aligns with the ISMS scope, business activities, systems, vendors, and obligations.

Should the SoA link to evidence?

Yes. A strong SoA should link applicable and implemented controls to evidence, control owners, risk treatment decisions, and supporting policies or procedures.

Can SharePoint help manage the Statement of Applicability?

Yes. SharePoint can track SoA controls, applicability status, justification, implementation status, owners, evidence links, risk links, corrective actions, and management review decisions.

Takeaway

The Statement of Applicability is not a formality.

It is the control decision record for the ISMS.

A strong SoA explains which controls apply, why they apply, which controls are excluded, what evidence proves implementation, and who owns each control.

When the SoA is accurate, justified, evidence-backed, and aligned with real control use, certification readiness becomes much clearer.

Make Your ISO 27001 Statement of Applicability Audit-Ready

Canadian Cyber can help your organization review the Statement of Applicability, test applicability decisions, map evidence, align risks and controls, and prepare for ISO 27001 certification readiness.

We support ISO 27001 SoA reviews, internal audits, Annex A evidence mapping, SharePoint ISMS dashboards, corrective action tracking, management review preparation, vCISO support, SOC 2 readiness, ISO 42001, ISO 27017, ISO 27018, and cybersecurity assessments.

Stay Connected With Canadian Cyber

Follow Canadian Cyber for practical guidance on ISO 27001 internal audits, Statement of Applicability, Annex A controls, risk treatment, certification readiness, SharePoint ISMS, SOC 2 readiness, AI governance, and vCISO services.