Skip to content

Protection needs, and how criticality is inherited

BSI-Standard 200-2 §8.2 and ISO/IEC 27005:2022 Annex A.2. How to work out what a server, a room or a network link actually needs to be protected against — by never rating it on its own merits, and always deriving it from the business process and the information sitting on top of it.

The idea that runs through all of it: you rate the business process and its information once, and everything underneath inherits that rating. Most asset registers get this backwards. They start at the bottom, ask "how important is this server?", and end up with a number nobody can defend. The order is the point.

On the German

BSI-Standard 200-2 is published in German, and its terms are usually left untranslated in practice — which makes the method needlessly opaque to anyone who does not read German. This page is in English throughout. Quotations are my own translations from the German original, marked as such; the BSI also publishes an official English edition, and its wording will differ from mine. Where a decision hangs on exact phrasing, work from one of the two official texts.

Why the order matters: Stop asking how important your server is.

Artefacts

Artefact Type Format
Interactive model and maximum calculator Click any element for the clause it comes from; set C, I and A and watch the overall need .html
Asset inheritance model Editable diagram — the full two-directional model .excalidraw

Download and adapt

Both are hosted here on the domain — no third-party requests, no CDN, no analytics. Open the .excalidraw file at excalidraw.com or in the Obsidian Excalidraw plugin. The diagram below is the simplified spine; the Excalidraw file has the full version, including the third-party boundary and the lateral-propagation case.

The model at a glance

How a protection need is inherited, and how risk travels back The diagram runs top to bottom. Step one rates the business process and its information against six damage scenarios: laws, regulations or contracts; informational self-determination; personal safety; task fulfilment; reputation and trust; and financial impact. These six are a starting set, not a closed list: the standard expects organisations to add scenarios that apply to them and drop those that do not. The worst scenario sets one of three categories — normal, where the effects are limited and manageable; high, where they can be considerable; and very high, where they can be catastrophic and threaten survival. Below that, four layers: primary or business assets at the top, then supporting assets in three tiers — applications, then IT systems, then rooms, communication links and other devices. An accent rail down the left shows the protection need inheriting from the top layer to every layer beneath it, per BSI Standard 200-2 section 8.2.2. A dashed teal rail up the right shows risk propagating in the opposite direction, from supporting assets back to business assets, per ISO/IEC 27005:2022 annex A.2.2. Between the layers, three adjustments are named: inheritance cascades the need, the maximum principle and cumulation can raise it, and the distribution effect can lower it, mainly for availability. At the foot, the overall protection need of an object is the highest of its confidentiality, integrity and availability ratings. Step 1 — rate the business process and its information Judge the damage against these scenarios. The worst one sets the category. 1 Laws, regulations or contracts 2 Informational self-determination 3 Personal safety 4 Task fulfilment 5 Reputation and trust 6 Financial impact BSI's starting set, not a closed list — add any that apply, drop any that do not (§8.2.1). normal — the effects are limited and manageable high — the effects can be considerable very high — the effects can be catastrophic, threatening survival Protection need inherits down — BSI 200-2 §8.2.2 Risk propagates up — ISO/IEC 27005:2022 A.2.2 Primary / business assets Business processes and the information they handle. The protection need is determined HERE, from the damage scenarios. Everything below inherits it. Inheritance — the need cascades to whatever processes it Supporting assets — applications The applications used to process them. BSI 200-2 §8.2.3. Maximum principle · cumulation can raise it Supporting assets — IT systems Servers, virtualisation hosts, clients. §8.2.4. Cumulation bites hardest here. Distribution effect can lower it — mainly availability Supporting assets — rooms, links, devices Buildings, communication links, other devices. §8.2.6–8.2.8. Derived last, from everything above. Per object: overall protection need = the highest of C, I and A How a protection need is inherited, and how risk travels back The diagram runs top to bottom. Step one rates the business process and its information against six damage scenarios: laws, regulations or contracts; informational self-determination; personal safety; task fulfilment; reputation and trust; and financial impact. These six are a starting set, not a closed list: the standard expects organisations to add scenarios that apply to them and drop those that do not. The worst scenario sets one of three categories — normal, where the effects are limited and manageable; high, where they can be considerable; and very high, where they can be catastrophic and threaten survival. Below that, four layers: primary or business assets at the top, then supporting assets in three tiers — applications, then IT systems, then rooms, communication links and other devices. An accent rail down the left shows the protection need inheriting from the top layer to every layer beneath it, per BSI Standard 200-2 section 8.2.2. A dashed teal rail up the right shows risk propagating in the opposite direction, from supporting assets back to business assets, per ISO/IEC 27005:2022 annex A.2.2. Between the layers, three adjustments are named: inheritance cascades the need, the maximum principle and cumulation can raise it, and the distribution effect can lower it, mainly for availability. At the foot, the overall protection need of an object is the highest of its confidentiality, integrity and availability ratings. Step 1 — rate the process Six damage scenarios. The worst one wins. 1 Laws, regulations or contracts 2 Informational self-determination 3 Personal safety 4 Task fulfilment 5 Reputation and trust 6 Financial impact Starting set, not a closed list — add or drop to suit (§8.2.1). normal — limited and manageable high — can be considerable very high — can threaten survival Primary / business assets Business processes and the information they handle. The protection need is set HERE. Inheritance — cascades down Supporting assets — applications The applications used to process them. §8.2.3. Maximum principle · cumulation Supporting assets — IT systems Servers, virtualisation hosts, clients. §8.2.4. Distribution — mainly availability Supporting assets — rooms & links Rooms, communication links, other devices. §8.2.6–8.2.8. Overall need = highest of C, I and A Risk propagates back up the same chain ISO/IEC 27005:2022 A.2.2

Two directions, two standards, and they are not the same claim:

  • Down (accent). The protection need inherits from the primary asset to every supporting asset that processes, stores, carries or houses it. BSI calls this inheritance.
  • Up (teal). Risk travels the other way: a weakness in a supporting asset reaches the business asset. This is 27005's framing, and it is why the diagram is a dependency graph rather than a tree.

You need both. Inheritance tells you how much protection the server needs. Propagation tells you what can go wrong because of it.

Every term, defined

Primary asset (business asset)

ISO/IEC 27005:2022, A.2.2 is unusually blunt about it:

"primary/business assets — information or processes of value for an organization"

Two things, not one. The most common mistake in an asset register is treating only the data as the primary asset and demoting processes to context. BSI takes the same position: the root of the whole exercise is the business processes and their associated information.

Business process

A process is a primary asset in its own right, valued on what its loss would do — not on whether someone has labelled it "core". Core versus non-core is a useful operational distinction and a poor protection-need criterion. What decides the rating is the information the process handles and the damage its failure would cause.

Supporting asset

27005, A.2.2:

"supporting assets — components of the information system on which one or several business assets are based"

Note one or several. That phrase is doing real work: it is the reason the maximum principle has to exist. BSI enumerates the types explicitly — applications, IT systems, industrial control systems and other devices, rooms, and communication links. Rooms are on that list and get forgotten anyway. People are not on it at all: §8.2 inherits onto objects, and a person is not one of them. 27005 is the standard that puts them in the model — its own worked dependency graph names "Administrator, type: human resource". If your inventory has no human entries, that is the taxonomy showing through, not an oversight.

Protection need

The output of the exercise. Three categories, defined in §8.2.1 by what the damage would do (translated):

Category Definition
normal The effects of the damage are limited and manageable
high The effects of the damage can be considerable
very high The effects of the damage can reach a catastrophic scale that threatens the organisation's existence

Assessed separately for each of the three security objectives — confidentiality, integrity and availability. It is not one blended score. A process can sit at confidentiality = very high, integrity = high, availability = normal, and all three travel down together as a triple.

The six damage scenarios

The protection need is not asserted, it is derived. §8.2.1 gives six scenarios, and an asset takes the category of the worst plausible damage across them:

# Damage scenario
1 Violation of laws, regulations or contracts
2 Impairment of the right to informational self-determination
3 Impairment of personal safety
4 Impairment of task fulfilment
5 Negative internal or external effect on reputation and trust
6 Financial impact

Three things about this list that are easy to miss.

It is a starting set, not a fixed six. Scenario 2 can be dropped if your data protection function already covers it. Scenario 3 can be dropped unless yours is an organisation in which malfunctions of IT systems can directly result in harm to people — the standard names healthcare and production as the cases where it stays. You can add your own; BSI's own suggestion is restriction of services to third parties.

Several usually fire at once. BSI's example: an application outage impairs task fulfilment, which produces direct financial loss. You take the worst, not the sum — which is what makes the overall rating a maximum.

The thresholds are yours to set. The standard's tables are orientation only, and it says so: they should be adapted by each organisation to its own circumstances. For a sense of the calibration, at normal the maximum tolerable downtime sits between 24 and 72 hours and reputational damage is slight or purely internal; at very high the financial damage threatens the organisation's existence. Which is why BSI suggests pegging the financial band to a percentage of total turnover or total profit rather than an absolute figure. Its own illustration: €200,000 measured against turnover may still be a minor loss for a large company, while €10,000 can be existentially threatening for a small one.

Inheritance

§8.2.2, and this is the load-bearing sentence of the whole method (translated):

"The protection need determined for these elements is inherited by the objects used to process them — applications, IT systems, industrial control systems and other devices, rooms and communication links."

The sequence is fixed: determine the need for processes and applications first, then derive it for everything else.

And it is not only the systems an application runs on that inherit. §8.2.4, p. 114 (translated):

"It is not enough to consider only the IT systems on which the application in question is installed. The data flow of the application must also be observed, by which the protection need of the application is inherited onto the intermediate network components."

§8.2.6, p. 121 repeats the same rule for other devices. So a switch sitting in the path of high-confidentiality traffic inherits that need whether or not anyone thought of it as part of the application.

Worth knowing before you draw a network diagram with protection needs cascading onto every line. §8.2.8 (p. 125) is reached after the need has been determined for processes, applications, IT systems, ICS and other devices and rooms — and it does not give a link an inherited rating. It asks you to identify the critical connections, of three kinds:

  • external connections — links leading into or through uncontrolled areas, such as the internet or public ground, wireless links included, and links used for remote administration;
  • links carrying high-protection-need information — whether the need arises from confidentiality, integrity or availability;
  • links in production environments, including the links between segregated networks.

The method is a sweep: take all external connections first, then every link out of a system or group with high or very high need, then the links those data are forwarded over, then the links the data must not travel over. For each, record the route, whether it is an external connection, and whether high-protection-need information crosses it. Document the result in a table or highlight it on the network plan.

So the honest summary is: the need is inherited onto the network components (§8.2.4) and the links are classified (§8.2.8). Those are two different operations, and a diagram that shows one accent rail reaching all the way to the bottom is a simplification of the second.

The overall need is a maximum, not an average

§8.2.4, p. 114 (translated):

"The overall protection need of an IT system is in turn derived from the maximum of the protection need with respect to the three security objectives of confidentiality, integrity and availability."

So you record the triple and a single overall figure, and the overall figure is the highest of the three. Worked through, for one object in the booking company:

How the overall protection need is taken as a maximum Three cards side by side give the protection need of one object against the three security objectives: confidentiality high, because it holds customer personal data; integrity high, for pricing correctness; and availability very high, because an outage stops sales. Availability is marked in accent as the one that decides. Arrows from all three converge into a single value, taken as the maximum of the three per BSI Standard 200-2 section 8.2.4: the overall protection need is very high. Below, two consequences are given. First, the other two objectives do not move — confidentiality and integrity stay high, the overall figure does not drag them up, and each still buys a different set of controls, per section 8.2.4. Second, because the object is now very high overall, IT-Grundschutz requirements alone are generally not sufficient, and the additional measures must be determined individually on the basis of a risk analysis, per section 8.2.9. Confidentiality high customer PII Integrity high pricing correctness Availability very high outage stops sales maximum of the three — §8.2.4 Overall protection need = very high The other two do not move. Confidentiality and integrity stay high — the overall figure does not drag them up, and each still buys a different set of controls (§8.2.4). But the object is now very high overall, and that changes what happens next: at very high, IT-Grundschutz requirements alone are generally not sufficient, and the additional measures must be determined individually on the basis of a risk analysis (§8.2.9). How the overall protection need is taken as a maximum Three cards side by side give the protection need of one object against the three security objectives: confidentiality high, because it holds customer personal data; integrity high, for pricing correctness; and availability very high, because an outage stops sales. Availability is marked in accent as the one that decides. Arrows from all three converge into a single value, taken as the maximum of the three per BSI Standard 200-2 section 8.2.4: the overall protection need is very high. Below, two consequences are given. First, the other two objectives do not move — confidentiality and integrity stay high, the overall figure does not drag them up, and each still buys a different set of controls, per section 8.2.4. Second, because the object is now very high overall, IT-Grundschutz requirements alone are generally not sufficient, and the additional measures must be determined individually on the basis of a risk analysis, per section 8.2.9. Confidentiality high customer PII Integrity high pricing correctness Availability very high outage stops sales maximum of the three — §8.2.4 Overall protection need = very high C and I stay high — the overall figure does not drag them up, and each buys different controls (§8.2.4). At very high, IT-Grundschutz alone is generally not sufficient: the additional measures come from a risk analysis (§8.2.9).

One very high anywhere makes the object very high. This is worth stating explicitly on any diagram that shows a single "very high" verdict, because readers reasonably assume it means all three. BSI makes the corollary explicit in the same section: a high overall rating does not drag the other two objectives up with it — an IT system can be overall high on the strength of confidentiality alone while integrity and availability stay normal, and you still record all three separately, because they buy different controls.

Where the rule is actually written

BSI states the maximum-of-C/I/A rule for IT systems (§8.2.4, p. 114), ICS systems (§8.2.5, p. 119) and other devices (§8.2.6, p. 121), in near-identical wording each time. It does not restate it for business processes and applications (§8.2.3), rooms (§8.2.7) or communication links (§8.2.8). In practice the same arithmetic is applied throughout — BSI's own RECPLAST worked example records C, I and A separately for links as well — but if you need to cite the rule, cite it for the object type you are rating.

Maximum principle

§8.2.2 (translated):

"Essentially, the damage — or the sum of damages — with the most serious effects determines an object's protection need."

An object that supports several things takes the highest need among them. A server hosting one very-high application and nine normal ones is a very-high server.

Cumulation effect

The one that raises a rating above any of its inputs. Where several applications or information sets sit on one object, ask whether the sum of several smaller damages is worse than any single one. BSI's own example is a server holding every application a function depends on: losing any one is tolerable because there are workarounds, losing the server is not.

Virtualisation is where this bites hardest — an application's need inherits to the virtual machine, and the virtual machines' needs cumulate onto the virtualisation host.

Distribution effect

The only one that lowers a rating, and the one most often misapplied (translated):

"The distribution effect occurs mainly with respect to the availability objective."

Redundancy genuinely reduces the availability need on an individual component — if any one of three servers can fail without consequence, each one individually is below the application. It does not work the same way for confidentiality. Copying personal data onto three servers does not dilute the confidentiality requirement; it triples the number of things you have to protect.

Confidentiality distribution is possible, but through a different mechanism: a component that only ever handles non-critical data. BSI's example is a client that can only ever retrieve uncritical rows from a highly confidential database.

Document every distribution decision

BSI flags this effect as methodologically awkward, because it usually rests on redundancy that was already built — which means you are borrowing a conclusion from the risk analysis and applying it during the protection-needs stage. The standard calls this essentially an anticipation of considerations required as part of the risk analysis. Its answer is not to ban the practice but to require that the reasoning is written down. If you lower a rating here, say why, in the register.

Lateral propagation

Inheritance is not only vertical. §8.2.2 (translated):

"An application A that is minor in itself can gain considerable value if another important application B depends on its results. In that case the protection need determined for application B must also be applied to application A."

This is the rule that catches the unglamorous internal tool nobody rated, sitting upstream of something that matters. And where A and B live on different systems, the requirement transfers between the systems too.

Risk propagation — the other direction

27005:2022 A.2.2 describes the same dependency graph read the other way:

"Business and supporting assets are related, therefore risk sources identified for supporting assets can impact business assets."

It also gives the one caution that matters when you draw this:

"dependencies between assets should be documented and risk propagation assessed, so that it can be documented that the same risk is not assessed twice, once when it occurs on the supporting asset, and once when it affects the primary assets."

A supporting asset does not carry a second, independent risk just because it inherited a high rating. Assess the propagation once.

A worked example

A fictional company running an online booking service. Ratings are illustrative — your thresholds come from your own damage-scenario definitions.

Processes (the root — rated from damage scenarios):

ID Process C I A Overall
PRC-01 Customer booking and payment very high very high high very high
PRC-02 Marketing newsletter normal normal normal normal
PRC-03 Customer support high high high high

Objects (derived — nothing here was rated on its own merits):

ID Object C I A Overall Why
OBJ-01 Booking database very high very high high very high Straight inheritance from PRC-01
OBJ-02 Shared virtualisation host (all three processes) very high very high very high very high Maximum principle for C and I. Availability cumulates to very high — losing the host loses all three at once, which is worse than any one of them
OBJ-03 Support laptops (pool of 40) very high high normal very high Distribution on availability only — one laptop failing is absorbed by the pool. Confidentiality does not distribute: every laptop reaches customer data
OBJ-04 Link to the payment provider very high very high high very high Classified, not inherited (§8.2.8) — an external connection carrying very-high-confidentiality data, so it is a critical connection on all three counts. Recorded with C, I and A separately, the way BSI's own example records links

Two things to read off this table. OBJ-03 shows the distribution effect working exactly as scoped: availability drops to normal, and the object is still very high overall, because confidentiality is untouched and the overall figure is a maximum. And PRC-02 looks like a normal process until the day booking confirmations start going through the same newsletter platform — at which point lateral propagation applies and PRC-01's rating transfers to it.

Where the two standards part company

They are compatible, but they are not interchangeable, and it is worth being precise about which one you are citing.

BSI-Standard 200-2 ISO/IEC 27005:2022
Gives you A determination method — categories, damage scenarios, inheritance and the three adjusting effects A relationship model — asset types, dependencies, and risk propagation
Direction Protection need flows down to supporting assets Risk flows up to business assets
Asset taxonomy Processes and information → applications, IT systems, devices, rooms, links Primary/business assets → supporting assets
Has an inheritance algorithm Yes — maximum, cumulation, distribution No

If you want the mechanics, they are BSI's. If you want the risk-assessment frame the mechanics feed into, that is 27005. A diagram that shows criticality cascading downward is arguing a BSI thesis, whatever standard is printed in the corner.

One more thing both agree on: this is iterative. BSI is explicit that the protection-needs determination should be revisited after the risk analysis has run — once risk analyses have been carried out, the determination should be checked again to see whether it needs adjusting. The up-arrow closes a loop, it does not just describe one.

Verify before you rely on it

This is a practitioner walkthrough, not legal or certification advice. Quotations from BSI-Standard 200-2 §8.2 are my own translations from the German original and are given for orientation, not as authoritative text — check them against the current German edition or the BSI's official English translation before operational use. ISO/IEC 27005:2022 is a paid standard; the quoted passages are short excerpts from Annex A.2.2 for identification purposes. Work from your own licensed copy.

Primary sources

  • BSI-Standard 200-2 — IT-Grundschutz-Methodik — free from the BSI. §8.2 is the protection-needs determination. Page numbers on this page refer to the German Version 1.0, October 2017 PDF as a 180-page file; other layouts of that same version circulate with different pagination, so the § numbers are the reference that travels
  • BSI-Standard 200-2 — official English translation
  • BSI-Standards overview — 200-3 covers the risk analysis you run on the high and very high items once this is done
  • ISO/IEC 27005:2022, Information security, cybersecurity and privacy protection — Guidance on managing information security risks — Annex A.2.2 for the asset model. Paid standard, available from ISO and national bodies

More on the ISO 27001 clauses this feeds into is in the ISO 27001 resource library.