Riskanalysis

Risk analysis forms the foundation of every Information Security Management System (ISMS). It systematically identifies, assesses and treats risks to information security. Without a sound risk analysis, organizations cannot adequately protect their critical information assets.

Navigation: ISMS → Risk Assessment

Core Objectives of Risk Analysis

• Create transparency: Make potential threats to information assets visible
• Enable prioritization: Focus resources specifically on the greatest risks
• Ensure compliance: Meet regulatory requirements (ISO 27001, BSI IT-Grundschutz)
• Promote proactivity: Switch from reactive to preventive security strategy

Relevance in ISMS Context

According to ISO 27001:2022, risk analysis is not optional but a central component of the ISMS. Risk analysis is the basis for:

• The selection of appropriate security measures (Controls from ISO 27001 Annex A)
• The creation of the Statement of Applicability (SoA)
• The continuous improvement of information security

Practice Tip: A risk analysis is particularly necessary when assets have high or very high protection requirements regarding confidentiality, integrity, or availability.

Methodological Approaches: ISO 27001 vs. BSI IT-Grundschutz

ISO 27001 Approach

Characteristics:

• Flexible and individual: Organization defines its own methodology
• Risk-based: Continuous assessment and adaptation
• Internationally recognized: Global standard
• Demanding: Requires methodological maturity

Suitable for:

• Internationally operating companies
• Organizations with specific requirements
• Industries with high regulatory requirements (finance, healthcare)

BSI IT-Grundschutz Approach

Characteristics:

• Structured and comprehensive: Predefined modules and threat catalogs
• Layer model: Multiple security levels reduce dependence on precise assessment
• Practice-oriented: Based on proven standards
• Guided: Clear specifications and guidelines

Suitable for:

• German authorities and public administration
• Companies with complex IT landscapes
• Organizations with less experience in risk assessment

Best Practice: Many organizations combine both approaches - use the structure of IT-Grundschutz with the flexibility of ISO 27001.

The Risk Management Process in Detail

1. Asset Identification

Objective: Capture every information asset worth protecting, leaving none out

Procedure:

• Inventory: Capture hardware, software, data, processes, and personnel
• Grouping: Combine similar assets into Target Object Groups (TOG)
• Classification: Define protection requirements (normal, high, very high)

Practice Example: Instead of evaluating 500 individual servers, they are grouped by operating system, function, or criticality (e.g., “All Oracle Linux Servers - Production”).

2. Risk Identification

Objective: Systematically capture threats and vulnerabilities

Components:

• Threats: What could go wrong?
• Vulnerabilities: Where are we vulnerable?
• Damage scenarios: What would be the consequences?

Catalogs and Sources:

• BSI IT-Grundschutz Compendium (Threat catalog)
• CVE databases for technical vulnerabilities
• Industry-specific threat intelligence

3. Risk Assessment

Central Concepts:

Inherent Risk

Definition: The risk without any protective measures - the “naked” threat situation.

Example: Unencrypted data transmission during server migration

• Probability of occurrence: High
• Damage potential: €175,000
• Inherent risk: High

Target Risk

Definition: The acceptable risk level after implementation of measures - in accordance with the organization’s risk appetite.

Determination based on:

• Regulatory requirements
• Business objectives
• Stakeholder expectations
• Cost-benefit analysis

4. Risk Treatment

Four Strategies:

A. Risk Reduction

• Most common strategy: Implement controls
• Example: Encryption, access controls, monitoring
• Implementation: Select controls from ISO 27001 Annex A

B. Risk Avoidance

• Stop activity: Eliminate risk source
• Example: Renounce cloud storage of critical data
• When sensible: Risk exceeds any possible benefit

C. Risk Transfer

• Shift responsibility: Insurance or outsourcing
• Example: Cyber insurance, managed security services
• Important: Risk remains, only responsibility is shared

D. Risk Acceptance

• Conscious decision: Tolerate risk
• Prerequisite: Within risk tolerance
• Documentation: Formal acceptance by management required

Assigning a control from within the risk

Navigation: ISMS → Risk Assessment → open the risk

The measure you mitigate a risk with hangs off the risk itself. The path there is easy to miss:

1. Fill in the risk assessment first. Without an assessed inherent risk you cannot create a treatment.
2. Under risk treatment, create a treatment, pick the strategy (for example Acceptance) and set the target risk.
3. Save.
4. In the treatment table, drag the horizontal scrollbar at the bottom to the right. The column with the three-dot menu sits at the far right and is off screen by default.
5. Three-dot menu → Add control, pick the control from the catalog, for example 5.18 Access rights, and assign it.

This assignment does two things at once. The risk belongs to a target object group. Assign a control to the risk and the control is assigned to that group as well, where it shows up in Modeling. You do not have to create it a second time.

Two views on the same assignment

There are two ways to assign a control, and both end up in the same data:

Route	Starting point	When it fits
Risk assessment	one specific risk	The control answers an assessed risk. The link to the target object group comes along for free.
Modeling	a target object group	The control belongs to the group’s baseline, regardless of any single risk.

Which one you pick is a question of direction, not of outcome. Risk-driven you work from the threat to the measure; in modeling you work from the object to the measure.

Tracking implementation

Implementation status belongs on the control, not on the risk. Open the control, Edit, set the status to Implemented, Save. Only that step moves the gap analysis.

5. Residual Risk Management

Definition: The remaining risk after implementation of all measures.

Process:

1. Assess effectiveness of implemented controls
2. Recalculate residual risk
3. Compare with target risk
4. If necessary, take further measures or formally accept

Practice Tip: Residual risk is never zero - it’s about an acceptable level, not perfection.

The 5-Step Workflow

1. Risk Identification (Yellow)

   • Assign threats
   • Document vulnerabilities
   • Define damage scenarios

2. Risk Assessment (Yellow)

   • Determine inherent risk
   • Define target risk
   • Complete documentation

3. Risk Treatment (Yellow)

   • Choose strategy
   • Plan measures
   • Assign responsibilities

4. Risk Mitigation (Yellow)

   • Implement controls
   • Execute measures
   • Monitor status

5. Residual Risk (Green = Completed)

   • Assess residual risk
   • Obtain acceptance
   • Complete documentation

Color Coding:

• Green: Step completed
• Yellow: In progress
• Gray: Not yet started

Authorization Concept

Global Role: ISMS_RISKS_ANALYSIS_ACCESS

• Basic requirement for access to risk analysis

Granular Permissions:

• Risks - Read/Create/Edit/Delete
• Threats - Assign/Edit/Delete
• Measures - Create/Edit/Delete
• Controls - Assign/Edit/Delete
• Vulnerabilities - Create/Edit/Delete

Glossary

Asset: Any value to the organization (hardware, software, data, processes, personnel)

Control: Security measure for risk mitigation (technical, organizational, physical)

CVE: Common Vulnerabilities and Exposures - database of known vulnerabilities

GRC: Governance, Risk Management, and Compliance

Inherent Risk: Risk without consideration of controls

Residual Risk: Remaining risk after implementation of measures

SoA: Statement of Applicability - applicability statement for ISO 27001

TOG: Target Object Group - grouping of similar assets in the ISMS

Target Risk: Desired/acceptable risk level