# EM-RSK-04 — Business Continuity, Backup and Recovery

## Verdict

Reuse and complete WM-ACT-043 as the continuity-capability aggregate for four of five candidates. **BusinessImpactAnalysis**, **ContinuityPlan**, **RestoreTest** (in its continuity-exercise form) and **RecoveryEvidence** are aggregate-owned releases, events and observations — not independent models. **BackupPolicy is the one candidate that needs a new model identity**: a data-protection policy plus restore-verification element, mastered by the data-protection/platform owner, not by the continuity capability. No identifier is allocated; a registry reservation and boundary review are required first. Boundary decision: **reuse + extend WM-ACT-043, one new reservation.**

## Evidence

WM-ACT-043 v0.3.0-research.1 (spec sha256 87f09001…, synthesis 8d9fc51a…) declares `entry_kind: aggregate`, ten functions, six bundles, twelve layers, twenty-four findings. Backup appears only three times: as a strategy solution option, as a readiness item, and as `backup integrity` inside one recovery finding. There is no policy object with schedule, copies, retention, immutability, encryption, key custody or job execution. Coverage marks **composition** and **interoperability** as `gap`; the WM-ACT-008 parent and WM-ACT-042 reference are unapproved; publication is `canonical_publishable: false`, single-provider, external review absent. Evidence depth for the contour is index-and-publication metadata; no clause-level source conformance exists.

## Identity/mastership

Four levels must not collapse: **impact tolerance** (business analytic assertion), **objective** (approved engineering target), **commitment** (contractual, external contract master, cf. WM-ECO-006), **outcome** (observed). WM-ACT-043 owns capability lineage, BIA releases, strategy releases, plan releases, readiness assertions, exercise records, activation events, continuity-mode observations, recovery verification, reconstitution and closure. External masters retain identity: service/activity, system, dataset, person/role, facility, asset, supplier, contract, incident, risk. Dependency edges belong to the landscape/dependency masters (WM-XCT-037, projected via WM-XCT-039), not to this aggregate. Raw observations belong to the observation master (WM-MAT-008). Minimum acceptable service level should bind an SLO version (WM-SFT-016), not be restated here. The frozen `standalone-mm` record-plane value and the document's `aggregate` entry kind describe different planes; record both, reconcile neither silently.

## BIA and objectives

BIA release identity = capability + scope profile + method version + approval. It asserts criticality, impact category, severity-over-time and **maximum tolerable disruption**, with justification and approver. RTO/RPO/capacity objectives are *derived* in the strategy release and are separate assertions: each must name subject and scope qualifier (sites, tenants, functions), the degraded level it applies to, the pinned BIA release, the verification method, and a feasibility statement. Required consistency rule, currently missing: **RTO ≤ MTPD with declared margin**, RPO ≤ tolerable data loss; a violation is an explicit exception with residual-risk acceptance, never an implicit overwrite. An objective without scope and verification method is inadmissible.

## Plans and policies

ContinuityPlan is an immutable release: applicability, triggers and thresholds, activation authority, procedures, roles, contacts, dependency references, deactivation criteria. Corrections create successors. Generic release/scheduling scaffolding is a candidate inheritance from WM-ACT-008 — until that edge is approved, WM-ACT-043 restates plan-release semantics, which risks the dual-root defect found in EM-RSK-02 (WM-ACT-033 / WM-ECO-035). Resolve inheritance-versus-reference before publication.

BackupPolicy is not a continuity artifact. It has independent identity and lifecycle: authored by data-protection governance, versioned on its own cadence, scoped to systems and datasets that may have no continuity plan, and executed by platform schedulers. Its facts are: protection scope, schedule, copy count and placement, retention, immutability/air-gap, encryption and key custody, verification cadence, and exception register. Continuity strategy **references** a policy version; it does not own it.

## Backup versus restore

Three distinct things, three owners: (1) **policy** — the intended protection rule; (2) **backup execution** — job records and resulting recovery points, mastered by the backup system as observations; (3) **restore verification** — a test that a named recovery point yields a working object or chain against stated criteria. A green job asserts only that an artifact was written and passed a write-time integrity check. It does not assert restorability, chain order, elapsed restoration time or data currency. Restore verification must pin policy version, recovery-point identifier and digest, target environment, tool versions, synthetic dataset identifier and version, criteria version and observation method. Restore into production is an activation, not a test; test targets must be isolated to prevent overwrite or split-brain. Synthetic fixtures declare representativeness and what they cannot exercise (production volume, real key rotation, live supplier interfaces); a synthetic pass never claims production-scale RTO.

## Exercises and real events

Exercise design, conduct and evaluation (ISO 22398-style) stay in WM-ACT-043 and reference restore verifications as inputs without restating their results. An exercise is bounded observation under declared assumptions, injects and safety controls; it is not proof of real-event capability. Real activation is a separate event chain: trigger reference, authority, decision, scope, continuity-mode observations, restoration, recovery verification, reconstitution, closure. Restoration ≠ return to normal; incident closure ≠ recovery completion; readiness assertion ≠ observed outcome. Gaps flow to corrective actions in the work master (WM-ACT-006) and remain open until independent re-verification, not on task completion.

## Dependencies and ordering

Inventory is membership; **order is a separate derived artifact**. A recovery sequence names steps, predecessor constraints, parallelism, per-step objectives, prerequisite-satisfaction criteria and a stated basis (which dependency edges, at which as-of time, with which completeness declaration). Bootstrap dependencies — identity, DNS, network, KMS/secret recovery — must be explicit first-order steps; encrypted backups are unrecoverable without key recovery, and WM-ACT-043 currently treats credentials only as an access-control concern. Cycles require a declared break point and a manual fallback. Without a covering completeness declaration the order is incomplete, and no "recoverable" claim is admissible.

## Evidence and time

Every artifact stores digest, media type, capability and release binding, source versions, actor, event and knowledge times, access marking, provenance. Released analyses, strategies, plans, exercises and evidence are append-only. Distinct clocks: objective, job start/end, **recovery-point time**, disruption, activation, restore start/complete, verification, service acceptance, normal-operation declaration, observation, ingestion. RPO is measured from disruption time to recovery-point time — never from job time. RTO is measured to verified service acceptance — never to restore completion. Outcome vocabulary, currently absent, must enumerate: verified, verified-with-limitations, failed, blocked-by-dependency, indeterminate-insufficient-observation, not-attempted. A chain verdict is the floor over required members plus ordering satisfaction. Continuity plans, alternate locations, contacts, supplier weaknesses and credentials remain default-deny; exceptions are purpose-bound, time-limited, scoped and logged.

## Acceptance scenario

Synthetic chain: service S requires identity A, database D and external signing supplier X. D's backup jobs are green for thirty days. Restore of D at recovery point t−12h into an isolated environment with synthetic fixtures passes object-level verification. A restores. X is unavailable. Result: D `verified` (object scope only); chain `blocked-by-dependency`; RTO **not attained** — the clock runs past the target because minimum service level was never reached; RPO **breached** — measured loss 12h against a 1h objective, a fact of the recovery point, not the job. Closure is refused: S remains in continuity mode, X's absence becomes a single-point finding and corrective action. The green job hides nothing.

## Invariants

1. Tolerance, objective, commitment and outcome are four separate assertions. 2. Every objective names scope, degraded level, pinned releases and verification method. 3. RTO ≤ MTPD or an explicit accepted exception exists. 4. Policy, backup execution and restore verification have distinct identities and owners. 5. Job success never asserts restorability, RTO or RPO. 6. RPO derives from recovery-point time; RTO from verified service acceptance. 7. Recovery order is a separate artifact with a completeness declaration. 8. Key and identity recovery are first-order ordered steps. 9. Synthetic-data passes carry declared scope limits; production restore is activation. 10. Exercise ≠ real activation; restoration ≠ reconstitution; closure ≠ recovery. 11. Partial and blocked outcomes are first-class; no required member may be silently dropped. 12. Releases and evidence are immutable; corrections create successors. 13. Referenced masters never cascade ownership. 14. No autonomous activation, disclosure, risk acceptance or disposal.

## Minimal model set

WM-ACT-043 (reuse; add objectives-versus-tolerance rule, recovery-sequence artifact, outcome vocabulary, test-isolation and synthetic-data rules, key-recovery dependency) + one identifier-unassigned **Data Protection Policy and Restore Verification** reservation + references to service/activity, system, dataset, supplier, contract, incident, dependency (WM-XCT-037/039), observation (WM-MAT-008), SLO (WM-SFT-016), audit (WM-ACT-033) and corrective-action (WM-ACT-006) masters. If the registry prefers finer granularity, restore verification splits from policy; it must not split into two roots inside WM-ACT-043.

## Holds

Gaps and contradictions found: no backup-policy object; no ordering artifact; no RTO/MTPD consistency rule; no verdict vocabulary; no synthetic-data or restore-isolation rules; key recovery missing from dependencies. Contradictions: publication holds record 120-second Claude/Grok timeouts while the provider policy cites 1800/900/600/300-second failures, and "explicitly waived" conflicts with "timed out" as the stated reason for absent review; `status: published` with two `gap` coverage dimensions and unapproved edges; `possible_duplicate_of` empty despite declared overlap with incident response, crisis, disaster recovery and emergency management. WM-ACT-008 and WM-ACT-042 edges unapproved. ISO evidence is abstracts and previews only. No standards conformance, canonical completeness, installability or publication readiness is claimed; no identifier is allocated.