ISO 27001 Clause 8.2: Risk Assessment

Clause 8.2 requires your organization to perform information security risk assessments at planned intervals or when significant changes occur - following the criteria established in Clause 6.1.2. This is where the risk methodology you defined during planning gets executed. The output feeds directly into risk treatment under Clause 8.3 and provides evidence for auditors that your ISMS is managing risks actively rather than on paper alone.

What the clause requires

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

The organization shall retain documented information of the results of the information security risk assessments.

Two requirements, clearly stated:

1. Perform risk assessments according to the methodology and criteria defined under Clause 6.1.2 - at regular intervals and when triggered by changes
2. Retain documented results as evidence of the assessment

The clause is short because the methodology is defined elsewhere (6.1.2). Clause 8.2 is about execution - actually running the assessments and recording the outcomes.

How to implement risk assessments

Define assessment frequency

Most organizations perform a full risk assessment annually, aligned with the management review cycle. But the standard also requires assessments when significant changes occur. Define what “significant change” means for your organization. Common triggers include:

• Major infrastructure changes (cloud migration, new data center, platform switch)
• Organizational changes (merger, acquisition, significant headcount change)
• New products or services that process different types of data
• Security incidents that reveal previously unidentified risks
• Regulatory changes that affect your obligations (new GDPR guidance, NIS2 entering scope)
• Changes to the ISMS scope itself

Document the planned frequency and trigger criteria in your risk assessment procedure. This gives auditors a clear reference point for checking whether assessments happen when they should.

Follow your established methodology

Clause 8.2 explicitly references the criteria from 6.1.2. This means every risk assessment must follow the methodology you defined during the planning phase - the same likelihood and impact scales, the same risk acceptance criteria, the same approach to risk identification.

For a 20-person SaaS company using a simple risk matrix approach, a typical assessment cycle looks like:

1. Review the asset inventory - confirm which information assets are in scope and whether new assets have been added since the last assessment
2. Identify threats and vulnerabilities - for each asset, identify what could go wrong (threats) and what weaknesses could be exploited (vulnerabilities). Use sources like the ENISA Threat Landscape report for current threat intelligence.
3. Assess likelihood and impact - rate each risk using the scales defined in your methodology. A 5x5 matrix is common: likelihood from rare to almost certain, impact from negligible to critical.
4. Calculate risk levels - combine likelihood and impact to produce a risk score. Compare against your risk acceptance threshold.
5. Determine treatment - for risks above the acceptance threshold, decide on treatment: mitigate (apply controls), transfer (insurance, outsourcing), avoid (stop the activity), or accept (with justification).
6. Document everything - record each risk, its assessment, and the treatment decision in your risk register.

Maintain a risk register

The risk register is the primary output of Clause 8.2. It should capture, at minimum:

• Risk ID - unique identifier for tracking
• Risk description - what could happen, to what asset, and the potential consequence
• Risk owner - who is accountable for managing this risk
• Likelihood rating - per your defined scale
• Impact rating - per your defined scale
• Risk level - the calculated score
• Treatment decision - mitigate, transfer, avoid, or accept
• Current controls - what is already in place to address this risk
• Residual risk - the risk level after treatment

For a small organization, a well-structured spreadsheet works. Compliance platforms like Vanta or Eramba provide built-in risk registers with workflow features. The tool matters less than the consistency and completeness of the data.

Handle change-triggered assessments

When a significant change triggers an assessment, you do not always need to reassess every risk. Focus on the risks affected by the change. A cloud migration warrants reassessing infrastructure and data processing risks but may not affect physical security risks at the office.

Document the trigger (what changed), the scope of the reassessment (which risks were reviewed), and the outcome (any new risks identified, any risk ratings changed, any treatment decisions updated). This targeted approach is efficient and defensible during audits.

Connecting 8.2 to the rest of your ISMS

Clause 6.1.2 connection. Clause 6.1 defines the risk assessment methodology and criteria. Clause 8.2 executes that methodology. If 6.1.2 says you use a 5x5 risk matrix with specific likelihood definitions, every 8.2 assessment must use those same definitions. The methodology is the plan; 8.2 is the action.

Clause 8.1 connection. Operational planning establishes the process framework for running the ISMS. Risk assessment is one of the key processes that 8.1 governs - with defined criteria (assessment frequency, triggers) and controls (the methodology, the risk register).

Clause 8.3 connection. Risk treatment takes the output of 8.2 and acts on it. Risks identified and assessed under 8.2 flow into the risk treatment plan under 8.3. The two clauses form a continuous cycle: assess risks, treat them, reassess to check whether treatment was effective.

Clause 9.3 connection. Management review requires reporting on risk assessment results. The risk register and any changes since the last review should be part of the management review agenda, giving leadership visibility into the organization’s risk posture.

CIA Triad connection. Every risk in your register ultimately threatens one or more aspects of the CIA triad - confidentiality, integrity, or availability. Structuring risks around these three dimensions helps ensure comprehensive coverage and clear communication with stakeholders.

What auditors check

Assessment frequency. Auditors verify that risk assessments happen at the intervals defined in your procedure. If your procedure says “annually,” they check for annual assessment records. Missing a planned assessment is a straightforward nonconformity.

Trigger-based assessments. Auditors look for significant changes that occurred between planned assessments and check whether those triggered a risk reassessment. A major infrastructure migration with no corresponding risk review raises questions.

Methodology consistency. Auditors compare your 8.2 assessment records against the methodology defined in 6.1.2. If your methodology defines a 5x5 matrix but your risk register uses a 3x3, that is an inconsistency. If your likelihood definitions are not applied consistently across risks, that signals a process problem.

Risk register completeness. Auditors sample risks from the register and check whether they have all required fields - owner, rating, treatment decision, residual risk. Incomplete entries suggest the assessment was not thorough.

Version history. Auditors compare current and previous risk assessments to see how the risk landscape changed. If the risk register looks identical year after year despite organizational changes, auditors question whether the assessment is a genuine exercise or a copy-paste formality.

Common mistakes to avoid

Copy-paste assessments. The most damaging pattern. Organizations copy last year’s risk register, update the date, and call it done. Auditors catch this immediately by comparing versions. Every assessment should genuinely re-evaluate risks based on current context.

No trigger-based assessments. Many organizations run annual assessments but never perform change-triggered ones. If the organization migrated to a new cloud provider, launched a new product, or experienced a significant incident mid-year without a corresponding risk review, that is a gap.

Inconsistent methodology application. Risk ratings that vary wildly between assessors suggest the methodology is not well understood or consistently applied. Calibration sessions - where the team assesses sample risks together to align on ratings - help maintain consistency.

Risk registers that never change. A static risk register suggests the organization is not learning from incidents, audit findings, or changes in the threat landscape. Risks should be added, removed, and re-rated as the organization evolves.

Separating risk assessment from risk treatment. Some organizations treat 8.2 and 8.3 as disconnected activities. Every risk above the acceptance threshold should have a clear treatment decision, and that decision should be tracked through to implementation. Assessment without follow-through is incomplete.

How 27kay can help

We help organizations build risk assessment processes that produce genuine insight - not just audit artifacts. As part of ISO 27001 implementation, we design the risk methodology, facilitate the first assessment, build the risk register, and train your team to run future cycles independently. For the full picture, see our ISO 27001 knowledge hub.

Need help running your next risk assessment or preparing for a surveillance audit? Get in touch - we will review your current approach and identify where it needs strengthening.