Stop asking how important your server is

It is the wrong question, and it is the first question almost every asset register asks.

You end up with a spreadsheet where someone has typed "high" next to a database because it felt important, and "medium" next to a file share because it felt less so. Nobody can defend a single one of those numbers, because they were never derived from anything.

The order is the whole method

BSI-Standard 200-2 §8.2 and ISO/IEC 27005:2022 Annex A both do it the other way round, and they agree on the shape even where they differ on the detail.

You rate the business process and the information sitting on it, once. Everything underneath inherits that rating.

The application inherits from the process it serves. The system inherits from the applications running on it. The room inherits from the systems in it. Nobody ever asks how important a server is, because a server has no importance of its own. It has whatever importance flows down to it, and that is a number you can point at an auditor and explain in one sentence.

This also kills the argument. When a team insists their box is critical, the question stops being a negotiation about the box and becomes a question about which business process it supports and how that process was rated. That is a conversation with an answer.

Rate against damage, not against feeling

The rating itself comes from six damage scenarios: breach of laws, regulations or contracts; impairment of informational self-determination; threat to personal safety; impaired task fulfilment; negative effects on reputation and trust; and financial impact.

Three categories come out the other side. Normal, where effects are limited and manageable. High, where they can be considerable. Very high, where they can be catastrophic and threaten the organisation's survival.

Two things about that list are usually missed. The six scenarios are a starting set, not a closed one — the standard expects you to add scenarios that apply to your organisation and drop ones that do not. And the categories describe consequences, not importance. "How bad is the worst realistic outcome" is a question a business owner can answer. "How important is this" is not.

The overall need is a maximum, not an average

Confidentiality high, integrity normal, availability normal does not average out to normal. It is high. The maximum principle is the default and it is not negotiable, because averaging is just a way of making an uncomfortable number smaller.

Two effects modify it, and only two.

Cumulation. Many small things in one place can add up to something bigger. A hundred normal-need applications on one platform can make that platform high, because losing them together is not the same as losing one.

Distribution. The reverse. If a system only carries a fragment of a process, and the process survives losing that fragment, the need can come down. This is the one people reach for too quickly, and it needs an argument written down next to it.

The exception nobody remembers

Communication links are the one place BSI does not use inheritance. A link is not rated by what flows over it in the way a server is rated by what runs on it; it gets assessed on its own terms, including whether it crosses a boundary you do not control.

That exception exists because a network link is where lateral propagation happens, and inheritance flowing politely downward does not describe how an attacker moves. Worth knowing before you apply the model mechanically to a network diagram.

The other direction

Inheritance runs down. Risk runs back up. A supporting asset that gets compromised propagates impact upward into the process that depends on it, and that is the direction that turns a protection-needs analysis into a business impact analysis rather than a filing exercise.

I have put the full model up as an interactive page: click any element and it tells you the clause it comes from, set confidentiality, integrity and availability and watch the overall need recompute. The editable Excalidraw version has the parts the simplified diagram leaves out, including the third-party boundary and the lateral-propagation case.

One note on the German. BSI-Standard 200-2 is published in German and its terms usually go untranslated in practice, which makes a genuinely clear method look forbidding. The page is in English throughout, with my own translations marked as mine. Where a decision hangs on exact phrasing, use one of the two official texts.

Protection needs, and how criticality is inherited →

BSI-Standard 200-2 §8.2 and ISO/IEC 27005:2022 Annex A.2. Practitioner material, not legal advice.