How to conduct a risk analysis
From blank page to a risk register that steers the business. Seven steps, grounded in ISO 31000 and ISO 27005, written for practice.
By Kim Borg, Founder, RiskNote · Last updated
Why most risk analyses stall before they start
Everyone knows there should be a risk analysis. The problem is rarely willingness. It's that the step from ”we should do one” to actually having one in place feels too big.
It starts with a blank page. What should we assess? Which categories? How do we set likelihood and consequence? Suddenly three months have passed and the page is still blank.
This guide takes you from start to finished risk analysis. Grounded in ISO 31000 and ISO 27005, but written for practice, not the textbook. Download the Excel template if you want to follow along in your own register as you read.
Step 1 — Start with the protected assets
Before you identify a single risk you need to know what you're actually protecting. This is where most risk analyses go wrong: people start by listing threats without first understanding what's worth protecting.
Protected assets are what the business can't do without. Do a short inventory: what happens if this disappears, is disrupted, or leaks? That becomes your prioritised list.
Information
Customer data, trade secrets, personal data.
Availability
Critical systems, processes, deliveries.
Financial resources
Revenue streams, assets, cash flow.
Brand and trust
Reputation, customer relationships, market position.
People
Employees, customers, third parties.
Regulatory compliance
Licences, permits, legal standing.
Step 2 — Define the scope
A common pitfall: trying to analyse the whole business at once. The result becomes shallow and unusable. Instead, clearly define what's included, the time horizon, and which stakeholders are affected.
What's in scope?
The whole organisation, a specific process, a system, a supply chain? A bounded analysis with depth is always worth more than a broad one without substance.
What time horizon?
The next 12 months, a project period, or a three-year strategic horizon? The timeframe shapes how likelihood is assessed.
Which stakeholders are affected?
Management, employees, customers, regulators? Different stakeholders have different tolerance levels.
A bounded risk analysis with depth always beats a broad one without substance. You can always do more.
Step 3 — Identify threats and risks
Now you fill the page. Separate the concepts: a threat is what can happen (ransomware, vendor failure). A vulnerability is the weakness that makes the threat possible (insecure backups, single supplier). A risk is the combination of threat, vulnerability, and consequence for a protected asset.
Work systematically. A few proven angles:
Per protected asset
What could hit the customer data? What could take out availability? What threatens the brand?
Per threat category
Cyber, physical, personnel, vendor, regulatory, financial. Ensures broad coverage.
Per scenario
What happens if the server goes down? If the key person leaves? If a subcontractor goes bankrupt?
Involve the right people. IT doesn't know everything about the processes, the business doesn't know everything about the threats. A workshop with a cross-functional group always beats a lone analyst.
Step 4 — Assess likelihood and consequence
This is where risks turn from words into prioritisation data. Use a scale that fits your business. A 5×5 matrix works best in most cases.
Define the scales before you start assessing. What does ”serious consequence” actually mean in kronor, downtime, or customer loss? Without definitions the assessments become arbitrary and aren't comparable over time.
Likelihood (1–5) — how probable within the time horizon
1. Unlikely
Hard to see how it would happen.
2. Less likely
Could happen but not expected.
3. Possible
Could very well occur.
4. Likely
Expected to occur.
5. Very likely
Occurs regularly or is imminent.
Consequence (1–5) — how serious if the risk materialises
1. Negligible
Barely noticeable.
2. Limited
Manageable disruption.
3. Moderate
Significant impact, but manageable.
4. Serious
Material damage to the business.
5. Catastrophic
Threatens the survival of the business.
Step 5 — Prioritise actions, not just red cells
A common misconception: the end product of a risk analysis is the matrix with red cells. It isn't. The end product is a prioritised list of actions. For each identified risk, choose a treatment strategy.
Treatment strategies
Reduce
Lower likelihood or consequence through controls.
Transfer
Insurance, contractual clauses, outsourcing.
Accept
A conscious risk within tolerance, documented.
Avoid
Remove the activity that creates the risk.
Every action must have
Clear owner
Named person with a mandate to drive the action.
Deadline
A concrete date. Not ”soon” or ”this autumn”.
Measurable outcome
How will you know the action worked?
Link to the risk
Which risk is addressed and how does the action affect L and C?
Prioritise actions by effect per effort, not just by the risk's level. A medium risk with a simple fix can be more important to handle first than a high risk that requires a three-year investment.
Step 6 — Keep the analysis alive
A risk analysis filed in a binder is dead the day after. Reality changes: new threats emerge, the business evolves, actions are implemented, regulations tighten.
A working risk analysis is a living process:
Regular review
At least annually, more often for critical areas.
Trigger-based updates
On incidents, changes, new systems, new vendors, new regulatory requirements.
Continuous follow-up
On action effectiveness and status, not just the risk list.
Clear owner
Someone who actually owns keeping it up to date.
For organisations subject to NIS2, ISO 27001 or similar, a living risk analysis isn't just a good idea. It's a requirement.
Step 7 — Map to frameworks and regulations
If your business is subject to specific requirements, make sure the risk analysis meets them. The most common in the Swedish context:
ISO 31000
General risk management, principles and framework. Read the ISO 31000 guide.
ISO 27005
Information security risk specifically.
ISO 27001
Requires documented risk assessment and treatment plan. See the ISO 27001 guide.
NIS2
Risk management measures for essential and important entities. Read about NIS2.
GDPR (DPIA)
Impact assessment for personal data processing. See GDPR risk analysis.
MSBFS 2020:6
Systematic information security work for Swedish public authorities.
DORA
Operational resilience for the financial sector.
The same underlying risk analysis can often cover multiple frameworks. It's mostly about how it's documented and reported.
Summary — the seven steps
1. Start with protected assets
Know what you're actually protecting.
2. Define the scope
Depth beats breadth.
3. Identify threats and risks
Systematic, cross-functional.
4. Assess likelihood and consequence
With defined scales.
5. Prioritise actions
Not red cells, but effect per effort.
6. Keep the analysis alive
Regularly and trigger-based.
7. Map to frameworks
Where needed.
Frequently asked questions about risk analysis
How long does a risk analysis take?
For an SME, half a working day is usually enough for the first round: 2–4 hours for identification and assessment, plus 1–2 hours for the action plan. Larger organisations or areas that need workshops: plan for 2–5 working days total.
What's the difference between risk analysis and risk assessment?
Risk analysis is the whole process: identify, analyse, evaluate, treat, monitor. Risk assessment is usually a subset, the actual assessment of likelihood and consequence. In practice the terms are used synonymously, but ISO 31000 separates them.
Do we have to use a 5×5 matrix?
No. ISO 31000 is agnostic about matrix size. 5×5 is common practice because 3×3 is too coarse (only 9 combinations) and 7×7 is too complex. Some organisations use qualitative categories instead. What matters is that the scale is consistent and defined up front.
Do all analyses have to be done in a workshop?
No, but single-person analyses are almost always narrower. A cross-functional group of 3–6 people catches risks a lone analyst misses. A workshop doesn't need to be a full day. 90 minutes per round goes a long way if it's well prepared.
How often should the risk analysis be updated?
Operational risks quarterly, strategic risks annually. Project risks update per sprint or steering meeting. On incidents, major changes (new vendor, system switch, regulatory change) always a new round. NIS2 and ISO 27001 require documented regular review.
Who should own the risk analysis?
Management owns the process and the risk tolerance. A designated risk lead (often the CISO, CFO, or COO at smaller companies) is responsible for keeping the analysis alive. Each individual risk should have a named owner with the mandate to drive actions.
More guides
From blank page to risk register in 20 minutes
This is what RiskNote was built for. Describe the business, the AI suggests relevant risks, and you have a structured risk register with a 5×5 matrix in the time it takes to drink a coffee. Then refine it with the business.