An important customer sends you their supplier security questionnaire. Forty questions. At line 12: “Have you carried out a risk analysis in the last 12 months? Attach the document.”
I see this question everywhere. In customer and supplier questionnaires, in cyber insurance forms, in ISO 27001 audits. And I almost always see one of the same two answers. Either there is nothing. Or there is a 400-line Excel file that nobody in the company can read, and that management never approved.
Neither one answers the question.
Statistics Canada figures show the scale of the problem. In 2023, one Canadian business in six was hit by a cybersecurity incident. Recovery spending doubled in two years, to $1.2 billion. Yet only 26% of businesses have written cybersecurity policies. About 59% say they carry out “activities” to identify their risks, but an activity is not a documented analysis.
A risk analysis is not a compliance exercise. It is the document that justifies every dollar you spend on security. And every dollar you decide not to spend.
In a previous article, I explained what ISO 27001 clause 6.1 requires. Here I move to practice: the method I use with my clients, the concepts to understand, and a complete sample result.
ISO 27005 in 30 seconds
ISO/IEC 27005 is a guide. It is not a standard you get certified against. It explains how to meet the risk-management requirements of ISO 27001, and it applies to any organization, whatever its size.
What it does not do: it imposes no method, no scale, no formula. Your method is acceptable if it produces results that are consistent, valid, and comparable from one year to the next. That is what ISO 27001 requires in clause 6.1.2.
The 2022 version brings three changes that are useful for an SMB:
- It is aligned with ISO 31000:2018 and with ISO 27001:2022;
- It introduces the idea of a risk scenario;
- It recognizes two approaches. The event-based approach starts from management’s concerns and builds scenarios. The asset-based approach starts from the inventory of assets, threats, and vulnerabilities.
The message for an SMB is simple: you no longer have to inventory every laptop and every piece of software to produce a defensible analysis. The method I present combines both approaches. You draw up a short list of grouped assets, then you assess about ten scenarios.
The six concepts to understand
1. Asset
Anything that has value and must be protected: data, systems, suppliers, people. Assets are grouped. Your employees’ 25 laptops form a single asset.
2. Risk scenario
A story in one sentence. “Ransomware encrypts the ERP server and the backups connected to it.” That is the basic unit of your register.
3. Impact and likelihood
Two scales, defined in writing before you start. Without written definitions, two people will give two different scores to the same risk, and your analysis will not be repeatable.
4. Acceptance criteria
The threshold above which management requires treatment. It is a management decision, not a calculation. ISO 27005 says so itself: a small business can start with a higher risk appetite and lower it as it grows.
5. Risk owner
The person who has the authority to decide and the budget to act. It is not your IT supplier. A supplier can advise you. A supplier cannot accept a risk on your behalf.
6. Residual risk
What remains once the measures are in place. Zero risk does not exist. ISO 27001 requires the risk owner to accept that residual explicitly: a signature, a date.
The method in 5 steps
Step 1: context and scope
State what you are analyzing: the whole company, a department, or a product. ISO 27005 does not require you to cover everything at once. Also note the context of the moment: budget, resources, projects underway.
The analysis is reviewed at least once a year. It is also redone at each trigger: a new project, an important new asset, a security incident, a major infrastructure change, a significant new customer.
Step 2: grouped assets and their value
Draw up a list of 6 to 10 asset groups. For each one, name an owner, then assign a score from 1 to 4 for availability, integrity, and confidentiality.
| Score | Availability (how long can you do without it?) | Integrity and confidentiality (consequence of a compromise) |
|---|---|---|
| 1 | Weeks | Negligible |
| 2 | Days | Serious |
| 3 | Hours | Catastrophic |
| 4 | Minutes | Threatens the survival of the business |
Asset value = Availability + Integrity + Confidentiality, so a value from 3 to 12.
Step 3: scenarios and their assessment
Write 8 to 12 scenarios. For each one, assess impact and likelihood against these scales:
| Score | Impact |
|---|---|
| 0 | Does not apply |
| 1 | Negligible effect on operations |
| 2 | Low effect on operations |
| 3 | Considerable effect on operations |
| 4 | Critical to the survival of the organization |
| Score | Likelihood |
|---|---|
| 0 | Impossible, or does not apply |
| 1 | Has never happened. Very low possibility |
| 2 | Has never happened. Low to medium possibility |
| 3 | Has already happened and could happen again |
| 4 | Could happen at any time, perhaps several times a year |
The calculation:
Risk = Asset value × (Impact + Likelihood)
The result ranges from 0 to 96. A rule to write in black and white in your method: if impact or likelihood is 0, the risk is 0. Without that rule, a scenario judged impossible would still receive a score.
Step 4: evaluation and treatment
Compare each risk with your acceptance criteria (next section). For each risk to be treated, choose one of four options:
- Reduce: put measures in place that lower the impact or the likelihood;
- Share: give part of the consequences to a third party, through insurance or a contract;
- Avoid: stop the activity that creates the risk, or stop collecting the data;
- Accept: keep the risk through an informed, documented decision.
A note on vocabulary: you no longer “transfer” a risk, you “share” it. Since the 2022 edition, ISO 27005 speaks of risk sharing. Transfer is only one form of it. The change is not cosmetic. When you buy cyber insurance or hand a service to a supplier, you share the financial or operational consequences. You never transfer the responsibility. If your customers’ personal information leaks at your supplier, you are the one who answers to your customers and to the access-to-information commission. If a document still talks about “transferring” the risk, it dates from before 2022.
Step 5: residual risk and acceptance
Once the measures are chosen, assess impact and likelihood again, taking those measures into account. Then recalculate the risk with the same formula.
You do not subtract points for each measure you add. Counting measures says nothing about how well they work. What matters is the real effect of each measure. Tested offline backups reduce the impact of ransomware. Multi-factor authentication reduces the likelihood that an account will be compromised. For each measure, note what it reduces and why: that is what makes your residual verifiable.
The risk owner then signs the result. A residual risk still above the threshold can be accepted temporarily, provided a dated action plan exists. ISO 27005 provides for this explicitly.
Acceptance criteria
Here are the zones I propose, inspired by the three-colour example in Annex A of ISO 27005:
| Score | Zone | Decision |
|---|---|---|
| 0 to 35 | Green | Acceptable as is. Reviewed at the annual review |
| 36 to 55 | Yellow | Tolerable under control. Medium-term action plan with a named owner |
| 56 to 96 | Red | Unacceptable. Short-term measures, or stop the activity |
The score alone is not enough. ISO 27005 also recommends considering impact and likelihood separately. I therefore add two rules:
- Any scenario whose impact is 4 (survival of the business) is treated, whatever its score;
- Any scenario that touches a legal obligation, such as the protection of personal information, with an impact of 3 or more is treated, whatever its score.
A golden rule: set your thresholds before you calculate. Otherwise, the temptation to adjust the threshold so the result looks good becomes irresistible.
Sample risk register
The company: Atelier Boréal inc. (a fictional company), a custom furniture maker, 40 employees. Its ERP runs on a 7-year-old local server. It uses Microsoft 365, sells online on Shopify, outsources payroll, and has an external firm manage its IT.
Table A: the assets
| # | Asset (group) | A | I | C | Value | Owner |
|---|---|---|---|---|---|---|
| A1 | ERP (production, accounting, orders) | 3 | 4 | 3 | 10 | Controller |
| A2 | Microsoft 365 (email, SharePoint, OneDrive) | 3 | 2 | 3 | 8 | President |
| A3 | Laptops and workstations (25 devices) | 2 | 2 | 2 | 6 | Director of operations |
| A4 | Online store | 3 | 3 | 3 | 9 | Sales director |
| A5 | HR and payroll files (outsourced) | 1 | 3 | 4 | 8 | Controller |
| A6 | Customer plans and drawings | 2 | 2 | 4 | 8 | Director of operations |
Table B: the risk assessment
| # | Scenario | Asset | Value | I | L | Risk | Zone |
|---|---|---|---|---|---|---|---|
| S1 | Ransomware encrypts the ERP server and its connected backups | A1 | 10 | 4 | 3 | 70 | Red |
| S2 | A Microsoft 365 account is compromised by phishing (MFA missing on some accounts) | A2 | 8 | 3 | 4 | 56 | Red |
| S3 | A fraudster has a supplier’s banking details changed by email | A2 | 8 | 3 | 3 | 48 | Yellow |
| S4 | Theft of an unencrypted laptop containing customer data | A3 | 6 | 3 | 3 | 36 | Yellow |
| S5 | ERP server failure (7 years old, no support contract) | A1 | 10 | 3 | 2 | 50 | Yellow |
| S6 | Leak of employees’ personal information at the payroll supplier | A5 | 8 | 3 | 1 | 32 | Green (treated: legal rule) |
| S7 | Online store defaced or unavailable (third-party app not updated) | A4 | 9 | 2 | 2 | 36 | Yellow |
| S8 | An employee who leaves keeps access to customer plans | A6 | 8 | 3 | 2 | 40 | Yellow |
| S9 | Accidental deletion of files in SharePoint | A2 | 8 | 1 | 3 | 32 | Green |
Table C: treatment and residual risk
| # | Option | Measures | Residual I | Residual L | Residual | Decision |
|---|---|---|---|---|---|---|
| S1 | Reduce | Offline or immutable backups, quarterly restore test, EDR, MFA on remote access | 3 | 2 | 50 (yellow) | Accepted by the president until the ERP migration (S5) |
| S2 | Reduce | MFA on 100% of accounts, block legacy authentication, training and phishing simulations | 3 | 2 | 40 (yellow) | Accepted by the president, reviewed in 6 months |
| S3 | Reduce and share | Mandatory callback to a number already on file before any change of banking details, dual approval of transfers, check of insurance coverage for social-engineering fraud | 3 | 1 | 32 (green) | Accepted by the controller |
| S4 | Reduce | Disk encryption (BitLocker), remote wipe | 1 | 3 | 24 (green) | Accepted by the director of operations |
| S5 | Avoid | Migrate the ERP to a cloud version within 12 months | 2 | 1 | 30 (green) | Accepted by the controller, after migration |
| S6 | Share | Written contract with personal-information protection clauses, supplier SOC 2 report obtained every year | 3 | 1 | 32 (green) | Accepted by the controller |
| S7 | Reduce | Quarterly review of installed apps, MFA on administrator accounts | 2 | 1 | 27 (green) | Accepted by the sales director |
| S8 | Reduce | Remove access on the day of departure, access review twice a year | 3 | 1 | 32 (green) | Accepted by the director of operations |
| S9 | Accept | Microsoft 365 recycle bin and retention already in place | 1 | 3 | 32 (green) | Accepted by the president |
How to read this result
Two red risks, five yellow, two green. The first budget goes to ransomware and to multi-factor authentication. Not to a new firewall.
Scenario S1 stays yellow after treatment. That is normal. A residual risk does not have to be green: it has to be decided. The president accepts it temporarily because a dated plan exists, the ERP migration.
Scenario S6 shows why the score alone is not enough. It is green, but it touches employees’ personal information. The legal rule requires it to be treated. In Quebec, entrusting personal information to a supplier requires a written contract that governs its protection.
Scenario S4 shows how one well-chosen measure lowers the impact: a stolen encrypted laptop no longer exposes the data it holds.
Scenario S5 illustrates the “avoid” option. You do not protect an end-of-life server indefinitely. You get rid of it.
These three tables, the written method, and the signatures answer the question from your customer, your insurer, and your auditor.
Five mistakes I see in audits
- A threshold set after the calculation. The rule is adjusted so the result looks good.
- Scales without written definitions. “Medium” means something different to each person around the table.
- The IT supplier named as the owner of the risks. They do not decide your budgets. They cannot accept your risks.
- A residual risk calculated by subtracting points for each measure added. Ten ineffective measures are not worth one effective measure.
- An analysis that is never redone. Not after an incident, and not after a major change. It becomes an archive document.
Where to start
- Block half a day with management and the person responsible for IT;
- Write the method and the scales before you score anything. Two pages are enough;
- List 6 to 10 asset groups, then 8 to 12 scenarios. Aim for the right ones rather than an exhaustive list: ISO 27005 recommends an iterative approach, more detailed at each pass;
- Have the risk owners sign the acceptance decisions;
- Put the annual review on your calendar, and redo the exercise at each trigger.
In short, the next time someone asks “Have you done your risk analysis?”, you will not have to improvise. You will attach three tables, a two-page method, and signatures.
Want a look at your register? Let’s talk.
References
ISO/IEC 27005:2022, Information security, cybersecurity and privacy protection: Guidance on managing information security risks (clauses 1, 5.1, 6.4.2, 7.2.1, 7.3.4, 8.2, 8.6.3, and Annex A); ISO/IEC 27001:2022, clauses 6.1.2 and 6.1.3; Statistics Canada, Canadian Survey of Cyber Security and Cybercrime, 2023 (The Daily, October 21, 2024).