Before you score the risk, score the asset

Where impact scores actually come from

A 5×5 matrix looks rigorous. Likelihood on one axis, impact on the other, colours in between. But the impact axis has a hidden dependency: you cannot say what a compromise costs unless you know what the asset is worth. When that value has never been established, every impact score is an improvisation, and the same risk lands on a 2 or a 4 depending on who is in the room.

The instrument that settles the question is the business impact assessment. Classify the asset once, with named levels everyone has agreed on, and the impact discussion changes nature: the score is read from the classification instead of being argued from intuition. In a risk programme, the BIA is not an annex. It is the input that makes every other score mean something.

The triad, plus the letter auditors care about

Convention classifies assets on three dimensions: confidentiality, integrity and availability. The triad is useful, but it is a convention, not a law of nature, and it has a blind spot that regulated organisations feel every year: it says nothing about whether you can prove who did what.

That is why SynapseRM classifies on four letters, C·I·A·T, where T stands for traceability: the level of logging and attribution the asset requires. The levels run from “no requirement to log who performed an action” to “full detail, author, precise action, data affected, date and time, sufficient for forensic or regulatory review”. In an era where NIS2 and DORA are built on evidence rather than assertion, the ability to reconstruct actions on an asset is a dimension of its criticality, not a technical afterthought.

Levels mean nothing until you define them

The second failure of most classification schemes is the naked scale. Asking an asset owner to rate confidentiality “from 1 to 4” produces numbers, not information: one owner's 3 is another owner's 2, and the aggregate is noise with decimals.

The fix is to give every level a definition in business language, written once by the organisation, applied identically to every asset. Not “confidentiality: 2” but “Internal: intended for use within the organisation; disclosure would cause limited inconvenience but no significant harm”. Not “availability: 3” but “the service must be restored within a few hours; prolonged downtime disrupts critical operations”. Availability levels expressed as tolerable downtime are particularly effective, because the asset owner is answering a question they actually know: how long can the business live without this?

With defined levels, classification stops being a matter of taste. Two assessors reading the same definitions about the same asset land on the same line, and an auditor reading the register three years later understands exactly what a “High” meant on the day it was assigned.

Three ways classification fails

Programmes that do run a BIA still lose value in three familiar ways:

• Inflation. When nothing constrains the scale, every owner rates their own asset critical, and the classification stops discriminating. Written level definitions are the constraint: an intranet that publishes internal news does not meet the definition of “Secret”, however fond its owner is of it.
• The one-off exercise. A classification from three years ago describes a company that no longer exists. Criticality needs an owner and a review date, like any other record that decisions depend on.
• The disconnected spreadsheet. A BIA that lives in a file nobody opens cannot inform an impact score. The classification only pays for itself when the risk assessment can read it directly.

What the frameworks expect

None of this is optional refinement. DORA Article 8 requires financial entities to identify, classify and adequately document their ICT supported functions and the information and ICT assets behind them, and to map the ones considered critical, including links and interdependencies. ISO 27001:2022 carries the same expectation in Annex A: an inventory of information and associated assets (control 5.9) and a classification of information according to the organisation's needs (control 5.12), while ISO 27005 places asset valuation at the start of the risk assessment it describes. NIS2, finally, asks for policies on risk analysis (Article 21(2)(a)); an analysis whose impact scores rest on classified assets is precisely what makes such a policy defensible in front of a supervisor.

How SynapseRM does it

The BIA module in SynapseRM applies everything above. An asset carries an identifier, an owner, a department and optional links to related assets. Each of the four dimensions is set by choosing a level whose full definition is on screen, in your organisation's own wording, since scales and definitions are configurable. A flag records whether the asset holds personal data, so the GDPR dimension of a later incident is a lookup rather than a scramble. The overall criticality is computed and displayed on the spot.

Because the platform runs on one data model, the classification does not retire into a file. The criticality sits on the same record that assessments, risks and exceptions reference, so when an analyst scores the impact of a finding on the finance ERP, the asset's level is in front of them, not in a spreadsheet from another year. The workshop argument about “3 or 4” ends the honest way: it was settled before the meeting started.

Related reading: The risk register: the document every framework assumes you have · Twelve modules, one data model: why integration beats tooling