ISO 27001 Clause 8.2: risk assessment cadence and change triggers

The auditor opens your risk register, points at the AWS migration from March and asks for the assessment that came before it. You have a methodology. You don't have that assessment, and the Stage 2 visit is booked.

This guide covers ISO 27001 Clause 8.2 for security and compliance leads at regulated and B2B SaaS firms of 25 to 250 people. It sets out the cadence to commit to, the changes that should trigger a fresh assessment, the evidence auditors sample and how results hand off to Clause 8.3.

What does ISO 27001 Clause 8.2 require, and how does it differ from Clause 6.1.2?

ISO 27001 Clause 8.2 requires the risk assessment to actually run: on a committed schedule and whenever a significant change is proposed or has landed, using the criteria set under Clause 6.1.2, with results kept as records. Clause 6.1.2 designs the method; Clause 8.2 operates it.

Clause 6.1.2 fixes the criteria, the scales and the acceptance line. An auditor tests that design by reading your methodology. Clause 8.2 is tested by reading your register's history, and plenty of firms pass the first test and fail the second.

Using the planning-time criteria on every run keeps results comparable. Reinvent the scales mid-cycle and this quarter's score says nothing about last quarter's.

Each run makes the same three moves. It identifies risks against named assets and owners, analyses how likely each one is and how much harm it would do to confidentiality, integrity and availability, then evaluates the result against your acceptance line. Only the inputs change between runs.

Records matter because the register's history is the proof the process is alive. A register that shows only its current state cannot tell an auditor whether anyone looked at it in March.

The exposure is sharpest for a regulated firm. A change-driven incident with no preceding assessment is the fact pattern regulators and insurers probe after a breach, and "we never looked" is the worst available answer.

How often should you run an information security risk assessment?

Run the cadence you committed to in your methodology. For a 50-person regulated firm, that means a quarterly register pass plus one fuller annual review, with change-triggered assessments in between. The auditor tests you against the interval you wrote down, so promise only what you will actually sustain.

Three layers of activity make up the rhythm, and each has a different job:

• Quarterly register pass. Walk every entry, confirm the owner, check the last review date and re-score anything whose inputs have moved, such as a fresh vulnerability scan or access review. Log the pass so the history shows it.
• Annual deep review. Step back from individual entries and test the frame: the asset inventory, the threats, and whether the scales and tolerance still fit the business. Leadership reviews the results here.
• Change-triggered assessments. Scoped to the change, run when an entry on your written trigger list fires, and kept apart from the calendar passes.

Once Clause 6.1.2 exists, this is a modest load. The criteria are fixed and the owners are named, so each pass becomes a review of what moved rather than a rebuild. The NCSC cyber security risk assessment and management guidance makes the same two-part point: revisit assessments at regular intervals and immediately when something significant changes.

The annual checkbox is the pitfall this rhythm exists to prevent. One yearly pass with no change triggers leaves a register describing the company as it was twelve months ago, with every migration, hire and release since then outside the record.

Writing "monthly" into the methodology and delivering twice a year produces a gap the auditor can measure. A smaller commitment, kept, is better evidence.

What counts as a significant change that triggers a new risk assessment?

A significant change is whatever your written trigger list says it is, defined in advance. Typical entries are cloud or platform migrations, customer-facing APIs, major releases, acquisitions or rapid headcount growth, hybrid working and entry into a new regulatory jurisdiction. A written list turns 'should we have assessed that?' into a lookup.

Make each trigger testable by tying it to the system that already records the event:

• Cloud or platform migration: the architecture change request or project approval.
• Customer-facing API or major release: the release pipeline or product roadmap sign-off.
• Acquisition or rapid headcount growth: board papers and the HR hiring plan.
• Hybrid working or a new jurisdiction: the policy change record, or the legal and sales approval for the new market.

The definition matters more than the specific list, because it makes the obligation testable. Your entries will differ from these. What counts is that someone can answer "did this event fire a trigger?" without calling a meeting.

Include outside changes as well as your own. The NCSC guidance names a change in the threat, or in the way a system or service is used, as reasons to revisit an assessment.

The clause covers proposed changes as well as completed ones, so the assessment belongs before the decision. A migration assessed after go-live is a retrofit, and auditors read it as one.

The best proof your risk process is alive is an assessment for something that never shipped.

So keep the pre-launch assessment when a project is cancelled. Auditors ask for one, because it shows the process runs on proposals rather than retrofits.

Incidents are triggers too. After any material incident, revisit the risks it touched and update the register, because post-incident updates are a trigger-based assessment auditors specifically look for.

What evidence proves your risk assessments are real?

Auditors want a register with change history spanning the whole period, assessment reports, sign-offs and the technical inputs behind scores: scan exports, access reviews, incident records. The deciding test is temporal: assessment activity must track your business change calendar, not the audit calendar.

A defensible evidence set usually holds these records:

• The register in its current state: assets, threats, weaknesses, scores against confidentiality, integrity and availability, and named owners.
• A change history that spans the whole audit period rather than a single export.
• Assessment reports from scheduled passes, plus the management or board minutes where results were reviewed and escalations decided.
• Change-triggered assessments tied to named projects or migrations.
• Technical inputs behind the scores, such as scan exports and access review outputs.
• Owner sign-offs on residual positions, and register updates traceable to closed incidents.

The auditor lines your business change calendar up against the register timeline. Each release, migration and hiring surge should have assessment activity beside it. A static document list cannot pass that test, because the test concerns when things were recorded, not whether documents exist.

Scores need the same grounding. A likelihood of 4 survives questioning when the risk owner can point to a recent scan, an access review finding or the incident history behind it.

A risk score with no evidence behind it is a guess with a number attached.

How do Clause 8.2 results feed Clause 8.3 risk treatment?

Every risk the assessment rates above your tolerance goes straight into Clause 8.3 as a treatment item with an option, an owner and a date. The handoff is the audit trail between the two clauses. If nothing ever flows across, an auditor concludes either that your business never changes or that the assessment is not real.

The handoff works as four steps:

1. Flag. Score every entry against the tolerance fixed at planning time.
2. Open. Turn each entry above the line into a treatment item in the Clause 8.3 plan.
3. Link. Cross-reference the register entry and the treatment item, so the auditor can follow the trail from either end.
4. Sign. Capture owner sign-off on risks accepted or tolerated, not only on those needing treatment.

Clause 8.3 depends on this feed. Without a current register, treatment has nothing current to treat, and the plan drifts towards last year's risks.

The pitfall is assessment outputs that never become treatment inputs. A process disconnected from treatment fails both clauses at once: Clause 8.2 produced nothing usable, and Clause 8.3 had nothing to work from.

What mistakes undermine a Clause 8.2 risk assessment?

Four patterns undermine the process: IT tunnel vision, a borrowed scoring matrix that ignores your real tolerance, flat prioritisation where everything scores medium, and leadership absent from the loop. Each leaves scores that exist but drive no decisions. The fixes are small and mostly structural.

• IT tunnel vision. A register full of malware and patching entries, with nothing on legal exposure, people, suppliers or reputation. Put legal, HR and operations in the review, so the register covers the whole business.
• Borrowed scoring matrix. Scales copied from a template do not map to your appetite. Build them around your own tolerance at planning, with leadership agreeing the acceptance line.
• Flat prioritisation. When everything scores medium, treatment effort spreads thin. Set an explicit escalation threshold so effort concentrates on the few entries above it.
• Absent leadership. Criteria set by the security lead alone, escalations that never reach the board, missing sign-offs. Leadership should approve the criteria, receive escalations and sign acceptances.

None of these fixes needs new tooling. They need decisions made once and written down.

How do auditors test Clause 8.2 at Stage 2?

Auditors sample individual register entries for review recency, cross-reference known business changes against assessment records, interview risk owners about their own entries, and trace acceptance decisions to a signature. Expect five questions, from 'when was this entry last reviewed?' to 'show me a risk you decided to live with.'

Rehearse these five questions with your risk owners:

1. "Open your register. When was this specific entry last looked at, and by whom?"
2. "You migrated to AWS in March. Show me the assessment that preceded the decision."
3. "Why is this likelihood a 4? What evidence sits behind that number?"
4. "You own this risk. Explain the score and where its treatment stands."
5. "Show me a risk you formally decided to live with, and who signed that decision."

Question four goes to the risk owner, not the security lead. Owners who cannot explain their own entries turn a clean register into a finding, so brief them before the visit.

Auditors grade by pattern:

• Major: no assessment activity since the last audit cycle, or a major change assessed only after the fact or never.
• Minor: a stale entry, an owner unsure of their risk, or thin evidence behind one score.
• Minor aggregating to major: repeated minor gaps that show the process is not operating.

A risk register that changes only in the fortnight before the audit isn't a register. It's a rehearsal.

Preparation is cheap. A month ahead, run the five questions yourself, pick one real change from the past year and trace it from trigger to assessment to treatment item to signature. Gaps you find then are fixable, whereas gaps found in the room are findings.

How can you automate Clause 8.2 so it runs itself?

Wire the clause into the systems that already hold your changes and evidence. Review tasks generate themselves, a qualifying change opens a scoped assessment, scan and access-review outputs attach to risks, closed incidents raise reassessments, and any score above tolerance opens an item in the Clause 8.3 plan.

Each piece removes a manual step that would otherwise depend on memory:

• Cadence as automation. Review tasks generate per entry and chase owners. Recency becomes a dashboard column, and "when was this last reviewed?" is answered by the system.
• Triggers wired to change sources. The trigger list lives as rules against the change pipeline, project tracker and vendor register, with each firing logged as evidence.
• Scores fed by telemetry. Vulnerability scan results and access review outputs sit on the risks they inform, so likelihood ratings carry their evidence by construction.
• The incident loop. Closing an incident of sufficient severity raises a reassessment task on the affected risks.
• Appetite-breach routing. Any entry above tolerance opens a treatment item automatically, which makes the handoff mechanically unbreakable.

The human layer shrinks to judgement: scoring what the system flags, deciding what to accept and challenging owners. The NCSC cyber security risk management framework describes risk management as a continuous process, and automation is how a small team keeps it continuous.

At this scale, a quarterly pass becomes a review of exceptions. When an enterprise customer's questionnaire asks how recently the register was reviewed, the answer is an export rather than a scramble. A fractional CISO can chair the reviews and hold owners to defensible scores, while GRC engineering builds the workflows.

Frequently asked questions