Protection Requirements Assessment

The Protection Requirements Assessment (PRA) is a central component of the IT security concept according to IT-Grundschutz and ISO/IEC 27001. It answers the fundamental question: How much protection do our information, applications, and IT systems need?

Through systematic analysis, it is determined which assets are critical for the company and which security measures are appropriate. This creates the foundation for an efficient and effective Information Security Management System (ISMS).

Why is the Protection Requirements Assessment relevant?

• Resource optimization: Security measures are deployed specifically where they are most needed
• Transparency: Traceable justification for security investments
• Compliance: Meeting regulatory requirements (BSI IT-Grundschutz, ISO 27001)
• Risk minimization: Systematic identification and assessment of protection requirements
• Prioritization: Clear decision basis for implementing protective measures

The Three Protection Goals in Detail

Note: You can adjust the protection goals and values in the settings.

The protection requirements assessment is based on the three fundamental protection goals of information security:

1. Confidentiality

Definition: Information can only be viewed by authorized persons.

Practical meaning:

• Protection against unauthorized access to sensitive data
• Preservation of trade secrets
• Compliance with data protection regulations
• Prevention of industrial espionage

2. Integrity

Definition: Information can only be modified by authorized persons. All changes are authentic and traceable.

Practical meaning:

• Protection against unauthorized manipulation
• Ensuring data accuracy
• Traceability of changes
• Prevention of data corruption

3. Availability

Definition: Information and systems are available at the right time and place.

Practical meaning:

• Ensuring business continuity
• Minimizing downtime
• Guaranteeing critical processes
• Compliance with Service Level Agreements (SLAs)

Protection Requirement Categories

Protection requirements are divided into three categories based on potential damage impacts:

Normal

Criteria:

• Damage impacts are limited and manageable
• Financial losses remain tolerable
• Maximum downtime: 24-72 hours
• Minor or only internal reputation damage

Typical examples:

• Internal documentation
• Non-critical administrative processes
• Publicly accessible information

High

Criteria:

• Damage impacts can be considerable
• Significant financial losses, but not existentially threatening
• Maximum downtime: 1-24 hours
• Broad reputation or trust impairment possible

Typical examples:

• Personal data
• Important business processes
• Critical customer information

Very High

Criteria:

• Existentially threatening, catastrophic impacts possible
• Fundamental violations of laws and regulations
• Maximum downtime: < 1 hour
• Danger to life and limb possible

Typical examples:

• Critical infrastructure systems
• Highly sensitive research data
• Systems with potential for personal endangerment

Damage Scenarios in Practice

During protection requirements assessment, various damage scenarios are systematically considered:

Note: You can store this information in the respective scope.

1. Violation of Laws/Regulations/Contracts

• Normal: Minor contract violations, minimal penalties
• High: Significant legal consequences, high fines
• Very High: Fundamental law violations, ruinous liability damages

2. Impairment of Informational Self-Determination

• Normal: Possible impairment of social standing
• High: Significant impairment of economic circumstances
• Very High: Danger to personal freedom of the affected person

3. Impairment of Task Fulfillment

• Normal: Classified as tolerable by those affected
• High: Classified as intolerable by individuals
• Very High: Classified as intolerable by all

4. Financial Impacts

• Normal: Tolerable financial damage
• High: Considerable but not existentially threatening losses
• Very High: Existentially threatening financial damage

Implementation of Protection Requirements Assessment

Phase 1: Preparation

1. Definition of Protection Requirement Categories
   • Adaptation to organization-specific requirements
   • Establishment of concrete threshold values
   • Coordination with management

2. Identification of Damage Scenarios
   • Consider industry-specific risks
   • Include regulatory requirements
   • Analyze historical incidents

Phase 2: Implementation

Protection Requirements Assessment for Business Processes

Procedure:

1. Identify all relevant business processes
2. Assess confidentiality, integrity, and availability for each process
3. Involve department management in the assessment
4. Document justification

Practice Tip: Use standardized questionnaires for uniform assessment. This accelerates the process and ensures comparability.

Protection Requirements Assessment for Applications

Inheritance Principles:

• Maximum principle: The highest protection requirement of all supported business processes is adopted
• Cumulation effect: Multiple processes with normal protection requirements can together result in high protection requirements

Important: The cumulative effect is only activated when higherordinate target object groups are linked to target object group is 3 or more.

Example: A CRM application supports multiple sales processes. Individually, these have normal protection requirements, but a complete failure would mean significant revenue losses → Availability: high

Protection Requirements Assessment for IT Systems

Special considerations:

• Protection requirements inherit from applications running on them
• Shared resources require special consideration
• Virtualization can lead to cumulation effects

Protection Requirements Assessment for Communication Connections

Identify critical connections:

• Internet connections
• Connections over public networks
• Transmission of sensitive data
• Single points of failure

Protection Requirements Assessment for Premises

To be considered:

• Physical access protection
• Environmental conditions (climate, fire protection)
• Concentration of critical systems
• Redundancies and alternative locations

Integration into the fuentis Suite

Functionalities in the ISMS Module

The fuentis Suite supports protection requirements assessment through:

1. Structured Recording

• Protection Requirements Tab: Central recording of all protection requirements
• Dropdown menus for standardized categories
• Free text fields for detailed justifications
• Custom PR Values: Extension with organization-specific protection goals

2. Automated Inheritance (Propagation)

• Propagation Tab: Automatic transfer of protection requirements
• Override functions for manual adjustments
• Visualization of inheritance chains
• Bulk operations for efficient processing

3. Intelligent Recommendations

• Algorithm-based analysis of linked assets
• Maximum principle and cumulation effect are automatically considered
• Preview function shows effects before adoption
• Multi-select options for flexible selection

4. Workflow Integration (Four-Eyes Principle)

• Submit → Review → Approve/Reject → Reopen
• Status tracking: Initial, Submitted, Approved, Rejected, Reopened
• Audit trail: Complete documentation of all changes
• Custom workflows: Adaptation to organization-specific approval processes

5. Questionnaire Module

• Standardized questionnaires for uniform assessment
• Template library with best practices
• Automatic evaluation and categorization
• Export functions for reports and audits

Authorization Concept

Global Roles:

• ISMS_PROTECTION_REQUIREMENT_ACCESS: Basic access to PRA functions

Granular Permissions:

• Scopes - PRA Read: Read access to scope protection requirements
• Scopes - Edit Protection Requirements: Editing of scope protection requirements
• TargetObject Groups - PRA Read: Read access to TOG protection requirements
• TargetObject Groups - Edit Protection Requirements: Editing of TOG protection requirements
• Propagation of Protection Requirements: Execution of inheritance
• TargetObject Groups - Recommendation: Use of recommendation function

Best Practices for Implementation

1. Preparation and Planning

✓ Secure management commitment

• Involve senior management early
• Clarify budget and resources
• Communicate commitment

✓ Assemble project team

• Include department representatives
• Ensure IT security expertise
• Define clear responsibilities

2. Implementation

✓ Follow top-down approach

• Start with critical business processes
• Gradually advance to technical assets
• Identify and implement quick wins

✓ Strive for standardization

• Use uniform assessment criteria
• Utilize questionnaires and templates
• Conduct regular calibration meetings

✓ Ensure documentation

• Justify all decisions
• Make assumptions explicit
• Document changes traceably

3. Quality Assurance

✓ Consistently apply four-eyes principle

• Conduct independent reviews
• Build in plausibility checks
• Plan regular audits

✓ Continuous improvement

• Document lessons learned
• Regularly optimize processes
• Establish feedback loops

4. Avoid Common Pitfalls

Avoid overestimation

• Not everything is “very high” critical
• Make realistic assessments
• Consider cost-benefit ratio

Prevent underestimation

• Don’t underestimate cumulation effects
• Fully capture dependencies
• Think through worst-case scenarios

Control scope creep

• Define clear system boundaries
• Maintain prioritization
• Choose iterative approach

Connection with Other ISMS Processes

Risk Analysis

Protection requirements assessment forms the basis for:

• Identification of relevant threats
• Assessment of probability of occurrence
• Prioritization of risk scenarios

Measure Selection

Based on protection requirements:

• Appropriate security measures are selected
• Implementation priorities are established
• Resources are optimally allocated

Business Continuity Management

Protection requirements flow into:

• Definition of Recovery Time Objectives (RTO)
• Establishment of Recovery Point Objectives (RPO)
• Prioritization in recovery

Compliance Management

Documentation supports:

• Evidence for auditors
• Meeting regulatory requirements
• Transparency to stakeholders

Glossary

Asset: Value or resource of an organization (information, system, process)

Cumulation Effect: Increase in protection requirements through concentration of multiple assets

Maximum Principle: Adoption of the highest protection requirement during inheritance

Propagation: Automatic inheritance of protection requirements between linked assets

TOG (Target Object Group): Logical grouping of assets

4EP (Four-Eye Principle): Four-eyes principle for quality assurance

Key Messages at a Glance

1. Foundation of Information Security: Protection requirements assessment is not a bureaucratic obligation but the basis for effective and efficient security measures.

2. Three protection goals in focus: Confidentiality, integrity, and availability must be individually assessed for each asset and categorized as normal/high/very high.

3. Consider inheritance: Protection requirements inherit from business processes through applications to IT systems - maximum principle or cumulation effects can lead to higher protection requirements.

4. Use tool support: The fuentis Suite automates many aspects of protection requirements assessment and ensures consistent implementation through workflows and questionnaires.

5. Continuous process: Protection requirements assessment is not a one-time task but must be updated when the IT landscape or business processes change.