ISO 27001 Risk Assessment: Method, Register, Treatment

Reviewed October 2026. Applies to: ISO/IEC 27001:2022, with Amendment 1:2024.

What the standard asks for

ISO/IEC 27001 does not prescribe a risk method. It asks for a defined process that you apply consistently, and it sets out what that process has to do.

Set risk criteria: how risks are assessed, and when a risk is acceptable.
Make the method repeatable, so that assessments done at different times give results you can compare.
Identify risks to the confidentiality, integrity and availability of information within the scope of the ISMS.
Give every risk an owner.
Analyse each risk: the consequences if it happened, how likely it realistically is, and the resulting level of risk.
Evaluate each risk against your criteria and put them in order of priority for treatment.
Treat the risks: choose an option, decide the controls it needs, check them against Annex A, record the decisions in a Statement of Applicability and a risk treatment plan, and have risk owners approve the plan and accept what remains.
Repeat the assessment at planned intervals and when significant changes are proposed or happen, and keep the results of assessment and treatment.

Guidance on doing this is in ISO/IEC 27005:2022, which follows the principles of ISO 31000, and the NCSC publishes a basic risk assessment method in its risk management guidance. The method below is one way to meet the requirements; any method that does the same things will do.

Risk criteria

Set the criteria before you assess anything, and have top management agree them. They need a scale for likelihood, a scale for consequence, a way to combine the two into a level of risk, and a rule for which levels can be accepted and by whom. Define each point on a scale in terms people can recognise, so two assessors reach the same rating.

An example of four-point scales. Adjust the descriptions to your organisation.
Score	Likelihood	Consequence
1	Rare: not expected in the next three years	Minor: no effect on customers; put right within a day
2	Unlikely: could happen within three years	Moderate: limited effect on customers or internal data exposed; days to recover
3	Likely: expected within a year	Major: customer data exposed or a service down for a day or more; a regulator may need to be told
4	Almost certain: expected several times a year	Severe: a large breach or a long outage; contracts or the business at risk

With these scales the level of risk is likelihood multiplied by consequence, from 1 to 16. A simple acceptance rule: 1 to 4 is low and the risk owner may accept it; 5 to 8 is medium and needs treatment or acceptance by a director; 9 to 16 is high and needs treatment, with progress reported at management review.

Assets and interested parties

The 2022 standard identifies risks against information within the scope, not against a list of assets, and does not require an asset-based method. ISO/IEC 27005 describes two complementary approaches: starting from events (risk sources and what they could do to you) or from assets (the assets, their threats and their vulnerabilities). Most organisations start with assets, because an inventory is concrete, and Annex A has a control for one (A.5.9).

Information: customer records, personal data, source code, financial records, contracts, credentials and keys.
The systems and services that store or process it: cloud accounts, SaaS applications, servers, laptops and phones, websites, domains and email.
People and suppliers who handle it: staff, contractors, hosting providers, managed IT, payroll and payment providers.

Record an owner for each asset: the person responsible for it day to day, who knows what it would cost to lose it. The NCSC's basic method notes that asset owners are key to understanding the impact on their assets.

Interested parties come from clause 4.2: customers, staff, regulators, suppliers, insurers and owners. Their requirements, such as contract terms, data protection law and sector rules, shape both your risk criteria and the consequences you assign. A breach that would put a key contract at risk rates higher than one that would not.

Internet-facing assets are the ones most often missing from inventories. Certificate transparency logs, DNS records and the technology a site reveals will show you what is public, including forgotten subdomains and records that point at services you no longer run.

Subdomain finder Find a domain's subdomains in public certificate transparency logs.
DNS checker Look up a domain's A, AAAA, CNAME, MX, TXT, NS, SOA, CAA and DS records through public resolvers.
Technology detector See the web server, CDN and frameworks a site's home page discloses.
Dangling DNS checker Find a CNAME that points at a name that no longer exists.

Threats and vulnerabilities

A threat is something that could cause harm: a criminal, a mistake, a supplier failure, a flood. A vulnerability is a weakness a threat can use: an unpatched server, an account without multi-factor authentication, a single administrator, untested backups. A risk is the combination: a threat exploiting a vulnerability to affect information, with a consequence for its confidentiality, integrity or availability.

Threat	Vulnerability	Effect on information
Phishing for passwords	Accounts without multi-factor authentication	Mailbox or system taken over; data read or changed
Exploitation of a published software flaw	Unpatched or end-of-life software facing the internet	Data stolen or encrypted for ransom
Domain spoofing	No DMARC policy at enforcement	Fraudulent email sent in your name
Subdomain takeover	A DNS record pointing at a cloud resource that no longer exists	Someone else serves content under your domain
Supplier outage	One provider and no tested fallback	A service or its data unavailable
Human error	Shared administrator accounts and no change review	Misconfiguration or deleted data

Write each risk as one sentence: what could happen, to which information, through which weakness, with what result. A risk statement that names a vulnerability points straight at its treatment.

Likelihood and consequence

Rate each risk against the scales, taking into account the controls already in place. Write down why you chose each rating: the reason is what makes the assessment repeatable, and it is what an auditor or next year's assessor will look for.

Likelihood: how exposed the asset is, how attractive it is, how often similar events happen to you and to organisations like you, and how well current controls work.
Consequence: the effect on customers, on operations, on legal and contractual obligations and on reputation, judged against the worst realistic outcome rather than the worst imaginable one.

Qualitative scales are normal and are enough for the standard. Numbers multiplied together look precise but are only as good as the descriptions behind them; consistency matters more than precision.

The risk register

The standard does not name a risk register, but it requires you to keep the results of assessment and treatment, and a register is the usual way to do it. A spreadsheet is enough for most organisations.

Field	What it holds
Reference	An identifier that stays with the risk.
Risk statement	What could happen, to which information, through which weakness, with what result.
Assets	The information, systems or services affected.
Owner	The person accountable for the risk.
Existing controls	What already reduces the risk.
Rating	Likelihood, consequence and level, with the reason for each.
Decision	The treatment option chosen.
Planned controls	New or changed controls, with Annex A references.
Target level	The level expected once treatment is complete.
Actions	Who does what, and by when.
Status and review	Progress, acceptance of the residual risk, and the date of the next review.

Risk owners

A risk owner is the person with the accountability and authority to manage a risk. That is usually a manager of the business area the risk affects, not the IT team by default: the finance director owns invoice fraud, the head of engineering owns the production platform. The risk owner may be the same person as the asset owner, but need not be.

Risk owners approve the risk treatment plan and accept the residual risk, so they need enough seniority to make those decisions within your criteria. If every risk is owned by one IT manager, ask whether that person can really accept risks on behalf of finance, HR and sales.

Risk treatment

For each risk that needs treatment, choose an option. The common options, in the terms used by ISO/IEC 27005 and ISO 31000, are these.

Option	What it means	Example
Modify	Apply or change controls to reduce likelihood, consequence or both.	Require multi-factor authentication on email.
Avoid	Stop the activity that creates the risk.	Retire a legacy service instead of securing it.
Share	Pass part of the risk to another party through a contract or insurance.	Cyber insurance; security terms in a supplier contract.
Retain	Accept the risk by an informed decision, within your criteria.	A low risk with adequate controls already in place.

Then decide which controls each chosen option needs. They can come from any source: your own design, a supplier's guidance, NCSC advice. Clause 6.1.3 then has you compare them with Annex A to confirm nothing necessary has been missed.

The Statement of Applicability

The Statement of Applicability lists every Annex A control, says whether it is needed and whether it is in place, and gives the reason for including or excluding it. Its reasons should trace back to the risk register: a control is included because it treats named risks, or because a requirement such as a contract or the law calls for it. The Annex A controls guide covers building one.

The risk treatment plan

The risk treatment plan sets out what will be done for each risk, by whom, with what resources and by when. Each risk owner approves the plan for their risks and accepts the residual risk: the level expected once treatment is done. Under clause 8.3 you then carry out the plan and keep a record of the results, and the state of the plan is an input to management review.

A worked example

Five risks from a small software company, rated with the scales above. L is likelihood and C is consequence.

Illustrative only. Ratings and controls depend on your own context and criteria.
Risk	Owner	L x C	Treatment	Residual
The customer database accepts password logins from the internet; a reused password lets an attacker copy customer records.	Head of engineering	3 x 4 = 12, high	Modify: restrict access to the application servers, require key-based authentication, alert on failed logins (A.8.20, A.8.5, A.8.16).	1 x 4 = 4, low; accepted
No DMARC policy at enforcement; a criminal sends invoices in the company's name and a customer pays the wrong account.	Finance director	3 x 3 = 9, high	Modify: publish SPF and DKIM, move DMARC to `p=reject`, confirm bank detail changes by phone and train staff (A.5.14, A.6.3).	2 x 3 = 6, medium; accepted by the director, review in six months
A file transfer server runs end-of-life software; a published flaw is used to take files.	IT manager	3 x 3 = 9, high	Avoid: retire the server and move transfers to the existing document platform.	Removed
The payroll provider is breached and staff bank details are exposed.	HR director	2 x 3 = 6, medium	Share: security and breach notification terms in the contract, a yearly supplier review, cyber insurance (A.5.19, A.5.20).	2 x 2 = 4, low; accepted
A laptop is stolen from a member of staff.	Head of operations	2 x 2 = 4, low	Retain: full-disk encryption and remote wipe are already in place.	2 x 2 = 4, low; accepted

Each Annex A reference in the treatment column appears in the Statement of Applicability with these risks as its reason, and each action goes into the treatment plan with an owner and a date.

Where external checks fit

An external check cannot assess risk for you; likelihood, consequence and acceptance are judgements only the organisation can make. It can supply facts about internet-facing assets, and show from outside whether a treatment changed anything.

Risk assessment evidence

Ironfang can check

Subdomains in certificate transparency logs, DNS records and dangling records, to complete the inventory of internet-facing assets.
Vulnerabilities visible from outside: end-of-life software, weak TLS, missing security headers, email authentication gaps.
For a verified domain, which services on a fixed list of high-risk ports answer from the internet.
Rechecks after treatment, showing the change from outside, with a dated history.

The organisation must establish

The method, the risk criteria and top management's agreement to them.
Assets that are not public, their owners and their value to the business.
Likelihood and consequence ratings and the reasons for them.
Treatment decisions, the Statement of Applicability and the risk treatment plan.
Risk owners' approval and acceptance of residual risk.
Risks with no internet footprint: people, suppliers, physical security, internal systems.

The External Security Check runs these checks on a verified domain and keeps the results with the domain's history. The check reference explains each finding and its fix.

Keeping it current

Clause 8.2 requires assessments at planned intervals and whenever significant change is proposed or happens. Set the interval in your method; once a year is common. Treat these as triggers for an extra review:

a new system, service, supplier or office;
a change of scope, ownership or business model;
an incident or near miss;
a new legal, regulatory or contractual requirement;
a change in threats, such as a widely exploited flaw in software you use.

Keep each version of the register, so you can show how risks moved over time. The ISO 27001 checklist includes the risk assessment in a full readiness review.

Sources

Checked on the review date above. Standards and schemes change; the source is the authority.

ISO 27001 risk assessment