Risk Governance & Ownership Fundamentals
What cyber risk actually means for a critical infrastructure operator, how to register it defensibly, how to treat it, and how to make sure someone real owns it.
What Cyber Risk Really Means in Critical Infrastructure
Cyber risk in a critical infrastructure operator is not the same thing as cyber risk in a typical IT business, and treating it that way is the single most common mistake GRC teams make. In IT, the dominant concern is usually confidentiality: protecting data from being stolen or exposed. In a substation, a water treatment plant, a rail signaling system, or an airport baggage network, the dominant concern flips. Availability and integrity almost always outrank confidentiality, because the consequence of a successful attack is not a data breach notice -- it is a train that cannot safely stop, a pump that will not shut off, or a control room that loses visibility into what the plant is actually doing. A useful working definition: cyber risk is the combination of a credible threat, an exploitable weakness, and a consequence that matters to the business or to public safety. All three parts have to be present. A theoretical vulnerability with no realistic threat actor and no operational consequence is not a risk worth spending your organization's limited attention on -- it is noise. Good risk programs spend their effort filtering signal from noise, not cataloguing every possible weakness with equal urgency. This is also why risk in OT environments has to be engineered, not guessed. You cannot reason about consequence without understanding the physical process behind the system: what happens if this PLC receives a bad command, what happens if this HMI loses its feed, what happens if this remote access path is abused at 3am on a weekend. Risk assessment that is disconnected from the actual engineering reality of the facility produces a document, not a defensible risk position.
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.
Risk Treatment: Mitigate, Transfer, Accept, Avoid
Identifying a risk is only half the job. Every risk in a mature program eventually needs a treatment decision, and there are really only four honest options: mitigate it, transfer it, accept it, or avoid it. Programs that only ever choose "mitigate" usually end up with a backlog of controls that never gets finished, because not every risk deserves the same level of investment. Mitigation means reducing likelihood or impact through a control -- network segmentation, monitoring, hardened configuration, MFA on remote access, and so on. This is the default instinct for most engineers, but it is not always the right call, especially when the cost of the control exceeds the realistic cost of the risk it is reducing. Transfer means shifting the financial consequence elsewhere, most commonly through cyber insurance or contractual liability with a vendor or integrator. Transfer does not reduce the likelihood of an incident and it rarely helps with safety or availability consequences, which is exactly why it is a poor primary strategy for OT risk and a reasonable secondary strategy for residual financial exposure. Accept means a named, authorized owner formally decides the risk is within tolerance and signs off on leaving it as-is -- ideally with a documented rationale and a review date. Acceptance without a named owner and a documented rationale is not risk management, it is just risk ignoring. Avoid means removing the risk entirely by not doing the thing that creates it -- decommissioning an unnecessary remote access path, retiring an unsupported legacy system, or redesigning a process so the exposure no longer exists. Avoidance is often the cheapest long-term option and the most underused, because it requires operational change rather than a technical purchase.
Assigning Ownership and Reporting Risk to Leadership
A risk program only works if leadership can act on what it is told, and most leadership reporting fails because it reports the wrong altitude of information. Boards and executives do not need a list of CVEs -- they need to know what could stop the business from operating, what it would cost, and what decision is being asked of them. Good executive risk reporting answers four questions clearly: What is the top exposure right now and why. What has changed since the last report. What is the plan and the cost to close the gap. And what decision, if any, is being requested -- budget approval, risk acceptance sign-off, or awareness of an accepted risk that leadership should know about even if no action is needed today. Ownership has to be explicit and personal, not organizational. When a risk is assigned to 'IT Department' instead of a named individual, there is no one whose performance review depends on closing it, and it will sit untreated indefinitely. Each risk owner should know three things about their assignment: what they are accountable for, by when, and who they escalate to if they are blocked. Finally, risk reporting cadence should match risk volatility, not a fixed calendar. A stable, well-controlled environment might reasonably report quarterly. A facility mid-way through a network re-architecture, an active vendor onboarding, or recovering from an incident needs tighter reporting -- because that is exactly when new exposure is most likely to appear and go unnoticed until the next scheduled report.