8.2 — Information security risk assessment

A risk assessment done once, at certification, and never again is not a risk assessment—it is a snapshot of a moment that no longer exists.

Mandatory requirement · Documented information required: yes

In plain language

8.2 requires you to actually perform your risk assessment again—at planned intervals, or whenever a significant change is proposed or happens—using the criteria you established under clause 6.1.2, and to keep the results as evidence each time.

Why this requirement exists

Risk is not static. New systems get adopted, staff turn over, threat actors change tactics, and business priorities shift—a risk assessment from certification day describes an organization that, eighteen months later, may no longer exist in the same form. This requirement forces the assessment to keep pace with reality instead of becoming a historical artifact.

Scenario: a company certifies with a risk assessment built around an on-premises environment, then migrates most workloads to the cloud over the following year without ever reassessing risk against the new architecture. At the surveillance audit, the risk register still describes infrastructure that no longer exists—a direct 8.2 finding, independent of how good the cloud migration itself was.

What the standard expects

The standard expects the organization to perform information security risk assessments at planned intervals, or when significant changes are proposed or occur, taking account of the criteria established under 6.1.2 a). The organization must retain documented information of the results of each information security risk assessment.

In practice

• Fix a planned interval (annually is common) for a full risk assessment refresh, independent of any changes.
• Define what counts as a "significant change" for your organization (new system, new office, major reorg, new regulatory obligation) so the trigger is not left to judgment in the moment.
• Reuse the exact criteria and scales from your 6.1.2 methodology each time, so results stay comparable year over year.

Evidence the auditor will ask for

• A history of risk assessment results showing they were performed on the planned schedule.
• Evidence that significant changes (system migrations, new offices, major reorgs) triggered an out-of-cycle reassessment.

Common pitfalls

• A single risk assessment performed at certification, never repeated by the first surveillance audit.
• A major infrastructure or organizational change that never triggered a fresh risk assessment.

Related requirements

• 6.1.2 Risk assessment (methodology)—sets the criteria and method that 8.2 requires you to actually re-apply.
• 8.3 Risk treatment (operational)—the next step: acting on what each reassessment finds.
• 8.1 Operational planning and control—significant unplanned changes controlled here are one of the triggers for reassessment.
• Parent clause: Clause 8 Operation.