Topic 16 · Deep Dive

16.5 Reviewing Risks After Incidents or Changes

An Incident Is a Free Risk Assessment

Every real incident proves that at least one register assumption was wrong: the likelihood was higher than scored, an unlisted asset was in the blast radius, or a control you counted on failed silently. The post-mortem therefore feeds straight back into the register. Re-score every row touched by the event using what actually happened -- real dwell time, real cleanup cost, real outage length -- instead of the estimates that scored it before. Add brand-new rows for threat paths the incident revealed, such as "shared admin password reaches the backup server", which rarely appears on a list written from imagination.

What Else Re-Opens a Risk

You do not have to wait for damage. Planned changes re-score risks too: a cloud migration moves trust boundaries, a new SaaS vendor introduces a dependency you do not control, a disclosed CVE changes vulnerability severity overnight, and a layoff or role change changes who can do what. The quiet danger is architecture drift -- the undocumented firewall tweak, the trial tool still running six months later, the second database someone stood up without telling the register. Drift means the world moved and the scores did not, so pair a fixed review cadence, say quarterly, with event-driven reviews triggered by incidents, deployments, and vendor changes.

Closing the Loop

Concretely, an update pass means: revise likelihood and impact on affected rows, change statuses as treatments land, attach new evidence, set the next-review date on every accepted risk because acceptances decay while exposures persist, and record the post-mortem's action items as rows with owners. The register is not an audit artifact; it is the live model your next decision -- buy, accept, avoid, insure -- will be made against.

Architecture Diagram

incident post-mortem register update re-score architecture drift re-opens old rows
Incidents and drift flow through the post-mortem into the register, whose re-scores set up the next incident's true baseline.

Key Takeaways

« Back to Topic 16« 16.4