Practical Risk Management According to ISO 27005: From Theory to Implementation

Risk management is the heart of every Information Security Management System. ISO 27005 provides the methodological framework but deliberately remains abstract. This article shows how to implement the standard in practice—with concrete methods, examples, and recommendations from consulting experience.

ISO 27005 Overview

ISO 27005 describes the risk management process for information security in six phases:

1. Context Establishment – Define framework and criteria
2. Risk Identification – Capture assets, threats, and vulnerabilities
3. Risk Analysis – Assess probability and impact
4. Risk Evaluation – Prioritize risks and compare with criteria
5. Risk Treatment – Select and implement measures
6. Risk Monitoring – Continuous review and adjustment

The standard is deliberately flexible and does not prescribe a specific methodology. This is both strength and weakness: it allows adaptation to the organization but requires your own decisions on implementation.

Phase 1: Context Establishment

Before you assess risks, you must define the framework. This step is often underestimated but is crucial for the consistency of all following activities.

Define Scope

Clearly define what is in scope:

• Which organizational units?
• Which locations?
• Which processes and systems?
• Which interfaces to external parties?

Practical tip: The scope should end at natural organizational boundaries, not in the middle of processes. A risk that is half in scope cannot be meaningfully treated.

Define Risk Criteria

Establish how you will assess risks:

Impact criteria: What does "high," "medium," "low" mean? Define concrete thresholds:

Probability criteria: Here too, you need clear definitions:

Risk acceptance criteria: At what risk level must measures be taken? Who may accept which risks?

Create Risk Matrix

Combine impact and probability in a matrix:

Phase 2: Risk Identification

Risk identification typically follows an asset-based approach: first identify the assets worth protecting, then the threats and vulnerabilities.

Create Asset Inventory

An asset is anything of value to the organization. Categorize systematically:

Primary Assets:

• Business processes (e.g., order processing, product development)
• Information (e.g., customer data, design plans, financial data)

Supporting Assets:

• Hardware (servers, clients, network components)
• Software (applications, operating systems, databases)
• Network (LAN, WAN, internet connection)
• Personnel (administrators, developers, users)
• Locations (data center, offices, production facilities)
• External service providers (cloud providers, outsourcing partners)

Practical tip: Start with business processes and work your way to supporting assets. This ensures you don't overlook anything important and maintain the business context.

Threat Identification

Use established threat catalogs as a starting point:

• BSI-Grundschutz Compendium (elementary threats)
• ENISA Threat Landscape
• MITRE ATT&CK Framework

Typical threat categories:

• Deliberate actions: Cyberattacks, sabotage, theft, social engineering
• Negligence: Misoperation, inadequate maintenance, misconfiguration
• Technical failure: Hardware failure, software bugs, network outage
• External events: Natural disasters, power outage, pandemic

Vulnerability Identification

Vulnerabilities are properties of assets that can be exploited by threats. Typical categories include:

• Technical: Missing patches, weak passwords, unencrypted transmission
• Organizational: Missing policies, unclear responsibilities, lack of training
• Physical: Inadequate access control, missing fire protection
• Personnel: Lack of security awareness, overload, missing backup staff

Practical tip: Use various sources for vulnerability identification: Technical vulnerability scans, penetration tests, interviews with process owners, findings from previous incidents, and audit findings.

Formulate Risk Scenarios

Combine asset, threat, and vulnerability into concrete risk scenarios:

Example:

• Asset: Customer database
• Threat: Ransomware attack
• Vulnerability: Outdated backup strategy, missing network segmentation
• Scenario: "A ransomware attack encrypts the customer database. Due to missing network segmentation, the malware spreads. The backups are also affected because they are not stored offline."

Phase 3: Risk Analysis

In risk analysis, you assess each risk scenario regarding probability and impact.

Qualitative vs. Quantitative Analysis

Qualitative analysis works with categories (low, medium, high). It is faster and simpler but less precise.

Quantitative analysis works with numbers (e.g., "annually expected loss in euros"). It is more precise but requires more data and effort.

Recommendation: Start qualitatively and quantify only the top risks where it is necessary for decisions.

Assess Probability

Consider when assessing:

• Historical data (own incidents, industry data)
• Current threat landscape (threat intelligence)
• Existing protective measures
• Attractiveness of the target for attackers

Practical tip: Distinguish between inherent probability (without measures) and residual probability (with measures). For risk analysis, you assess residual probability.

Assess Impact

Consider all relevant impact dimensions:

• Financial damages (direct and indirect)
• Reputation damages
• Business interruption
• Legal consequences
• Personal injury

The highest individual assessment determines the overall impact.

Phase 4: Risk Evaluation

In risk evaluation, you compare the analyzed risks with your criteria and prioritize them.

Prioritize Risks

Sort risks by risk level. For the same level, additional criteria can be used:

• Treatability (how easily can the risk be reduced?)
• Cost-benefit ratio of treatment
• Regulatory requirements
• Strategic importance of the affected asset

Check Risk Acceptance

Compare each risk with the defined acceptance criteria:

• Is the risk below the acceptance threshold? → Document and monitor
• Is the risk above the acceptance threshold? → Treatment required
• Is the risk critical? → Immediate escalation to management

Phase 5: Risk Treatment

For each risk that needs treatment, select one or more treatment options.

Treatment Options

Risk avoidance: The risky activity is discontinued or redesigned.

Risk reduction: Measures reduce probability and/or impact.

Risk transfer: The risk is transferred to third parties (e.g., cyber insurance).

Risk acceptance: The residual risk is consciously accepted.

Select Measures

When selecting measures, consider:

• Effectiveness (how much does the measure reduce the risk?)
• Cost (investment and ongoing costs)
• Feasibility (technical, organizational, personnel)
• Side effects (impacts on other processes)
• Synergies (does the measure address multiple risks?)

Practical tip: Use ISO 27001 Annex A or BSI-Grundschutz as a measure catalog. Don't reinvent the wheel.

Assess Residual Risk

After the planned implementation of all measures, assess the remaining residual risk. This must be documented and accepted by the responsible party.

Phase 6: Risk Monitoring

Risk management is not a one-time project but a continuous process.

Regular Review

• Risk review: Review all risks at least annually
• Trigger-based reviews: For significant changes (new systems, new threats, incidents)
• Measure tracking: Regularly check implementation status

Key Risk Indicators (KRIs)

Define early indicators that point to rising risks:

• Number of security incidents
• Number of open critical vulnerabilities
• Patch compliance rate
• Results of phishing simulations
• Number of overdue measures

Reporting

Establish regular risk reporting:

• Operational: Monthly status to the CISO
• Tactical: Quarterly to the security committee
• Strategic: Annually to executive management

Common Pitfalls

Too Many Risks

Some organizations identify hundreds of risks and lose track.

Solution: Aggregate similar risks. Focus on the essential ones. A register with 30-50 risks is manageable for most organizations.

Too Abstract Risks

"Cyberattack" is not a risk but a threat category. Risks that are too abstract cannot be meaningfully assessed and treated.

Solution: Formulate concrete scenarios with asset, threat, vulnerability, and impact.

Risk Assessment Without Context

The same threat can represent completely different risks for different organizations.

Solution: Always assess in the context of your specific organization, assets, and protective measures.

Measures Without Effectiveness Testing

Measures are implemented, but no one checks if they work.

Solution: Define for each measure how its effectiveness will be measured. Conduct regular tests.

Risk Management as a Paper Tiger

The risk register exists, but no one uses it for decisions.

Solution: Anchor risk management in decision processes. Every significant change should undergo risk assessment.

Conclusion

Practical risk management according to ISO 27005 does not require a perfect methodology but a pragmatic, consistent approach. The key success factors are:

• Clear criteria: Define what the categories mean before assessment
• Concreteness: Formulate specific scenarios instead of abstract risks
• Focus: Concentrate on the essential risks
• Integration: Anchor risk management in decision processes
• Continuity: Risk management is a process, not a project

Start pragmatically, learn from practice, and improve continuously. A lived, simple risk management is more valuable than a perfect system on paper.

---

Do you want to build or optimize your risk management? We support you with proven methods, templates, and coaching—from conception to implementation.

---

Looking to address these topics in your organization? Siegel Resilience supports you from analysis to implementation – independent, pragmatic and standards-based. Get in touch →