Risk assessment with ITSRM, and why a good ITSP raises your cyber maturity

The register nobody reads

Every organisation we walk into has a risk register. It is usually a spreadsheet. It usually has a column called “Likelihood” with values between 1 and 5, another called “Impact” with the same range, and a third that multiplies the two. Somebody built it in a hurry before an audit two years ago. Nobody has opened it since, because everyone in the room knows the numbers were guessed.

That is not a criticism of the people who built it. It is a criticism of a method that never told them where the numbers were supposed to come from. If a risk score has no traceable link to a specific asset, a specific threat and a specific dependency, it is an opinion wearing a number costume. Auditors sense this immediately. So do boards, which is why security funding conversations so often stall.

The alternative is not more sophistication. It is more structure. A structured risk assessment methodology does one useful thing above all others: it makes every number in the final table answerable to a question asked earlier in the process. You can walk backwards from a risk score to the asset it threatens, the dependency that carries it, and the business value that justifies caring. That is what makes a plan defensible — and defensible is the whole game when a regulator, a client’s procurement team, or your own management asks why you spent the money.

ITSRM is one such methodology. It is the one the European Commission uses on its own systems, and it happens to be very well suited to organisations that need a rigorous, per-system answer rather than an organisation-wide statement of intent.

What ITSRM actually is

ITSRM² — the IT Security Risk Management Methodology — was developed by DG DIGIT’s IT Security Policy unit at the European Commission. The current published version is 1.2, released in 2020, accompanied by a description document and a set of detailed catalogues covering threats, vulnerabilities and security measures.[1][2] The methodology exists because Commission Decision (EU, Euratom) 2017/46 requires that IT security in the Commission be based on a risk management process — a decision that applies to every communication and information system owned, procured, managed or operated by or on behalf of the Commission.[3]

Three things distinguish it from the risk methodologies most private-sector teams have met.

It is per-system, not per-organisation. ITSRM does not ask you to assess “the company.” It asks you to assess one CIS — one system, with a name, a scope and an owner. This sounds like a limitation until you have tried to run a meaningful risk workshop about an entire enterprise, at which point it starts to feel like mercy. Scope discipline is the single largest driver of assessment quality.

It separates what you care about from what you depend on. ITSRM draws a hard line between primary assets (the data and the business processes the system exists to serve) and supporting assets (the hardware, software, networks, services, people and premises that make the primary assets possible). Value lives in the primary assets. Vulnerability lives in the supporting ones. Risk is what happens when a threat reaches a primary asset through a supporting one. Keeping these apart is what stops teams from producing the classic non-risk: “the firewall could fail.” So what? Which data set suffers, and how badly?

It ships with catalogues. The threat catalogue draws on established sources such as MAGERIT, and there is a corresponding catalogue of security measures with sophistication levels.[2] This matters more than it sounds. Catalogues remove the blank-page problem, make two assessments comparable, and stop the assessment from reflecting the imagination of whoever happened to be in the room.

Conceptually, ITSRM sits in the same family as ISO/IEC 27005, the fourth edition of which was published in 2022 and which adapts the general risk management principles of ISO 31000 to information security.[4] If your organisation already works to ISO 27001, nothing here will feel alien. ITSRM is simply more prescriptive about the mechanics: it tells you what to enumerate, in what order, and how the arithmetic works.

A risk score that cannot be traced back to an asset and a dependency is an opinion wearing a number costume.

So what is an ITSP?

An IT Security Plan is the deliverable that comes out the other end. It is not a policy. It is not a set of standards. It is a document about one system that states, in order: what the system is and who owns it; what it holds and what that is worth; what it depends on; what could go wrong and how likely that is; which of those risks are acceptable and which are not; and precisely what will be done about the unacceptable ones, by whom, by when, and what the risk will look like afterwards.

The last part is the part people underestimate. An ITSP is not an assessment with recommendations attached. It is an assessment and a commitment. Every unaccepted risk carries a treatment measure with an owner and a deadline, and a computed residual risk that says what remains once the measure is in place. That is the difference between a report your management reads and a plan your management signs.

This is also why the ITSP is a genuinely useful artefact outside the compliance context that produced it. If you are in scope for NIS2, Article 21(2)(a) requires policies on risk analysis and information system security — and national supervisors will want to see that risk analysis actually happened, on real systems, with real outputs. A per-system ITSP is direct evidence. A generic organisational risk policy is not.

The seven phases, and what each one is really for

ITSRM runs as a sequence. The order is not decorative — each phase consumes the output of the one before it, and skipping ahead is the most reliable way to produce a plan that falls apart under questioning.

Read as a whole, the sequence has an obvious logic: establish scope, establish value, establish dependency, connect value to dependency, enumerate what can go wrong, score it, fix it. What makes it work is the discipline of confirming each phase before starting the next. Carry an unvalidated asset list into phase 5 and you will discover the problem in phase 7, when re-work is expensive.

Where these assessments go wrong

We have reviewed a fair number of risk assessments that did not survive contact with an auditor. The failure modes repeat.

• Scoping the whole estate as one system. If the scope statement contains the word “and” more than twice, it is probably several systems. Split it. Two clean ITSPs beat one incoherent one, and the second is always faster than the first.
• Valuing primary assets by intuition. “High” is not a valuation. Tie the value to something real: regulatory exposure, contractual penalty, operational downtime cost, reputational commitment already made to a client. Write down the reasoning next to the score, because in eighteen months nobody will remember it.
• Confusing a control gap with a risk. “We have no MFA” is a gap. The risk is what an attacker does with a credential, to which data, and what that costs. Gap-driven assessments produce control shopping lists; risk-driven ones produce priorities.
• Setting acceptance criteria after seeing the results. This is the most human mistake and the most damaging. Once you know your scores, any threshold you choose is reverse-engineered to make the picture look manageable.
• Treating inherited risk as somebody else’s problem. If you run on a managed platform, some risks are genuinely the provider’s to control. They remain yours to accept, in writing, with a named accepter. “The cloud handles it” is not a risk decision.
• Producing a plan with no dates. An ITSP whose treatment measures all say “ongoing” is a document, not a plan. Dates create accountability, and accountability is the entire mechanism by which assessments change anything.

How a good ITSP actually raises cyber maturity

“Improves maturity” is the kind of phrase that appears in every consultancy deck and means nothing by itself. Here is the specific, mechanical version — five things a well-built ITSP changes about how an organisation operates.

It forces an accurate asset inventory into existence. Not the theoretical one in the CMDB — the real one, including the dependencies discovered in phase 3 that nobody had documented. Almost every maturity model in existence puts asset knowledge at the bottom of the pyramid, because nothing above it works without it. Organisations routinely tell us the dependency map was the most immediately useful output of the whole exercise, ahead of the risk scores.

It converts security from opinion into arithmetic. Once likelihood and consequence are computed from documented inputs, arguments about priority stop being arguments about seniority. This changes the internal politics of security in a way that is hard to overstate. The question moves from “do you think this is serious?” to “which input do you disagree with?” — and that second question is answerable.

It gives you a budget argument that finance can read. A treatment measure with a cost, an owner, a deadline and a computed residual risk reduction is an investment case. A slide saying “we need EDR” is not. We have watched security budgets get approved on the strength of a residual-risk column after two previous attempts failed on the strength of enthusiasm.

It makes reassessment cheap. The first ITSP for a system is genuinely hard work. The second, twelve months later, is mostly delta: what changed in scope, which assets moved, which treatments landed, what the residual risk is now. Maturity is largely the difference between organisations that can answer “has our risk gone up or down since last year?” and organisations that cannot. A repeatable methodology is what makes that question answerable at all.

It creates the paper trail that regulation now assumes exists. NIS2 makes management accountable for cybersecurity risk-management measures, not merely aware of them. Under that model, the useful artefact is a signed, dated plan showing that risks were identified, evaluated against stated criteria, and either treated or explicitly accepted by someone with the authority to accept them. Whatever else it does, an ITSP produces exactly that record.

None of this requires the plan to be long. Some of the most useful ITSPs we have produced are forty pages including annexes. Length is not the deliverable; traceability is.

If you are starting from nothing

A pragmatic sequence for a first attempt, assuming no existing methodology and limited appetite:

• Pick one system that matters and that you understand. Not the most critical one — the most knowable one. The goal of the first assessment is to learn the method, and you want the business owner reachable and the architecture documented.
• Get the risk acceptance criteria agreed in writing before you start. By someone senior enough to accept risk. This one step prevents more downstream trouble than any other.
• Timebox the asset phases hard. Two workshops for primary assets, two for supporting assets. Perfection here is the enemy of ever reaching phase 7, and the gaps you leave will be visible in the modelling phase anyway.
• Use the catalogues rather than brainstorming threats. Brainstormed threat lists reflect the room. Catalogue-driven ones reflect the field, and they are comparable across systems and across years.
• Present the plan to management as a decision, not a report. Unaccepted risks with proposed treatments and costs on one page. The meeting should end with signatures or with explicit, recorded acceptance of the risks that will not be treated.
• Diarise the review. Twelve months, or on material change to the system. An ITSP that is never revisited decays into exactly the spreadsheet this article started with.

How CL2R Advisory can help

We build IT Security Plans to ITSRM v1.2 for a fixed price, and we do it in weeks rather than quarters. The methodology is unchanged — the same seven phases, the same catalogues, the same arithmetic — but the process is engineered so that you review and confirm each phase before the next one starts, which is what keeps the calendar short and the output yours rather than ours.

You get a plan you can sign and defend: a full ITSRM assessment, a treatment roadmap with owners and deadlines, computed residual risk, and a walkthrough for your management. If you would rather build the capability in-house, we also run the first assessment alongside your team so that the second one does not need us.

If you want to know what this would cost for a specific system, the fastest route is a thirty-minute scoping call. See ITSP as a Service for pricing and the phase-by-phase process, or get in touch.

Sources

• [1] European Commission, DG DIGIT Unit S1 — IT Security Policy, ITSRM² IT Security Risk Management Methodology v1.2 — Description of the methodology. Copy hosted by CERN (PDF).
• [2] European Commission, DG DIGIT Unit S1, ITSRM Methodology v1.2 — Detailed Catalogues (threats, vulnerabilities and security measures). Copy hosted by CERN (PDF).
• [3] Commission Decision (EU, Euratom) 2017/46 of 10 January 2017 on the security of communication and information systems in the European Commission, OJ L 6, 11.1.2017, pp. 40–51. EUR-Lex.
• [4] ISO/IEC 27005:2022, Information security, cybersecurity and privacy protection — Guidance on managing information security risks (fourth edition). iso.org.
• [5] Directive (EU) 2022/2555 (NIS2), Article 21 — cybersecurity risk-management measures. EUR-Lex.
• [6] EU Academy, Foundations of IT Security and Risk Management (ITSRM) — official training on the methodology. academy.europa.eu.