Risk Assessment in the ISMS: Methodology, Matrix, and Practical Example

TL;DR

The qualitative risk assessment with a 5x5 matrix is the most pragmatic approach for SMEs and delivers meaningful results without statistical overhead.
Every risk is evaluated across two dimensions: likelihood of occurrence and impact. Their product yields the risk score.
Asset-based and scenario-based assessment complement each other. Combine both approaches for complete coverage.
Residual risk must be reassessed after treatment and formally accepted by top management.
Every risk needs a risk owner who is accountable for assessment and treatment and who reviews regularly.

Why the Risk Assessment Determines Your ISMS Success

An ISMS without a solid risk assessment is like a navigation system without a map. You know you want to go somewhere, but you have no idea where the dangers lie and which route is safest. ISO 27001 explicitly requires a documented risk assessment process in clause 6.1.2, and for good reason: only those who know their risks can treat them in a targeted manner and deploy their limited resources where they have the greatest effect.

The risk assessment connects two worlds. On one side stands the technical reality with vulnerabilities, threats, and concrete attack scenarios. On the other side stand business priorities, budgets, and top management's risk appetite. A good assessment methodology translates technical complexity into understandable decision-making foundations.

Many organizations, however, do not fail at the concept of risk assessment but at its practical implementation. They get lost in overly complex methods, assess hundreds of risks in advance, or produce spreadsheets full of numbers that nobody can interpret anymore. This article shows you a pragmatic path: a qualitative assessment with a 5x5 matrix that is both audit-proof and practically feasible.

Fundamentals: What Exactly Is Being Assessed?

Before you begin the actual assessment, you need a clear understanding of the terminology. ISO 27005 defines the risk concept in the information security context through three building blocks:

Assets are the valuable items of your organization that you inventory through IT asset management. These include information (customer data, contracts, source code), IT systems (servers, applications, networks), processes (order processing, software development), and also persons with critical knowledge.

Threats are potential causes of a security incident. They can be intentional (hacker attack, data theft by an insider), accidental (hardware failure, software bug), or environmental (power outage, flooding).

Vulnerabilities are properties of an asset that can be exploited by a threat. An unpatched server is a vulnerability, as are missing access controls or untrained employees.

A risk arises when a threat meets a vulnerability and can thereby compromise an asset. The risk assessment quantifies this interplay across two central dimensions: how likely is it that the risk materializes? And how severe would the consequences be?

Qualitative vs. Quantitative Assessment

There are fundamentally two methodological approaches to risk assessment, and the choice has significant implications for effort, results, and acceptance.

Quantitative Assessment

The quantitative method works with concrete numbers. Likelihoods are expressed as percentages (e.g., 15% probability per year), damages quantified in currency (e.g., EUR 500,000 expected loss). The risk value then emerges as Annual Loss Expectancy (ALE) = Probability x Loss Amount.

This sounds precise but has several drawbacks in practice. Where do you get reliable probabilities for a ransomware attack on your specific company? How do you quantify the reputational damage after a data leak? The apparent precision of the numbers suggests a certainty that does not exist. For large corporations with their own risk departments and extensive loss histories, the quantitative approach can make sense. For SMEs, it is usually overkill.

Qualitative Assessment

The qualitative method works with defined levels instead of exact numbers. Likelihood and impact are assessed on a scale, typically with 3, 4, or 5 levels. The result is visualized in a risk matrix that shows at a glance which risks are critical and which are acceptable.

This approach has become the standard for mid-market companies because it offers three decisive advantages: it is understandable (also for non-technical decision-makers), consistently applicable (different assessors arrive at similar results), and low-effort enough to enable regular reassessments.

For most ISMS implementations in mid-market companies, we therefore recommend the qualitative assessment with a 5x5 matrix. It offers sufficient differentiation without descending into false precision.

The 5x5 Risk Matrix in Detail

Assessing Likelihood

Likelihood describes how realistic it is that a specific risk scenario actually occurs within a defined period (usually one year). Define five clear levels with concrete criteria:

Level 1 – Very unlikely: The event is expected to occur less than once in ten years. There are no known incidents in the industry, no known exploitable vulnerabilities, and existing protective measures are robust. Example: A targeted APT attack on a 50-person trades company.

Level 2 – Unlikely: An occurrence within three to ten years is conceivable. Isolated incidents in the industry are known, but the organization's own exposure is low. Example: Physical break-in at the data center of a well-secured office building.

Level 3 – Possible: An occurrence within one to three years is realistic. Comparable organizations have already been affected, and the organization's own vulnerability profile makes an incident plausible. Example: Successful phishing attack on an employee without specific awareness training.

Level 4 – Likely: An occurrence within the next year is to be expected. There are known, unresolved vulnerabilities, active threats in the industry, and past incidents within the organization. Example: Malware infection via outdated software without patch management.

Level 5 – Very likely: An occurrence within the next months or even weeks is almost certain. The vulnerability is being actively exploited, there are no effective countermeasures, and the organization is an attractive target. Example: Data loss on an unsecured file server without a backup concept.

Assessing Impact

Impact describes the damage that occurs if the risk actually materializes. Again five levels, where you should consider various damage dimensions:

Level 1 – Negligible: Minimal disruption that can be resolved within hours. No financial damage exceeding EUR 5,000, no external effects, no data loss. Normal operations are barely affected.

Level 2 – Minor: Noticeable but limited disruption. Financial damage up to EUR 25,000, individual business processes impaired for a few days, small amounts of non-sensitive data affected. Resolution possible within one week.

Level 3 – Moderate: Significant disruption to business operations. Financial damage up to EUR 100,000, important processes down for several days, personal data possibly affected (check reporting obligations). Resolution within two to four weeks.

Level 4 – High: Severe disruption with long-term consequences. Financial damage up to EUR 500,000, core processes down for weeks, sensitive data compromised, reporting obligations triggered, reputational damage with customers and partners.

Level 5 – Critical: Existentially threatening consequences. Financial damage exceeding EUR 500,000, complete business standstill for weeks, massive data exfiltration, regulatory consequences (fines, license revocation), sustained loss of market trust.

Important: adapt the thresholds to your organization. For a startup with ten employees, EUR 50,000 may already be existentially threatening, while a corporation may classify this amount as negligible. The levels must match your organization's reality.

Building the Matrix

The risk matrix is created by combining likelihood (Y-axis) and impact (X-axis) in a grid. The risk value for each cell results from multiplying both levels:

	Negligible (1)	Minor (2)	Moderate (3)	High (4)	Critical (5)
Very likely (5)	5	10	15	20	25
Likely (4)	4	8	12	16	20
Possible (3)	3	6	9	12	15
Unlikely (2)	2	4	6	8	10
Very unlikely (1)	1	2	3	4	5

From this, you derive four risk categories:

Low (1-4): Risk is acceptable. Maintain standard measures, no additional treatment needed. Next review in the regular cycle.
Medium (5-9): Risk requires attention. Check whether existing measures are sufficient and plan improvements if needed. Timeframe: within six months.
High (10-16): Risk requires timely treatment. Define concrete measures with responsible persons and implementation deadlines. Timeframe: within three months.
Critical (17-25): Risk requires immediate action. Escalation to top management, initiate emergency measures, implementation within weeks.

Asset-Based vs. Scenario-Based Assessment

There are two fundamentally different perspectives from which you can approach risk assessment. Both have their merits, and in practice, a combination of the two yields the best results.

The Asset-Based Approach

In the asset-based approach, you start with an inventory of your valuable assets. For each asset, you then identify relevant threats and vulnerabilities and assess the resulting risk.

The typical process looks like this: first, you create a list of all relevant assets within your ISMS scope. Then you classify each asset through a protection needs analysis by confidentiality, integrity, and availability. Next, you identify relevant threats and existing vulnerabilities for each asset. Finally, you assess each threat-vulnerability combination by likelihood and impact.

Pros: Complete coverage of all assets, clear assignment of risks to specific systems and data, well suited for deriving technical measures.

Cons: Can become very extensive with many assets (an ERP system alone has dozens of potential threats), risk of redundancy when the same scenario applies to multiple assets.

The Scenario-Based Approach

The scenario-based approach reverses the perspective. You start with realistic threat scenarios and then assess which assets would be affected and how severe the impact would be.

Typical scenarios would include: a ransomware attack encrypts all corporate data. An employee forwards confidential customer data to third parties. The cloud provider has a multi-day total outage. A former administrator uses still-active credentials. A fire destroys the server room.

Pros: More practical and understandable for non-technical stakeholders, covers complex attack chains affecting multiple assets, more efficient with limited resources.

Cons: Risk that less obvious scenarios are overlooked, less systematic than the asset-based approach.

The Combination in Practice

For most SMEs, we recommend a combined approach: start with an asset inventory to ensure you miss nothing. Then group similar assets (all workstation computers, all SaaS applications) and develop relevant threat scenarios for each group. This gives you the completeness of the asset-based approach with the practicality of the scenario-based approach, without drowning in an endless list.

Practical Example: Ransomware Risk for a 100-Employee Company

Let's walk through the entire methodology with a concrete example. Our fictional company is a mid-market mechanical engineering firm with 100 employees, 80 workstation computers, an on-premises ERP system, an in-house design department with CAD workstations, and a small IT team of three.

Step 1: Define the Scenario

Risk scenario: An employee opens an infected email attachment. The ransomware spreads across the network and encrypts data on the file server, the ERP system, and the CAD workstations. The attackers demand EUR 200,000 in ransom and threaten to publish exfiltrated design data.

Step 2: Identify Affected Assets

Directly affected are the central file server with project documents and customer data, the ERP system with order and financial data, the CAD workstations with proprietary design data, and the email system. Indirectly affected are all business processes that use these systems: order processing, design, accounting, and customer communication.

Step 3: Assess Likelihood

For the likelihood assessment, you consider several factors:

The general threat landscape is high. Ransomware attacks on the German SME sector have multiplied in recent years according to the BSI situation report and are among the top 10 security risks. Mechanical engineering firms are attractive targets due to their valuable intellectual property.

The company's specific vulnerability profile shows gaps. There is no systematic patch management, awareness training takes place only once annually, network segmentation is rudimentary, and the email filter is a basic spam filter without sandbox analysis.

On the positive side, there is a functioning backup concept (daily backup to separate storage, weekly offsite copy) and basic endpoint protection on all workstations.

Assessment: Level 4 (Likely). The combination of a high general threat landscape and existing vulnerabilities makes a successful ransomware attack within the next year realistic.

Step 4: Assess Impact

You assess impact across several dimensions:

Financial damage: Revenue loss during downtime (estimated two weeks with EUR 10 million annual revenue yields approximately EUR 385,000), costs for incident response and recovery (EUR 80,000 – 150,000), possible ransom (EUR 200,000, though the BSI advises against payment), regulatory costs for data protection violations. Total potential damage EUR 500,000 – 800,000.

Operational impact: Complete production standstill in the design department, order processing by phone and paper severely limited, customer projects delayed by weeks. For a company of this size, a two-week standstill is a massive disruption.

Reputational damage: If design data from customer projects is published, trust among clients is sustainably damaged. Especially in B2B mechanical engineering, where business relationships span decades, this weighs heavily.

Assessment: Level 4 (High). The potential total damage exceeds EUR 500,000, core processes are down for weeks, and sensitive data is at risk. The company's existence is not immediately threatened (reserves are sufficient), but the incident would have long-term consequences.

Step 5: Calculate Risk Score

Likelihood (4) x Impact (4) = Risk score 16 (High)

The risk is in the upper range of the "High" category and requires timely treatment with concrete measures and defined implementation deadlines.

Step 6: Plan Treatment

Concrete measures are derived from the assessment to reduce the risk to an acceptable level:

To reduce likelihood: introduction of systematic patch management (all critical patches within 72 hours), switch to an email filter with sandbox analysis, implementation of network segmentation (design, administration, production in separate segments), quarterly phishing simulations with follow-up training.

To reduce impact: implementation of a 3-2-1 backup concept with an air-gapped offsite copy, creation of a ransomware-specific incident response plan, encryption of design data (reduces damage in case of data exfiltration), preparation of emergency operating procedures for core processes.

Step 7: Assess Residual Risk

After implementation of all planned measures, you reassess the risk:

Likelihood drops from Level 4 to Level 2 (Unlikely) because patch management significantly reduces the attack surface, the improved email filter catches most phishing attempts, and network segmentation impedes lateral movement.

Impact drops from Level 4 to Level 3 (Moderate) because the improved backup enables faster recovery (days instead of weeks), the incident response plan shortens response time, and data encryption reduces the extortion leverage in case of exfiltration.

New risk score: 2 x 3 = 6 (Medium)

The residual risk is now in a range manageable with standard monitoring. Top management must formally accept this residual risk.

Designating Risk Owners: Who Bears Responsibility?

A frequently underestimated aspect of risk assessment is the assignment of risk owners. ISO 27001 explicitly requires in clause 6.1.2 that risk owners be designated. This is not a formal act but a central element for the effectiveness of the entire process.

What Does a Risk Owner Do?

The risk owner is the person who bears overall responsibility for a specific risk. Specifically, this means: they approve the initial risk assessment and ensure it is realistic. They decide on the treatment strategy (mitigate, accept, transfer, or avoid). They monitor the implementation of agreed-upon measures and initiate regular reassessment of the risk. And they escalate to top management when the risk situation changes.

Who Should Be Risk Owner?

The risk owner should be someone who has both the subject-matter competence and the organizational authority to make decisions about the risk. For our ransomware example, this would be the IT manager or, if there is none, top management themselves.

A common mistake is to make the ISM the risk owner for all risks. The ISM coordinates the risk management process, but the operational responsibility for individual risks belongs in the business units. The ISM is the process guardian, not the universal risk owner.

Other typical assignments: risks in the area of personnel (insider threats, awareness) belong to HR management. Risks in physical security belong to facility management. Risks with suppliers and service providers belong to procurement or the respective business unit.

Documenting Risk Ownership

The risk register should clearly document for each risk: Who is the risk owner? When was the risk last assessed? What treatment measures are planned or implemented? When is the next review due?

Common Mistakes in Risk Assessment

From consulting practice, we know a range of mistakes that repeatedly creep into risk assessments. If you avoid these, you are already a big step ahead.

Mistake 1: Assessing Too Many Risks at Once

Some organizations start with a list of 200 or 300 risks and want to assess them all in one workshop. The result is superficial assessments, fatigued participants, and risk scores that depend more on the time of day than on the actual threat level.

Better: start with the 20 to 30 most important risks that emerge from your critical assets and the most probable threat scenarios. Expand the scope in later cycles.

Mistake 2: Assessment in Isolation

When the ISM sits alone at a desk and assesses risks, the expertise from the business units is missing. IT can estimate the technical likelihood, the business unit can estimate the business impact, and top management can assess the strategic relevance. Risk assessment is teamwork.

Mistake 3: No Uniform Assessment Criteria

Without clearly defined criteria for each level, different people assess differently. What one person rates as "likely," another considers "possible." Invest time in defining concrete, measurable criteria for each level before you begin the assessment.

Mistake 4: Ignoring Existing Measures

The risk assessment should reflect the current risk level, not the theoretical maximum without any protective measures. If you already have a good backup, that factors into the impact assessment. Otherwise, all risks end up in the highest category, and the assessment loses its differentiating power.

Mistake 5: Assess Once and File Away

Risk assessment is not a one-time project but a continuous process. At least once a year, you should reassess all risks. Additionally after relevant security incidents, upon significant changes to the IT infrastructure or organizational structure, and when the threat landscape changes significantly.

Tools and Templates for Risk Assessment

For practical execution, you do not necessarily need an expensive GRC tool. In the initial phase, a well-structured risk register suffices that captures the following information for each risk:

A unique risk ID, a meaningful risk description, the associated threat scenario, the affected assets, the likelihood assessment with justification, the impact assessment with justification, the resulting risk score, the planned treatment strategy, the risk owner, the status of measures, and the date of the next review.

Importantly, document the justifications for your assessments. Not just "Likelihood: 4," but why you arrived at this estimate. In ISMS Lite, you document the risk assessment including the 5x5 matrix and residual risk calculation directly on the respective risk, so traceability is automatically ensured. This makes the assessment traceable and facilitates reassessment.

Integration into the Overall ISMS Process

The risk assessment does not stand alone but is closely intertwined with other ISMS processes. Asset management feeds in the valuable assets. The results of the risk assessment determine which measures from ISO 27001 Annex A must be applied and thus flow directly into the Statement of Applicability. The risk treatment plans define concrete projects and tasks to be implemented in operations. And the regular reassessment is part of the management review and continual improvement.

When you set up the risk assessment properly and maintain it consistently, it becomes the compass of your ISMS: it shows you at any time where you stand, where the greatest dangers lie, and where your next investments will yield the greatest security gain.

Conclusion: Start Pragmatically, Improve Systematically

The risk assessment does not have to be perfect to be effective. Start with a manageable number of relevant risks, a clearly defined 5x5 matrix, and a structured assessment process. Involve the right people, document your decisions traceably, and plan regular review cycles from the outset.