ISO 27001 Clause 6.1.2 Risk Assessment: A Practical Implementation Guide

A risk register is not the same as a risk assessment process. The process needs defined criteria, repeatable application and usable outputs. It should help the organization identify, analyze and evaluate information security risks in a way that supports decisions. Use the free Clause Explainer for a quick orientation, then work through these implementation questions.

What is being assessed?

Define the scope and unit of analysis. Risk scenarios may be organized around services, processes, information, systems, locations or business objectives. Avoid entries that are merely control failures such as “no MFA.” Express the business risk: what event could occur, why it is plausible and what would be affected?

How are risks identified?

Use multiple inputs:

• business and system knowledge;
• threat intelligence;
• incident and near-miss history;
• vulnerability findings;
• supplier dependencies;
• legal and contractual requirements;
• architecture changes; and
• workshops with process owners. One generic threat list is unlikely to be sufficient for every scope.

How are consequences and likelihood analyzed?

Define scales with observable criteria. Specify the time horizon, impact dimensions, how existing controls are treated and how uncertainty is recorded. Use the risk register guide to test sample cases, but remember that ISO/IEC 27001 does not require one universal matrix.

The free ISO 27001 Risk Score Calculator can help you test a documented 5×5 approach and compare inherent and residual risk. Configure it to reflect your approved criteria rather than treating its example scale as an ISO-prescribed method.

How are risks evaluated?

Evaluation compares analyzed risk with approved risk-acceptance criteria. The output should make clear which risks require treatment, escalation, monitoring or formal acceptance. Define authority. A project manager may accept low operational risk; a high customer-data risk may require executive approval.

How is consistency demonstrated?

Consistency does not require identical judgement. It requires a common method applied in a comparable way. Useful techniques:

• assessor guidance;
• worked examples;
• calibration workshops;
• quality review;
• periodic method review; and
• clear change triggers. Keep the rationale behind scores so reviewers can understand the conclusion.

What evidence should exist?

Possible evidence includes the approved method, criteria, assessment records, workshop inputs, risk-owner review, evaluation and acceptance decisions, version history and review triggers. Then connect treatment decisions to the Statement of Applicability and treatment plan. Explore Clause 6.1.2: ISO 27001 Clause Explainer Build consistent likelihood and impact criteria: information security risk register guide