Risk Assessment Iso 27001 Example

Getting Your Risk Assessment Actually Working for ISO 27001

ISO 27001 requires a documented risk assessment as part of clause 6.1.2, and most people treat it like a compliance checkbox exercise. That approach works until an auditor asks you to explain your methodology and you realize your spreadsheets don't actually connect to each other. The standard doesn't prescribe a specific method. It just says you need to establish, implement, maintain, and continually improve a risk assessment process. The ambiguity is intentional. They want you to pick something that fits your organization, not follow someone else's template blindly.

Risk Assessment Iso 27001 Example

Here is what a practical example looks like in practice, not the sanitized version you find in training materials. Step 1: Identify your information assets This sounds simple. It isn't. Most organizations start with an asset register that looks nothing like their actual operations. I spent three weeks once going through an environment where the server inventory hadn't been updated since 2019. You will not believe how many production databases were running on machines nobody could find in the CMDB.

Start with the data, not the hardware. List what information you actually hold and process. Customer PII, intellectual property, financial records, employee data. Then map which systems touch each category. The asset list becomes a reference document, not the core of your assessment. Step 2: Determine the threats and vulnerabilities Threats are events that could cause harm. Vulnerabilities are weaknesses that make those events possible. People conflate them constantly.

A threat is a hacker exploiting a SQL injection flaw. The vulnerability is the unpatched application code. A threat is a power outage at your data center. The vulnerability is the missing backup generator. A threat is an employee forwarding payroll data to a personal email account. The vulnerability is the absence of DLP controls. For each asset, ask what could go wrong and why it could go wrong. Write both answers down separately. When you blur them together, your risk treatment plan becomes incoherent because you don't know whether to fix the vulnerability or block the threat. Step 3: Assess the risk

This is where methodology matters. Most organizations use a simple likelihood × impact matrix. That is adequate if you are disciplined about the scales. The problem is when everyone uses different scales for different risk categories. I work with teams that rate "data breach" on a five-point scale but rate "printer jam" on a three-point scale, then try to compare them in a single register. It does not work. Standardize your scales across the entire register. Use consistent definitions for each level. Likelihood scales:

5 = Almost certain, expected within the year 4 = Probable, likely within two years 3 = Possible, could occur within three years

2 = Unlikely, might occur within five years 1 = Rare, only in extraordinary circumstances Impact scales for confidentiality, integrity, and availability separately. Don't collapse them into one number. A ransomware attack that encrypts files has a high integrity impact and a high availability impact but potentially zero confidentiality impact. A leaked spreadsheet has a high confidentiality impact but no integrity or availability effect. Mixing them gives you a meaningless score.

Step 4: Identify and evaluate treatment options Four options exist: mitigate, avoid, transfer, or accept. Mitigate means implementing controls. Avoid means stopping the activity that creates the risk. Transfer means moving it to a third party through insurance or contracts. Accept means acknowledging it and moving on deliberately. Most organizations mitigate everything. That is inefficient and expensive. I had a client who spent $40,000 annually on a control to mitigate a risk they had already accepted through contractual terms with their vendor. The vendor's SLA covered the scenario completely. The control was redundant. We removed it and reduced the risk to acceptable levels through the existing contract instead.

Before you select controls from Annex A, check whether the risk is already covered by existing arrangements. Insurance policies, vendor contracts, legal obligations, and business continuity plans all count as risk treatment. They are not optional extras. Step 5: Document everything in a risk treatment plan Your risk treatment plan needs to reference the risk assessment results directly. Each identified risk, the chosen treatment, the controls selected, and the residual risk after implementation. This is clause 6.1.3 territory and auditors check it rigorously.

The format doesn't matter as long as the traceability exists. I have seen excellent registers in Excel, Sharepoint lists, and purpose-built GRC tools. What I have never seen work is a risk assessment document and a separate risk treatment plan with no cross-references between them. When an auditor picks a random risk and asks to see the treatment, you need to find it in under two minutes or it becomes a nonconformity.

Things That Go Wrong in Practice

One issue I encounter constantly is treating the risk assessment as a point-in-time exercise. The standard requires continual improvement, which means your assessment needs to be refreshed. But "refresh" does not mean re-doing everything every year. It means updating based on changes in your environment. I recommend a trigger-based approach. Reassess when: new systems go into production, significant changes happen to existing systems, new threats emerge in your sector, incident patterns change, or the scope of your ISMS changes. Between triggers, do a light review of your top twenty risks and update their status. This takes about two hours a quarter instead of the three weeks a full reassessment requires. Another common problem is using generic threat libraries without adapting them. The ISO 31000 guides and BSI guidelines provide useful starting points, but copying threat categories verbatim into your register means you will include items irrelevant to your organization and miss things that actually matter. A SaaS company selling productivity software has a different threat profile than a hospital running electronic health records. Adjust the library to your context.

The biggest blind spot I see is ignoring external dependencies. Your risk assessment should cover not just what you control directly but also what depends on third parties. Cloud providers, managed service providers, software vendors, and even your own customers can be sources of risk. The 2023 incident where a widely used cloud platform went down for six hours took down thousands of organizations simultaneously. If your risk assessment does not include dependency analysis, that scenario will surprise you. There is a limit to what this approach handles well. Risk assessment is inherently subjective. Different assessors will rate the same scenario differently. Two qualified people reviewing the same threat could assign likelihood scores that differ by two levels. This is not a failure of the process. It is a feature of working with uncertain information. Document your assumptions and rationale so reviewers understand why you rated something the way you did. If your organization operates in a highly regulated industry where quantitative risk analysis is required, the qualitative matrix approach alone may not satisfy the regulator. Financial services firms under DORA or critical infrastructure operators under NIS2 often need numerical probability estimates and financial impact modeling. In those cases, supplement your ISO 27001 assessment with a quantitative method like FAIR. They do not replace each other. They serve different purposes.

A Working Template Structure

Asset name and description Owner Confidentiality requirement

Integrity requirement Availability requirement Identified threats

Existing controls Likelihood score with justification Impact score per attribute with justification

Inherent risk rating Treatment option selected Controls implemented or planned

Residual risk score Risk owner Last review date

Next review trigger Keep it flat. Nested structures look organized but become impossible to query when you need to extract data for reporting. One row per risk, not one row per asset with threat details embedded in cells. The goal is not perfection. A risk assessment that is eight percent complete and actively maintained beats a risk assessment that is one hundred percent complete and sits in a drawer. Auditors can tell the difference immediately.