Why This Audit Task Trips Up Even Experienced Auditors
The Statement of Applicability (SoA) is one of the most scrutinised documents in any ISO 27001 audit. Certification bodies spend considerable time on it at Stage 1. Internal auditors often treat it as a box-ticking exercise. Neither approach serves the organisation well.
On this page
The real audit value lies not in confirming the SoA exists, but in checking whether it connects logically and consistently to the risk treatment plan. These two documents are supposed to tell the same story from different angles. When they do not, you have found something worth raising.
This article walks through how to audit that connection in practice: what to look for, what questions to ask, and how to classify what you find.
What the Standard Actually Requires
ISO 27001:2022 Clause 6.1.3 sets out the requirements for information security risk treatment. The organisation must produce a risk treatment plan and a Statement of Applicability. The SoA must include all necessary controls, justification for inclusion or exclusion, whether each control is implemented, and justification for any exclusions from Annex A.
The risk treatment plan documents what decisions were made about each identified risk: which risks are treated, how they are treated, and which controls are applied. The SoA then reflects those decisions across the full Annex A control set.
In theory, the two documents are complementary. The risk treatment plan drives the decisions. The SoA records the outcome of those decisions against every Annex A control. In practice, organisations often produce them independently, update one without updating the other, or treat the SoA as a template exercise rather than a genuine reflection of risk treatment decisions.
That gap is exactly what you are auditing.
Exemplar Global Certified Training ProviderRTP No. 310970
Understanding the Relationship Between the Two Documents
Before you can audit the connection, you need to be clear on what the connection should look like.
The Risk Treatment Plan Side
The risk treatment plan records each information security risk that has been assessed, the treatment option selected (accept, avoid, transfer, or modify), and where modification is chosen, the specific controls applied. It should reference the Annex A controls or other controls that address each risk. It should also identify control owners and target implementation dates.
The Statement of Applicability Side
The SoA lists every Annex A control (all 93 in the 2022 edition) and for each one states whether it is applicable, whether it is implemented, and the justification. For controls that are included, the justification typically references the risk treatment plan or a legal, contractual, or other obligation. For controls that are excluded, the justification must explain why the control is not necessary.
The Link You Are Looking For
Every control selected in the risk treatment plan should appear as applicable and implemented (or in progress) in the SoA. Every control marked as applicable in the SoA should trace back to at least one driver: a risk treatment decision, a legal requirement, a contractual obligation, or a business need. Controls that are applicable but have no traceable justification are a finding. Controls in the risk treatment plan that do not appear as applicable in the SoA are a finding. Controls excluded from the SoA where the risk treatment plan has identified related risks without an alternative control are a finding.
How to Prepare for This Audit Task
Do not walk into this audit expecting to review both documents line by line in real time. Request them in advance as part of your document review. You want time to read them carefully before you sit down with the information security manager or ISMS lead.
Documents to Request Before the Audit
- The current Statement of Applicability, including version and date
- The current risk treatment plan, including version and date
- The information security risk assessment register or report
- The risk assessment methodology document
- Any evidence of management approval for the risk treatment plan and SoA
Check the version dates first. If the risk treatment plan was last updated eight months ago and the SoA was updated three months ago, ask yourself what changed and whether both documents reflect the same point in time. Version mismatches are common and often indicate that one document has been updated without revisiting the other.
Building Your Audit Sample
You cannot audit every one of the 93 controls in detail during a typical internal audit. Be deliberate about your sample. Consider selecting controls from the following categories:
- Controls that the risk treatment plan explicitly references for high-rated risks
- Controls that are marked as not applicable, particularly for common areas like access control or supplier management
- Controls that are marked as applicable but not yet implemented
- Controls in areas where you know the organisation has had incidents or near misses
- A random sample from the remaining controls to test general consistency
For a focused internal audit, a sample of 15 to 25 controls is usually sufficient to draw reasonable conclusions, provided you weight the sample toward higher-risk areas.
Running the Audit: What to Check and How
Step 1: Confirm Both Documents Are Approved and Current
Start with the basics. Both documents must be approved by authorised personnel. The standard requires that the risk treatment plan be approved by risk owners and, where required, by asset owners. Check who approved each document and when. If approval is missing or outdated, that is a nonconformity against Clause 6.1.3 or Clause 7.5 depending on how you frame it.
Also confirm that the SoA version in use is the one that was approved. It is not unusual to find that the document has been edited since approval without a new approval record.
Step 2: Trace Controls From the Risk Treatment Plan Into the SoA
Take the risk treatment plan and identify five to ten controls it references for treated risks. Find those controls in the SoA. For each one, check:
- Is the control marked as applicable?
- Is the implementation status consistent with what the risk treatment plan says?
- Does the justification in the SoA reference the risk or the risk treatment decision?
A common finding here is that the SoA marks a control as implemented but the risk treatment plan records it as planned with a future target date. That is an inconsistency. Neither document is necessarily wrong, but they are telling different stories, and that undermines the integrity of both.
Step 3: Trace Controls From the SoA Back Into the Risk Assessment
Now reverse the direction. Take five to ten controls from the SoA that are marked as applicable and trace them back to the risk assessment. You are asking: what risk or obligation justifies this control being included?
For each control, you should be able to find either a risk in the risk register that this control addresses, or a documented legal, contractual, or business requirement. If neither exists, the control has no traceable justification. That is a gap worth raising, particularly if the organisation cannot explain verbally why the control is there.
Step 4: Test the Exclusion Justifications
Controls marked as not applicable deserve specific attention. The standard requires justification for exclusions. A justification of not relevant to our business is not sufficient unless it is backed by an explanation of why the risk does not exist or has been addressed by other means.
Common exclusions that warrant scrutiny include:
- Physical security controls excluded by organisations operating in shared office environments
- Supplier relationship controls excluded by organisations with significant outsourced functions
- Cryptography controls excluded without any explanation of how data in transit or at rest is protected
When you find a weak exclusion justification, probe it in your interview. Ask the ISMS lead to explain the reasoning. If they cannot, and the risk assessment does not address the relevant risk, you have a finding.
Step 5: Check for Controls That Appear in Neither Document
This is a less obvious check but an important one. Look for Annex A controls that are not mentioned in the risk treatment plan and are marked as not applicable in the SoA, but where the organisation clearly has a relevant risk or obligation. For example, if the organisation handles personal data and has no reference to data masking (Control 8.11) or privacy protection (Control 5.34) anywhere in the risk treatment plan, and both are excluded from the SoA without justification, that is a gap worth raising.
This check requires you to have some contextual knowledge of the organisation. Use what you know from the scope, the context of the organisation documentation, and your understanding of the business to identify areas where you would expect certain controls to feature.
Interview Questions That Reveal the Real Story
Document review alone will not tell you whether the SoA reflects genuine decisions or was produced to satisfy the auditor. Your interview with the ISMS lead or information security manager is where you test the substance behind the documents.
Useful questions include:
- Walk me through how a risk treatment decision becomes an entry in the SoA. What is the process?
- When was the SoA last reviewed? What triggered that review?
- This control is marked as not applicable. Can you explain the reasoning behind that decision?
- The risk treatment plan references this control for three different risks. How is implementation progress tracked?
- If a new risk was identified tomorrow, how would it flow through to the SoA?
You are listening for evidence that the process is understood and followed, not just that the documents exist. An ISMS lead who can answer these questions confidently and consistently with the documentation is giving you assurance. One who cannot is telling you something important about the maturity of the system.
Common Findings and How to Classify Them
Minor Nonconformity
Version inconsistencies between the risk treatment plan and the SoA where the substance is the same but the documents have not been formally reconciled. A small number of controls with weak but not absent justifications. Implementation status recorded slightly differently across the two documents without material impact.
Major Nonconformity
Controls selected in the risk treatment plan for high-rated risks that do not appear as applicable in the SoA. Controls excluded from the SoA where the risk assessment identifies a relevant unmitigated risk and no alternative control is documented. No evidence of management approval for either document. The SoA and risk treatment plan are so inconsistent that there is no demonstrable link between risk assessment and control selection.
Observation or Opportunity for Improvement
Controls marked as applicable but with generic justifications that do not reference specific risks or obligations. Implementation status fields left blank or marked as partially implemented with no target date or owner. No documented process for keeping the SoA current when the risk landscape changes.
For guidance on how to classify and write up findings clearly, the article on Risk Treatment and the Statement of Applicability: Clause 6.1.3 Demystified provides useful background on what the clause actually requires, which anchors your classification decisions.
Practical Tips From Real Audit Experience
A few observations from conducting these audits in practice:
The SoA is often a template that was never fully customised. Many organisations download a generic SoA template and fill in the minimum required fields without genuinely working through each control. You can usually spot this because the justifications are identical across multiple controls, or the implementation status fields are all marked the same way. Push into the details and the inconsistencies emerge quickly.
Risk treatment plans are frequently out of date. Organisations update their risk registers periodically but forget to update the risk treatment plan to reflect new decisions. The result is a risk treatment plan that references risks that have since been closed or controls that have since been replaced. Always check the date and ask when it was last reviewed.
Implementation status is often aspirational rather than factual. Controls marked as implemented in the SoA are sometimes only partially implemented, or implemented in some areas but not others. When you see a control marked as implemented, ask for evidence. A policy document that has not been communicated to staff, or a control that exists in the ISMS documentation but is not followed in practice, is not implemented in any meaningful sense.
The link between documents is often in someone’s head, not on paper. Smaller organisations in particular often have one person who understands how everything connects but has not documented the linkage. That creates a key-person dependency and a risk that the next auditor, or the next ISMS lead, will not be able to follow the thread. Raise this as an observation if the linkage is real but undocumented.
If you are developing your skills in auditing information security management systems, the Auditing the Risk Assessment: Is It Repeatable, Owned and Documented? article covers the upstream step that feeds into the risk treatment plan, which is essential context for this audit task.
When You Are Auditing as an Internal Auditor vs a Lead Auditor
The approach described above applies whether you are conducting an internal audit or acting as a lead auditor on a certification or surveillance audit. The depth of your sample and the consequences of your findings differ, but the logic is the same.
As an internal auditor, your role is to give management an honest picture of whether the SoA and risk treatment plan are genuinely aligned. You have the advantage of knowing the organisation, which helps you identify areas where the risk landscape has changed. Use that knowledge to direct your sample toward the areas most likely to reveal gaps.
As a lead auditor conducting a certification or surveillance audit, you are assessing conformity against the standard. Your findings carry direct consequences for the certification decision. Be precise in how you reference the clause and be specific about the evidence you reviewed. Vague findings are harder to close and create disputes that could have been avoided.
The article on Auditing ISMS Operations: What to Sample Under Clause 8 is a useful companion read if you are planning a broader ISMS audit and want to coordinate your Clause 6 and Clause 8 sampling.
Exemplar Global Certified Training ProviderRTP No. 310970Keeping the SoA Current: What Good Practice Looks Like
As an auditor, you are not there to tell the organisation how to run its ISMS. But understanding what good practice looks like helps you recognise its absence.
Organisations with mature information security management systems treat the SoA as a living document. It is reviewed whenever the risk assessment is updated, whenever a significant change occurs to the business or its technology environment, and at least annually as part of the management review cycle. The risk treatment plan and SoA are updated together, not independently. Control owners are identified and accountable for implementation status. The SoA is version-controlled and the approval record is maintained.
When you see these practices in place, your audit of the SoA against the risk treatment plan will be straightforward. When you do not, the audit becomes more interesting and more valuable.
Building This Skill as Part of Your Auditor Development
Auditing the SoA against the risk treatment plan is a skill that takes practice. The first time you do it, you will likely spend more time than you expect working through the logic of the connection. With experience, you develop a feel for where the gaps tend to appear and which questions cut to the heart of the matter quickly.
If you are working toward ISO 27001 internal auditor or lead auditor credentials, this is exactly the kind of practical skill that structured training should develop. At Audit Workshop, the ISO 27001 Internal Auditor and Lead Auditor courses cover ISMS audit techniques including how to review and cross-reference the SoA and risk treatment plan in a real audit context. The training is delivered by auditors with hands-on certification audit experience, so the scenarios reflect what you will actually encounter rather than what the theory suggests you might.
You can explore the available ISO 27001 training options at auditworkshop.com.
