What Clause 8.2 Requires
Clause 8.2 carries two obligations, both operative rather than design-level. First, the organization must perform information security risk assessments at planned intervals — and additionally whenever significant changes are proposed or occur. Second, every assessment must take account of the criteria the organization established under Clause 6.1.2: the risk acceptance criteria and the criteria for performing assessments. Consistency is the point — each round uses the same scales and the same thresholds, so results are comparable across time and acceptance decisions remain defensible.
The clause closes with a records duty: the organization must retain documented information of the results of each assessment. Note the trigger wording — changes that are proposed, not only changes that have happened. The standard expects assessment before a significant change lands wherever that is possible, not a retrospective scoring exercise after the migration, the acquisition, or the product launch has already shipped its risk.
Why This Clause Exists
To keep the ISMS's picture of risk current — risk assessment as a recurring operational rhythm with defined triggers, not a one-time implementation artifact that quietly ages.
What This Really Means
Clause 6.1.2 builds the camera; Clause 8.2 makes you actually take the pictures — on a schedule, and whenever the scene changes. A risk assessment is a snapshot, and snapshots age: the threats move, the architecture moves, the law moves, the company moves. 8.2 exists because the natural fate of a risk register is to become an archaeological record of what the organization feared during its implementation project. In the standard's operating loop, this is the second station: Clause 6.1 designs the risk machinery, 8.2 keeps the risk picture current, 8.3 executes the treatments that picture demands, and 9.1 measures whether they worked.
In practice the clause means two operating rules. The planned interval: annual is the accepted norm, with faster cycles — semi-annual or quarterly, sometimes scoped to critical assets — for high-change environments. And the trigger list: events that force an off-cycle assessment, such as a new product or major feature, a cloud or architecture migration, a merger or acquisition, a major incident, a new law or significant contract, or a change of key supplier. The word proposed matters: for changes you can see coming, the assessment belongs before the go-live decision, where it can still shape it.
Consistency with the 6.1.2 criteria is the quiet requirement most organizations miss. If round one scored likelihood on a five-point scale and round two switches to percentages, or the acceptance threshold drifts from meeting to meeting, you can no longer compare rounds, demonstrate a trend, or defend why a risk was accepted. Method changes are allowed — the methodology is yours — but they are versioned events, declared in the results, never silent drift.
Retaining results means more than keeping the current register. Auditors want the history: a dated, versioned register snapshot or assessment report for each round, showing scope, participants, method version, scores, movements since last time, and the decisions taken. The heart of 8.2 for an auditor is recency and trigger discipline — when reality changed, did the assessment follow? They will find your changes in other evidence (the incident log, the SoA conversation, a new office on your own website) and check whether the register noticed.
Why It Matters
Risk assessment is the engine that justifies everything else in the ISMS — control selection, the SoA, treatment priorities, acceptance decisions. When assessment stops recurring, that chain of justification detaches from reality: the organization operates controls chosen for the risks it had two years ago, while the risks it has now sit unscored and untreated. Clause 8.2 is the standard's mechanism for keeping the engine running after the implementation project ends.
The certification stakes are concrete. At Stage 1, auditors expect a completed assessment consistent with your documented methodology. At Stage 2 and at every surveillance audit after, they expect the rhythm: assessments at the planned interval, off-cycle assessments where significant changes occurred, results retained for each round. A register last touched fourteen months ago, with a cloud migration and two product launches in between, is one of the most reliably issued findings in the scheme.
Where the assessment rhythm breaks down, organizations face:
- •A stale risk picture – treatment priorities and SoA justifications rest on risks that no longer exist, while live risks stay invisible to management
- •Change blindness – products launch, platforms migrate, and companies merge unassessed; the risk assessment finally happens inside the post-incident review
- •Incomparable rounds – method drift between assessments destroys trend evidence and makes past acceptance decisions impossible to defend
- •The standing surveillance finding – an assessment older than the planned interval, or a significant change with no assessment trace, is classic nonconformity material at every surveillance visit
- •A wasted Clause 6 investment – a methodology that is never re-executed converts the entire planning effort into shelf-ware
Regional Compliance Context
Regulatory change is a textbook 8.2 trigger, and the calendar is busy. In India, the DPDP Act's full compliance obligations land on 13 May 2027, with the DPDP Rules notified in 2025 — an off-cycle risk assessment scoped to personal-data processing ahead of that date is exactly the discipline this clause expects, and it feeds the treatment work while there is still runway. A CERT-In-reportable incident is a double trigger: first the 6-hour report, then reassessment of whatever the incident revealed about the environment.
For organizations entering or operating in the Gulf, Saudi PDPL and the UAE federal PDPL changed the risk profile of personal data in those markets. Treat market entry, new regional data flows, or a first regulated customer there as significant changes that warrant a scoped assessment round.
Documented Information Required
Risk assessment results
MandatoryA dated, versioned output for every assessment round — updated risk register entries scored against your 6.1.2 criteria, plus a short report capturing scope, participants, method version, and key movements. Good looks like being able to produce the last three rounds and show what changed between them.
Assessment schedule and significant-change trigger list
RecommendedThe planned interval on a compliance calendar plus a concrete list of events that force an off-cycle assessment. It usually lives inside the risk assessment methodology, and it makes the trigger duty testable instead of aspirational.
Versioned risk register
RecommendedThe living register with snapshot history — a dated export or tagged version per round. Tooling is irrelevant; a spreadsheet with disciplined versioning beats a GRC platform nobody updates.
Change-triggered assessment records
RecommendedScoped mini-assessments attached to projects, migrations, incidents, or new laws — the evidence that the trigger mechanism actually fires between planned rounds.
See the full ISO 27001 mandatory documents checklist for every document and record the standard requires.
How to Implement Clause 8.2
Set the planned interval and put it on the calendar
Annual is the norm certification auditors recognize; high-change organizations often run semi-annual or quarterly cycles for critical scope. Assign a named owner, book the round in the compliance calendar, and treat it like the financial close — a recurring obligation with a date, not an intention.
Define what "significant change" means for you
Write a concrete trigger list into the risk methodology: new product or market, major architecture or cloud change, merger or acquisition, major incident, new law or material contract obligation, change of critical supplier. Add a default rule for ambiguity — when in doubt, run a 30-minute screening assessment and record the conclusion, even when it is "no material change".
Run every round against the same 6.1.2 criteria
Use the established likelihood and impact scales, the same acceptance thresholds, and the documented method each time. When the method genuinely must change, version it, map or re-baseline existing scores, and declare the comparability break in that round's report — silent method drift is what auditors read as an unreliable register.
Refresh the inputs before scoring
Re-validate the asset inventory, the context analysis from Clause 4.1, and interested-party requirements before the workshop, so the round assesses the organization that exists now. Retire risks that no longer apply — with a recorded rationale — instead of letting the register accrete forever.
Score, decide, and route the outputs
Assess and prioritize against the criteria, then route the results: risks above acceptance thresholds flow into risk treatment (Clauses 6.1.3 and 8.3); risks accepted get a named approver and a recorded decision. An assessment round that produces no decisions is a ceremony, not an assessment.
Snapshot the results
Version the register at the close of each round — a dated export, a tagged version, a numbered report. Capture scope, participants, method version, date, key movements since the previous round, and the decisions taken. This snapshot discipline is the entire difference between "we assess risk continuously" (unprovable) and retained results (provable).
Wire the triggers into business processes
Add the question — does this need a risk assessment? — to project intake, change management, procurement, and incident post-mortems. Off-cycle assessments only happen when the processes where change originates prompt them; a trigger list that lives solely in the methodology document fires never.
Audit Evidence
During Stage 1 and Stage 2 of your ISO 27001 certification audit, auditors will expect the following evidence to demonstrate conformity with Clause 8.2:
Documentation
- Risk assessment methodology showing the planned interval and the significant-change trigger list
- Dated risk register snapshots or assessment reports for successive rounds, scored against the documented criteria
- Change-triggered assessment records tied to specific projects, migrations, incidents, or regulatory changes
- Records of risk acceptance decisions with named approvers, consistent with the acceptance criteria
- Evidence that inputs were refreshed per round — updated asset inventory extracts, context review notes
Interviews
- The risk owner or CISO on how rounds are run, how the criteria are applied, and how triggers are monitored
- Product, engineering, or PMO leads on whether recent major changes prompted assessments before go-live
- Top management or the risk committee on their awareness of current top risks and acceptance decisions
Observations
- The register tooling — GRC platform or versioned spreadsheet — inspected for genuine round-over-round history
- One recent significant change (a migration, launch, or acquisition) traced to its assessment record
- A sampled risk re-scored live against the documented scales to test that the criteria are actually used
Practitioner Insights
The pattern I see most is one giant risk spreadsheet, last modified fourteen months ago — usually a week before the previous audit. The fix is not a GRC platform; it is snapshot discipline. Export and date the register at the close of every round, keep the exports, and write a one-page summary of what moved and why. A small company can run an entirely respectable 8.2 operation in a spreadsheet. What it cannot survive is having no history, because retained results are the literal requirement of the clause.
Auditors do not take your word for what changed — we triangulate. The new SaaS platform mentioned in the SoA discussion, the incident in your log, the office opening announced on your own website: each one gets checked against the register for a corresponding assessment trace. If reality moved and the register did not, that is the finding, and it writes itself. Make trigger review a standing management-review input — a quarterly question of what changed and whether the register noticed — so the gap closes internally before anyone external finds it.
Common Challenges & Solutions
Challenge
The risk assessment was done once during ISMS implementation and has never been repeated.
Solution
Convert it from a project task into an operating rhythm: a named owner, a booked annual round on the compliance calendar, and assessment results as a mandatory management-review input. The first re-run is the hardest — scope it tightly to re-validating the existing register plus changes since, rather than restarting from a blank page.
Challenge
Nobody defined "significant change", so no change ever triggers a reassessment.
Solution
Adopt a concrete trigger list with examples — product launches, migrations, M&A, major incidents, new laws, supplier changes — and a default: when in doubt, a 30-minute screening assessment with a recorded conclusion. Even a documented "no material change to the risk picture" is evidence the mechanism works; silence is not.
Challenge
The methodology drifts between rounds — different scales, different thresholds — making results incomparable.
Solution
Treat the methodology as a versioned document. When scales genuinely need to change, map old scores across or re-baseline the full register in one declared exercise, and record the comparability break in the round report. The goal is that any two rounds can be honestly compared — or the discontinuity is explicit and explained.
Challenge
The register bloats — hundreds of copied-forward risks nobody owns, obscuring the ones that matter.
Solution
Make retirement a formal step in every round: close risks that no longer apply with a one-line rationale, merge duplicates, and require every open risk to carry a named owner. Auditors probe a sample in depth — fifty current, well-owned risks defend far better than four hundred stale ones.
Challenge
Assessment workshops become rubber-stamping — the same people re-confirm last year's scores from memory.
Solution
Feed each round with external signal so scores move for reasons: the year's incidents, vulnerability scan trends, threat intelligence (A.5.7), internal audit findings, supplier failures. Run shorter, domain-scoped sessions with the people who own those domains instead of one marathon workshop, and ask each session to justify any score that did not change.
