ISO 27001 Clause 6.1: risk assessment, treatment and the SoA

The due-diligence questionnaire asks for your risk assessment methodology and your Statement of Applicability. You have a spreadsheet nobody has opened since the last audit, and the deal is waiting.

This guide covers ISO 27001 Clause 6.1 for information security leads, compliance managers and CTOs at 25–250 person firms. It separates 6.1.1, 6.1.2 and 6.1.3, shows how to score risk consistently, how to write the SoA and who signs for residual risk, and what stage 2 auditors actually test.

What does ISO 27001 Clause 6.1 require?

Clause 6.1 requires an organisation to plan how its ISMS handles risk and opportunity in three parts. 6.1.1 covers management-system risks and upside, 6.1.2 defines a repeatable confidentiality, integrity and availability risk assessment, and 6.1.3 covers risk treatment, control selection against Annex A, the Statement of Applicability and owner sign-off.

The ISO/IEC 27001:2022 Specification explains why: an ISMS keeps information confidential, intact and available by managing risk, and that is what gives interested parties confidence. Clause 6.1 is where that process is defined, which is why controls, objectives and management review all lean on its output.

Each sub-clause hands its output to the next:

• 6.1.1 plans for the management system itself. It asks what could stop the ISMS delivering and what could make it deliver better, using your Clause 4.1 and 4.2 analyses as input.
• 6.1.2 assesses risk to information. It fixes the rules first, then applies them to find, score, rank and assign owners to risks against in-scope information.
• 6.1.3 treats, selects and signs. It takes the ranked list, decides what to do with each risk, selects controls, records the lot in the SoA and gets owners to accept what remains.

The architecture matters at stage 2 because the register is the justification layer for the whole ISMS. Every control you built, every Annex A control you skipped and every pound of security spend should trace back to it. The SoA is the most-read document the ISMS produces: the certificate references it, auditors work from it session by session and enterprise buyers ask for it in due diligence.

What does managing risks according to Clause 6 of ISO 27001 look like at 25–250 people?

At 25–250 people, managing risks according to Clause 6 means one methodology and one register serving both 6.1.1 and 6.1.2, run as a single planning exercise once Clause 4 is done, then a treatment cycle for 6.1.3. The NCSC Cyber Security Risk Management Guidance advises risk management that illuminates real risks rather than satisfying compliance requirements.

Sequencing matters more than volume at this scale. A workable order:

1. Finish Clause 4 first. The context and interested-party analyses are the raw material for everything else.
2. Write one methodology. Scoring and acceptance thresholds sit in a single document that 6.1.1 and 6.1.2 both use. A likelihood-times-impact grid with defined thresholds is enough.
3. Run 6.1.1 and 6.1.2 back to back. A focused workshop plus a few days of write-up covers the strategic side. The first full asset-level pass typically takes one to two weeks of elapsed effort.
4. Move to treatment. With the assessment done, expect roughly a week to treatment decisions and a draft SoA, plus a sign-off cycle.

Sophistication you won't use consistently is a liability, and a second register for a second sub-clause doubles the upkeep without improving a single decision.

The NCSC position gives you a practical filter. If a scoring exercise never changes a budget line, a priority or a release decision, it is the tick-box technique the guidance warns against. A risk assessment earns its keep when the ranked list explains why money went to one control rather than another.

How do you turn Clause 6.1.1 context and opportunities into owned actions?

Start from your Clause 4.1 context and Clause 4.2 interested-party analyses and ask of each item what it could break and what it could unlock. Each answer becomes a register entry with an owner, an action built into existing processes, and a defined measure of effectiveness. Opportunities are mandatory, not optional.

6.1.1 is planning for the ISMS itself, not for individual information assets. "Key engineer leaves and the ISMS stalls", "budget cut kills the awareness programme" and "regulatory shift lands mid-year" belong here. "Laptop stolen with client data" belongs in the 6.1.2 register.

Five moves make the planning operational:

1. Trace every entry. Each register entry points to the Clause 4 item it came from. That traceability is exactly what the auditor tests.
2. Record upside deliberately. Certification opening enterprise deals, SSO cutting risk and support load, automation shrinking audit prep. Each gets an owner, an action and a definition of done.
3. Push actions into machinery that already runs. Change control, vendor onboarding, the engineering backlog and HR joiner processes carry the work. An action that lives only in the register stalls.
4. Decide effectiveness measures up front. A small set reviewed at management review replaces "risks reviewed, noted" in the minutes.
5. Close the loop from incidents. Every post-mortem ends with the register being touched, or a note of why not.

An opportunity with no owner, no action and no definition of done is a wish, and the clause doesn't accept wishes.

The failures this practice inverts are predictable. Context drift leaves a register describing the company as it was two years ago, with retired products and the pre-cloud stack. An empty upside column is a routine audit finding, not a style point. Done properly, planned and owned upside is also how security spend gets tied to revenue instead of being framed as pure cost.

How do you build a Clause 6.1.2 risk assessment that scores consistently?

Write the methodology before assessing anything: a 5×5 likelihood-and-impact grid with scales anchored in real numbers, such as pounds lost, downtime or clients affected, plus an explicit acceptance line. Then assess scenarios against an asset inventory, record the reasoning behind each score, and give every risk a named, senior owner.

Anchoring is the step teams skip, and it is what makes the process repeatable. Two people running the assessment six months apart should reach scores that can be compared.

Scores that mean different things in different teams aren't a methodology. They're opinions with a grid.

The acceptance line states which scores you will tolerate and which force action. It is the most load-bearing sentence in the document. With the rules fixed, the build runs in this order:

1. Inventory the assets. List systems, data sets, key suppliers, sites and the people who hold critical knowledge. Rate each for how much its loss would hurt and map it to an owner, because risks hang off assets.
2. Frame scenarios. Write a specific threat meeting a specific weakness with a specific consequence, not a one-word entry like "ransomware".
3. Score raw exposure first. Rate before crediting any safeguards, then record the reasoning. The rationale is what the auditor reads.
4. Name the owner. A person or role senior enough to fund treatment and sign for what remains. "IT Support" is not an owner.
5. Identify cross-functionally. One workshop with a risk champion each from engineering, ops, HR, finance and legal beats a compliance officer guessing alone.
6. Keep the register alive. Timestamped entries and a visible change history, with reassessment after cloud migrations, big releases, supplier changes, incidents or M&A.

The evidence this leaves is concrete: the methodology, the register with pre- and post-treatment ratings, the asset inventory, workshop attendance and owner sign-offs. Auditors weigh coherence and life. They look for scores that follow the stated scales and a change history spanning months.

Two failures undo the work. One-person risk management inherits a single perspective's blind spots, and the copy-paste refresh, last year's register re-dated, is betrayed by its own change history. A defensible assessment pays back in the other direction too: it lets a 50-person firm say no to a control with a straight face.

How do Clause 6.1.3 risk treatment and the Statement of Applicability work?

Clause 6.1.3 turns the ranked risk list into signed decisions. For each risk above the line you choose treat, tolerate, terminate or transfer, derive the controls that choice demands, then sweep all 93 Annex A controls as a completeness check. The Statement of Applicability records each control's status and rationale, in or out.

Record which option you chose and why, because the reasoning is audited, not the label. The standard doesn't mandate the four labels, only a recorded and reasoned choice per risk.

Order matters. Derive the control set from the treatment choices first, then run the Annex A sweep as a checklist pass. Starting from Annex A is how 30-person firms end up building controls no risk asked for. Controls can come from anywhere, and Annex A is the backstop that catches what you missed.

Keep the SoA to one disciplined table: control, in or out, rationale and implementation status. Honest "partially implemented" entries are fine, because auditors distrust a certification-ready SoA far more than a truthful in-progress one. Make each exclusion defensible in a sentence grounded in the business, such as "no software development, so the secure-coding controls don't apply".

The ICO Guide to Data Security applies the same proportionality to personal data. Under UK GDPR you can weigh the state of the art and implementation costs, provided measures stay appropriate to your circumstances and the risk your processing poses. That is what makes a reasoned SoA exclusion defensible rather than a shortcut.

The treatment plan is where decisions become work. Each plan line needs:

• A specific safeguard, naming the tool or configuration.
• A named individual, not a team.
• A budget and a date.
• A definition of done.

"Improve security" is not a plan line.

Two other pitfalls recur. Controls chosen from habit and never held against the full catalogue leave genuine needs undiscovered until audit week. Transfer treated as wishful thinking assumes cyber insurance or outsourcing makes risk vanish, when nobody can state the coverage limits or who watches the supplier.

Who should sign off risk acceptance under Clause 6.1.3?

The named risk owner signs: a senior leader with the budget and accountability to stand behind the decision. A sysadmin or IT contractor accepting residual risk on the business's behalf is a finding waiting to happen. Acceptance must be recorded, through a signed form, minuted decision or workflow approval, not verbal.

This is a governance decision, not a technical task. Sign-off moves a risk from something IT worries about to something a named business leader has formally chosen to live with. That is the posture regulators, NIS2 and DORA in particular, now expect boards to demonstrate.

A defensible record shows four things:

• the risk and the exposure that survives treatment;
• the treatment plan the owner is accepting;
• the owner's name and the date;
• the form of approval, whether signature, minute or workflow step.

An email thread saying "fine by me" doesn't survive an audit well, and "show me the record, not the conversation" is a question to expect. Keep one more safeguard in the loop: whoever plans a treatment shouldn't be the only person who reviews it. Capturing approvals as workflow steps, covered in the final section, turns who-approved-what-when into a report rather than an inbox hunt.

What do stage 2 auditors test under Clause 6.1, and where do audits go wrong?

Stage 2 auditors sample risks end to end, tracing asset to scenario, score, owner, treatment, SoA line and sign-off, and check timestamps to tell a living register from a pre-audit batch edit. Missing methodology or SoA grades major; inconsistent scoring, stale entries or weak traceability grade minor, aggregating to major as a pattern.

Expect questions in the room that follow each sub-clause. They reflect audit practice, not the standard's own wording:

• 6.1.1: "Pick any register entry. Which context issue or stakeholder requirement did it come from?" and "Show me an opportunity, who owned it and what happened."
• 6.1.2: "What makes a risk one you'll accept, and who set that line?" and "Two departments assessed similar scenarios. Why do the ratings differ?"
• 6.1.3: "Who accepted the risk that remains here? Show me the record." and "You've excluded this control. Justify it."

Grading follows certification-body practice rather than the clause's own wording. No evidence of planning at all, such as no methodology, no SoA or no owner approval anywhere, is the absence-of-requirement case, which is why it grades major. A single stale entry or missed sign-off grades minor on its own. The risk is the pattern.

Four patterns recur in findings:

• Pre-audit batch editing. Forty entries edited in one week, timestamped for the auditor to find.
• Past incidents mixed with prospective risks. An incident is an issue to fix. A risk is an uncertainty to manage.
• Stale SoA status. A control marked implemented that other audit sessions show is half-built.
• "N/A" in the SoA. Exclusions with no business reasoning attached, raised as findings in their own right.

A register last edited three weeks before the audit isn't evidence of risk management. It's evidence of an audit.

The test underneath all four is reconciliation. Register, SoA and treatment plan must tell one story, and auditors find a mismatch faster than internal reviews do. Where the three agree, the interviews become a formality: owners know they own their risks, scores follow the scales and the dates make sense.

How do you run Clause 6.1 as code instead of a spreadsheet?

Treat the register as structured data. Each entry links to the Clause 4 item and asset it came from, actions live as Jira or Linear tickets, scoring is constrained in the tool, and the SoA renders from control records on demand. Scheduled reconciliation checks catch orphaned risks before an auditor does.

The aim is evidence as a by-product of working, not a project before the audit. The reconciliation job verifies that every above-threshold risk maps to a treatment decision and an SoA line, and that every "in" control has plan coverage. Around it sit a few more mechanisms:

• Asset-joined data. A new system, vendor or data set entering the inventory raises an "assess me" task, and a criticality change flags dependent risks.
• Provenance by construction. Every edit is timestamped and attributed as a side effect of using the system, so the living-register evidence exists without anyone curating it.
• Event-driven triggers. Incident closure, vendor onboarding or a major change request opens a scoped review, with the trigger logged as proof the process is dynamic.
• Sign-off as workflow steps. Owner approvals of plans and residual exposure are captured where the work happens.
• Effectiveness on a dashboard. The small measure set feeds management review automatically, replacing the quarterly hunt for numbers.

The payoff is commercial as much as operational. Continuous evidence means less audit-prep drag for a small team. A buyer who reads a living register, a generated SoA and timestamped approvals gets assurance they accept rather than discount.

Frequently asked questions