6.1.2 — Information security risk assessment

In plain language

In plain language: sub-clause 6.1.2 requires you to define and apply a consistent method for identifying your information security risks, estimating their severity and likelihood, and prioritizing them. The keyword is repeatable: two people applying your method to the same information should arrive at comparable results.

Why this requirement exists

You cannot protect what you have not identified. This requirement ensures your security decisions rest on a structured evaluation rather than intuition or the latest technology trend. It also enforces consistency over time: without a defined method, every re-assessment would produce different, uninterpretable results.

Scenario: a company invests heavily in a top-tier firewall because "that is what everyone does," but has never assessed its risks. As a result, its real weak point — backups that are never tested and shared access credentials — stays ignored, until the day ransomware hits. A proper risk assessment would have surfaced those priorities first.

What the standard expects

The standard asks you to establish and maintain risk criteria, then apply a process that produces consistent, valid, and comparable results. In concrete terms, it expects five things: define your risk acceptance criteria and the criteria for performing assessments; identify the risks that threaten the confidentiality, integrity, and availability of your information within the ISMS scope; assign risk owners responsible for each one; analyze each risk by estimating its potential consequences and likelihood; then evaluate the results against your criteria to establish treatment priorities. You are free to choose the method (asset-based, scenario-based, qualitative, or quantitative), as long as it is defined and applied consistently.

In practice

• Choose an approach: scenario-based ("an employee loses an unencrypted laptop") or asset-based ("customer database"). The scenario approach is often more intuitive for an SME.
• Define a simple scale: for example, a 1-to-5 rating for impact and a 1-to-5 rating for likelihood, whose product gives a risk level.
• Set the acceptance threshold: above what level must a risk mandatorily be treated? This threshold is a leadership decision.
• Keep a risk register: a table listing each risk, its owner, impact, likelihood, level, and planned treatment.
• Name risk owners: one accountable person per risk — not "IT" in general, but an identifiable role.

Evidence the auditor will ask for

• The documented risk assessment methodology (criteria, scales, acceptance threshold).
• The completed risk register, with owners, levels, and priorities.
• Proof that the method was actually applied (dates, participants, source data).
• Consistency between the identified risks and the ISMS scope defined in clause 4.
• Traceability into treatment (6.1.3): every significant risk must lead somewhere.

Common pitfalls

• An implicit method: doing the exercise "in your head" without documenting criteria or scales — impossible to reproduce, therefore nonconforming.
• A frozen register: an assessment done once and never revisited, while risks keep evolving.
• Phantom owners: assigning risks to an entire department instead of an accountable person.
• Copying a generic register: reusing a template risk list without grounding it in your real assets and context.
• Confusing assessment and treatment: listing risks (6.1.2) and deciding on measures (6.1.3) are two distinct steps; blending them blurs the logic.

Related requirements

Parent link: 6.1 Actions to address risks and opportunities

2013 → 2022 mapping

Frequently asked questions