In brief
ISO 27001 Clause 6.1.2 requires a repeatable risk assessment method. Learn what the standard demands and how teams structure a risk register that works.
An ISO 27001 risk assessment is the defined, repeatable process that clause 6.1.2 of ISO/IEC 27001:2022 requires for finding, analysing and evaluating information security risks. Its output, a risk register with owners and risk levels, drives risk treatment (clause 6.1.3) and therefore which Annex A controls you implement and record in the Statement of Applicability.
Why does ISO 27001 start from risk?
ISO/IEC 27001 is a risk-based standard: it does not hand you a fixed control list but asks you to choose controls that treat your own risks. PCI DSS, by contrast, prescribes requirements for any environment that stores, processes or transmits card data.
That makes the risk assessment the decision engine of the ISMS. If it is generic ("we might get hacked"), the controls chosen from it will be generic too, and certification auditors will ask why a given control was selected or excluded.
What does clause 6.1.2 require?
Clause 6.1.2 requires you to define and apply a risk assessment process and to keep documented information about it. The process must:
- establish criteria, including risk acceptance criteria and criteria for performing assessments;
- produce consistent, valid and comparable results when it is repeated;
- identify risks associated with loss of confidentiality, integrity and availability within the ISMS scope, and identify a risk owner for each;
- analyse risks by assessing realistic likelihood and potential consequences, and determine the risk level;
- evaluate risks by comparing results with the criteria and prioritizing them for treatment.
The standard does not mandate a method. You choose the scales and the formula, provided the method is written down and gives comparable results when someone else runs it. Clause 8.2 then requires you to perform risk assessments at planned intervals and when significant changes are proposed or occur, and to retain the results.
How is risk assessment different from risk treatment?
Risk assessment (6.1.2) is analysis: what can go wrong, who owns it, how likely and how bad. Risk treatment (6.1.3) is decision: what to do about each risk above your acceptance criteria.
Clause 6.1.3 requires you to select treatment options, determine the necessary controls, compare them with Annex A, produce the Statement of Applicability, formulate a risk treatment plan and obtain the risk owners' approval of the plan and their acceptance of residual risks. ISO/IEC 27001 does not list the treatment options; the usual set, described in ISO/IEC 27005, is:
| Option | ISO/IEC 27005 term | Example |
|---|---|---|
| Mitigate | Risk modification | Add MFA to reduce account-takeover risk |
| Accept | Risk retention | Accept a low-impact risk for a defined period, with owner sign-off |
| Transfer | Risk sharing | Move card handling to a payment provider; add cyber insurance |
| Avoid | Risk avoidance | Stop storing a data type you do not need |
What should an ISO 27001 risk register contain?
The standard does not prescribe a template, but to satisfy 6.1.2 and 6.1.3 each risk entry needs enough to show identification, ownership, analysis, evaluation and treatment.
| Field | Why it is needed |
|---|---|
| Asset, process or scenario | Identifies what is at risk inside the ISMS scope |
| Threat and vulnerability | Makes the risk specific enough to choose a control |
| Risk owner | Required by 6.1.2 c; approves treatment and residual risk |
| Likelihood and consequence | The analysis step, on scales you define |
| Risk level | Compared with your acceptance criteria |
| Treatment option and actions | Output of 6.1.3, with owners and due dates |
| Related Annex A controls | Links the risk to the Statement of Applicability |
| Residual risk and acceptance | Shows the owner accepted what remains |
| Last and next review date | Evidence for clause 8.2 |
A spreadsheet is enough to start. What matters is that the fields are filled consistently and the register is kept current.
Which scoring approach should you use?
Most first-time ISO 27001 teams use a qualitative matrix: likelihood and impact each rated 1 to 5, risk level equal to likelihood × impact, giving 1 to 25. You then set the acceptance threshold in your criteria, for example "risks scoring 10 or more require treatment", and define what each rating means in your context so two assessors score the same scenario the same way.
ISO/IEC 27005:2022 describes event-based and asset-based approaches to identifying risks. Event-based starts from scenarios ("a former employee keeps production access"); asset-based starts from the inventory and asks what could affect each asset. Smaller companies often find event-based quicker and more concrete, then check coverage against the asset inventory.
Which risk areas should the assessment cover?
Cover the whole ISMS scope, using the four Annex A themes as a checklist so nothing obvious is missed:
- Organizational: supplier and cloud dependencies, incident handling gaps, unclear roles, legal and contractual obligations.
- People: insider misuse, low awareness, social engineering, accounts not removed at offboarding.
- Physical: office access, lost or stolen laptops, equipment disposal.
- Technological: misconfigured cloud services, unpatched systems, weak authentication, missing encryption or logging, insecure code.
Write each risk as a specific scenario tied to an asset or process. Specific risks lead to specific controls; vague risks lead to vague controls that auditors challenge.
When must you repeat the risk assessment?
At the planned interval you set (usually at least once a year) and whenever significant changes are proposed or occur, as clause 8.2 requires. Typical triggers:
- new cloud infrastructure or a new hosting region;
- a new product feature that handles sensitive or personal data;
- a major supplier change;
- a security incident or a near miss;
- organizational changes such as a merger or a large hiring wave;
- entering a market with different legal requirements.
Surveillance audits in years two and three of the certificate cycle will look for an assessment that reflects current operations.
How does the risk assessment connect to Annex A and the SoA?
Treatment decisions determine the controls you need; you then compare that list with the 93 Annex A controls and record the result in the Statement of Applicability. Every Annex A control appears in the SoA as included or excluded, with a justification, and the included controls should trace back to treated risks or other requirements such as contracts or law. The control-by-control view is in the ISO 27001 Annex A controls guide.
What do certification auditors check in the risk assessment?
- A documented, repeatable method with acceptance criteria.
- A named owner for every risk.
- Justified treatment decisions, including signed-off acceptance of residual risk.
- Consistency between the risk register and the SoA.
- Evidence of review at planned intervals and after significant changes.
The most common initial-certification finding is a register that is too generic. Your internal audit should test these five points before the certification body does.
How does pTrackly support ISO 27001 risk assessment?
pTrackly's risk register scores each risk as likelihood × impact on 1–5 scales, records inherent and residual risk, the threat and vulnerability, the risk owner and a linked asset. For each risk you choose Mitigate, Accept, Transfer or Avoid; treatment actions carry an owner, a due date, control references such as "ISO 27001 A.5.17" and an evidence reference, and an owner or admin verifies them. Accepted risks need a justification and an expiry date, and each risk has last and next review dates. Your team still defines the method and criteria, identifies the risks and makes the treatment decisions. See pTrackly for ISO 27001.
Frequently asked questions
Does ISO 27001 require a specific risk assessment method?
No. Clause 6.1.2 requires a defined process with criteria that gives consistent, valid and comparable results. A simple 1–5 likelihood and impact matrix is acceptable if it is documented and applied consistently.
Is ISO/IEC 27005 mandatory for ISO 27001 certification?
No. ISO/IEC 27005 is guidance on information security risk management. You are audited against ISO/IEC 27001 only, though following 27005 makes the method easier to defend.
How often should the ISO 27001 risk assessment be updated?
At the planned interval you define, commonly yearly, and whenever significant changes are proposed or occur, as clause 8.2 requires. Keep the dated results as documented information.
Who should own each risk?
A person with the accountability and authority to manage it, usually the head of the affected business area or system, not the security team by default. Risk owners approve the treatment plan and accept residual risk.
References:
- ISO/IEC 27001:2022, Information security management systems (iso.org/standard/82875.html)
- ISO/IEC 27005:2022, Guidance on managing information security risks (iso.org/standard/80585.html)
