The risk tent¶

Having agreed on which mountain, the “risk tent” represents the shelter of structured risk management, without a reliable framework, your risk assessment collapses under pressure. Choosing the right methodology provides the support structure that keeps your organisation protected, even when conditions change.

Quick reference¶

New to risk assessment? Start with OCTAVE. It is the most accessible for organisations without dedicated risk management teams and emphasises business stakeholder involvement.

Need regulatory compliance? EBIOS aligns well with EU frameworks and ISO standards, particularly in regulated industries.

Want quantitative metrics? MEHARI provides structured scoring for risk prioritisation and board reporting.

Choosing your risk map¶

Before assessing risk, you need a method that everyone can follow without getting lost. A good risk assessment approach clearly identifies potential impacts, evaluates how likely they are, produces consistent results, and stays reliable even when things change.

There are several established ways to do this:

• OCTAVE – a self-directed method focused on aligning risks with organisational goals. It looks beyond technology to consider how strategy, culture, and practices affect security. Best for organisations that want to involve business stakeholders directly in identifying and prioritising risks, rather than leaving it solely to IT teams.

• MEHARI – a modular European framework that integrates neatly with other management systems. It offers tools for analysing and managing risks throughout the security lifecycle. Ideal for organisations needing quantitative risk scores for board reporting or integration with existing management frameworks.

• EBIOS – a French-developed method that defines security needs and objectives before diving into technical risks, ensuring that every control serves a clear business purpose. Well-suited for regulated environments and organisations needing to demonstrate compliance with EU frameworks.

Each approach gets you to the same goal: understanding what could go wrong, how bad it could get, and how to keep climbing safely with a consistent, repeatable map.

Which methodology should you choose?¶

Note: Each table below reflects its methodology’s focus, OCTAVE emphasises threat sources and assets, MEHARI uses quantitative scoring, and EBIOS centres on security objectives. Choose the style that best fits your organisational culture and reporting needs.

OCTAVE style¶

Self-directed, organisational focus, identifying threats, assets, and impacts

Threat source definitions:

• Internal – employees, contractors, insiders with legitimate access

• External – attackers, competitors, malicious actors

• Environmental – natural disasters, infrastructure failures, climate events

• Accidental – human error, unintentional actions

MEHARI style¶

Threat-oriented, quantitative scoring, risk treatment plan

Risk scoring guide:

• Likelihood: Low (rare) / Medium (occasional) / High (frequent or expected)

• Consequence: Low (minimal impact) / Medium (moderate impact) / High (severe impact)

• Risk Score: Combination of likelihood and consequence

  • High: Requires immediate action and senior management attention

  • Medium-High: Action needed within defined timeframe (typically 3-6 months)

  • Medium: Monitor and plan mitigation within 6-12 months

  • Low: Accept or monitor periodically

EBIOS style¶

Risk expressed in terms of security objectives and threat scenarios

Security objectives:

• Confidentiality: Protecting information from unauthorised disclosure

• Integrity: Ensuring information accuracy and preventing unauthorised modification

• Availability: Ensuring systems and data are accessible when needed

• Traceability: Maintaining audit trails for accountability

• Authenticity: Verifying identity and origin of information

• Non-repudiation: Preventing denial of actions taken

• Compliance: Adherence to legal, regulatory, and policy requirements

Tools/Templates¶

Note: Tool availability and maintenance status verified as of November 2025. Check project websites for current status.

Risk treatment options¶

When managing information security risks, selecting an appropriate treatment strategy is critical. ISO/IEC 27005 identifies four primary approaches: avoidance, modification, retention, and sharing. Each option can be applied depending on the nature of the risk, the affected assets, and organisational priorities.

Applying risk treatment: Once you’ve mapped risks using your chosen methodology, apply the appropriate treatment strategy. Most mitigating controls in the tables above represent risk modification (mitigation). If a control is too costly or complex, consider risk retention (acceptance) or sharing (transfer) instead. Risk avoidance means choosing not to engage in the risky activity at all.

Risk avoidance¶

Eliminating a risk by choosing not to engage in the activity that generates it.

Example: Mobile device security

An organisation identifies that employee-owned devices (BYOD) introduce a high risk of malware or data leakage. Instead of attempting complex technical controls, the organisation may decide not to allow BYOD at all, avoiding the risk entirely. In practice, this means requiring staff to use company-issued devices with pre-configured security controls and mobile device management, ensuring consistent security posture across all endpoints.

Example: Cloud/SaaS data storage

A team considers storing highly sensitive customer records in a low-cost, public cloud environment. Given the risk of accidental exposure or misconfiguration, the organisation may choose to avoid using that cloud provider and instead use an on-premises solution with tighter access controls. This eliminates dependency on third-party security whilst accepting the operational overhead of self-hosting.

Risk modification (mitigation)¶

Reducing the likelihood or impact of a risk through controls or process changes.

Example: Network access

Open or misconfigured network ports may allow unauthorised access. The organisation implements firewalls, network segmentation, and intrusion detection systems, reducing both the likelihood of successful attacks and the potential impact of any breach by limiting lateral movement.

Example: Software vulnerabilities

Legacy software may be exploitable. The organisation adopts a patching schedule, automated updates, and secure configuration baselines, mitigating the risk of exploitation. Critical systems receive priority patching within 48 hours, whilst lower-priority systems follow monthly maintenance windows.

Risk retention¶

Accepting a risk, usually after informed assessment, because the cost of mitigation may outweigh the potential impact.

Example: Minor operational disruptions

Periodic short-term network outages may temporarily interrupt internal communications but do not significantly affect critical services. The organisation chooses to retain this risk, accepting minor downtime as tolerable given the cost of implementing fully redundant network infrastructure would exceed the business impact of occasional brief outages.

Example: Low-value hardware loss

Small peripheral devices (e.g., inexpensive mice or keyboards) may be lost or stolen occasionally. Due to the low value and minimal operational impact, the organisation accepts this risk rather than investing in asset tracking systems, RFID tags, or security cables for every peripheral device.

Risk sharing¶

Spreading the consequences of risk with other parties, internally or externally.

Example: Cloud storage services

Sensitive backups are stored in a third-party cloud with strong SLA guarantees and insurance for data loss. The organisation shares the risk with the provider and the insurance company, reducing its direct exposure. The contract specifies liability limits, recovery time objectives, and compensation for service failures.

Example: Vendor dependencies

A key software supplier maintains critical systems. The organisation implements contracts specifying liability, service levels, and disaster recovery obligations, sharing responsibility for availability and security. Escrow agreements ensure access to source code if the vendor ceases operations, further mitigating dependency risk.

Next¶

Head for the gear depot to select the tools and equipment that protect you on the climb.