Determining protection requirements under BSI 200-2

This guide explains the method in our own words, shows an example from production and gives you a checklist. The examples are invented.

What the assessment achieves

The protection requirement answers one simple question: how bad would it be if the confidentiality, integrity or availability of a piece of information were lost? You rate these three basic values separately. A design drawing may need high confidentiality but only normal availability. For a controller it is often the other way round.

In the BSI IT-Grundschutz method, determining protection requirements is the step after the structure analysis. It builds on the list of business processes, applications, systems, rooms and links, and it decides what comes next:

• Normal protection requirement: The requirements of the modules in the IT-Grundschutz Compendium are usually enough.
• High or very high protection requirement: The target object is a candidate for a risk analysis under BSI Standard 200-3.

Basic protection skips this step at first. Core and standard protection include it, and so does ISO 27001 certification on the basis of IT-Grundschutz.

Step 1: Set out the categories

So that everyone rates the same way, you first describe what the three categories mean in your company. In simple terms:

Damage scenarios make this tangible. IT-Grundschutz names six typical ones:

1. Violation of laws, regulations or contracts
2. Impairment of the right to informational self-determination
3. Impairment of the physical integrity of a person
4. Impairment of the ability to perform tasks
5. Negative internal or external effects
6. Financial consequences

For each scenario you set the limits between the categories, with examples from your daily work. An example for the ability to perform tasks: production down for up to one day is normal, up to one week is high, longer is very high. Put amounts in relation to revenue or profit; a figure from a sample template rarely fits. In production, the physical integrity of persons almost always matters, in a pure office rarely. Management approves the categories.

Step 2: Rate business processes and applications

Rate every business process and every application separately for confidentiality, integrity and availability. For each basic value, go through the damage scenarios and ask for the realistic worst case. The highest value across all scenarios sets the category.

• Rate together: The process and application owners know the consequences. The information security officer moderates and keeps the yardstick consistent.
• Think about knock-on damage: If order intake fails, the effect spreads through late deliveries and contractual penalties.
• Watch dependencies: If an inconspicuous application feeds data into a critical one, it takes over that protection requirement.
• Give short reasons: One or two sentences per rating. Without a reason it cannot be followed in an audit.

Be honest and sparing with "very high". Every such rating brings a risk analysis and additional measures with it.

Step 3: Pass the requirements on

The protection requirement of the technology follows from what runs on it. The chain "process, application, system, room" from the structure analysis is the common thread. Three effects shape the result:

Derive the protection requirements this way for IT systems, ICS systems, other devices, rooms and communication links. A room inherits from the systems inside it. Among the links, those leading outside are especially critical, as are links carrying highly sensitive information and links over which certain information must not flow, for example between the production and office networks.

A distribution effect through redundancy only counts if the redundancy really works. Refer to the last failover test. Document every deviation from the maximum principle with particular care.

Step 4: Evaluate and pass on

Finally, list which target objects have a high or very high protection requirement in at least one basic value. Mark them for the risk analysis. This is how the result flows onward:

• Risk analysis: The categories are your yardstick for impact. Align them with your company's risk method, so that protection requirements and risk assessment speak the same language. Our guide to ISO 27005 risk assessment shows how an assessment runs.
• OT zones: In production, protection requirements help you cut the zones under IEC 62443. Do not mix plant sections with a very high protection requirement with uncritical systems in one zone. Critical links from step 3 are candidates for their own conduits.
• Modeling: Only group similar systems if they also share the same protection requirement.

Example from production

The example is invented. A maker of plastic parts rates the process "injection molding line 2".

• Process: Availability high, because an outage of more than a week puts delivery commitments to an automotive customer at risk. Integrity very high, because manipulated parameters can damage the machine and endanger people. Confidentiality normal.
• Applications: The control system inherits integrity very high. The recipe management also gets confidentiality high, because the recipes are trade secrets.
• Systems: Under the maximum principle the line's controllers inherit integrity very high. The virtualization host in the server room carries 14 virtual machines. Each on its own has normal availability; together they would stop planning, the control system and quality inspection: cumulative effect, availability high.
• Rooms: The server room inherits availability high, the line's control cabinet area integrity very high.
• Links: The machine supplier's remote maintenance access leads outside and reaches systems with very high integrity. It is marked as a critical link.

Result: Controllers, control system, virtualization host and remote maintenance access go into the risk analysis. Line 2 gets its own zone, the remote maintenance access its own conduit.

Checklist

• The categories normal, high and very high are described for the company and approved by management.
• Each relevant damage scenario has limits or examples per category.
• Unused or additional scenarios are justified.
• All business processes and applications are rated per basic value, with reasons.
• The owners have confirmed their ratings.
• Protection requirements of IT and ICS systems, rooms and links are derived.
• Cumulative and distribution effects are checked and documented.
• Critical communication links are marked.
• Target objects with high or very high protection requirements are marked for the risk analysis.

Protection requirements in Complass

In a spreadsheet, processes, applications and systems sit on separate tabs, and nobody notices when something changes at the top that should be passed down. In Complass everything is connected:

• On the asset: Every asset carries its protection requirement for confidentiality, integrity and availability as normal, high or very high. When you import from Excel or CSV, you map the three columns directly.
• Gaps in view: The checks in the asset inventory report assets without a rated protection requirement and, with the IEC 62443 extension, assets with a very high requirement but no target security level.
• IT-Grundschutz per target object: In a BSI IT-Grundschutz project you create target objects from the asset inventory, one by one or as a group. The protection requirement follows the maximum principle from linked assets and business processes. If you deviate because of a cumulative or distribution effect, a justification is mandatory.
• Export: The exports of reference documents A.3 (modeling) and A.4 (IT-Grundschutz Check) include an extra sheet with the target objects, their protection requirements and the justification, as Excel or PDF.
• On into risk: For a risk, Complass proposes the impact from the protection requirements of the linked assets, non-binding and with reasons. If the protection requirement of a linked asset changes, the risk shows a hint to reassess it.

Frequently asked questions

Do we need more than three categories?

Not necessarily. If you use more levels, for example because your risk method has five, state which level corresponds to "high" and which to "very high". This controls which target objects go into the risk analysis.

Who rates the protection requirements?

The owners of the processes and applications, because they know the consequences of an outage. The information security officer moderates, keeps the yardstick consistent and documents the result.

How do we handle cumulation with virtualization?

Check every host, every central storage system and services such as directory and backup specifically. They often carry many applications and therefore inherit a higher protection requirement than any single one of them. Justify the rating in writing.

Does this still apply with Grundschutz++?

Yes. According to the BSI, structure analysis, protection requirements and risk analysis remain inputs for the new structure modeling. Requirements at the "elevated" level apply there to target objects with elevated protection requirements.

How often do we review protection requirements?

With every significant change, such as a new process, a new plant or a new service provider, and as part of the regular review of the security concept.

In a demo we show you, using the demo company, how protection requirements carry through from the asset to the risk assessment.

Request a demo Try it for 14 days

Read more

• Guide "ISO 27005 risk assessment explained simply"
• Guide "Building an OT asset inventory in six steps"
• Guide "Zones and conduits explained"
• BSI IT-Grundschutz in Complass
• Risk management: assessment, treatment and residual risk

Not legal advice. This guide gives a general overview and does not replace a case-by-case review. The current versions of BSI Standards 200-2 and 200-3 and the IT-Grundschutz Compendium are authoritative. As of November 2026.