Direction of impact

Run the Risk Map Backwards

Impact is not a score on a row. It is directional — and the question that matters is not what you would break, but what could break you.

Most dependency mapping is written from the source outward. Here is the system, here is what could go wrong with it, here is what the organisation would lose. Shock a node and watch the damage cascade to everything downstream. It is a useful picture, and it answers a real question: if this fails, what do I take down with me?

The wrong person's question

The trouble is it answers it for the wrong person. The people who most need this analysis rarely own the thing that fails first. They own the service three steps downstream — the one that goes dark for reasons that have nothing to do with anything they control. They will leave others to work out what their system damages. What they need to know is what could hurt them, and how hard it would land when it arrived.

The answer was already in the model

You do not start your morning by simulating a failure in network infrastructure on the off chance it reaches you. You start from your own front door: what is upstream of me, and which of those things, if they failed, would actually hurt? Risk relationships carry direction. “A depends on B” is drawn one way, but if B fails the consequence travels back to A. So when a failure starts upstream it is already flowing into everything that depends on it — your service included — with no special handling. The impact that lands on you was being calculated all along. Running the map backwards is a question of where you stand when you ask, not of new machinery.

It reorders your priorities

Point at your own service and the model returns every upstream origin that can reach you, ranked by how much of its impact would actually arrive. That ranking rarely matches your reporting line. The system that delivers the largest share of its failure onto you is your real dependency, whether or not it sits anywhere near you on the org chart. Distance on the map does not protect you.

So what?

A source-centric view and a target-centric view answer two different operational needs, and most organisations only ever see the first. The source view belongs to whoever models the enterprise — it finds the systemic weak points. The target view belongs to whoever is accountable for one service, and it tells them where their genuine exposure comes from, which is almost never the thing they spend their time watching. You know what your own system depends on. The harder question is what, somewhere upstream, you depend on without knowing it.

See it on your own risks.

Risk Portal turns these ideas into something you can interrogate — the dependencies, the failure points, and how disruption travels.