A Risk You Can’t Trace to the Work Is a Risk You Named

You have a risk register. It gets reviewed. Someone owns it. And when an auditor asks where a particular risk is actually controlled, the answer takes longer than it should — because the honest answer is that the risk is named in one place and the work happens in another, and nobody has walked the distance between them in a while.

That distance is the subject here. Not whether you have a register. Not whether you’ve identified the right risks. Whether the risks you identified ever became anything.

Risk runs at three altitudes

Contextual risk is what’s coming at the organization. Regulatory change, market movement, a new product whose functionality is different enough that the regulatory scheme applied to it changes. This altitude is scanned rather than measured. It’s owned at the top, reviewed on a slow cadence, and its methods are interpretive — someone reads the environment and forms a judgment. This is the altitude most enterprise risk management programs are built to serve, and the one ISO 31000–style frameworks describe best.

Process risk is what breaks between functions. Handoffs, assumptions, the space where design believes manufacturing has it and manufacturing believes design specified it. This altitude is mapped rather than scanned. It’s owned by whoever owns the process, reviewed when the process changes, and its methods are structural — the work of process design and mapping.

Failure mode risk is what fails at the point of work. The component, the step, the inspection that passes something it shouldn’t. This altitude is enumerated. It’s owned close to execution, reviewed on a fast cadence, and its methods are analytic — ISO 14971 risk management and the FMEA family, which are superb at the failure modes someone has already imagined and structurally silent on the ones nobody has.

Each altitude has its own methods, its own cadence, and its own owner. And each is blind to what the others see. A team doing excellent failure mode work will not see a market shift. A leadership team writing excellent contextual risk will not see the inspection step that quietly stopped being performed.

The common failure is picking one altitude and calling it a risk program.

But the altitudes aren’t the point

The taxonomy is setup. What matters is whether anything travels between the levels.

An enterprise risk that never decomposes into a process control never became anything. It’s a receipt for a decision nobody made. The organization can point to the entry, describe it accurately, and produce no evidence that it changed a single thing anyone does.

That’s the failure worth naming — not the absence of risk identification, but the absence of decomposition.

Where the walk stops

Here is the shape it takes in medical devices, where the decomposition is auditable and therefore visible. The same pattern runs in aerospace and in information security; devices just make it easiest to see, because a medical device quality management system is built to hold the trace on purpose.

A regulatory risk gets identified at the contextual altitude. A device requires conformance to particular technical standards — biocompatibility testing, say. The risk is real and correctly named. It shows up on the register. It may show up in a submission plan. Frequently it makes it into a top-line SOP or a list of standards the device must comply with.

And in a meaningful number of organizations, that is where it stops.

It doesn’t reach the design plan. It doesn’t reach the training materials. It doesn’t reach the work instructions actually deployed to the teams doing design, manufacturing, testing, and inspection. The risk was translated once, into a document that other documents were supposed to inherit from, and the inheritance never happened. A documentation structure is what makes that inheritance possible at all — and when the hierarchy is decorative rather than functional, the trace has nowhere to travel.

Nobody notices, because every artifact at every level looks fine on its own. The register entry is well written. The SOP is current. The work instruction is followed. Nothing is missing — until you ask what connects them.

This is not something you find by reading the register, and it is not something you find by reading the procedure. It surfaces during internal audit, walking the process with the people doing the work — asking what they do and why, and hearing the “why” come back thin.

Why it breaks at the handoffs

The break isn’t usually a missing owner. It’s the relay.

In a conventional hierarchical model, regulatory and contextual requirements live with top management or legal. They get communicated downward — not systematically, just communicated — to middle managers and process leaders. Those leaders then have the job of translating further down to the operator level.

At every stop, something degrades. Usually not the control. The reason for it.

The step survives the relay. The concern behind the step doesn’t. And an operator holding a control without the concern behind it can’t defend it under audit, can’t recognize when conditions have changed enough to make it insufficient, and can’t tell which parts of the job are load-bearing and which are habit.

There are two ways to hold traceability, and it’s an either-or

The first is systematic downflow. The organization takes a process approach to decomposing risk controls into procedures, training, and work instructions comprehensively — so traceability is a property of the system rather than an achievement of a person. This is slower to build and it is the version that survives turnover.

The second is people. Competent quality and regulatory professionals who can take the elevator up and down the spine of the company — engaging leadership at the contextual altitude, process owners in the middle, and technicians on the floor, and carrying the thread themselves.

Where traceability actually holds in larger organizations, it is usually the second one. A quality or regulatory function that transports between layers is one of the more effective structures available, precisely because it doesn’t depend on every handoff surviving intact. If you don’t have the first, you need the second.

But notice what that is

The elevator is a person, not a system.

Organizations leaning on individuals as subject matter experts rather than building the expertise into their systems generally know it. This is not a blind spot. Ask what happens if that person leaves and they’ll tell you plainly there would be a large gap. They can see the dependency. They haven’t resolved it, because building the capability into the system is slower and harder than relying on the person who already has it.

Which is the whole argument turned back on the organization itself. A risk identified accurately, named clearly, and never decomposed into structure.

The direction that doesn’t break

The framework implies traceability should run both ways — down from context to control, and up from control to concern. In practice, only one direction fails.

You rarely find a control at the point of work that traces back to nothing. People are risk-averse and organizations respond to impact, so most controls exist because something happened: a nonconformity, a defect, a customer complaint, a security event. Corrective and preventive action is the machinery that converts a realized risk into a permanent control, and the control arrives with its history attached.

Controls have scars. That is why the upward trace holds.

The unrealized risk is the hard one. The undecomposed risk is the common one. Both of them run downward.

The diagnostic

Take one entry off your enterprise risk register. Not a representative sample — one entry, ideally one that matters.

Walk it down. Where does it appear in the process documentation? Where does it appear in training? Where does it change what a specific person does on a specific Tuesday?

Wherever the walk stops is the altitude your organization actually operates at. Everything above that line is named. Everything below it is uncovered.

Run it on three entries and you’ll know which problem you have. If the walk stops at the same level every time, the decomposition mechanism is missing and that is a structural fix. If it stops in different places, you have a coverage problem instead, and that is a different kind of work. Those two failures look identical on a register and need opposite responses — which is most of why risk management consulting engagements start with the walk rather than with the register.