Risk Assessment – how to deal with it.

When thinking about Risk Assessment you might use following techniques:

  • bayesian method,
  • bowtie analysis, or
  • brainstorming and structured discussions,
  • cause and consequence analysis,
  • cause and effect analysis.

It´s useful to use Risk Rankings – levels of risk associated with a threat – severity, likelihood, characteristics. Risk Rankings might be presented in the form of Risk Maps. E.g. Heat Maps.

Whenever thinking about Risk Assessment we need to make sure we individually identify Risk Owner. Risk Owner who is empowered to make decision on behalf of an organization. Otherwise taking any action will be crippled.

Risk Assessment Phase should be documented for the Senior Management including:

  • risk assessment report indicating gaps,
  • advises if they are on the acceptable levels,
  • provides basis for severity assessment,
  • report should mention issues which has already been addressed as well – to give the comprehensive picture of risk landscape.

Remember that in order to provide comprehensive documentation, following sections should be included:

  • objectives of the risk assessment,
  • scope,
  • external context,
  • internal factors,
  • risk assessment methodology,
  • identification or risk, threats and vulnerabilities,
  • results of risk assessment,
  • recommendation and conclusions.

And as the say in ISACA:

The reason to conduct risk assessments in a consistent, structured manner is to provide predictable, repeatable results that support future assessments.

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.


Key Risk Indicator

We use KRIs to provide early warning signs that risk levels are rising, allowing the organization to take proactive measures to mitigate or manage the risk.

In the Software Development scenario this would be e.g. Percentage of Projects Delivered Late.

When KRIs exceed the threshold, stakeholders should be informed. The information should result in either investigation of the cause or directly into mitigation.

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!