Creating Risk Scenarios

First of all, how do Risk Scenarios help us?

First of all Risk Scenarios are part of Risk Identification.

We can mention:

  • provide description of threat events which have uncertain impact,
  • conceptualizing risks which contributes to risk identification,
  • and simply documenting the risks.

Good Risk Scenario should include following elements.

  1. Description of an Actor or Threat Community.
  2. Description of an Intent or Motivation.
  3. Description of a Threat Event – what might cause a Security Incident?
  4. Description of an affected Asset or Resource.
  5. What was the effect of the impact? How much loss do we feel?
  6. Description of the timing and timeline.

In most of the cases Risk Scenarios development can use two models: top-down approach and bottom-up approach.

Top-down approach starts with business goals and the impact on those goals. It is well suited for general enterprise Risk Management strategy. The advantage is that it deals with objectives which had been already identified as important for an enterprise.

Bottom-up approach starts with individual enterprise situation. It focuses on technical proceedings or services. It gives more technical insight, however might not retain interest of higher management.

From the high-level perspective Risk Scenarios enable you to:

  • identify risks,
  • analyse those risks and their frequency and magnitude, and finally
  • evaluate those risks based risk evaluation criteria and risk acceptance criteria.


Use generic scenarios as a starting point.
Deduce complex scenarios from simple ones.
Complex technical scenarios are best developed from the bottom-up.

Some basics about Vulnerabilities

When identifying vulnerabilities one should focus on three areas:

  • people,
  • technology,
  • processes.

The whole game is to define, identify and classify potential points of compromise.

One of the most common way to validate results of Vulnerability Assessment is to run Penetration Tests. Following are the most popular areas where Penetration Testing is conducted:

  • network vulnerabilities (misconfiguration or poor architecture)
  • physical access
  • applications and web-facing services (one of the most common attack vector)
  • utilities (rely on controlled environmental conditions)
  • supply chain
  • equipment
  • cloud computing
  • big data

Remember that Penetration Tests may include:

Penetration tests may include:

  • networks and applications (only 1/3 of vulnerabilities within enterprise!)
  • people
  • processes
  • physical access
  • wireless
  • third parties

The easiest way is to use automated Vulnerability Assessment – e.g. software solution. Another level is to run Penetration Testing. Both of them however, should be accompanied with potential Root Cause Analysis (e.g. pre-mortem analysis).


The most common Threat Modelling Models


STRIDE is a useful method for identifying and addressing security threats in software development, promoting robust and secure system designs.

Spoofing: Pretending to be someone else to gain unauthorized access.

Tampering: Altering data or code to cause harm.

Repudiation: Denying actions to avoid accountability.

Information Disclosure: Exposing sensitive information to unauthorized entities.

Denial of Service (DoS): Disrupting services to make them unavailable to users.

Elevation of Privilege: Gaining higher access levels than permitted.


PASTA is a comprehensive, risk-focused threat modeling method that helps organizations align their security strategies with business goals while systematically identifying and mitigating potential threats.

Definition of Objectives (DO): Establish the business and security objectives.

Definition of Technical Scope (DTS): Define the technical environment, including infrastructure, applications, and dependencies.

Application Decomposition and Analysis (ADA): Break down the application to understand its components and data flows.

Threat Analysis (TA): Identify potential threats and vulnerabilities in the system.

Vulnerability and Weakness Analysis (VWA): Assess the identified vulnerabilities and their potential impact.

Attack Modeling and Simulation (AMS): Simulate attacks to understand how threats could exploit vulnerabilities.

Risk and Impact Analysis (RIA): Analyze the risks and their potential impact on the business.


Privacy threat modeling framework specifically designed to address privacy concerns in software systems. It helps identify and mitigate privacy threats by categorizing them into distinct types.

Linkability: The risk that two pieces of information can be linked to identify an individual.

Identifiability: The potential to uniquely identify an individual within a dataset.

Non-repudiation: Ensuring actions or transactions cannot be denied by the entities involved.

Detectability: The likelihood that an adversary can detect whether an individual’s data is present in a dataset.

Information Disclosure: The unauthorized release of private information.

Unawareness: The state of individuals being unaware of how their personal data is being used or collected.

Non-compliance: Failure to adhere to privacy laws, regulations, or policies.


PnG (Persona non Grata) threat modeling is a methodology designed to identify and assess potential threats by focusing on the motivations and capabilities of potential adversaries. It emphasizes understanding the perspective of those who might seek to compromise a system, considering their goals and the methods they might use.

Adversary Profiling: Identifying and understanding the different types of adversaries that might pose a threat. This includes their goals, resources, skills, and typical attack methods.

Attack Scenarios: Developing detailed scenarios of how adversaries might attempt to achieve their objectives. This involves considering the steps they would take to exploit vulnerabilities.

Motivation Analysis: Assessing the motivations behind potential threats. Understanding why an adversary would target a system helps prioritize the threats based on their likelihood and potential impact.

Capability Assessment: Evaluating the capabilities of potential adversaries. This includes their technical skills, resources, and access to tools or information that could facilitate an attack.

Mitigation Strategies: Developing strategies to mitigate identified threats. This involves implementing security measures that address the specific methods and motivations of potential adversaries.


Security Audit Framework.

The Trike threat modeling methodology employs a structured approach to identifying and mitigating security threats through a detailed analysis of actors, actions, and assets. One of the key tools used in Trike is the Actor-Action-Asset Matrix, which helps map out the interactions within a system to identify potential security risks.

Understanding Risk Events & Risk Factors

Firstly, the difference between Risk and Risk Event.

Risk represents the potential for something to happen.
Risk Event is the actual occurrence of that potential.

Risk exists before anything happens; it is a possibility.
Risk Event occurs when the possibility becomes reality.

Risk is managed through identification, analysis, and mitigation strategies.
Risk Event is managed through response actions and contingency plans when it occurs.

Whereas Threat is something simple – communicated intent to inflict harm.

How about Risk Event vs Threat Event?

Well… Risk Event is something broader and can refer to any sort of event that impacts objectives.

Threat Event assumes malicious intent. Threat Actor executing on his previous threat.

Basically Risk Events include Threat Events.

Examples of Risk Events:

  • regulations with new requirements
  • loss of key personnel
  • natural disasters
  • networks intrusions resulting in data exfiltration
  • ransomware attack
  • abuse of positional authority

How about Risk Factors?

A Risk Factor is anything that makes a problem or negative event more likely to happen, without ensuring that it will definitely occur.

Risk – it might rain and spoil the picnic.
Risk Factor – dark clouds in the sky or a weather forecast predicting rain are risk factors. They don’t guarantee it will rain, but they make it more likely.

Quite obviously smoking is a risk factor for lung cancer. It increases the chances but doesn’t mean every smoker will get lung cancer.

In Project Management having tight deadlines is a risk factor for project delays. It increases the likelihood of missing deadlines but doesn’t guarantee it.

Risk Management Process in 5 steps.

The first step is to Setting the Context. It includes defining the scope and objectives of the risk management process, establishing the criteria for risk assessment, and identifying the stakeholders.

The second step is to Identify and Assess Risks.

To identify risks you can use:

  • historical or evidence-based methods (audit, incident reports, public media, annual reports),
  • systematic approach – expert opinion (vulnerability assessment, review of BCP and DRP, interviews and workshop with managers, customers and employees),
  • theoretical analysis – e.g. penetration testing,
  • existing taxonomy – already existing risk library with already indicated risks.

When assessing risk remember to include both likelihood and consequences. Following tools will be very useful:

  • Risk Matrix,
  • BowTie analysis, or
  • Decision Tree.

The third step is to Analyze Risks and Evaluate Business Impact. We need to fully understand those risks to prioritize risks based on their potential effect on business objectives.

The fourth step is to Response to the Risk. Do we accept? Do we mitigate? Do we transfer? Do we avoid?

Finally, we Report and Communicate. Simple, right?

Risk Profile, Risk Apetite, Risk Acceptance, Risk Tolerance and Risk Capacity.

Let´s try to clear the fog out.

Risk Profile is simply an overview of the Risk Lanscape in the context of an organization. What and where we are afraid of?

Risk Apetite is simply the number of risk we want to take. Having how many risks is ok? Risk apetite might be sometimes stated by policies and standards established by Senior Management.

Risk Acceptance is the decision to accept a risk as it is, without taking steps to reduce or mitigate it. It means deciding to live with a certain level of risk because dealing with it further isn’t worth the effort or cost.

Risk Acceptance should not exceed Risk Apetite and can´t exceed Risk Tolerance.

Risk Tolerance tells us how much risk you can handle without too much stress. How much is an organization willing to bear? Sometime also established by policies and standards provided by Senior Management.

Whereas Risk Capacity is an indicator can you handle the risk based on operational and financial stability. Basically how much we can take before our business dies.

Having clearly defined Risk Apetite & Capacity is not that common. Even though there is plenty of benefits. Take a look:

  • providing evidence for risk-based decision-making processes,
  • understanding how components contribute to overall risk profile,
  • understanding how resource allocation can add or lessen the burden of risk,
  • prioritizing response actions through risk budgets,
  • identifying areas where risk response should be made.

It requires significant effort though. That might be the problem.

Hence remember to have all 5 elements in place:

  1. Risk Profile,
  2. Risk Apetite,
  3. Risk Acceptance,
  4. Risk Tolerance,
  5. Risk Capacity.


Risk Practitioner – Key Roles

Firstly, you need to make sure the management is aware of the Risk Profile.

Secondly, you need to make sure the organization manage risks in a way that meets management objectives.

Thirdly, you monitor risks hand by hand with Risk Owners, IT Staff, Third-Parties, Incident Responders and Auditors.

Finally, you evaluate effectiveness and efficiency of the control framework.


Creating a Risk Profile

When creating a Risk Profile of an organization – I will focus on software development company – you need to conduct following activities:

  1. Establish the organization’s risk appetite and risk tolerance.
  2. Identify potential risks in the categories vital for the organization (see below).
  3. Rank, or prioritize, based on the impact risks might have on the organization. Including the likelihood it might happen.
  4. Think about further prioritization including defined relevant subcategories.
  5. Present the risk profile in the readable way, e.g. through a color-coded heat map.

If you wonder how to distinguish risk appetite from risk tolerance, here is my understanding:

  • Risk Appetite: How much risk you want to take.
  • Risk Tolerance: How much risk you can handle without too much stress.

I hope it helps.

Now about those categories. In software development I usually go with the following ones:

  • Operational Risks – project management failures, technical failures, resource allocation
  • Financial Risks
  • Market Risks
  • Technological Risks – including cyber security threats
  • Regulatory and Compliance Risks
  • Human Resources Risks
  • Strategic Risks
  • Reputation Risks

Remember that Risk Profile changes over time! It needs to be regularly monitored and reviewed!

Checklist of elements of Enterprise Risk Management Framework.

If you want to make sure you included and considered all of the vital elements of Enterprise Risk Management Framework just follow the checklist below.

  1. Clearly indicate Data / System / Risk Ownership.
  2. Clearly identified crucial Business Operations.
  3. Clearly documented Process & Procedure Formation.
  4. Clearly documented Risk Framework & Policy Formation.
  5. Clearly identified Compliance and Oversight mechanisms.
  6. Clearly identified Check & Challenge mechanism.
  7. Established independent assurance Board, Senior Management and Audit bodies.


Explaining 3 lines of Defense in Risk Management.

It´s absolutely not complicated. Worth remembering though.

The Three Lines of Defense is a model used in risk management to ensure effective risk governance and control across an organization. This model provides a clear structure for assigning and coordinating risk management roles and responsibilities. Here’s an explanation of each line of defense:

1. First Line of Defense: Operational Management

  • Role: The first line of defense is composed of operational managers and staff who own and manage risks directly. They are responsible for maintaining effective internal controls and executing risk and control procedures on a day-to-day basis.
  • Responsibilities: Identifying, assessing, controlling, and mitigating risks as part of their operational activities. They ensure that processes and controls are embedded in their operations and that risk management is part of their routine tasks.
  • Examples: Business unit managers, process owners, and frontline employees.

2. Second Line of Defense: Risk Management and Compliance Functions

  • Role: The second line of defense consists of risk management and compliance functions that provide oversight and guidance on risk-related matters. These functions help build and monitor the implementation of effective risk management practices.
  • Responsibilities: Developing risk management frameworks, policies, and procedures. Monitoring compliance with regulatory requirements and internal policies, conducting risk assessments, and providing advice and training to the first line.
  • Examples: Risk management teams, compliance officers, and financial control units.

3. Third Line of Defense: Internal Audit

  • Role: The third line of defense is provided by the internal audit function, which offers independent assurance on the effectiveness of governance, risk management, and internal controls.
  • Responsibilities: Conducting objective assessments and audits to evaluate the adequacy and effectiveness of the first and second lines of defense. Reporting findings to senior management and the board, and recommending improvements.
  • Examples: Internal auditors and external auditors (when engaged for internal audit purposes).


  • First Line: Operational management directly manages risks and implements controls.
  • Second Line: Risk management and compliance functions provide oversight, guidance, and support to the first line.
  • Third Line: Internal audit provides independent assurance on the effectiveness of risk management and controls across the organization.