Building a Defensible Risk Register

A risk register that cannot survive being questioned by an auditor, a board member, or an insurer is not actually doing its job. Defensibility comes from structure, evidence, and traceability -- not from the length of the spreadsheet. Every entry in a defensible register should be traceable back to something real: a specific asset or system, a specific threat scenario, and a specific set of existing controls. Vague entries like "cyber attack on the network" are not risks -- they are categories. A real entry looks more like: "Unauthorized remote access to the RTU network via a vendor VPN with no MFA, leading to manipulation of breaker control commands." That level of specificity is what lets you actually score likelihood and impact meaningfully, and it is what lets an auditor verify your reasoning instead of just trusting your color-coded heat map. A defensible register also separates inherent risk (before controls) from residual risk (after controls), and records the evidence for why a control is believed to be effective -- not just that it exists on paper. A firewall rule that has never been tested is not the same thing as a validated segmentation boundary, and your register should be honest about that difference. Finally, every risk needs an owner who is a named person, not a department. "IT" does not own a risk. A named engineering manager, plant operations lead, or CISO owns it, and that person is accountable for the treatment decision and its timeline. Registers that assign ownership to departments instead of people are one of the most common reasons risk treatment stalls -- accountability diffuses until nobody actually acts.