You’re in the middle of an internal ISO (International Organization for Standardization) 27001 audit.
The auditor reaches your Statement of Applicability, scans the rows, and stops at control 8.30, Outsourced development. The row says “Not applicable: development is performed in-house.” But your company pays an outside firm to build its mobile app.
Uh oh!
That’s where ACME Software found itself. The team spent weeks collecting audit evidence and one afternoon on the Statement of Applicability, filling it in from a template and keeping most of the defaults.
That’s backwards. The Statement of Applicability is the Rosetta Stone of an ISO 27001 audit: it translates your risks and obligations into the standard’s list of controls, and it tells the auditor which controls to test.
A Statement of Applicability (SoA) records which security controls your ISMS (Information Security Management System) needs, why each one is in or out, and whether it’s in place yet. ISO 27001 certification requires one, and many certificates cite the SoA’s version and date in their scope wording.
ACME’s problem points to the rule this article is built on: every row in your SoA must trace back to a real reason, such as a risk from your risk assessment, a customer contract, or a law. You don’t have to implement every Annex A control, but you’d better have a legitimate reason for every control you skip.
Our scope statement guide covers where your ISMS boundary sits, and our ISO 27001 ISMS requirements overview covers the ISMS as a whole. This article picks up where scope leaves off: deciding which controls apply inside the boundary and recording why. The company, rows, and decisions below are illustrative, so borrow the reasoning and write your own answers.
What Does ISO 27001 Require in a Statement of Applicability?
ISO/IEC (International Electrotechnical Commission) 27001:2022 requires a Statement of Applicability that contains four things:
- The necessary controls. These are the controls your risk treatment work says you need, wherever they came from.
- A justification for including each one. Every control needs a reason to be there.
- Whether each necessary control is implemented. The standard asks for status, so “planned” is an allowed answer.
- A justification for excluding any Annex A control. If you leave one out, you write down why.
Annex A lists 93 controls in four themes: organizational, people, physical, and technological. A numbered list that long looks like a checklist every certified company must complete.
The standard uses it as a cross-check instead. Here’s what you do in practice:
- Start with your risks. Use your risk treatment plan to decide which controls you need. ISO 27001 says those controls can come from any source and that Annex A isn’t exhaustive, so you can design your own or borrow from another compliance standard your customers already ask about.
- Check your list against Annex A. Walk through the 93 controls and confirm you haven’t missed anything necessary. At this step, Annex A works as a gap check on decisions you’ve already made.
- Record the outcome in your SoA. List each necessary control with its reason and status, and write down why you excluded any Annex A control.
That has two consequences. A company can be certified without implementing every Annex A control, as long as each exclusion has a sound reason. It can also add controls that Annex A doesn’t name. The SoA is where both kinds of decisions get recorded.
Check which edition your SoA follows, too. The 2013 edition of ISO 27001 had 114 controls under a different numbering scheme. Certificates issued against it expired when the transition period ended on October 31, 2025, so an SoA still built on 2013 numbering is out of date. An older template will still contain that numbering, which is one more reason not to trust its rows as written.
That leaves the practical part: deciding which controls you need.
How Do You Make SoA Control Decisions?
Most control decisions come from your risk assessment. The rest come from obligations you’ve taken on.
The reasons behind each row fall into four groups:
- Risk treatment. Your risk assessment identifies what could go wrong, and your risk treatment plan picks controls to reduce those risks. This is the backbone of the SoA.
- Legal and regulatory requirements. Privacy laws, breach notification laws, and industry regulations can require controls on their own terms. The European Union’s NIS2 (Network and Information Security 2) Directive, for example, requires medium and large organizations in 18 critical sectors to take cybersecurity risk-management measures.
- Contractual requirements. Customer agreements can spell out specific security commitments, such as encryption, breach notification timelines, or data deletion when a contract ends.
- Interested party expectations. ISO 27001 asks you to identify your interested parties (customers, regulators, investors, and employees) and decide which of their requirements your ISMS will address. Some of those needs aren’t written into any contract yet, like the questions in a prospect’s security questionnaire or an investor’s due diligence checklist, but they still shape which controls you choose.
A single control can have more than one driver. ACME’s largest customer’s contract requires notification of a security incident within a set number of days. Several states where its customers live also set their own deadlines for notifying affected people, from 30 to 60 days. Both point to the incident response plan. Recording both reasons in the SoA tells an auditor, and the next person to own the document, that removing that plan would break both a contract and a legal obligation.
The Annex A comparison comes last. After ACME’s team decides what they need, they walk the 93 controls to check for gaps. That step should have caught the nonconformity (ISO’s term for a failure to meet a requirement): it would have prompted the question “Do we outsource any development?” and the answer was “yes!”
Once the decisions are made, record them in the SoA.
What Does a Well-Reasoned SoA Row Look Like?
A good row answers four questions in a sentence or two each: whether the control is included, why, whether it’s done, and who owns it. An auditor asks those questions, and so does the next person who inherits the document.
Here are five illustrative rows from ACME’s corrected SoA:
| Control | Included? | Reason (driver) | Implementation status | Owner |
| 5.23 Information security for use of cloud services | Yes | Risk R-04: misconfigured AWS (Amazon Web Services) storage exposes customer data. The platform runs entirely on AWS. | Implemented. Cloud configuration standard approved; automated configuration checks run daily. | Head of Engineering |
| 5.31 Legal, statutory, regulatory and contractual requirements | Yes | Customer contracts include security and breach notification terms; state breach notification laws apply to customer data. | Implemented. Register of legal and contractual requirements maintained and reviewed each quarter. | Operations Lead |
| 6.7 Remote working | Yes | Risk R-07: lost or stolen laptops at home offices. Engineers access production remotely. | Implemented. Remote work policy, full-disk encryption, and multi-factor authentication on all accounts. | Operations Lead |
| 7.4 Physical security monitoring | No | The Austin office holds no servers, network equipment, or stored customer data; production runs in AWS, which handles data center physical security under its shared responsibility model; Sarah’s team assesses AWS under supplier controls (5.19 to 5.22). No risk in the risk register calls for monitoring the office. | Not applicable (excluded). Revisit if the office begins storing equipment or data. | Operations Lead |
| 8.30 Outsourced development | Yes | Risk R-11: insecure code from the contract mobile app firm reaches production. The firm builds an in-scope product. | Partially implemented. Code review before release is in place; security requirements go into the contract at renewal on [target date]. | Head of Engineering |
A few things make these rows work.
Every entry in the Reason column refers to something you can find elsewhere: a risk ID (identifier) in the risk register, a contract, or a law. An auditor can follow that thread in either direction. Pick a risk and find its controls, or pick a control and find its risk.
Row 5.31 has no risk ID at all. Its driver is the contracts and laws themselves, which is exactly the kind of obligation-based decision the previous section described.
The exclusion in row 7.4 says why the control doesn’t fit and what would change the answer. “Not applicable” by itself gives the auditor nothing to evaluate. It’s also a judgment call: auditors have accepted this exclusion for companies with no office at all, but a staffed office, even a small one, will draw more questions. The supplier controls it relies on also have to hold up, which means assessing your vendors and keeping that evidence on file.
Row 8.30 admits the work isn’t finished. “Partially implemented,” with a date, is a more useful answer than “Implemented” with a footnote nobody reads.
Many SoAs have extra columns, such as a link to the evidence, the related policy, or the date the row was last reviewed.
Can a Template Decide Applicability?
Templates earn their popularity. Building an SoA from a blank page is slow, and a good template gives you the control list, sensible columns, and example wording. For a small team preparing for a first audit, that saves many hours.
The trouble starts when the template’s answers stay in the document. A template author can’t know your technical environment. Any “Applicable” or “Not applicable” in a template is a guess about some generic company. The same caution applies to the prebuilt SoA templates and control mappings inside compliance software platforms, which still leave the justifications to you.
ACME’s nonconformity is the mild version. The more serious version is a template that marks everything “Applicable” and “Implemented.”
It looks thorough on the surface: “look at all our security controls!”
But it suggests nobody made decisions. Every “Implemented” row is also a claim the auditor can sample and ask you to prove, and a template can’t produce that evidence for you. (Yikes.)
Use a template for structure. Clear out its answers before you start, then fill each row from your own risk register and obligations.
How to Record Implementation Status
Record what’s true on the day you approve the document. A common set of statuses looks like this:
- Implemented. The control is in place and you can show evidence of it working.
- Partially implemented. Some of the control exists, and the rest is in your risk treatment plan with an owner and a date.
- Planned. The control is necessary but not started yet. It should also appear in your risk treatment plan.
- Not applicable (excluded). The control doesn’t fit, and the reason is written in the row. Strictly speaking, this is an applicability decision rather than a status, but many SoAs track it in the same column.
ISO 27001 asks only whether each necessary control is implemented or not. Finer statuses are your team’s choice, made to keep the document useful, and some compliance platforms track controls the same way (implemented, in process, not started, or excluded).
Keep the SoA and the risk treatment plan in step. ISO 27001 requires a risk treatment plan, which should set out what will be done, by whom, and by when. If a row says “Planned,” expect your auditor to look for that control in the plan, with an owner and a deadline. When the two documents disagree, the gap can turn into a finding, or at least an uncomfortable conversation.
Status is usually the column that changes most often. ACME’s 8.30 row moves to “Implemented” the day the new contract terms are signed, which raises a practical question: who makes that change, and when?
Who Updates the SoA When the Organization Changes?
Give the SoA one named owner (usually the same person who owns the ISMS), and make control owners responsible for telling that person when their rows change. ISO 27001 requires documented information to be reviewed and approved, though it doesn’t say who approves. Having top management sign each new version shows the decisions have backing.
At ACME, the operations lead owns the document. The head of engineering owns the technical rows and flags changes to them. The CEO approves each new version. Every version gets a number and a date, because the scope statement and, in many cases, the certificate itself point to a specific SoA version.
The SoA needs a review whenever the reasons change. These events should send the owner back to the document:
- A new or updated risk assessment. ISO 27001 calls for risk assessments at planned intervals and when significant changes happen. New risks can add rows; retired risks can change justifications.
- A scope change. New products, locations, or providers change what the ISMS covers, which can change which controls you need.
- A new contract or regulation. A customer agreement with new security terms can add a contractual driver to existing rows or require new controls.
- An internal audit finding or a security incident. Either one can show that a control marked “Implemented” isn’t working.
- Management review. ISO 27001 requires management review at planned intervals, which makes a good recurring checkpoint for the whole document.
Picture ACME eighteen months from now, buying a small analytics firm that runs on Microsoft Azure. The scope statement changes first. Then the SoA follows: row 5.23 now needs to cover Azure as well as AWS, a new risk about two cloud environments appears in the register, and several rows pick up a new owner on the acquired team.
Check your certification agreement too. Certification bodies set their own rules about reporting changes between audits, and a change tied to scope, like ACME’s acquisition, usually means updating the certificate’s scope wording, including the SoA version it cites. Ask your certification body how it wants to hear about SoA changes before you make a big one, not after.
How Do You Run an Internal Audit of Your Own SoA?
Block out a few hours (an SoA with 93 or more rows takes longer than it looks), open it next to your risk register, and run every row through these questions:
- Does the row have a real reason? It should point to a risk ID, a contract, a law, or another named requirement, not “best practice” or “required by ISO.”
- Does the reason still hold? Check whether the risk, contract, or regulation behind it is still current.
- Is the status true today? Spot-check a few “Implemented” rows by asking for the evidence.
- Do “Partially implemented” and “Planned” rows match the risk treatment plan? Each one should have an owner and a date there.
- Does every exclusion explain itself? A reader should understand why the control doesn’t fit and what would change that.
- Did you check Annex A for gaps? Walk the list once more and ask whether anything new in the business, such as a vendor, product, or contract, makes a control you excluded necessary, or calls for one you haven’t listed.
- Does each row have an owner, and does the document have a version and approval date?
Rows that fail any of these questions need to be fixed. Many fixes take just a sentence or two; a missing control takes longer and belongs in your risk treatment plan. If you’d like an outside view, a cybersecurity gap assessment compares your whole security program against a defined set of controls and shows what’s missing.
How Did ACME Fix Row 8.30?
Back to the internal audit. ACME’s team doesn’t argue with the finding. They rewrite row 8.30 to name the contract firm, link it to a new risk in the register, and mark it “Partially implemented,” with code review already in place and contract security terms due at renewal. Then they run the same audit questions against every other row the template filled in and fix four more. This time, the SoA gets more than an afternoon, and nobody accepts a default without checking it against how the company actually works.
By the time the certification auditor arrives two months later, the contract has been renewed with the new security terms, and the operations lead has moved row 8.30 to “Implemented.” The row answers its own questions. The auditor reads it, asks to see the signed terms and one code review record, and moves on. (The CEO counts that as the best kind of audit conversation: a short one.)
If your own SoA still carries a template’s answers, start with the audit questions above and your risk register. Fractional CISO writes Statements of Applicability and risk treatment plans with growing companies, usually as part of a broader ISO 27001 or SOC 2 (System and Organization Controls 2) program. If you’d like a second set of eyes, take a look at our ISO 27001 compliance services.
Want to get great cybersecurity content delivered to your inbox? Click here to sign up for our monthly newsletter, Tales from the Click.
