Why this comes before everything
The risk assessment is the input that drives which Annex A controls apply to you. Clause 6.1 requires you to identify risks to the confidentiality, integrity and availability of information in scope, analyse and evaluate them, and decide what to do about each.
The order matters more than teams expect. Scope, then risks, then treatment, then the Statement of Applicability. Projects that pick controls first end up unable to answer the auditor question that follows every control: which risk does this address?
Choosing a methodology
ISO 27001 does not prescribe one. It requires that yours is documented, repeatable, and produces consistent, comparable results. Two broad approaches:
| Approach | How it works | Suits |
|---|---|---|
| Asset-based | Inventory assets, then threats and vulnerabilities per asset | Organizations with a clear asset inventory |
| Scenario-based | Start from plausible events, work back to what they affect | Cloud-native companies where assets are ephemeral |
Scenario-based has become more common for SaaS companies, because an asset inventory of auto-scaling infrastructure is a moving target. Either is acceptable. What is not acceptable is an undocumented method, or one that produces different answers depending on who runs it.
What the register must contain
| Field | Why the auditor looks |
|---|---|
| Risk description | Specific enough to act on, not a category |
| Affected information or asset | Ties the risk to the scope |
| Likelihood and impact | Scored on your documented scale |
| Risk owner | A named person — the most commonly missing field |
| Treatment decision | Modify, retain, avoid or share |
| Controls applied | Which Annex A controls address it |
| Residual risk | What remains after treatment |
| Acceptance | Who accepted the residual risk, and when |
Risk owners are the field that sinks first-time registers. A register where every risk is owned by the security lead is not a register of organizational risk; it is one person's to-do list. Owners should be the people who can actually decide, which usually means engineering leads and department heads.
The four treatment options
Modify. Apply controls to reduce likelihood or impact. The default, and what most of Annex A exists for.
Retain. Accept the risk as it stands. Entirely legitimate when the residual risk is within your appetite — provided somebody with authority accepted it in writing.
Avoid. Stop doing the thing that creates the risk. Rare, but the honest answer for some legacy integrations.
Share. Transfer via insurance or contract. Note that you cannot transfer accountability, only financial consequence — auditors are alert to this being used as a substitute for a control.
Where first-time assessments go wrong
Generic risks. A register that could belong to any company describes no company. Data breach is not a risk; unauthorised access to customer records via an over-permissioned support tool is.
No scale definition. Scoring likelihood 1 to 5 without documenting what each number means makes the scores unrepeatable, which fails the consistency requirement.
Everything is high. A register where most risks are rated high has not prioritised anything and will not survive a conversation about treatment sequencing.
Never revisited. Clause 6.1 requires the assessment at planned intervals and when significant changes occur. A register last touched before certification is a surveillance finding.
No link to the SoA. If the auditor cannot trace a control in your SoA back to a risk, the connection between the two documents does not exist.
How often to redo it
At planned intervals, which in practice means annually for most organizations, and additionally whenever something significant changes: a new product, a major architectural shift, a new class of customer data, an acquisition, or a security incident that revealed something the register did not anticipate.
The annual refresh usually runs alongside the internal audit and management review, which is a sensible rhythm because each feeds the other.
FAQs
What does ISO 27001 clause 6.1 require?
That you define and apply a documented risk assessment process, identify risks to the confidentiality, integrity and availability of information in scope, analyse and evaluate them against defined criteria, assign a risk owner to each, and produce a risk treatment plan. The results drive your Statement of Applicability.
Does ISO 27001 require a specific risk assessment methodology?
No. It requires that your methodology is documented, repeatable and produces consistent, comparable results. Asset-based and scenario-based approaches are both accepted; scenario-based has become common for cloud-native companies where asset inventories are ephemeral.
What has to be in an ISO 27001 risk register?
A specific risk description, the affected information or asset, likelihood and impact scored on a documented scale, a named risk owner, the treatment decision, the controls applied, the residual risk, and a record of who accepted that residual risk. Named risk owners are the field most often missing.
What are the four risk treatment options?
Modify the risk by applying controls, retain it by accepting the residual risk, avoid it by ceasing the activity, or share it through insurance or contract. Sharing transfers financial consequence but never accountability, and auditors check that it is not being used in place of a control.
How often must the ISO 27001 risk assessment be repeated?
At planned intervals — annually for most organizations — and whenever significant change occurs, such as a new product, a major architectural change, a new category of data, an acquisition or a security incident. A register untouched since certification is a common surveillance finding.
Where to go next
Get the assessment run as part of an where you stand against ISO 27001, see how it drives control selection in the Statement of Applicability, or read Annex A controls.