Protection Needs Assessment: Evaluating Confidentiality, Integrity, and Availability

What is a protection needs assessment?

The protection needs assessment is a structured method for determining how worthy of protection each asset in the organization truly is. It answers the question: what damage does our organization suffer if the confidentiality, integrity, or availability of this asset is violated?

The concept originates from the BSI Standard 200-2 (IT-Grundschutz methodology) and is a central building block of the security process there. But even if you are not pursuing a BSI IT-Grundschutz certification and are instead building your ISMS according to ISO 27001 or implementing NIS2 requirements, the protection needs assessment is a proven method for determining protection needs systematically and traceably.

The decisive difference from an informal assessment like "that's just important" lies in traceability. The protection needs assessment forces you to concretely justify for each asset and each protection goal why you place it in a specific category. This justification is based on damage scenarios, not gut feeling. And that is exactly what an auditor wants to see during a certification audit or what the BSI wants during a NIS2 review.

The three protection goals: CIA in detail

The three protection goals of information security form the foundation of every protection needs assessment. They are known by the English acronym CIA (Confidentiality, Integrity, Availability) and are often referred to in German-speaking countries as "the three pillars of information security."

Confidentiality

Confidentiality means that information is only accessible to persons or systems authorized to access it. A loss of confidentiality occurs when unauthorized parties gain access to information not intended for them.

This sounds abstract but quickly becomes concrete: when an attacker copies the customer database, confidentiality is violated. When an employee sends an email containing salary data to the wrong distribution list, the same applies. When a laptop with an unencrypted hard drive containing contract drafts is stolen, likewise.

The assessment of confidentiality depends heavily on what type of information an asset processes or stores. Personal data is subject to DSGVO (GDPR) and has elevated protection needs for that reason alone. The proper classification of this data is the foundation. Trade secrets, financial data, and strategic plans are also typical candidates for high confidentiality protection needs.

Integrity

Integrity ensures that information is correct, complete, and unaltered. A loss of integrity means that data has been undetectably falsified or its correctness can no longer be guaranteed.

Integrity violations are often more dangerous than confidentiality violations because they are harder to detect. If someone steals your customer data, you may notice quickly (ransom demand, data leak on the darknet). But if someone changes a single value in your accounting database, manipulates a price in a quote, or redirects a DNS entry, it can go undetected for months and cause considerable damage.

Integrity is particularly relevant for systems where data serves as the basis for decisions: financial systems, production data, measurement and test results, audit logs, and configuration data.

Availability

Availability means that systems and information are accessible and usable when needed. A loss of availability occurs when a system fails, responds too slowly, or data is not retrievable.

Availability is the protection goal where the impacts are most immediately felt. The question of how long a system may be down at most is systematically answered in the Business Impact Analysis. When the email server goes down, every employee notices within minutes. When the ERP system is unreachable, order processing, procurement, and accounting come to a halt. When production control fails, in the worst case the entire manufacturing stops.

The assessment of availability revolves around two central questions: how long may the asset be down at most (Maximum Tolerable Downtime)? And how current must the data be after recovery (Recovery Point Objective)?

Why the separate assessment matters

A common beginner's mistake is to classify an asset generically as "critical" or "non-critical." But the separate assessment by the three protection goals is essential because an asset can have different protection needs for each goal and because different protection goals require different measures.

Let us take the example of a public website: confidentiality is low because all content is public anyway. Integrity is high because a manipulation of the website (defacement, malware injection) causes significant reputational damage. Availability depends on whether the website only provides information or generates revenue.

From these different protection needs, different measures are derived: for integrity, you need a web application firewall, content security policy, file integrity monitoring, and change management. For availability, you need redundancy, CDN, monitoring, and an emergency plan. For confidentiality, you need hardly any special measures for a public website.

BSI protection needs categories

The BSI defines three protection needs categories, each determined by the severity of possible impacts.

Normal

The protection need is "normal" when the damage impact is limited and manageable. This does not mean that no protection is necessary. It means that the standard protective measures (the so-called basic and standard requirements of BSI IT-Grundschutz) are sufficient to bring the risk to an acceptable level.

Typical formulation: "The potential damage is limited and manageable. No existentially threatening consequences are expected."

Examples for "normal" protection needs:

• General internal information whose disclosure would not cause significant damage
• Systems whose failure for up to 24 hours is tolerable without significantly impairing business operations
• Data whose falsification would be annoying but easily detectable and correctable

High

The protection need is "high" when the damage impact is considerable. Standard protective measures are not sufficient; additional measures beyond basic protection must be taken.

Typical formulation: "The damage impact can be considerable. Significant financial losses, noticeable impairment of task fulfillment, or violations of regulations with serious consequences are likely."

Examples for "high" protection needs:

• Personal data whose disclosure could significantly harm data subjects
• Business-critical systems whose failure within a few hours leads to noticeable revenue losses
• Financial data whose manipulation could lead to erroneous bookings and wrong business decisions

Very high

The protection need is "very high" when the damage impact can reach an existentially threatening, catastrophic level. Individually designed protective measures are required that go beyond standard and enhanced requirements.

Typical formulation: "The damage impact can reach an existentially threatening level. Existentially threatening financial losses, serious violations of law, or endangerment of personal safety are possible."

Examples for "very high" protection needs:

• Health data whose disclosure would have existential consequences for those affected
• Production control systems whose manipulation could cause personal injury
• Systems whose failure brings the entire business to a standstill and causes six-figure damages within hours

Damage scenarios: the basis of the assessment

The assignment of an asset to a protection needs category is not arbitrary but based on concrete damage scenarios. The BSI defines six damage categories used in the assessment.

The six damage categories

1. Violation of laws, regulations, or contracts What legal consequences are likely? GDPR fines (up to 4% of annual revenue), NIS2 penalties (up to 10 million euros or 2% of revenue), contractual penalties toward customers, liability claims. A system processing personal data has at minimum a high confidentiality protection need solely due to the GDPR.

2. Impairment of informational self-determination Is personal data affected? How sensitive is this data? Health data, religious affiliation, or biometric data (special categories under GDPR Art. 9) lead to a very high protection need. Contact data of business customers, however, often justifies only a normal to high protection need.

3. Impairment of personal safety Can people come to harm if the protection goal is violated? For IT systems in office environments, this is rarely relevant. For production controls, medical devices, or building automation, however, an integrity or availability loss can indeed cause personal injury.

4. Impairment of task fulfillment How severely are business operations impaired? An archive failure is annoying but core processes continue. An ERP system failure paralyzes procurement, production, sales, and accounting. The question is: which business processes are affected and how long can the organization work without this asset?

5. Negative impact on public perception (reputation) What reputational damage does an incident cause? A data leak at an IT service provider that advertises information security is more devastating than at a craft business. But even for smaller companies, a publicly known security incident can sustainably damage customer trust.

6. Financial impact What does the damage cost directly and indirectly? Direct costs include recovery, forensic investigation, legal advice, notification of affected persons, and potential fines. Indirect costs arise from production downtime, lost revenue, customer attrition, and increased insurance premiums.

How to work through the scenarios

For each asset and each protection goal, you formulate concretely what would happen. Not abstractly ("could lead to damage") but with reference to your organization and your situation.

Instead of writing "An ERP system failure would have considerable impact," you should write: "An ERP system failure means that no orders can be captured, no delivery notes created, and no invoices issued. With average daily revenue of 85,000 euros and an estimated recovery time of 8 hours, this results in a direct revenue loss of approximately 35,000 euros, plus overtime costs for catch-up work."

This specificity has two advantages: it makes the assessment traceable (for yourself, for management, for the auditor), and it prevents you from precautionarily setting the protection need too high. In ISMS Lite, damage scenarios are stored directly with the asset and automatically linked to the risk assessment, so the justifications are retrievable at any time. Because an excessively high protection need leads to over-dimensioned measures that consume resources needed elsewhere.

Inheritance of protection needs

Inheritance is one of the most important concepts in the protection needs assessment and simultaneously one of the most frequently overlooked. The basic idea: the protection need of an asset is inherited by the assets it needs to function.

How inheritance works

If your ERP system has a very high availability protection need, then the server it runs on also needs at least the same availability protection need. Because what good is a highly available ERP system if the server it runs on is only secured with normal protective measures?

Inheritance typically works downward through the infrastructure layers:

Business process (order processing)
  └── Application (ERP system) → Availability: very high
        └── Database (PostgreSQL) → inherits: Availability very high
              └── Server (production server) → inherits: Availability very high
                    └── Network (core switch) → inherits: Availability very high
                          └── Infrastructure (UPS, cooling) → inherits: Availability very high

Maximum principle

When multiple applications run on the same server, the maximum principle applies: the server inherits the highest protection need of all applications it hosts.

Suppose three applications run on one server:

• Application A: Confidentiality high, Integrity normal, Availability high
• Application B: Confidentiality normal, Integrity high, Availability normal
• Application C: Confidentiality very high, Integrity high, Availability normal

The server inherits: Confidentiality very high (from C), Integrity high (from B and C), Availability high (from A).

This maximum principle also shows why segmentation can be beneficial: if you move the application with very high confidentiality protection needs to its own server, the other servers do not need to be protected with very high confidentiality measures. This saves effort and costs.

Cumulation effect

There is an exception to the pure inheritance principle: the cumulation effect. It occurs when many individual assets with normal protection needs are bundled on one system and the sum of individual risks produces a higher overall risk.

A single workstation may have a normal protection need. But a terminal server where 50 employees work simultaneously deserves a higher availability protection need simply through cumulation, because its failure affects 50 workstations simultaneously.

Distribution effect

The counterpart to the cumulation effect is the distribution effect. It reduces the inherited protection need when risk is distributed through redundancy.

If your email system runs on two redundant servers that can replace each other, then the availability protection need for the individual server is lower than for the email system as a whole. If one server fails, the other takes over. The individual server therefore does not need to carry the full availability requirement of the overall system.

Important: the distribution effect only applies to availability. For confidentiality, the opposite occurs: two servers with the same data double the attack surface because an attacker only needs to compromise one of them.

Practical examples: conducting a protection needs assessment

The theory becomes tangible when we apply it to concrete systems. The following examples show the protection needs assessment for typical assets of a mid-market company.

Example 1: ERP system

Derived measures: Database encryption, fine-grained access control, logging of all changes, automated integrity checks, high-availability cluster, backup with RPO under 1 hour, documented recovery plan with regular tests.

Example 2: Email system (Microsoft 365)

Derived measures: Multi-factor authentication for all mailboxes, conditional access policies, email encryption for sensitive communication (S/MIME or encryption gateway), anti-phishing measures, regular awareness training, mailbox backup (Microsoft does not guarantee complete data recovery).

Example 3: File server / SharePoint

Derived measures: Access control concept with departmental structures and need-to-know principle, versioning and recycle bin functionality, regular permission reviews, daily backup, encryption of sensitive areas.

Example 4: Production control (OT system)

Derived measures: Strict network segmentation (IT/OT separation), integrity monitoring of control software, whitelisting of permitted applications, physical access controls, redundant control systems, specialized backup solution for OT systems, contingency plans for manual production.

Documenting the protection needs assessment

The protection needs assessment is only as good as its documentation. In an audit, you must not only show that you conducted an assessment but also traceably demonstrate how you arrived at the results.

What must be documented

For each assessed asset, you document:

Asset reference: Reference to the asset in the inventory (asset ID, name, category).

Assessment per protection goal: For confidentiality, integrity, and availability, the respective protection needs category (normal, high, very high).

Justification: For each protection goal, a concrete justification specific to your organization. Which damage scenarios did you consider? Which damage categories are relevant? Why did you choose this classification and not a higher or lower one?

Inheritance notes: If the protection need was adjusted through inheritance, cumulation, or distribution, this must be traceably documented. Example: "The availability protection need was raised from 'normal' to 'high' because the asset, as an infrastructure component, partially inherits the protection need of the ERP system (very high). Due to the redundant design (two servers in a cluster), the distribution effect applies, so the individual server is rated as 'high.'"

Responsible: Who conducted the assessment, who approved it?

Date: When was the assessment conducted, when was the last review?

Formal presentation

There is no prescribed format for the documentation. A tabular overview supplemented by more detailed justifications in an accompanying document has proven effective. The overview table could look like this:

The overall assessment is derived from the highest individual value of the three protection goals (maximum principle). It serves as quick orientation but does not replace the differentiated assessment per protection goal.

Relationship with the risk assessment

The protection needs assessment is not an isolated step but part of a chain leading from the asset inventory through protection needs to the risk analysis and finally to measure planning.

From the protection needs assessment to risk analysis

The protection needs assessment provides the damage side of the risk equation. It tells you: if the confidentiality of this asset is violated, the damage is "high." The risk analysis adds the threat and vulnerability side: how likely is it that this violation occurs?

Risk results from the interplay of both dimensions:

Risk = Probability of occurrence x Damage magnitude (from protection needs)

An asset with a very high availability protection need and a high probability of availability loss (e.g., because there is no redundancy and the hardware is aging) yields a critical risk requiring immediate action.

The same asset with a low probability of occurrence (because it is already redundantly designed and regularly maintained) yields an acceptable residual risk despite the high protection need.

Deriving measures

The protection need also determines the appropriateness of measures. For assets with normal protection needs, standard measures suffice: regular updates, basic security, standard backup. For assets with high protection needs, enhanced measures are added: encryption, strengthened access controls, shorter backup intervals, monitoring. For assets with very high protection needs, individually designed measures tailored to the specific risk are necessary: high-availability clusters, dedicated security zones, real-time monitoring, close controls. The risk treatment then documents which option you choose for each identified risk.

This proportionality is important because security measures cost money and consume resources. An asset with normal protection needs does not deserve maximum-security treatment, and an asset with very high protection needs must not be treated with just standard measures.

Regular review

The protection needs assessment is not a one-time exercise. It must be regularly reviewed and updated as needed. Typical triggers for a reassessment include:

• New assets are added or existing ones are decommissioned
• Business processes change and with them the significance of certain assets
• New legal requirements arise (NIS2 has raised the protection needs of many assets)
• Security incidents show that an assessment was too low
• Organizational changes (mergers, spin-offs, new locations) shift dependencies
• The annual management review as a fixed date for the overall review

Typical mistakes in the protection needs assessment

From practice, we know recurring problems you can avoid from the start:

Everything is "high" or "very high." If you classify everything at maximum out of caution, the assessment loses its value. You cannot protect everything with maximum effort, and prioritization is lost. Be honest and differentiated. A test system simply has different protection needs than the production database.

Justifications are missing or generic. "High protection need due to data protection" is not a justification. A justification describes the concrete damage scenario for your organization and quantifies the damage as far as possible.

Inheritance is ignored. The database server has "normal" protection needs even though it hosts the highly critical ERP database. This is a contradiction that is immediately noticed in an audit and in an emergency leads to insufficient protective measures for the server.

One-time assessment without review cycle. Last year's protection needs assessment does not reflect today's reality if cloud services have been introduced, locations consolidated, or new business areas developed since then.

Only IT assesses. The protection needs assessment requires professional knowledge about the value of the processed information. The IT department knows the technical dependencies, but the business departments know the business value. Both perspectives must come together.

How to proceed: step by step

If you want to introduce the protection needs assessment in your organization, follow this approach:

Step 1: Preparation. Ensure that a current asset inventory is available. Without an inventory, no protection needs assessment. Define the protection needs categories and the damage scenarios you want to use. The BSI provides good templates that you can adapt to your organization.

Step 2: Information assets first. Start with the information assets (customer data, financial data, personnel data) because their protection needs form the basis for assessing the processing systems.

Step 3: Applications and services. Assess the business applications and services that process this information. Involve the asset owners from the business departments.

Step 4: Infrastructure. Assess servers, network components, and cloud services. Apply inheritance here: the infrastructure inherits the protection needs of the applications it supports.

Step 5: Plausibility check. Review the overall assessment for consistency. Are there contradictions? Is the distribution plausible (not everything "very high")? Are the inheritances correct?

Step 6: Documentation and approval. Document the results with justifications, present them to executive management for approval, and define the next review date.

The entire process typically takes two to four weeks for a company with 50 to 250 employees if a current asset inventory is available. Without an inventory, the inventory work must be added, extending the timeframe to six to eight weeks.

Your next step

The protection needs assessment connects your asset inventory with the risk assessment and gives you a reliable foundation for prioritizing protective measures. If you are just starting with your ISMS, focus first on the 15 to 20 most important assets. A clean protection needs assessment for the critical assets is more valuable than a superficial assessment for 200 assets.

Further reading

• IT Asset Management for the ISMS: Inventory, Criticality, and Classification
• Risikobewertung im ISMS: Methodik, Matrix und Praxisbeispiel
• Business Impact Analyse (BIA) durchführen: Geschäftsprozesse bewerten
• Risikobehandlung: Mitigieren, Akzeptieren, Transferieren oder Vermeiden
• ISMS aufbauen: Der komplette Leitfaden für Unternehmen mit 50 bis 500 Mitarbeitern

And remember: the protection needs assessment is a tool, not an end in itself. Its value does not lie in the table that comes out at the end, but in the conversations you have along the way. When the head of sales thinks for the first time about what damage a CRM failure would actually cause, and the head of HR realizes what a disclosure of personnel data would mean for those affected — then the protection needs assessment has fulfilled its purpose.