From Surprise Outage To Governed Risk Practice

A SaaS rollout goes live Friday night. By Saturday morning, customers cannot log in, the support queue spikes, and the vendor status page says partial outage. The sponsor asks why risk management did not catch this.

Before you update a risk register, you have to answer a harder question. Was there a real risk signal you could have acted on, or are you turning hindsight into blame. This lesson builds a governance-ready way to separate knowable signals from true surprises, classify what you find, and decide where AI helps without letting AI become the decision maker.

To start, look at the incident as a timeline, not a conclusion. Decide what information existed at the time, who had it, and what a reasonable project manager could have done with it.

A common mistake is to label every bad outcome as predictable. It feels accountable, but it drives teams to over-document low-value risks and ignore the few signals that matter.

Classifying what you are looking at

During the outage, four different types of statements tend to get mixed together, and AI outputs will mix them too unless you enforce rules.

A risk is an uncertain future event that, if it happens, affects objectives. Example. Vendor authentication service rate limits under peak load during launch weekend.

An issue is a current problem that already happened. Example. Users are receiving 500 errors on login now.

An assumption is something you are treating as true for planning, but it might be false. Example. The vendor will maintain current capacity levels through the quarter.

A dependency is an external deliverable or condition your project needs. Example. Vendor completes the planned maintenance window before your cutover.

Prediction question. Which misclassification creates the worst escalation delay during an outage.

Now practice enforcing the labels, since your governance process depends on consistent classification before prioritization.

The wrong instinct is to file everything as a risk because it keeps options open. The consequence is that real issues do not get owned and resolved, and assumptions never get validated.

What governance expects in artifacts

If your risk practice must survive audit, you cannot rely on an informal list in a chat thread. You need artifacts that show consistent thinking and decision history.

A risk taxonomy is a structured set of categories used to group risks so reporting stays consistent across projects. It reduces the problem where one PM writes vendor risk and another writes third-party reliability and no one can roll up trends.

A risk register is the controlled list of identified risks and their management data. Governance usually expects specific fields such as Risk ID, Risk Statement, Cause, Event, Impact, Probability, Impact Score, Exposure, Risk Owner, Response Strategy, Response Actions, Target Date, Status, Triggers, and Last Reviewed. The audit trail comes from showing what changed, when, and who approved it.

Prediction question. Which missing register field makes it hardest to prove you managed the risk and not just recorded it.

Compare what an informal list cannot prove versus what a governed register can.