Must the score change after every risk review?

No. If the assumptions checked remain valid, the assessment can stand. Document the trigger, information reviewed, result and next review trigger.

When should we review outside the regular schedule?

When the assessment basis may have changed, for example through new usage, a supplier change, incidents or failed tests. First check the specific impact on your organisation.

Can completing a measure automatically reduce the risk?

A completion status alone does not demonstrate effectiveness. Check the result and justify any change using your defined assessment method.

ISMS risk review: When do you need to reassess?

A risk needs review when the basis of its assessment no longer holds. That may be the scheduled review date, but it can also be a new supplier, a failed test or a changed use case. Do not wait for the annual review in those circumstances.

A review starts by checking. It does not necessarily produce a different risk level. What matters is whether the existing assessment and treatment remain justified.

What is the difference between review and reassessment?

During a review, you check the existing assessment against current information. A reassessment changes that judgement when its basis has changed. Both should be traceable: what was checked, with what result and by whom?

NIST SP 800-30 describes maintaining a risk assessment as an ongoing step. New monitoring information should feed into the assessment, including treatment effectiveness and changes to systems and their environment. NIST SP 800-30, section 3.4

An unchanged score can therefore be a meaningful outcome. An unchanged score without a review says little about the current situation. If your assessment criteria are not yet defined, start with the risk matrix and worked example.

Which events should trigger a review?

Define triggers where changes become known: in operations, procurement, projects and among business process owners. This table is a suggested working approach, not an exhaustive requirement of a standard.

Trigger	What to check
A service is used for another business process	Are impact, data scope and dependencies still described correctly?
A supplier or subcontractor changes	Do assumptions about service, access and recovery still hold?
A security incident or near miss occurs	Was the scenario underestimated, or was an effective measure missing?
A relevant vulnerability becomes known	Does it affect the version and configuration actually in use?
A measure is completed	Is there evidence of its effect under relevant conditions?
A test fails or evidence is missing	Is the assumed protection still justified?
A time-limited risk decision expires	Do its conditions and decision-making authority still apply?

Not every external report requires a complete reassessment of every risk. First establish whether you are affected and record why an event is relevant or irrelevant.

Review the assessment in five steps

1. Record the trigger and scope. Name the scenario, information asset or process and the specific change. “General review” offers little help later.

2. Compare assumptions. Which data, uses, dependencies and safeguards underpinned the previous assessment? Which still apply?

3. Check current evidence. A configured backup differs from a successfully tested restoration. Distinguish intended effect from demonstrated effect. Our guide to current, verifiable evidence explains how to assess suitability.

4. Justify the assessment. Apply the agreed method. Document changes to likelihood and impact, along with remaining uncertainty. Missing information is not evidence of low risk.

5. Update treatment and decisions. Add or adjust measures, owners and deadlines. Escalate any decision beyond your authority to the designated role. If the remaining risk is to be carried, record risk acceptance as a separate decision.

ISO describes an ISMS as an approach bringing together people, policies and technology and treating risks in a way that fits the organisation. Risk assessments should therefore also consider organisational changes. ISO/IEC 27001

Example: A secondary application becomes an important service

Fictional case: An application previously managed internal training appointments. A business unit now also uses it for binding customer appointments. The technology stays the same, but the consequences of an outage change.

During the review, the team finds that the previous impact assessment covers only internal use. It adds the new business process and checks which appointments would be affected by an interruption. The existing backup is known; a tested fallback procedure is missing.

The team reassesses the risk using the existing method and proposes a fallback procedure with a test. The responsible person decides on treatment and residual risk. A new number in the register alone would not have protected the customer appointment.

Retain the previous reasoning

A working record for this case could look like this. The roles are illustrative and must fit your organisation.

Change	Affected risk	Review question	Responsible	Documented result
Application now supports customer appointments	An outage prevents appointment handling	Do the assessment and fallback procedure cover the new use?	Process owners with IT and ISMS responsibility	New use assessed; fallback procedure and test proposed as treatment; decision outstanding

Do not overwrite a previous assessment in a way that loses its basis. Later comparison requires at least the trigger, date, method, previous and new assessments, evidence and decision.

If the method itself changes, values may no longer be directly comparable. Mark that break. A lower value on a new scale is not yet demonstrated improvement.

Set the next review trigger

Combine a planned date with specific events. For example: “Review again after the recovery test, no later than the scheduled review date.” Someone must be responsible for recognising and handling the trigger. If resources are missing or management must set priorities, prepare the result for the ISMS management review.

Kopexa’s risk management software connects assessment with work on measures. Evidence belongs to measures; measures are mapped to controls. This provides evidence of implementation. Whether that evidence sufficiently supports your risk judgement still requires subject-matter assessment.

A completed review leaves a reasoned assessment, a clear next action and another review trigger. That keeps a risk list useful beyond its initial creation.