ISO 27001:2022 Clause 8.2: Information Security Risk Assessment

ISO27001-2022 Clause 8.2 Information Security Risk Assessment

The Definitive Governance Requirement.

Clause 8.2 mandates that you perform information security risk assessments at planned intervals and when significant changes occur. It is the enforcement mechanism that prevents your Risk Register from becoming a “static artifact” (shelf-ware). You built the engine in Clause 6.1.2; Clause 8.2 requires you to turn it on and run it.

The Mandate

Many organizations confuse Clause 6.1.2 (Defining the Methodology) with Clause 8.2 (Executing the Assessment).

  • Clause 6.1.2 is the Rulebook. It defines how you calculate risk.
  • Clause 8.2 is the Schedule. It dictates when you calculate risk.

The standard requires execution under two specific conditions:

  1. Planned Intervals: You must assess risk on a schedule (e.g., Annually or Quarterly).
  2. Significant Changes: You must assess risk when the environment shifts (e.g., A merger, a new product launch, or a migration to the Cloud).

The Verdict: If your last Risk Assessment is dated three years ago, you are compliant with Clause 6.1.2 (you have a methodology) but you have failed Clause 8.2 (you aren’t using it). You are non-compliant.

The Implementation Strategy

Do not treat risk assessment as a “once-a-year” panic before the audit. It must be a living process.

  1. The Annual Baseline: Schedule a full refresh of the Risk Register annually. Review every threat and vulnerability. Has the likelihood changed? Has the impact increased?
  2. The “Trigger” Protocol: Define what constitutes a “Significant Change.” Does a new office opening trigger a review? Does a new CISO trigger a review? Define the triggers in your policy.
  3. Retain Documented Information: You must keep the results of the risk assessment. An email saying “we checked it” is insufficient. You need a dated report showing the scores.

The Auditor’s Trap

[The Auditor’s View] The most common Major Non-Conformance here is “The Static Register.” I often see a Risk Register created during the initial implementation (Year 1) that remains untouched in Year 2 and Year 3. If the date on your Risk Assessment is older than 12 months, or if you have deployed a new ERP system without a corresponding risk entry, you have failed.

Required Evidence

An auditor looks for currency and validity.

  • Dated Risk Assessment Reports: Evidence of the “Planned Interval” reviews.
  • Project Risk Assessments: Specific assessments conducted during major changes (e.g., “Cloud Migration Risk Review”).
  • Risk Register Version History: A log showing that risk scores have moved up or down over time, proving active management.

Strategic Acceleration

Performing a manual re-assessment of hundreds of risks is administratively heavy. You need a tool that allows for “Delta Reviews”—assessing only what has changed.

The Hightable™ Risk Dashboard allows you to schedule reviews and triggers alerts when assessments are due. It creates the audit trail automatically, so you never miss a planned interval.

The Next Move: Deploy the Risk Dashboard