The short version
An ISO 27001 risk assessment finds your security risks, scores them, and ranks them. You judge them against rules you write down first. There are four steps: set the context, find the risks, score them, and rank them.
One number should shape your plan: DNV audited more than 1,700 certified firms and found that 27% do not meet Clause 6.1.2, the clause that governs this work.
This guide walks the whole process and marks the spots where audits break.
Sources: DNV, ISO Survey 2024, IBM Cost of a Data Breach 2026
What ISO 27001 asks you to do #
ISO 27001 runs on risk. You do not pick controls from a menu. You find your risks first. Then you pick the controls that treat them.
Auditors test that chain of logic. They test it harder than they test any single control.
Two clauses do the work. Clause 6.1.2 says you must define a risk process and then use it. Clause 6.1.3 says you must define a treatment process. Write both down. Both must leave records.
The market has grown fast. The ISO Survey counted 96,709 valid ISO/IEC 27001 certificates worldwide in 2024. That is close to double the 2023 count. Growth like that is why your buyers now ask for the certificate by name.
Which standard guides the method #
ISO 27001 names no method. It sets rules the method must meet. Write it down. Define the scales. Use it the same way in every unit. Review it on a set schedule.
The guidance document is ISO/IEC 27005:2022 (ISO). Watch the version numbers here. Some blogs cite an “ISO/IEC 27005:2024”. That is EN ISO/IEC 27005:2024, the European version of the same 2022 text. The ISO edition is still 2022. You cannot certify to 27005, but auditors read your method against it.
The 2024 change most teams missed #
ISO/IEC 27001:2022/Amd 1:2024 landed in February 2024. It added climate change to Clauses 4.1 and 4.2. You now have to ask two questions: Is climate change a live issue for your ISMS? Do your interested parties have climate demands?
Small change, real audit risk. Your context record has to show you asked. Your answer can be no. Silence cannot.
Our complete ISO 27001 guide covers the rest of the clauses.
Steps 1 and 2: set the context, then find the risks #
Step 1 Context establishment #
Context comes before everything else. You set the scope. You set the goals. You write the rules you will judge risks by. You list the assets. You record the issues inside and outside the business that shape your risk picture, climate change now among them.
The output is a short plan: Scope, roles, rules, method, review dates. Get it signed before anyone opens the risk register. Work built without a signed plan has no baseline, and the auditor will say so.
Step 2 Risk identification #
Now you list what could go wrong. For each asset you name the threats. You name the weak points those threats use. You name the controls you already run. You name the damage a hit would cause.
The classic failure is an IT-only list. Annex A covers four themes. Two of them are People (8 controls) and Physical (14 controls). If your list holds nothing but servers and SaaS apps, it is short by design. DNV saw the same habit across its audits: teams focus on IT risks and threats from outside, missing the rest.
Pull from more than one source. Use your incident history. Use your vendor list. Use your pen test findings, your access reviews, and your near misses.
Steps 3 and 4: score the risks, then rank them #
Step 3 Risk analysis #
Analysis puts a number on each risk. You judge the chance it happens. You judge how much it would hurt. Work in words, in numbers, or in a mix. What counts is that you use one scale for all of it.
Real breach data helps you set the impact bands. The average breach cost US$4.99 million in 2026, up 12% in a year. Firms took 247 days to find and shut one down (IBM). Healthcare stayed the worst hit sector at US$6.64 million, its 13th year in that spot.
Canadian numbers land better with a Canadian board. The average breach here hit CA$7.11 million, a record, and ran for 205 days (IBM Canada).
“Attackers are increasingly targeting sectors where disruption creates real operational and economic consequences, while also looking for the weakest link in the supply chain.”
Chris Sicard Security Leader, IBM Canada
That is a risk statement in plain form. Do you sell into energy, health, or finance? Then your spot in the supply chain is a risk of its own. Put it in the register.
Step 4 Risk evaluation #
Now you compare each score against the rules you set in Step 1. Anything above your line moves to treatment under Clause 6.1.3. Anything below it gets logged as accepted, with a named owner.
You end up with a ranked list. That list is the spine of the whole ISMS. Every control you claim in the Statement of Applicability should trace back to a line in it.
Teams that lean on security AI and automation cut breach costs by US$1.93 million and cut 65 days off the breach lifecycle (IBM). The Canadian split is just as sharp: heavy AI users spot a breach in 124 days and shut it down in 57, compared to 154 and 71 days for firms without AI.
“AI has dramatically lowered the barrier for cybercriminals. Attackers can now execute attacks in minutes rather than days with advanced frontier models.”
Mark Hughes Global Managing Partner, Cybersecurity Services, IBM
Pick one method and stick to it #
You get a choice of method. You do not get a choice about writing it down. The table covers the common options.
| Method | Origin | How it works | Fit with ISO 27001 |
|---|---|---|---|
| Asset-based | Common practice | List assets, value them, map threats and weak points | Strong. Mirrors the 27005 asset view |
| Threat-based | Common practice | Start from threat scenes, work back to assets | Strong for threat-led teams |
| Weakness-based | Common practice | Start from scan results and CVEs | Weak on its own. Use it to back up another method |
| OCTAVE | Carnegie Mellon SEI | Workshops drive the work | Works in practice, less ISO-native |
| NIST SP 800-30 r1 | NIST (US) | Step-by-step guidance | Compatible, US government flavour |
| MEHARI | CLUSIF (France) | Full method built around ISO/IEC 27005 | Closest to ISO-native |
| CRAMM | UK government | Asset, threat, weak point triplet with tooling | Compatible, older tooling |
| EBIOS Risk Manager | ANSSI (France) | Workshop-based, scene-driven | Compatible, strong on context |
Mixing methods across business units is a fast route to a non-conformity. Pick one. Write it down. Use it in every unit.
Scoring: chance times impact #
Most teams use a 5×5 matrix. Chance runs 1 (rare) to 5 (almost certain). Impact runs 1 (minor) to 5 (severe). The product, or a lookup table, gives you low, medium, high, or critical.
The matrix works when each level carries a plain line of text. “Likelihood = 3” means nothing on its own. “Could happen once a year, based on our own incident history” means something.
Tie your rules to the business: revenue, contracts, patient safety, legal duty. Rules lifted from a template with no tie to your strategy fail the context test.
Treat the risks and prove it #
Clause 6.1.3 gives you four options for each risk.
Pick one per risk. Write down why.
The Statement of Applicability #
Treatment leaves you three artifacts: the risk register, the risk treatment plan, and the Statement of Applicability (SoA).
Annex A holds 93 controls across 4 themes: Organizational (37), People (8), Physical (14), and Technological (34). The SoA has to cover all 93. For each one, say whether you use it, whether you drop it and why, and where it stands.
The SoA is not a checklist of what you built. It is a map of why. Each control you keep points back to a risk. Each one you drop carries a reason. Auditors test that trail, not the raw coverage.
Our guide on how to design and build an ISMS shows how the three artifacts fit together. ISO 27001 vs ISO 27002 explains where the control guidance comes from.
Set your sign-off rules up front. High-impact risks need senior sign-off. A note from the risk owner will not hold.
Why 27% fail Clause 6.1.2 #
DNV’s audit data tells a blunt story: across more than 1,700 certified firms, 78% had at least one finding, and 27% fell short on Clause 6.1.2 alone.
Here are the eight mistakes behind most of those failures:
- No written method. Write the method, the scales, and the rules before you start. Work handed over with no written scale fails on first review.
- IT-only lists. Annex A covers People and Physical. A list that skips staff, paper, and premises is short by design.
- Scales with no meaning. You cannot defend “high, medium, low” without a line of text behind each level.
- Rules cut loose from the business. Template rules with no tie to strategy fail the context test.
- Risks with no owner. Every risk needs a named owner who has the power to act.
- No trail from the register to the SoA. Controls you keep need a risk. Controls you drop need a reason.
- High risks accepted with no sign-off. Sign-off has to come from the right level, in writing.
- One pass, never repeated. Clause 6.1.2 and Clause 9 both expect review. A 2024 spreadsheet fails in 2026.
Fix the first and the fifth before you touch anything else. Those two gaps drive more findings than the rest put together.
Doing this in Canada #
The four steps are the same anywhere. The inputs are not.
Canadian data residency compliance #
Your context step has to name the law you live under. That means PIPEDA at the federal level, PHIPA if you touch Ontario health data, Quebec Law 25 if you serve Quebec, and PIPA if you serve Alberta or B.C. Financial services add OSFI B-13 and B-10, which push third-party and tech risk straight into your register.
Treat cross-border data flow as a line item, not a footnote. Buyers in health, government, and finance ask where the data sits before they ask for the certificate. Canadian data residency compliance shows up twice: once as a named risk with a named treatment, and again in the SoA under the transfer and supplier controls.
Nank.ai runs ISO 27001 certification across Ontario and Canada. We hold client data in the client’s own country as a design choice, not an add-on.
From ISO 27001 to SOC 2 #
The work you do here carries over. SOC 2 asks for a risk process of its own in the CC3 criteria, drawn from the COSO framework. The register, the scales, the owners, and the review cycle all count as evidence in a SOC 2 audit.
That overlap is why SOC 2 readiness in Canada moves faster when the ISO 27001 work already exists. Is SOC 2 your first target? Start with what SOC 2 is and build the register once for both.
Nank.ai delivers this as compliance as a service. A dedicated compliance manager runs the work with you, and our agentic AI compliance platform handles evidence collection, control monitoring, and drift alerts.
Frequently asked questions #
How often do you have to review an ISO 27001 risk assessment?
At planned intervals, and after any big change. The standard sets no fixed period. Most certified firms review once a year. They add extra reviews after a major incident, a new product, or a reorg. Auditors want a set schedule and at least one finished cycle.
Does ISO 27001 require a specific risk assessment method?
No. Clause 6.1.2 asks for a defined process that you use. It names no method. ISO/IEC 27005:2022 is the guidance document. MEHARI, OCTAVE, NIST SP 800-30 r1, CRAMM, and EBIOS Risk Manager all pass. You just have to write down your choice and use it the same way each time.
What is a Statement of Applicability?
The SoA lists all 93 Annex A controls. For each one it states whether you use it, whether you drop it and why, and where it stands. Controls you keep must trace back to risks in the register. Clause 6.1.3 d) makes the SoA mandatory.
Can you accept a risk under ISO 27001?
Yes. Retention is one of the four treatment options. You have to follow your own written sign-off rules, and high-impact risks need senior management approval. An accepted risk stays in the register and comes up at every review.
What is the difference between ISO 27001 and ISO 27005?
ISO/IEC 27001 is the standard you certify to. It defines an information security management system. ISO/IEC 27005:2022 is guidance on how to manage security risk. You certify to 27001. You borrow the method from 27005.
Do you need all 93 Annex A controls?
You have to address all 93 in the SoA. You do not have to build all 93. Say which apply, which do not, and why. Every drop needs a risk-based reason that points back to the register.
How long does an ISO 27001 risk assessment take?
Two to six weeks for a first pass at a small or mid-sized firm, once the scope is set. Context and the asset list eat most of that time. Teams on a compliance automation platform cut it further, because the asset list and the current controls come straight from connected systems.
Key takeaways #
- An ISO 27001 risk assessment has four steps: set the context, find the risks, score them, and rank them. Clauses 6.1.2 and 6.1.3 govern the work.
- ISO/IEC 27005:2022 is the guidance standard. The “2024” version you see quoted is the European edition of the same text.
- 27% of certified firms fail Clause 6.1.2. No written method and no audit trail drive most of it.
- The average breach now costs US$4.99 million worldwide and CA$7.11 million in Canada. Heavy AI and automation use cuts US$1.93 million off that.
- The SoA covers all 93 Annex A controls. Each one you keep traces back to a risk.
- Canadian teams have to name PIPEDA, PHIPA, Law 25, and OSFI in the context step. Treat data residency as a risk with an owner.
Start with two things: write down your method, and give every risk an owner. Those are the two gaps auditors cite most, and closing them moves you out of the 27% before you touch a single control.
Browse the rest of our compliance library or read more on the compliance blog.
Ready to make compliance a non-issue? #
Talk to us about SOC 2 and ISO 27001 in Toronto and across Canada. Audit-ready in about three months, with your data held in your own country.
