Auditing the Risk Assessment: Is It Repeatable, Owned and Documented?

Why the Risk Assessment Is the Heart of an ISMS Audit

When you audit an Information Security Management System against ISO 27001, you can spend a lot of time checking policies, reviewing access controls, and sampling Annex A evidence. All of that matters. But if the risk assessment is broken, none of the rest holds together. The risk assessment is the mechanism that connects the organisation's context to its controls. If it is not credible, the Statement of Applicability is not credible, and the entire ISMS is built on uncertain ground.

Clause 6.1.2 of ISO 27001 sets out what the risk assessment process must do. Clause 8.2 requires that the process be carried out at planned intervals and whenever significant changes occur. Together, these two clauses give auditors a clear framework for evaluation. In practice, though, many organisations treat the risk assessment as a document they completed once during implementation and filed away. That is exactly the problem you are there to find.

This article walks through the three questions that should anchor your audit of the ISMS risk assessment: Is the process repeatable? Is it owned? Is it properly documented? Each question unlocks a different layer of evidence, and together they tell you whether the organisation is genuinely managing information security risk or simply maintaining the appearance of doing so.

What ISO 27001 Actually Requires

Before you can audit effectively, you need to be precise about what the standard asks for. Clause 6.1.2 requires the organisation to define and apply an information security risk assessment process that produces consistent, valid and comparable results. It must identify risks associated with the loss of confidentiality, integrity and availability of information within the ISMS scope. It must analyse and evaluate those risks against defined criteria. And it must retain documented information as evidence.

Clause 8.2 then requires the organisation to perform the risk assessment at planned intervals or when significant changes are proposed or occur. This is not optional. The word “shall” appears throughout, and certification auditors will treat any gap here as a potential major nonconformity.

The phrase that trips up many organisations is “consistent, valid and comparable results.” This is the standard's way of saying the process must be repeatable. If two people ran the risk assessment using the same inputs, they should arrive at similar conclusions. If the methodology is so vague that outcomes depend entirely on who is filling in the spreadsheet that week, the process does not meet the requirement.

For a deeper look at how the risk assessment connects to risk treatment and the Statement of Applicability, the article on risk treatment and the Statement of Applicability covers the linkage in detail.

Is the Risk Assessment Repeatable?

What repeatability actually means

Repeatability is about methodology, not outcomes. You are not asking whether the organisation identified the same risks as last time. You are asking whether the process they used could be followed by anyone in the organisation and produce a defensible result. This distinction matters because information security risks change. New assets appear, new threats emerge, and the organisation's context shifts. A repeatable process accommodates that change without producing arbitrary results.

Start your review by asking for the documented risk assessment methodology. This might be a procedure, a set of criteria, a scoring guide, or a combination. Whatever form it takes, it should answer four questions without ambiguity. How does the organisation identify information assets or risk scenarios? How does it assess likelihood? How does it assess impact? And how does it calculate or determine the overall risk level?

What to look for in the methodology

A credible methodology will have defined scales. Likelihood might be rated on a three point or five point scale, with each level described in concrete terms. Impact should be similarly defined, ideally with separate consideration of confidentiality, integrity and availability consequences. The risk level should be derived from these inputs in a consistent way, whether through a matrix, a formula, or another documented approach.

Where organisations commonly fall short is in the definitions. You might see a spreadsheet with columns for likelihood and impact, each rated one to five, but no explanation of what a three means versus a four. When you ask the risk owner how they decided on a particular score, they cannot explain it beyond “it felt right.” That is a repeatable process in form only. In substance, it is guesswork dressed up as methodology.

During the audit, ask to walk through a specific risk entry with the person responsible. Ask them to explain how they arrived at the likelihood rating. Then ask how that rating would change if a particular control were removed. If they can answer both questions clearly and consistently with the documented criteria, the methodology has real substance. If they hesitate or give answers that contradict the documented scale, you have found a gap worth noting.

Comparing results across assessment cycles

If the organisation has conducted more than one risk assessment, you have an opportunity to test comparability directly. Ask to see the previous version alongside the current one. Look for risks that have been removed or significantly re-rated without a documented rationale. A risk that was rated high in one cycle and medium in the next, with no change in the threat landscape or controls, suggests the ratings are not stable or comparable. That is precisely what the standard is trying to prevent.

Is the Risk Assessment Owned?

Ownership goes beyond a name on a document

One of the most common findings in ISMS audits is a risk assessment that exists on paper but has no genuine owner. There is usually a name attached to it, often the IT Manager or the Information Security Manager. But when you dig into what that person actually does with the risk register, the picture becomes less clear. They may have created it during the implementation project, reviewed it once, and not touched it since.

Real ownership means the person responsible understands the risks in their area, can explain the basis for each rating, knows when the assessment was last reviewed, and can tell you what triggered that review. It also means they have the authority and the means to initiate a reassessment when something changes. If the owner cannot describe any of these things, the ownership is nominal.

How to test ownership in an interview

When you sit down with the person identified as the risk assessment owner, resist the temptation to ask yes or no questions. Instead, ask open questions that require them to demonstrate knowledge. Ask them to describe the three highest-rated risks in the current assessment and explain why they are rated that way. Ask what has changed in the organisation since the last assessment and whether those changes prompted a review. Ask how they would go about adding a new risk if a significant change occurred tomorrow.

If the owner can answer these questions with specificity and confidence, ownership is real. If they need to pull up the spreadsheet just to recall what the risks are, or if they say they would need to check with the consultant who built the system, you are looking at a gap in ownership that has practical consequences for the ISMS.

Top management's role in ownership

Clause 5.1 of ISO 27001 requires top management to demonstrate leadership and commitment to the ISMS. One of the ways this shows up in the risk assessment is through the risk acceptance criteria. The standard requires the organisation to define criteria for accepting risks, and this is fundamentally a management decision. If top management has never been involved in setting or reviewing those criteria, or if they cannot describe what the organisation's risk appetite looks like, that is a leadership gap that connects directly to the risk assessment process.

Ask to see the documented risk acceptance criteria. Then ask who approved them and when. If the answer is that they were set by the consultant during implementation and have never been revisited, that is worth exploring further. Risk appetite can and should evolve as the organisation changes. A set-and-forget approach to acceptance criteria is inconsistent with genuine risk management.

The article on auditing leadership evidence in an ISMS goes into more depth on what top management engagement actually looks like in practice.

Is the Risk Assessment Properly Documented?

What documented information the standard requires

Clause 6.1.2 explicitly requires documented information about the risk assessment process and its results. Clause 8.2 requires documented information on the results of the information security risk assessment. This is not a grey area. The organisation must be able to produce records that show the assessment was conducted, what it found, and how risks were evaluated.

In practice, this means you should be able to see a risk register or equivalent document that identifies the risks assessed, shows the methodology applied, records the likelihood and impact ratings, states the resulting risk level, and links each risk to a treatment decision. You should also be able to see evidence of when the assessment was conducted and who was involved.

Common documentation gaps

The most frequent documentation gap is not a missing risk register. Most organisations have one. The gaps tend to be more subtle. The register may not be version controlled, making it impossible to tell whether you are looking at the current version or an older one. It may not record the date of the last review. It may not capture the rationale for risk ratings, so there is no way to understand why a particular risk was rated as it was.

Another common gap is the absence of documented review records. The standard requires the assessment to be performed at planned intervals. If there is no record showing when reviews occurred and what was considered during each review, you cannot verify that the requirement has been met. A risk register with a single creation date and no subsequent version history is not evidence of an ongoing process. It is evidence of a one-time exercise.

Linking documentation to the Statement of Applicability

The risk assessment documentation does not stand alone. It feeds directly into the risk treatment plan and the Statement of Applicability. During the audit, trace a sample of risks from the register through to the treatment decisions and then to the corresponding Annex A controls in the Statement of Applicability. The chain should be clear and logical. If a risk is rated high but the treatment plan shows it as accepted with no compensating controls, that decision should be documented and justified.

If you find Annex A controls that are marked as applicable in the Statement of Applicability but cannot be traced back to a risk in the register, ask why. Either the risk assessment is incomplete, or controls have been selected without a risk basis. Both scenarios are worth exploring.

The article on checking the Statement of Applicability against the risk treatment plan provides a practical walkthrough of this traceability exercise.

Auditing the Clause 8.2 Requirement: Has the Assessment Been Repeated?

Planned intervals and significant changes

Clause 8.2 requires the risk assessment to be performed at planned intervals and when significant changes occur. Both conditions need to be audited separately. Start by asking what the organisation's planned interval is. It might be annual, biannual, or tied to the management review cycle. Whatever it is, it should be documented somewhere, and there should be evidence that it has been followed.

Then ask about significant changes. This is where many organisations fall short. They may conduct their annual review diligently but fail to trigger a reassessment when something significant happens. A new cloud platform, a major restructure, a significant data breach at a peer organisation, or a change in the regulatory environment can all constitute significant changes that warrant a review. If the organisation cannot point to any reassessments triggered by change events, either nothing significant has changed (which is unlikely) or the trigger mechanism is not working.

Practical audit questions for Clause 8.2

Ask the information security manager to describe the last three occasions when the risk assessment was reviewed. For each occasion, ask what prompted the review, who was involved, and what changed as a result. If all three reviews were scheduled rather than change-triggered, probe whether any significant changes occurred in the intervening periods that should have prompted an ad hoc review.

Also ask what the process is for identifying significant changes that should trigger a reassessment. Is there a formal change management process that feeds into the ISMS? Is someone responsible for monitoring for external threat intelligence and determining whether it warrants a review? A mature ISMS will have answers to these questions. A paper-based ISMS will not.

Putting It Together: What a Finding Looks Like

When to raise a nonconformity

Not every gap in the risk assessment warrants a nonconformity. An observation or opportunity for improvement might be appropriate where the methodology is broadly sound but lacks some definition, or where the documentation is adequate but could be more structured. Reserve nonconformities for situations where a clear requirement of the standard is not being met.

A major nonconformity is appropriate where the risk assessment has not been performed at all since implementation, where the process produces results that cannot be shown to be consistent or comparable, or where there is no documented evidence of the assessment results. A minor nonconformity might be appropriate where the process exists and has been applied but the documentation of rationale is absent, or where a planned review was missed by a significant period.

Writing the finding clearly

When you write a risk assessment finding, be specific. Reference the clause, describe what you observed, and state what was missing or inconsistent. Avoid vague language like “the risk assessment process needs improvement.” Instead, write something like: “The risk assessment register, last updated in March 2023, contains no record of a review following the organisation's migration to a new cloud infrastructure platform in November 2023, contrary to the requirement in Clause 8.2 to perform the risk assessment when significant changes occur.” That is a finding that tells the auditee exactly what happened and gives them a clear basis for corrective action.

For more on writing findings that hold up, the article on information security risk assessment provides useful background on what a sound assessment looks like from the inside.

Building Your Audit Approach for Risk Assessment

Before the audit, request the risk assessment methodology, the current risk register, the previous version of the risk register, the risk acceptance criteria, and the risk treatment plan. Review these documents before you arrive on site. Look for version control, review dates, and the traceability between risks and controls. Make a note of anything that is missing or unclear, and use those gaps to shape your interview questions.

On site, start with the information security manager or whoever owns the process. Use the three questions as your framework. Is it repeatable? Is it owned? Is it documented? Then trace a sample of risks through the system, from identification through to treatment and into the Statement of Applicability. Finish by asking about the review cycle and any recent changes that might have triggered a reassessment.

This approach gives you a complete picture of whether the risk assessment is a genuine, living part of the ISMS or a compliance artefact that was built once and forgotten.

Why This Matters Beyond the Audit

The risk assessment is not just an audit requirement. It is the mechanism by which the organisation decides where to invest in information security. If the assessment is not credible, those investment decisions are not grounded in reality. Controls may be over-engineered in areas of low risk and under-resourced in areas of high risk. Incidents that were foreseeable may not have been treated because the risk was never properly identified or rated.

As an auditor, your job is to test whether the process is real. That means going beyond the documents and asking the questions that reveal whether the methodology is understood, the ownership is genuine, and the documentation reflects what actually happened. When you do that well, you provide the organisation with something genuinely useful: an honest assessment of whether their risk management is working.

If you are looking to build your skills in auditing information security management systems, Audit Workshop offers ISO 27001 Internal Auditor and Lead Auditor training delivered by practitioners with real-world ISMS audit experience. The courses cover risk assessment auditing in depth, including how to test repeatability, ownership and documentation in live audit scenarios. You can explore the available courses at auditworkshop.com.