Why ISO 27001 Clause 8.2 Makes You Repeat the Risk Assessment

The Clause That Keeps Coming Back

If you have been working with ISO 27001 for any length of time, you have probably noticed something about Clause 8.2. It does not introduce a new risk assessment methodology. It does not ask you to build a fresh framework from scratch. What it does is tell you to actually perform the risk assessment you already designed under Clause 6.1.2, and to do it again at planned intervals, or whenever significant changes occur.

That repetition is intentional. And it is one of the most misunderstood requirements in the entire standard.

This article explains what Clause 8.2 actually requires, why organisations routinely get it wrong, what auditors look for when they examine it, and how to structure your risk assessment cycle so it genuinely supports your information security management system rather than just filling a compliance box.

What Clause 8.2 Actually Says

The clause is short. ISO 27001:2022 states that the organisation shall perform information security risk assessments at planned intervals or when significant changes are proposed or occur, taking account of the criteria established in Clause 6.1.2.

That is essentially it. No lengthy sub-clauses. No elaborate documentation requirements spelled out in detail. Just a clear instruction: do the risk assessment, do it on a schedule, do it when things change, and do it the same way you said you would.

The brevity can be misleading. Because the clause is short, some organisations treat it as a minor procedural step. Tick the box, update the date on the risk register, move on. That approach will not satisfy a competent auditor, and it will not protect your organisation either.

The Relationship Between Clause 6.1.2 and Clause 8.2

To understand Clause 8.2, you need to understand what Clause 6.1.2 sets up. During planning, your organisation is required to define a risk assessment process that includes consistent, valid and comparable criteria for accepting risks and for performing assessments. You also need to identify information security risks, analyse them, and evaluate them against your acceptance criteria.

Think of Clause 6.1.2 as the blueprint and Clause 8.2 as the construction requirement. You cannot build without a blueprint, and a blueprint that never gets used is worthless.

The phrase taking account of the criteria established in Clause 6.1.2 in Clause 8.2 is doing significant work. It means your operational risk assessments must follow the methodology you documented during planning. You cannot invent a new approach at assessment time. You cannot use a different risk matrix. You cannot change your likelihood or consequence scales between cycles without updating your documented process first.

This is where many organisations stumble. They design a risk assessment methodology during implementation, then gradually drift away from it as the years pass. By the time an auditor arrives for a surveillance audit, the risk register looks nothing like what the procedure describes.

What Does Planned Intervals Actually Mean?

The standard does not specify how often you must repeat the risk assessment. That is a deliberate choice. The appropriate frequency depends on your organisation, your sector, the pace of change in your environment, and the nature of the information assets you are protecting.

In practice, most organisations settle on an annual cycle as a minimum. Some higher-risk environments, such as financial services, healthcare, or critical infrastructure, run assessments more frequently. Some organisations tie their risk assessment cycle to their management review schedule, which makes sense because the outputs of the risk assessment are directly relevant to management review inputs.

What auditors want to see is evidence that you have actually defined your planned intervals somewhere in your documented information, and that you have followed them. If your procedure says annually and you last ran the assessment 22 months ago, that is a nonconformity. If your procedure says annually but your last assessment was triggered by a system migration six months ago and you are due for the scheduled one next month, that is fine. The key is that the schedule is defined and followed.

For more on how to structure your ISMS documentation requirements, the article on documented information in an ISMS under Clause 7.5 covers what you need to retain and maintain across the system.

Significant Changes: The Trigger That Gets Ignored

The second trigger for a Clause 8.2 assessment is significant changes, whether proposed or occurring. This is the part of the clause that organisations most consistently fail to operationalise.

A significant change in the context of an ISMS might include:

• Migrating systems or data to cloud infrastructure
• Acquiring a new business or integrating a new team
• Introducing a new software application that handles personal or sensitive data
• Changing key personnel in roles with privileged system access
• Entering a new market or jurisdiction with different regulatory requirements
• A significant incident or near-miss that reveals a previously unidentified threat
• A major change to your supply chain or third-party service providers

The challenge is that organisations often handle these changes operationally without looping back to the risk assessment. The IT team migrates a database to a new cloud provider. The project is managed, the migration is tested, and the system goes live. But nobody updates the risk register to reflect the new threat landscape associated with that cloud environment.

When an auditor asks to see evidence that the risk assessment was performed following the cloud migration, the answer is often a blank stare or a reference to the last scheduled assessment that predates the change by 18 months.

This is not just an audit problem. It is a genuine security gap. Changes in your operating environment change your risk profile. If your risk assessment does not reflect current reality, your controls cannot be appropriately targeted.

What Auditors Actually Check Under Clause 8.2

When auditing Clause 8.2, a competent auditor is not simply looking for a risk register with a recent date. They are verifying a chain of evidence that connects your documented methodology to your actual practice.

Is the risk assessment methodology being followed?

The auditor will compare your risk assessment procedure or methodology document against the current risk register. Are the same risk categories being used? Is the same scale applied for likelihood and consequence? Are assets, threats and vulnerabilities identified in the way the procedure describes? Inconsistencies between the methodology and the register are a common finding.

Is the assessment current?

The auditor will check the date of the most recent assessment against your defined schedule. They will also probe whether any significant changes have occurred since the last assessment and whether those changes triggered a reassessment. This often involves interviewing the ISMS manager or information security team about recent projects, system changes, or incidents.

Is there retained evidence?

Clause 8.2 explicitly requires that documented information about the results of the information security risk assessment be retained. This is not optional. The risk register itself is the primary evidence, but auditors will also look for records of who conducted the assessment, when it was conducted, what information was used as input, and how the outputs were reviewed and approved.

Are the outputs connected to treatment?

The risk assessment does not exist in isolation. Its outputs feed directly into Clause 8.3, which requires a risk treatment plan. Auditors will trace the connection between identified risks and the controls selected to treat them. If high-rated risks appear in the register with no corresponding treatment decisions, that is a problem. For a detailed look at how that treatment process works, the article on implementing the risk treatment plan under Clause 8.3 walks through the requirements in practice.

The Comparability Requirement: Often Overlooked, Always Tested

One of the most specific requirements in Clause 6.1.2, which flows directly into how Clause 8.2 assessments must be conducted, is that the process produces comparable and reproducible results.

This means two things in practice. First, if two people independently assessed the same risk using your methodology, they should arrive at broadly similar ratings. Second, if you assess the same risk in this year's cycle and next year's cycle, the results should be comparable enough to identify genuine changes in your risk profile rather than just variations in how the assessor was feeling that day.

Many organisations use risk matrices that are so loosely defined that the results are essentially subjective. A likelihood rating of three out of five might mean anything from this has happened once in the industry to this happens to us quarterly, depending on who is doing the assessment. When the methodology is that vague, the results are neither comparable nor reproducible.

Auditors testing this requirement will often ask the ISMS manager to walk them through how a specific risk was rated. They want to hear reasoning grounded in the methodology, not gut feel. If the answer is we just felt it was medium, that is a signal that the process is not producing comparable results.

Common Nonconformities Under Clause 8.2

Based on audit practice across a range of organisations, these are the findings that come up most consistently against Clause 8.2:

• Outdated risk register: The last assessment is older than the defined review interval, with no documented justification for the delay.
• No change-triggered assessment: A significant system change, restructure, or incident occurred but did not trigger a risk reassessment.
• Methodology drift: The risk register uses different scales, categories, or formats than the documented procedure.
• Missing retained evidence: The risk register exists but there is no record of who conducted the assessment, when, or on what basis.
• Disconnected treatment: Risks are rated but there is no clear link to treatment decisions or Annex A control selection.
• Approval gaps: The risk assessment was performed but never formally reviewed or approved by appropriate personnel.

Building a Risk Assessment Cycle That Actually Works

The goal is not to produce a document that satisfies an auditor once a year. The goal is to maintain a living understanding of your organisation's information security risk profile so that your controls remain relevant and proportionate.

Here is what a practical, well-functioning Clause 8.2 cycle looks like in organisations that do it well.

Define your schedule clearly

Document your planned interval in your ISMS procedure. Most organisations choose annually, but some choose semi-annually or tie it to a specific event like the start of the financial year. Whatever you choose, write it down and stick to it.

Build change triggers into your change management process

Your change management procedure should include a step that asks: does this change affect our information security risk profile? If yes, a risk assessment update is required before the change is approved or implemented. This connects Clause 8.2 to your operational change process rather than treating it as a separate annual exercise.

Assign clear ownership

Someone needs to own the risk assessment process. That person is responsible for scheduling the annual review, identifying when change triggers apply, coordinating the assessment, and ensuring the outputs are documented and approved. Without clear ownership, the assessment drifts.

Keep your methodology stable

Resist the temptation to redesign your risk assessment approach every cycle. Stability in methodology is what makes results comparable over time. If you need to update the methodology, do it deliberately, document the change, and note in the risk register that the methodology was updated and how that affects comparisons with prior cycles.

Connect outputs to management review

The results of the risk assessment should be a standing input to your management review. This closes the loop between operational risk management and leadership oversight, which is exactly what the standard intends. The article on management review of an ISMS under Clause 9.3 explains what that review process needs to cover.

A Real Audit Scenario

Here is the kind of situation that comes up in practice. An organisation has an ISO 27001 certificate and is going through its second surveillance audit. The auditor asks to see the most recent risk assessment. The ISMS manager produces a risk register dated 14 months ago.

The auditor notes that the organisation migrated its primary CRM system to a cloud platform eight months ago. They ask whether a risk assessment was conducted as part of that migration project. The ISMS manager explains that the IT team ran a security review but it was not formally documented as a risk assessment update.

The auditor then asks to see the change management records for the migration. There is no documented step in the change process requiring a risk assessment update. The risk register still shows the old on-premise CRM system as an asset with its original risk ratings.

The result is a nonconformity against Clause 8.2. Not because the organisation failed to protect its data, but because the risk assessment process was not performed in accordance with the planned intervals and change triggers, and the retained documented information did not reflect the current state of the environment.

This is a fixable problem, but it requires connecting the risk assessment to how the organisation actually operates, rather than treating it as an annual paperwork exercise.

For Auditors: How to Audit Clause 8.2 Effectively

If you are auditing an ISMS, Clause 8.2 is one of the clauses where process-based questioning pays dividends. Do not just ask to see the risk register. Ask the ISMS manager to walk you through the last assessment cycle. Ask what triggered it. Ask who was involved. Ask how a specific risk was rated and why. Ask what changed since the previous assessment and how those changes were reflected.

Then cross-reference the risk register against other sources of information you have gathered during the audit. If you found evidence of a significant system change during your review of operational records, and the risk register does not reflect it, you have a finding.

The quality of the risk assessment is also worth probing. A risk register with 200 risks all rated medium is a signal that the methodology is not producing meaningful differentiation. A risk register with no high-rated risks in an organisation that handles significant volumes of personal data is worth questioning. The assessment should reflect reality, not just produce comfortable ratings.

For those building their skills in this area, auditing the risk assessment process covers the evidence to gather and the questions to ask when verifying that the process is repeatable, owned, and documented.

Why the Repetition Is the Point

The reason Clause 8.2 makes you repeat the risk assessment is not bureaucratic. It reflects a fundamental truth about information security risk: it changes. The threat landscape evolves. Your organisation changes. New vulnerabilities are discovered. Regulatory requirements shift. What was an acceptable risk two years ago may not be acceptable today.

A risk assessment that was done once during implementation and never revisited is not a risk assessment. It is a historical document. It tells you what the risks were, not what they are.

The standard is asking you to maintain a current, evidence-based understanding of your information security risk profile and to use that understanding to drive your control decisions. That requires repetition. That is the point.

If you are working toward ISO 27001 competence, whether as an internal auditor, an ISMS manager, or someone pursuing lead auditor credentials, understanding how operational requirements like Clause 8.2 connect to the broader ISMS framework is essential. At Audit Workshop, our ISO 27001 training covers exactly this kind of clause-level analysis, grounded in real audit practice rather than abstract theory. Whether you are building your internal audit skills or preparing for lead auditor certification, the courses are designed to give you the practical understanding you need to apply the standard with confidence.