ISO 27001 risk assessment methodology
Clause 6.1.2 does not prescribe a method. It prescribes properties the method must have, and the register it produces has about ten columns. Both are set out here, with the failures auditors see most often.
ISO 27001 requires a documented risk assessment method that produces consistent, valid and comparable results, applied to identify risks to the confidentiality, integrity and availability of information in scope, with a named owner and an assessed level for each risk. That is clause 6.1.2 in a sentence. It does not tell you to use a five by five matrix, or to assess threats against assets, or to use any particular scale. Those are your choices, and the only real test is whether two people applying your method to the same situation land in the same place.
Most first attempts fail on one of three things: the register was bought rather than built, so it describes a generic company; the risks are worded as control gaps rather than as risks; or nobody owns anything. All three are visible to a stage 1 auditor in about ten minutes.
What the standard actually requires
| Requirement | What satisfies it |
|---|---|
| Risk acceptance criteria | A written statement of what level of risk you will accept without treatment, and who can accept above it. |
| Criteria for performing assessments | When assessments happen: annually, on significant change, after an incident, and what counts as significant. |
| Consistent, valid, comparable results | Defined scales with worded anchors, so "high likelihood" means the same thing to two different assessors. |
| Risk identification | Risks to confidentiality, integrity and availability of information within your scope, derived from your own asset and data inventory. |
| Risk owners | A named person per risk who has the authority to accept it or fund its treatment. Not a team, not a job family. |
| Analysis and evaluation | Assessed consequence and likelihood, a resulting level, and a comparison against your acceptance criteria to prioritise. |
| Documented information | The method and the results, both retained. The method is a document auditors ask for by name. |
Note what is absent. There is no requirement to use threat and vulnerability pairs, no requirement for a quantitative model, and no requirement to assess every asset individually. ISO/IEC 27005 offers guidance on techniques and ISO 31000 sits above it as the general risk standard, and neither is mandatory to certify.
A method that survives an audit
This is a scenario based method. It is the one that works best for small and mid-sized Canadian companies, because it produces a register of manageable length that people can actually discuss, and it maps cleanly onto treatment decisions.
- Start from the inventory, not from a list of threats. Take the systems and data sets in scope from your asset and data inventory. If you do not have one, that is the actual first task, and it is the thing a consultant cannot build for you without interviewing everyone.
- Write risks as scenarios with a consequence. The wording test is that a risk should be a sentence containing a cause and an effect on confidentiality, integrity or availability. "No multi-factor authentication on the admin console" is a control gap. "An attacker who obtains an administrator password reaches the customer database, exposing personal information for all clients" is a risk. Control gaps belong in the treatment column, not the risk column.
- Assess inherent, then residual. Score the scenario ignoring your controls, record the controls that are actually in place, then score it again. The difference is the argument for why those controls are applicable, which is exactly what the Statement of Applicability has to justify.
- Name one owner per risk. The person who can spend money or accept the risk. If nobody in the room can name that person, the risk is really an organizational gap and should say so.
- Keep it to a length people will read. Thirty to eighty scenarios covers most companies under two hundred staff. A register of four hundred rows is a register nobody reviews, and auditors notice that the review dates are all the same day.
Scales, and how to word them
Consistency comes from wording the levels, not from the number of them. Five by five is conventional and three by three is defensible for a small company. What matters is that each level has an anchor a non-specialist can apply.
| Level | Likelihood anchor | Consequence anchor |
|---|---|---|
| 1 Very low | Not expected in the next five years | Internal inconvenience, no customer or regulatory effect |
| 2 Low | Possible once in three to five years | One customer affected, resolved without notification |
| 3 Moderate | Plausible once a year | Service outage under a day, or a reportable near miss |
| 4 High | Expected at least annually | Personal information exposed, breach reporting obligations engaged |
| 5 Very high | Occurring now or expected within months | Extended outage or material loss of customer data, contract and regulatory consequences |
Anchor the consequence scale to your own obligations rather than to generic severity words. For a Canadian company, level 4 upward is where PIPEDA breach reporting to the Privacy Commissioner and to affected individuals becomes relevant, and in Quebec the Law 25 obligations bite at a similar point. Wording the scale that way means the register itself tells you which scenarios trigger a legal duty, which is useful long after certification.
The register, column by column
This is the structure auditors are comfortable with. A spreadsheet is fine. The tool is not the point.
| Column | Why it exists |
|---|---|
| Reference | So the treatment plan and the Statement of Applicability can point back at it. |
| Scenario | Cause and effect in one sentence. |
| Assets or data affected | Ties the risk to the inventory and to the scope boundary. |
| Property affected | Confidentiality, integrity, availability, or more than one. |
| Inherent likelihood and consequence | Before controls. Makes the value of the controls visible. |
| Existing controls | What is genuinely in place, referenced to Annex A numbers. |
| Residual likelihood and consequence | After controls. This is what gets compared to your acceptance criteria. |
| Decision | Treat, accept, avoid or share. Accept requires the owner's name against it. |
| Risk owner | One named person. |
| Treatment actions, owner, due date | This column set is the risk treatment plan under clause 6.1.3. |
| Last reviewed | Dates that vary tell an auditor the register is alive. |
How the assessment feeds the Statement of Applicability
This is the join that projects get backwards. The treatment decisions determine which Annex A controls are applicable, and the Statement of Applicability records that decision for all 93 of them with a justification. Written in that order, the justification column writes itself: control A.8.2 is applicable because risks R-014 and R-022 are treated by restricting privileged access. Written the other way round, the justification column can only say "industry good practice", and an auditor reading a Statement of Applicability full of that phrase knows the risk assessment was decorative.
Exclusions work the same way. A control is excluded because no risk in your register requires it and the underlying activity does not exist in your organization, which is why a company with no premises can exclude parts of A.7 and a company with no software development can exclude the secure development controls. The Annex A page covers which exclusions hold up. Ordering this correctly is phase 5 and 6 of the implementation sequence.
What auditors actually reject
- A register with no variation. Every risk moderate, every review date identical, every owner the same person. It reads as a document produced in one sitting to satisfy a requirement, because it was.
- Risks that are control gaps. Discussed above, and it is the most common wording problem by a distance.
- Acceptance with no acceptor. If a risk sits above your criteria and the decision is accept, a named person with authority has to have accepted it, in a record with a date.
- A method document that describes a different method. Companies write the method early, change the approach during the workshops, and never update the document. The auditor compares the two.
- No reassessment after a real change. You acquired a company, moved to a new cloud region, or shipped a product that processes personal information, and the register has not moved. Clause 6.1.2 asks you to define when reassessment happens, and then you have to do it.
Templates are a starting point, not a deliverable
A bought register saves you the column structure and nothing else. Its contents describe a company that does not exist, and the auditor has read the same template from four other clients. Use one for the shape, then throw away every row and rebuild from your own inventory in a workshop with the people who run the systems. That workshop is where the actual value is, because it is the first time your organization has ever discussed these scenarios out loud.
Get help running the first assessment
Tell us your scope and we will match you with Canadian firms that will run the workshops rather than send you a spreadsheet.
Get matchedCommon questions
Does ISO 27001 require a specific risk assessment methodology?
No. Clause 6.1.2 requires that you define a method and that it produces consistent, valid and comparable results, with risk owners and assessed levels. Asset based, scenario based and threat based approaches all satisfy it. What fails is having no documented method, or having one that nobody followed.
Is there an official ISO 27001 risk assessment template?
There is no official template, and the standard is deliberately method-neutral. ISO/IEC 27005 gives guidance on techniques and is worth reading, but it is guidance rather than a requirement. The column structure on this page is the practical shape auditors are used to seeing, and a spreadsheet is an entirely acceptable tool for it.
How many risks should a register have?
Thirty to eighty scenarios covers most companies under two hundred staff. The right number is the number your risk owners will genuinely review at the frequency you committed to. Four hundred rows is not more rigorous, it is a register that gets reviewed once and then goes stale, which an auditor spots from the review dates.
How often do we have to redo the risk assessment?
At the frequency you defined in your own criteria, which for most organizations is annually plus on significant change. Significant change should be defined concretely: a new product handling personal information, a new hosting region, an acquisition, a material incident. Surveillance auditors check that the register moved between visits.
Who should be the risk owner?
Whoever can either fund the treatment or accept the risk. That is usually a director or executive rather than the security lead, and putting the security lead's name against all of them is a finding, because they cannot accept a risk on behalf of the business. Getting the right names in that column is often the most useful thing the whole exercise does.