Auditing the Risk Assessment and the Statement of Applicability

Auditing the Risk Assessment and the Statement of Applicability (ISO/IEC 27001 Lead Auditor)

Introduction
Auditing the information security risk assessment and the Statement of Applicability (SoA) is one of the most important activities in any ISO/IEC 27001 certification or internal audit. These two elements are the engine of the Information Security Management System (ISMS). The risk assessment decides which risks matter. The SoA records which controls the organization has chosen to treat those risks, and why. If either is weak, the whole ISMS rests on an unreliable foundation. Lead Auditor exams therefore test this topic heavily, usually through scenario-based questions.

Why It Is Important
1. Risk-based thinking is the core of ISO/IEC 27001. Unlike a fixed checklist standard, ISO/IEC 27001 requires organizations to select controls based on their own risks. Clauses 6.1.2 (risk assessment), 6.1.3 (risk treatment), 8.2 and 8.3 make this mandatory.
2. The SoA is a mandatory documented output. It links the risk treatment plan to Annex A. Certification bodies use it to define what is actually being certified, and it often appears on or is referenced by the certificate.
3. Justification of exclusions. An organization cannot simply ignore Annex A controls. Every inclusion and exclusion must be justified. Auditors must verify this to prevent inappropriate scoping-out of controls.
4. Consistency and repeatability. Clause 6.1.2 b) requires that repeated risk assessments produce consistent, valid and comparable results. Auditors confirm this so that risk decisions are not arbitrary.
5. Management accountability. Risk owners must approve the risk treatment plan and accept residual risks (6.1.3 f). This shows top management involvement, as required by Clause 5.
6. Audit planning depends on it. Auditors use the risk assessment and SoA to sample controls, focus on high-risk areas and plan audit trails.

What It Is
The Information Security Risk Assessment (Clause 6.1.2 and 8.2)
The organization must define and apply a risk assessment process that:
a) establishes and maintains risk criteria, including risk acceptance criteria and criteria for performing risk assessments;
b) ensures repeated assessments produce consistent, valid and comparable results;
c) identifies risks associated with the loss of confidentiality, integrity and availability within the ISMS scope, and identifies risk owners;
d) analyses risks by assessing potential consequences and realistic likelihood, and determining levels of risk;
e) evaluates risks by comparing results against the criteria and prioritizing them for treatment.
The organization must retain documented information about the process (6.1.2) and the results (8.2). Risk assessments must be performed at planned intervals or when significant changes occur (8.2).

Risk Treatment (Clause 6.1.3 and 8.3)
The organization must select treatment options (modify, avoid, share or retain risk) and determine all necessary controls. It must then compare these controls with Annex A to verify that no necessary controls have been omitted. It must produce the SoA, formulate a risk treatment plan, and obtain risk owners' approval of the plan and acceptance of residual risks.

The Statement of Applicability (Clause 6.1.3 d)
The SoA must contain:
- the necessary controls (whether from Annex A or other sources);
- the justification for their inclusion;
- whether the necessary controls are implemented or not;
- the justification for excluding any Annex A controls.
In ISO/IEC 27001:2022, Annex A contains 93 controls in four themes: Organizational (37), People (8), Physical (14) and Technological (34).

How It Works: The Audit Approach
Step 1: Stage 1 Audit (Documentation Review and Readiness)
- Review the documented risk assessment methodology. Check that it defines criteria, scales, acceptance thresholds and roles.
- Confirm that a risk assessment has actually been performed and that results are retained.
- Review the SoA for completeness: all Annex A controls must be addressed, with justification and implementation status.
- Check the version, date and approval of the SoA.
- Identify concerns, such as unjustified exclusions, that could cause a nonconformity at Stage 2.

Step 2: Stage 2 Audit (Implementation and Effectiveness)
a) Audit the methodology in practice
- Interview the risk manager and risk owners. Ask how risks are identified and how likelihood and impact are scored.
- Re-perform or sample risk calculations to verify that the defined criteria were applied consistently.
- Check that the assessment covers the full ISMS scope, including interested parties and issues from Clauses 4.1 and 4.2.
b) Verify risk ownership
- Each risk should have a named owner with appropriate authority.
- Confirm that risk owners approved the treatment plan and formally accepted residual risks.
c) Trace risks to controls (the audit trail)
- Forward trace: select a high risk, follow it to its treatment decision, then to the selected controls in the SoA, then to evidence of implementation.
- Backward trace: select an implemented control or an SoA entry, and trace it back to the risk or requirement that justifies it.
- Check that excluded controls are genuinely unnecessary. For example, if teleworking is excluded but staff work remotely, that is a finding.
d) Verify implementation status
- If the SoA says a control is implemented, gather objective evidence through records, observation and interviews.
- If a control is marked as planned, verify that the risk treatment plan has timelines and responsibilities.
e) Verify currency
- Check that risk assessments are repeated at planned intervals and after significant changes, such as new systems, mergers, cloud migration or incidents.
- Compare the dates of the risk assessment, the risk treatment plan and the SoA for consistency.
f) Link to other clauses
- Check Clause 9.3 management review inputs for risk assessment results and treatment plan status.
- Check that Clause 10.2 corrective actions trigger a risk reassessment where appropriate.

Typical Nonconformities
- No defined risk acceptance criteria (6.1.2 a).
- Risk scores applied inconsistently between departments (6.1.2 b).
- Risks without assigned owners (6.1.2 c).
- Risk assessment covering only IT assets and ignoring processes, people or suppliers in scope.
- An SoA that lacks justifications for inclusion or exclusion (6.1.3 d).
- An SoA stating controls are implemented when there is no evidence.
- Residual risks not accepted by risk owners (6.1.3 f).
- Risk assessment not updated after a significant change (8.2).
- Controls excluded simply because they are difficult or costly, while related risks exist.
- An SoA inconsistent with the risk treatment plan.

Grading Findings
- Major nonconformity: absence or total breakdown of a requirement. Examples: no risk assessment performed, no SoA, or a systemic failure to apply the methodology.
- Minor nonconformity: an isolated lapse. Examples: one risk lacking an owner, or one missing exclusion justification.
- Opportunity for improvement: the requirement is met but could be better, such as an unclear threat catalogue.

Key Points Auditors Must Remember
- ISO/IEC 27001 does not prescribe a specific methodology. Asset-based, scenario-based, ISO/IEC 27005 and ISO 31000 approaches are all acceptable if they meet 6.1.2.
- Annex A is a reference list, not a mandatory checklist. However, every control must be considered and addressed in the SoA.
- Organizations may add controls from other sources, such as NIST or sector standards. These should appear in the SoA too.
- Excluding an Annex A control is acceptable only with valid justification. Excluding a Clause 4 to 10 requirement is never acceptable.
- The auditor evaluates conformity of the process. The auditor does not perform the risk assessment for the client or judge whether they chose the auditor's preferred controls.
- Auditors must remain impartial and must not act as consultants. They must not recommend specific risk scores or controls.

Exam Tips: Answering Questions on Auditing the Risk Assessment and the Statement of Applicability
1. Know the clause numbers. Memorize 6.1.2 (risk assessment), 6.1.3 (risk treatment and SoA), 8.2 (performing risk assessment), 8.3 (implementing risk treatment) and 5.3 (roles). Exam answers that cite the correct clause score higher.
2. Memorize the four SoA elements. These are: necessary controls, justification for inclusion, implementation status, and justification for exclusion. Many questions present an SoA missing one of these.
3. Look for the evidence trail in scenarios. When a scenario describes a risk, ask yourself whether there is a treatment decision, a control in the SoA, evidence of implementation, and owner approval. A break anywhere in this chain is the likely finding.
4. Watch for contradictions. Exam writers often hide inconsistencies. Examples include excluding cryptography while the scenario mentions encrypted laptops, or excluding supplier controls when cloud providers are used. Spot the mismatch.
5. Do not over-grade. A single missing owner is typically a minor nonconformity. No risk assessment at all is a major one. Justify your grading by explaining the impact on the ISMS's ability to achieve its intended outcomes.
6. Write findings in the proper structure. State the requirement (clause), the evidence (what you saw, where, who), and the nonconformity statement (how the evidence fails the requirement). Keep the language factual, objective and non-judgmental.
7. Remember the methodology freedom. If a question suggests a finding because the organization did not use ISO/IEC 27005, that is incorrect. The standard does not mandate a method.
8. Distinguish auditor and consultant roles. Answers recommending that the auditor rewrite the risk register or choose controls are wrong. The auditor reports findings, and the auditee determines corrections and corrective actions.
9. Consider timing and change. If a scenario mentions a major change, such as an acquisition, a new data center or a new remote working policy, check whether the risk assessment was updated (8.2). This is a frequent exam trap.
10. Link to Stage 1 versus Stage 2. At Stage 1, focus on documented methodology and SoA existence and adequacy. At Stage 2, focus on implementation, effectiveness and sampling evidence. Exams often ask what to check at each stage.
11. Use sampling logic. When asked how to audit, mention selecting a representative sample of high, medium and low risks and tracing them in both directions. Also mention interviewing risk owners, not just the ISMS manager.
12. Remember residual risk acceptance. Questions frequently test whether residual risks above the acceptance threshold were formally accepted by the appropriate risk owner. Acceptance by an unauthorized person is a finding.
13. Apply the 2022 version. Annex A has 93 controls in 4 themes, aligned with ISO/IEC 27002:2022. If an SoA still references 114 controls without a transition, consider the transition requirements and the period of validity.
14. Read every word of multiple-choice options. Words like 'must', 'all' and 'always' often signal incorrect answers. For example, 'all Annex A controls must be implemented' is false, while 'all Annex A controls must be considered' is true.
15. Structure essay answers. Use a clear flow: purpose of the audit activity, requirements, audit method (document review, interviews, observation, sampling), evidence expected, possible findings and grading.

Sample Exam Question and Model Answer
Question: During a Stage 2 audit, you find that the SoA excludes control 5.23 (Information security for use of cloud services) with the justification 'not applicable'. During interviews, the HR manager mentions that payroll is processed on a SaaS platform. What should you do?
Model answer: This is a potential nonconformity against Clause 6.1.3 d), because the justification for exclusion is invalid given the evidence of cloud use. It may also indicate a failure in 6.1.2 c), since cloud-related risks were not identified. I would verify the evidence by checking supplier contracts and the risk register. I would then record a nonconformity with the requirement, the objective evidence and the statement of nonconformity. If the failure is isolated, I would grade it minor. If many cloud services are unassessed, indicating a systemic risk identification failure, I would grade it major. The auditee is responsible for the correction and corrective action.

Summary
Auditing the risk assessment and SoA means verifying three things. First, the organization has a defined, consistent and repeatable risk process. Second, that process has been applied across the whole scope with accountable risk owners. Third, the resulting control decisions are fully justified, documented in the SoA and actually implemented. In exams, show clause knowledge, follow the audit trail, spot inconsistencies, grade findings proportionately and stay within the auditor's impartial role.