Scenario Libraries and Maintenance

A scenario library is a collection of scenarios kept for reuse, together with the notes, injects and lessons that make each scenario usable again. A library is useful only if it is maintained. Services change, suppliers change, and threats change, so a scenario that was severe and plausible when written can become misleading if it is reused without review. Maintenance means linking each scenario to the services it tests, recording when it was last used and what it taught, revising it when the service changes, and retiring it when it no longer fits. Without that discipline, a library becomes an archive of old stories that rehearse a service that no longer exists.

A library should be organised so that a scenario can be found by service, by cause, and by the decision it is meant to test. A scenario about supplier failure for a payments service should be findable by someone preparing a payments exercise, without relying on memory or on the person who wrote it. Each entry should state the service, the tolerance at stake, the scenario narrative, the facilitator notes, and the lessons from previous use. That structure helps a new facilitator run a scenario well, and it helps reviewers see which services have been tested recently and which have not. A library that is organised only by date or by author will be hard to use, however good its individual scenarios may be.

Scenarios should be linked to the services they test, so that a change to a service triggers a review of its scenarios. If a service gains a new supplier, changes a channel, or alters its tolerance, the scenarios that assume the old arrangement need revision. That link can be maintained simply, through a record that lists, for each service, the scenarios that test it and the date each was last reviewed. The link also works in the other direction: when a scenario reveals a weakness in a service, the lesson should be recorded against that service, so that the next review of the service considers it. Without those links, scenario maintenance becomes a separate activity that drifts away from the services it is meant to protect.

A scenario should be retired when its causes are no longer credible, when its service has changed so much that the story no longer fits, or when it has been used so often that participants know its twists and stop deciding. Retirement does not mean deletion without trace. The retired scenario should be marked as retired, with a note explaining why, so that it is not reused by mistake and so that its lessons remain available. Some retired scenarios can be useful as source material for a new scenario, provided the new version is written for the current service rather than lightly edited. A library that never retires anything will grow until its useful scenarios are buried among outdated ones, and facilitators will stop trusting it.

Reviews should be triggered by change, not only by a calendar. Useful triggers include a material change to a service, a new supplier, a significant incident or near miss, new guidance from a regulator or a body such as ENISA, and lessons from an exercise that showed a scenario to be too easy or too contrived. A periodic review still has value as a safety net, catching scenarios that have quietly aged without any single triggering event. The review itself should be practical: does the scenario still breach tolerance, are its causes still plausible, are its assumptions still sound, and does it still force the decisions it was designed to force? A scenario that fails any of those tests should be revised or retired.

Library quality is judged by use, not by size. A small library of current, well documented scenarios that are regularly used and regularly revised is more valuable than a large library of outdated stories. Quality can be seen in coverage: whether each important service has scenarios that test its most harmful disruptions, rather than only its most convenient ones. It can also be seen in the lessons attached to each scenario, which show that the scenario has taught something and that the teaching was acted on. A library that is reviewed, retired and refreshed in that way supports the whole cluster, because every exercise that follows will start from a story that fits the service as it is now, not as it was when the story was first written.