Risk Assessment Methodology Template: Scales, Criteria and Workflow

Most cyber risk ratings cannot be compared from one assessment to the next because nobody wrote down how likelihood, impact and acceptance were supposed to be decided. ISO/IEC 27001:2022 clause 6.1.2 expects documented risk criteria, including acceptance criteria and criteria for performing assessments, so that repeated assessments give consistent, valid and comparable results, and NIST CSF 2.0 subcategory GV.RM-06 asks for a standardised method for calculating, documenting, categorising and prioritising cyber risk. This template is that method document: when an assessment is triggered, the risk model, the likelihood and impact scales, the evaluation and acceptance thresholds, the step-by-step workflow, the confidence rating and the quality checks. It is for risk managers, GRC leads and CISOs who already know which approach they want and need a fillable methodology their assessors can follow. If you have not yet chosen an approach, start with the Risk Assessment Methods Compared guide; the register this method feeds is covered in the Risk Register Template.

How to use this template

• Replace text in square brackets, such as [Organisation], [Risk committee] and [£1m], with your own terms and values. "Must" is mandatory; "should" may be skipped with a recorded reason.
• All thresholds and band values are illustrative. Calibrate them once against your own loss history, business impact analysis and risk appetite statement, then freeze them for at least a year so ratings stay comparable.
• This document defines how to assess. The register defines where results are recorded. Keep the two aligned: the register columns must hold every output listed in section 8.
• The structure follows the four steps of NIST SP 800-30 Rev. 1 (prepare, conduct, communicate, maintain) and the criteria requirements of ISO/IEC 27005:2022, so it can serve an ISO/IEC 27001 ISMS or a NIST-based programme.
• Approve the whole document at [Risk committee]. Assessors must not change scales or thresholds locally.

1. Purpose

This methodology sets out how [Organisation] identifies, analyses and evaluates information and cyber security risks, so that:

• Any two trained assessors given the same scenario and evidence reach the same rating, or record why they differ.
• Ratings can be compared across business units, systems and years, and rolled up into the enterprise risk register.
• Every rating is tied to a decision: treat, accept, escalate or monitor, at a level of authority defined in section 7.

2. Scope and assessment triggers

The methodology applies to all assessments of risk to the confidentiality, integrity and availability of [Organisation]'s information, systems and services, including human identities, non-human identities (service accounts, API keys, tokens, certificates, workload identities), AI systems and agents, suppliers with access, cloud and SaaS.

An assessment must be performed:

NIST SP 800-30 Rev. 1 notes that a risk assessment is valid only for a bounded period and should be maintained across the system life cycle, which is why triggers, not just a calendar, drive reassessment here.

3. Roles and responsibilities

• [Risk committee]: approves this methodology, the scales and the acceptance thresholds; accepts risks above [High].
• Methodology owner ([Head of Cyber Risk]): maintains this document, trains assessors, runs calibration (section 10) and reports method changes.
• Assessor: facilitates the assessment, applies the scales, records evidence and confidence; must have completed [method training] in the last [24] months.
• Risk owner: a named senior manager who provides business context, confirms impact ratings and decides treatment within their authority.
• Subject matter experts: system owners, identity, cloud, threat intelligence and privacy staff who supply facts on threats, vulnerabilities and controls.
• Independent reviewer (second line or internal audit): samples completed assessments for quality (section 10).

4. Risk model and assessment approach

[Organisation] uses the NIST SP 800-30 Rev. 1 risk factors: a threat source initiates a threat event, which exploits a vulnerability or predisposing condition, producing an adverse impact; risk is a function of likelihood and impact. ISO/IEC 27005:2022 allows scenarios to be identified event-based (risk sources and scenarios) or asset-based (assets, threats and vulnerabilities); [Organisation] uses [event-based for Tier 1 and asset-based for Tier 3].

For quantitative analysis of selected scenarios, follow the FAIR Model and Open FAIR Standard Guide. Results must be mapped back to the impact bands in section 6 so they sit in the same register.

5. Likelihood scale

Likelihood is assessed over a [12-month] horizon and combines two judgements, as NIST SP 800-30 Rev. 1 describes: the likelihood that the threat event is initiated or occurs, and the likelihood that it results in adverse impact given current controls.

5.1 Likelihood of initiation (adversarial threats)

Rate capability, intent and targeting separately, then take the [median] of the three as the initiation score.

5.2 Likelihood of occurrence (non-adversarial events)

For errors, failures and environmental events, use frequency evidence: 5 = more than [once a year]; 4 = about once a year; 3 = once in [2 to 5] years; 2 = once in [5 to 10] years; 1 = less than once in [10] years. Cite incident records, supplier availability data or peer data as evidence.

5.3 Likelihood of adverse impact

Score how likely the event is to succeed against current controls: 5 = no effective control; 4 = controls exist but are untested or bypassable; 3 = one tested preventive control; 2 = layered preventive and detective controls, tested in the last [12] months; 1 = the event is technically prevented. A control counts only if there is evidence it operates, for example a test record, configuration export or audit result dated within [12] months.

5.4 Overall likelihood

Overall likelihood = the lower of the two scores in 5.1 (or 5.2) and 5.3, raised by one level where [three or more] internal or peer incidents of the same type occurred in the last [24] months. Record both component scores in the register so reviewers can see why the overall score was given.

6. Impact criteria

Rate impact for the realistic worst case of the scenario as written, after considering only controls that limit consequence (backups, segmentation, insurance excluded unless section 4 says otherwise). Score on the highest category affected, never the average.

The identity column exists because credential compromise rarely shows its full cost on day one. A leaked token for a CI pipeline or an over-scoped AI agent can reach production data long before money is lost; rating it on the financial column alone understates it. See the NHI Risk Scoring Guide for scoring individual machine identities.

7. Risk evaluation and acceptance criteria

Risk level is read from the matrix, not calculated by multiplying, so that a Severe impact cannot be diluted into Medium by a low likelihood score without a reviewer seeing it.

Acceptance criteria, aligned to the board appetite in the Cyber Risk Appetite Statement Template:

Category overrides apply: any residual Severe impact on regulated personal data or on an identity root of trust is evaluated as at least High, whatever the likelihood. ISO/IEC 27001:2022 clause 6.1.3 requires risk owners to approve treatment plans and accept residual risk, so acceptance must name a person and an expiry date.

8. Assessment workflow

1. Prepare (NIST SP 800-30 Task 1-1 to 1-5): record purpose (which decision this supports), scope (systems, data, identities, time frame), assumptions and constraints, information sources (incident records, logs, vulnerability scans, threat intelligence, identity inventory), and confirm the approach from section 4.
2. Identify scenarios: write each as cause, event and consequence, one owner and one treatment per scenario. Include at least one scenario for privileged non-human identities and, where relevant, one for AI agents with tool access.
3. Assess threat sources and events (Tasks 2-1, 2-2): score capability, intent and targeting (section 5.1) or frequency (5.2), citing evidence.
4. Assess vulnerabilities and controls (Task 2-3): list the weaknesses and the controls that apply, with evidence date. Score 5.3.
5. Determine likelihood and impact (Tasks 2-4, 2-5): apply sections 5.4 and 6; risk owner confirms impact.
6. Determine risk and confidence (Task 2-6): read the level from the matrix and assign confidence (section 9).
7. Evaluate: compare with section 7; propose treatment (avoid, mitigate, share or transfer, accept) and target rating.
8. Communicate (Tasks 3-1, 3-2): record in the register within [5] working days; brief the risk owner; escalate per section 7.
9. Maintain (Tasks 4-1, 4-2): set key risk indicators and the next review date; reassess on any trigger in section 2.

9. Confidence and uncertainty

NIST SP 800-30 Rev. 1 treats uncertainty as inherent in risk assessment and suggests communicating it, for example as ranges, rather than hiding it. Every rating carries a confidence level:

• High: control evidence dated within [12] months, incident or frequency data available, SMEs agree.
• Medium: some evidence is older or indirect; SMEs broadly agree.
• Low: mainly expert opinion, untested controls or disputed scores.

A Low-confidence rating of High or Critical must be reassessed within [60] days with the missing evidence, and must not be accepted until it is. Where assessors disagree by more than one level, record both views and the reason.

10. Quality assurance and calibration

• Calibration session: each [quarter] all assessors independently rate the same [3] sample scenarios; spreads of more than one level trigger guidance updates.
• Independent review: the reviewer samples [10]% of completed assessments, and every Critical rating, against this document.
• Back-testing: after each significant incident, compare its actual impact and frequency with the pre-incident rating and record the variance.
• Method change control: any change to scales or thresholds is versioned, approved by [Risk committee] and applied to all open risks within [one cycle], with old and new ratings kept.

11. Review and approval

This methodology is reviewed at least [annually], after any material incident or change in risk appetite, and when regulation changes. Version [1.0], approved by [Risk committee] on [date], next review [date], owner [Head of Cyber Risk].

Implementation guidance

Rolling it out

1. Calibrate first: fill in money and outage values with finance and the business impact analysis, and test the matrix against [10] already-known risks. If more than a third land as Critical, the bands are too tight.
2. Pilot: run the method on two systems and one Tier 1 review; time each assessment and note which fields assessors could not fill.
3. Train and approve: train assessors on the pilot outputs, then seek committee approval.
4. Re-rate in waves: move existing register entries to the new method, Critical and High first, keeping the old rating in a history field. Roll back by restoring that field if the committee rejects the new bands.
5. Health check: after two cycles, review the programme with the Cyber Risk Register Health Check.

Choosing settings for your size

Small organisations should keep one Tier 3 template, a three-person calibration and qualitative confidence only; the full trigger table is still worth keeping. Large or regulated organisations should add quantitative analysis for top scenarios, separate business unit money bands that roll up to group bands, and a formal second-line challenge.

Measures that show the method works

• Percentage of assessments completed before go-live or change approval (target [95]%).
• Calibration spread: share of sample ratings within one level of the median (target [80]%).
• Percentage of High and Critical ratings with High or Medium confidence.
• Accepted risks past their expiry date (target zero).
• Back-test variance: incidents whose actual impact exceeded the rated band.

Common failure patterns

• Criteria agreed after scoring: bands drift to fit the answer people wanted; freeze them before the cycle starts.
• Multiplying ordinal scores: treating 4 × 5 = 20 as a measurement; use the lookup matrix and quantitative analysis where precision matters.
• Controls credited without evidence: a policy is scored as a tested control; require dated evidence for 5.3.
• Machine identities missing: scenarios cover users but not service accounts, pipeline tokens or agents. Credential theft from a CI system, as in the Codecov breach, shows why these need their own scenarios.
• Assessments that never return: Step 4 is skipped and ratings go stale; tie reviews to the triggers, not just the annual cycle.

Framework mapping

Standards and references

• NIST: SP 800-30 Rev. 1, Guide for Conducting Risk Assessments
• ISO: ISO/IEC 27005:2022 Guidance on managing information security risks
• ISO: ISO/IEC 27001:2022 Information security management systems
• NIST: IR 8286 Rev. 1, Integrating Cybersecurity and Enterprise Risk Management
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5
• NCSC: Risk management guidance

This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Risk Assessment Methods Compared · Risk Register Template · Cyber Risk Register Health Check · Risk Management Guide