TL;DR
The Statement of Applicability is the output of your risk treatment, not the input. Build it from the controls you decided you need, then check that list against Annex A. Teams who work the other way round spend months justifying controls nobody asked for.
- Clause 6.1.3 d) asks for four things in one document. The necessary controls, why each one is in, whether you run it, and why any Annex A control is out.
- Annex A holds 93 controls in four themes. Organizational 37, People 8, Physical 14, Technological 34.
- Annex A is a cross-check under 6.1.3 c), not a starting menu. It exists so you notice a control you forgot.
- Inclusion has more than one justification. Risk assessment result, legal requirement, contractual obligation and business need are all valid, and they are not interchangeable.
- “Not implemented yet” is not an exclusion. It is an inclusion with an implementation status of no and a date in your risk treatment plan.
- Canadian law puts controls in your SoA whatever your risk scores say. PIPEDA breach reporting has been mandatory since 1 November 2018.
Sources: ISO/IEC 27001:2022 · BSI, control changes in the 2022 edition
What Clause 6.1.3 d) asks for #
ISO/IEC 27001 is a copyrighted standard, so this guide paraphrases rather than reproduces it. Buy the text before you build against it.
Clause 6.1.3 sets out the risk treatment process in six steps, a) through f). Step d) tells you to produce a Statement of Applicability. That one document has to carry four separate things.
- The necessary controls. The ones you determined in step b), after you chose your treatment options in step a).
- Justification for including each one. Why that control is necessary for your ISMS.
- Whether you run each control today. A status, not a promise. Yes, no, or partial with a date.
- Justification for excluding any Annex A control. Every control you left out needs a reason, written down.
What good looks like
A reader picks any Annex A reference at random and finds it in your SoA. One line tells them whether it applies, why, and whether you run it today. If they have to open three documents to answer that, the SoA is not finished.
The order that saves you months #
Most teams open Annex A, work down 93 rows, and argue about each one. That produces a document, and it produces the wrong one. Clause 6.1.3 runs in a specific direction.
- a) Choose treatment options. Modify, retain, avoid or share each risk from your risk assessment.
- b) Determine the controls you need. Work from the risk and the treatment decision. Do not look at Annex A yet.
- c) Compare your list with Annex A. Verify you have not missed anything necessary.
- d) Write the SoA. Record the result of a), b) and c).
Step c) is a safety net. The standard notes that Annex A is a list of possible controls and not an exhaustive one. You can design controls it does not contain. Teams who start at step c) reason backwards, inventing risks to justify controls they have already decided to keep.
What trips people up
Working Annex A first is not a nonconformity. It is a time sink. You still have to show the auditor how each control traces to a risk, a law or a contract. Rebuilding that after the fact takes longer than doing it in order.
Common justifications for including a control #
“Applicable” on its own is not a justification. Auditors want to know what makes it necessary. Four reasons carry real weight, and they are not the same reason.
The risk assessment said so #
The most common one, and the strongest. Reference the risk ID. A justification that reads “Risk R-014, unauthorised access to production data” beats one that reads “good practice” every time.
The law requires it #
This one stands whatever your risk score. If a statute obliges you to do the thing, the control is in, and a low risk rating does not release you. See the Canadian list below.
A contract requires it #
Customer agreements, data processing agreements and your own supplier commitments. A buyer who wrote encryption at rest into your MSA has put A.8.24 into your SoA. Your risk register has no say in it.
The business requires it #
Operational need rather than security need. Availability commitments in a service level agreement are the clearest case. Reach for this one last. It is the justification teams use when they have not thought about the other three.
What the law puts in your SoA #
Your Clause 4.1 context lists these as issues. The SoA is where they stop being context and start forcing specific controls in. Four bind most Canadian companies.
PIPEDA. Mandatory breach reporting has applied since 1 November 2018. Reporting to the Privacy Commissioner and to affected individuals needs a process behind it. That puts the incident management controls at A.5.24 through A.5.28 into your SoA. You also keep records of every breach, reported or not.
Quebec Law 25. Phased in across three dates, and it goes further than PIPEDA. The confidentiality incident register and mandatory breach reporting began 22 September 2022. Privacy by default and privacy impact assessments for transfers outside Quebec began 22 September 2023. A data portability right followed on 22 September 2024. Those obligations reach A.5.34 for privacy and personal information, plus A.8.10 and A.8.11 for deletion and masking.
PHIPA. Ontario health information custodians and their service providers. Notification duties and a duty to report to the Information and Privacy Commissioner of Ontario in defined circumstances.
OSFI B-13. For the financial institutions OSFI regulates in Canada. Technology and cyber risk expectations that map onto a wide band of the technological controls.
The practical consequence
Two Canadian companies with identical risk registers can have different Statements of Applicability, because one holds Quebec personal information and the other does not. Write the statute name into the justification column. A reviewer at a provincial health authority reads that column looking for it.
Common justifications for excluding a control #
You may exclude controls, and most companies do. What an exclusion needs is a reason tied to what your ISMS does, not to what you find inconvenient.
The ones that hold up:
- You do not do the activity. A company that develops no software excludes the development controls at A.8.25 through A.8.31. This is the cleanest exclusion there is.
- The asset does not exist in your scope. No physical premises inside the boundary means the site controls in A.7 need a hard look, though see the trap below.
- Another party operates it, and you say who. Name the provider and the contract. This one records better as an inclusion that a third party operates.
- The role does not exist. No remote workers, no removable media, no development environment.
The three exclusions auditors reject #
- “We have not implemented it yet.” That is an inclusion with an implementation status of no. Put it in the risk treatment plan with an owner and a date. Excluding it instead is the single most common SoA finding.
- “We are too small for this.” Size is not a justification. A.5.7 threat intelligence draws this one more than any other control. If a control does not fit your size, scale it down. Do not delete it.
- “Everything is in the cloud, so physical security does not apply.” Your cloud provider’s data centres and your staff’s home offices are both interfaces under Clause 4.3. Address them rather than deleting the theme.
Excluding a control is not the same as scoping something out. Scoping moves the boundary and shows on your certificate. Excluding keeps the boundary and records that a named control does not apply inside it. The Clause 4.3 guide covers the difference. Auditors notice when the two documents disagree.
A sample Statement of Applicability #
Six columns do the job. More columns look thorough and get maintained less.
| Ref | Control | Applicable | Justification | Implemented | Evidence |
|---|---|---|---|---|---|
| A.5.7 | Threat intelligence | Yes | Risk R-011, undetected exploitation of a known vulnerability | Partial, full feed due 31 Jan | Threat intel procedure, monthly review minutes |
| A.5.24 | Incident management planning and preparation | Yes | PIPEDA breach reporting duty, and risk R-004 | Yes | Incident response plan v3, tabletop exercise report |
| A.5.34 | Privacy and protection of PII | Yes | Quebec Law 25, customer data processing agreements | Yes | Privacy policy, PIA register, Law 25 governance policy |
| A.8.24 | Use of cryptography | Yes | Contractual, encryption at rest in the enterprise MSA | Yes | Key management standard, KMS configuration export |
| A.8.28 | Secure coding | No | The organization develops no software. Every application is third-party SaaS | Not applicable | Scope statement, application inventory |
| A.7.4 | Physical security monitoring | Yes | Operated by the cloud provider for the hosting region. Home offices covered by the remote working policy | Yes, by a third party | Provider ISO 27001 certificate, remote working policy |
Two habits make this table survive an audit. Write each justification as a sentence a stranger can read. Put a real evidence reference in the last column rather than the name of a folder. The A.7.4 row shows the pattern for a control somebody else runs. It stays applicable, and the justification names who operates it.
Keeping it current #
The SoA counts as documented information, so it carries a version and a change history. Four events should trigger a review.
- The scope changed. A new product, region, entity or acquisition moves the boundary, and the boundary decides which controls apply.
- The risk assessment changed. New risks add controls. Retired risks do not remove them, because a control may still be held in by law or contract.
- A contract landed. Read the security schedule of every enterprise deal against your SoA before you sign it.
- Management review. Clause 9.3 brings the ISMS back to the table at planned intervals. Put the SoA on that agenda.
Your certification body reads the SoA at the audit and compares it against what it finds. ISO/IEC 27006-1:2024 keeps that expectation unchanged from the prior edition. A control marked implemented that nobody can evidence is a nonconformity. It is a worse one than an honest “no” with a date beside it.
Frequently asked questions #
Is the Statement of Applicability mandatory?
Yes. Clause 6.1.3 d) requires you to produce one, and it counts as documented information, so it has to exist in a controlled form. A certification body asks for it first.
Do I have to list all 93 Annex A controls in the SoA?
You have to account for all of them. Every control you exclude needs a written justification, which means every control appears somewhere. Most teams list all 93 in one table with an applicable column, because that is the cheapest way to show you skipped nothing.
Can I exclude a control because we have not implemented it yet?
No. Applicability and implementation are two different columns. A control you intend to run is applicable, with an implementation status of no and a date in your risk treatment plan. Excluding it instead is the most common finding raised against a Statement of Applicability.
What is the difference between excluding a control and scoping something out?
Scoping out moves the ISMS boundary under Clause 4.3, and the scope statement appears on your certificate. Excluding a control leaves the boundary where it is. It records in the SoA that a named Annex A control does not apply inside it. Different documents, different justifications, and auditors check that the two agree.
Can I add controls that are not in Annex A?
Yes. Annex A is a list of possible controls and the standard says it is not exhaustive. If your risk treatment needs a control that Annex A does not describe, design it and put it in the SoA alongside the rest. Sector requirements often drive this.
Do customers get to see our Statement of Applicability?
Your certificate carries the scope statement, not the SoA. Enterprise buyers and public sector reviewers ask for the SoA anyway, because it is the only document that names the controls you run. Write it expecting a customer to read it. Keep the sensitive detail in the evidence it points to.
Key takeaways #
- Clause 6.1.3 d) wants four things in one document: controls, why in, implementation status, why out.
- The SoA is the output of risk treatment. Annex A is the cross-check at step c), not the starting menu.
- Annex A holds 93 controls across four themes, 11 of them new in the 2022 edition.
- Risk, law, contract and business need are four distinct inclusion justifications. Name which one applies.
- Canadian statute puts controls in whatever the risk score says. PIPEDA breach reporting has been mandatory since 1 November 2018.
- “Not implemented yet” is an inclusion with a date, never an exclusion.
- Size is not a justification for excluding a control. Scale the control instead.
- Excluding a control and scoping something out are different mechanisms. Keep the two documents consistent.
- Six columns are enough. Write justifications a stranger can read and cite real evidence.
- Review the SoA when scope, risk or contracts change, and at management review.
Write it once, and write it right #
Nank.ai runs ISO 27001 programmes for companies in Canada and the United States, with a dedicated compliance manager backed by AI agents. We build the Statement of Applicability from your risk treatment rather than from a template, and we review every justification before your certification body does.
