Seeing the cracks¶

Seeing the cracks sets out to make risk visible in practical, human terms and to put it in front of the people who own the work. It reads risk from what can be observed, a process as it actually runs, a dependency as it actually holds, and surfaces weak points while there is still time to act.

What gets looked at¶

Three questions run through a session, in order.

The first is what is at stake: the systems, processes and relationships the organisation depends on, the interdependencies that usually go unrecorded (a key person, a single vendor, an undocumented data flow), and the quiet assumptions about what keeps the lights on.

The second is what happens when one of those is pulled. A realistic event gets walked through, a ransomware outbreak, a supplier failing mid-project, two of four named responders on leave at once, and the consequences traced as they cascade across departments.

The third is what to do about it: which single points of failure are worth removing, which exposures the organisation can live with, and where redundancy or monitoring would repay the effort.

Where the evidence comes from¶

A walkthrough usually carries its own evidence. When a team works a ransomware scenario and finds that the offsite backup is three days behind, or that the two people who understand the failover are both on leave, the discovery is behavioural: it shows that an assumption encoded in the continuity plan has drifted from the current environment. A finding of that kind records what the organisation did when the scenario ran, which is the material a resilience map is built from.

The distinction shapes what happens next. When a gap surfaced in one round returns in the next after a corrective action, the action may have reached only the surface condition, and the underlying assumption held its ground. The question worth asking is what the organisation believed about the process that made the gap seem impossible. That belief is what a durable fix corrects, at the level of the system model.

A mid-sized insurer ran the same supplier-failure walkthrough two quarters running. The first surfaced that moving claims to the backup processor took eleven hours against a contracted two, and the fix was a written runbook. The second run, runbook in hand, still took nine: the runbook assumed a data export the backup processor had quietly retired. The runbook was faithful to a format that no longer existed, and the belief about that format was the thing to correct.

What is left behind¶

The output is a resilience map the team keeps: the risks, the dependencies, the mitigations and their owners, in a form that invites the next walkthrough. Read once, it is a snapshot. Re-run on a cadence, it can trace whether the cracks are widening or closing, the same reading the loop produces when offence and defence work a move together.

Last updated: 2 July 2026