Ask a room of responsible entities what their risk management program covers and most will describe a cyber security program. Firewalls, patching, access control, maybe an incident response plan. All good things. All roughly a fifth of the obligation.
The phrase “all hazards” is doing a lot of work in the critical infrastructure regime, and it is the single most under-read requirement I encounter. Entities that scope their program around cyber alone are not partially compliant. They have built a program that does not address four of the five hazard categories they are responsible for.
The five vectors
An all-hazards program has to consider the ways an asset can be disrupted, not just the ways it can be hacked. In practice that means five distinct categories, each with its own failure modes and its own controls.
Cyber and information security. The one everyone starts with. Malware, credential compromise, exploitation of internet-facing services, attacks against the control and management plane of operational systems. This is the category where most entities already have capability, and it is usually the only category where they have evidence.
Personnel. The risk that the people who operate the asset are themselves the hazard, whether through malice, coercion, error, or simple absence. Screening on hire is the obvious control. The one that gets missed is key person dependency: if two engineers hold all the operational knowledge for a system and both are unavailable, the asset is exposed regardless of how good the firewall is.
Physical security. Perimeter, access control, tamper detection, and the physical protection of the equipment that runs the process. In operational technology environments this matters more than in enterprise IT, because physical access to a controller frequently means total control of the process.
Natural hazards. Flood, fire, storm, extreme heat, earthquake. This is the category most often waved through with a reference to an existing business continuity plan. The question a program has to answer is narrower: which natural hazards can disrupt this asset, and what happens to the process when they do?
Supply chain. Vendors, contractors, service providers, and the hardware and software they supply. For infrastructure operators the sharpest version of this is the maintenance contractor with remote access to a control system, or the single supplier of a component with a twelve-month lead time.
Why entities read it narrowly
Three reasons, in my experience, and none of them are laziness.
The first is that the cyber category is where the language of the regime is loudest. Frameworks, maturity models, and audit questions are disproportionately about cyber, so that is where attention goes.
The second is organisational. Physical security sits with facilities. Personnel sits with HR. Natural hazards sit with the business continuity team. Supply chain sits with procurement. Each of those functions may be doing competent work, but nobody owns the question of whether the five together add up to a program for the asset.
The third is that a cyber-only program is easier to write. The other four categories force uncomfortable questions about dependencies the organisation cannot fully control.
What “in practice” actually looks like
The obligation is not to produce a document that names five categories. It is to run a process that identifies material risks in each of them and shows how the entity minimises or eliminates those risks so far as is reasonably practicable.
That distinction is where most programs fall down on review. A program that lists supply chain as a hazard vector and then says “managed through existing procurement policy” has named the category without doing the work. The question is which suppliers, which dependencies, what happens when each fails, and what the entity does about it.
A useful test: for each of the five vectors, can you point to a specific hazard you identified for this asset, the assessment that made it material, the control you applied, and the evidence that the control operates? If the answer for four of the five is a policy reference, the program is not all-hazards yet.
Scoping the program
A few things that make the scoping tractable.
Start from the asset, not the organisation. The obligation attaches to a critical infrastructure asset, and the hazards that matter are the ones that disrupt that asset’s function. An enterprise-wide risk register is a useful input but it is not the program.
Write down the interdependencies. Which other assets does this one rely on, and which rely on it? Cascading dependency is where a manageable local failure becomes a national one, and it cuts across all five vectors.
Treat the categories as a checklist for coverage, not a structure for the document. Real hazards do not respect the boundaries. A contractor with remote access is simultaneously a supply chain hazard, a personnel hazard, and a cyber hazard. Forcing it into one category to keep the document tidy tends to lose two thirds of the risk.
Make review a scheduled activity with an owner. An all-hazards program that was accurate at the time of writing and has not been touched since is a snapshot, not a process. The regime asks for the process.
The uncomfortable part
Scoping honestly across five vectors usually surfaces risks the entity cannot fix quickly, and sometimes risks it cannot fix at all within its own boundary. A sole-source supplier, a single physical site, a workforce with no depth in a critical skill.
That is not a reason to scope narrowly. A program that documents an unresolved material risk, with a rationale and a plan, is in better shape than one that never looked. The gap between what you know and what you have written down is the part that actually creates exposure.
Working out whether your risk management program covers what it needs to? Get in touch — we run all-hazards scoping reviews for critical infrastructure operators.