ISO/IEC 27005 Foundation study materials
ISO/IEC 27005 Foundation study resources

Case 1 - 212 Entries, One Colour: When the Register Cannot Be Evaluated

ISO/IEC 27005 Foundation · Put your knowledge to work in context.

All case studies

Case 1 - 212 Entries, One Colour: When the Register Cannot Be Evaluated

Meridian Insurance Brokers employs 600 staff across three offices and holds personal data on 1.2 million policyholders. Its risk register contains 212 entries. Likelihood and impact are each scored Low, Medium or High, and the two scores are multiplied into a 1–9 value. Of the 212 entries, 171 are scored Medium × Medium and therefore all appear as 'Medium (4)'. Entries include 'no formal password policy', 'ransomware encrypts the claims system before month-end close', and 'a key underwriter may leave'. The board has approved €400,000 for treatment and asked for the ten risks to address first. An external auditor has written that 'risk evaluation is not demonstrably performed'. The CISO believes the register is fine because every asset has at least one entry.

1. Identify the conceptual errors in this register and explain why, under ISO/IEC 27005 concepts, the board cannot prioritise from it.

Read the worked answer

The register fails at three levels.

First, the entries are not risks as ISO/IEC 27005 understands them. A risk combines a scenario - a threat exploiting a vulnerability - with consequences and likelihood. 'No formal password policy' is a control weakness; it becomes a risk only when paired with a threat (credential guessing) and a consequence (account takeover on the claims system). Without that pairing the entry cannot be analysed or evaluated.

Second, multiplying ordinal three-point scores into a 1–9 value produces false arithmetic and collapses 171 entries into a single cell. Discrimination is impossible because almost everything looks identical, whatever the underlying severity.

Third, no risk criteria were established. Risk evaluation means comparing analysis results against criteria such as appetite and acceptance thresholds. Meridian never defined them, so evaluation cannot be said to occur.

Add the absence of named risk owners and of calibrated scale descriptors, and the board is choosing from noise rather than from evidence.

2. The CISO proposes rescaling to a 10×10 matrix to spread the scores out. Assess this proposal.

Read the worked answer

It treats a symptom. A 10×10 matrix reduces ties and can support finer evaluation, but only if the descriptors are defined and calibrated - impact bands in euros of loss, regulatory notification, days of outage; likelihood bands as expected frequency per year with a stated horizon. Without that, a 7×8 score is as arbitrary as Medium × Medium and simply creates a false sense of precision.

More importantly, rescaling does nothing about the category error: control gaps, events and business scenarios would still share one list.

The defensible route is to define risk criteria and acceptance thresholds; define consequence and likelihood scales with observable descriptors; rewrite each entry as a scenario with threat, vulnerability, consequence, likelihood and owner; calibrate in a workshop using past incidents and operational knowledge; then evaluate and prioritise. If discrimination is still insufficient for the top risks, use ranges or quantitative estimates for those only, rather than inflating the whole scale.

3. How should the entry 'a key underwriter may leave' be handled?

Read the worked answer

Screen it against scope before scoring. ISO/IEC 27005 addresses information security risk - risk to the confidentiality, integrity and availability of information and to information security objectives. Loss of an underwriter is primarily a business, HR and continuity risk.

It belongs in this register only if the underlying information scenarios are articulated, for example: loss of tacit knowledge needed to restore the claims system (availability); departure of a privileged user who retains access (confidentiality and integrity); or insider exfiltration of the underwriting book. Each of those should be recorded as a scenario with its own owner and controls - knowledge capture, access revocation, exit procedures.

If no information security consequence can be stated, move it to the enterprise risk register and cross-reference it. Keeping scope and criteria consistent matters, because a register that mixes domains cannot produce a meaningful top ten, and the €400,000 will be allocated on the wrong basis.