What Belongs in a Risk Register
A risk register records things that have not happened yet. Each entry names six things: the event, what would cause it, what it would cost, how likely it is, who owns it, and what is being done. The moment an entry has already occurred it stops being a risk and becomes an issue, tracked somewhere else.
That boundary is where most registers decay. Issues get logged as risks because the register is the document that gets reviewed, the list grows, and within two months nobody reads it because it has become a mixed record of worries and facts. What belongs in the file rather than the frames is anything commercially sensitive: named suppliers, contract penalties, and internal cost exposures should stay in the project file rather than in a module used across teams.
The register is laid out over seven scenes: one on the distinction between a risk and an issue, two on writing an entry that is specific enough to act on, one on likelihood and impact and why the scoring matters less than the conversation, one on ownership and why an unowned risk is decoration, one on response types, and one on the review cadence that keeps it alive.
