The continuity plan

Assembled from what already exists

The plan is generated, not drafted. Scope, recovery requirements, bottlenecks, dependencies, strategies, and the restoration sequence come from the BIA, the processes, the assets, and the strategies already registered. What you write are the roles and the free-form context.

The gain is not saved typing: it is that the plan cannot diverge from reality without reality having changed first.

Deterministic generation

Generating twice over the same data produces exactly the same document. That took explicit care — a generated-at field, for instance, would change the content on every run and make it impossible to tell "the plan changed" from "the plan was generated again".

With determinism guaranteed, comparing two versions answers a useful question: what actually changed in the organization between one generation and the next.

Drift

Once published, the plan keeps being compared against live data. When an object's RTO changes, when a process gains a new dependency, when a strategy is removed, that surfaces as drift — the published plan has stopped describing the organization.

Each drift finding can become an action plan item in one click, and the same finding clicked twice does not produce two items: the item's identifier is derived from the finding's content rather than drawn at random on each read.

Publishing sends the plan to the document repository

A published plan becomes a record in the organization's document repository, because that is where the things an auditor asks for live — and ISO 22301 asks for exactly this one. A plan that exists only inside the continuity screen is a document the company cannot produce when someone requests it.

Publishing to the repository does not expose the plan on the Trust Center. Making a document public is a separate, deliberate act, and nothing in this flow performs it for you — which is a safety line, not a limitation.