Resilience

The Resilience module governs your business continuity and operational resilience posture: which services are critical, what they depend on, what impact disruption would have, what continuity and recovery plans exist, what tests have been conducted, and what recovery objectives are committed.

This module is the governance layer for resilience work. It does not perform failover, run backups, or orchestrate disaster recovery. Those are operational. This module captures the records that auditors, regulators, and customers ask to see when they want evidence that the organization has thought through what happens when things go wrong.

When you would reach for this

You set up resilience when:

A regulator or framework requires documented business continuity, disaster recovery, or operational resilience posture.
Critical services need an identified register with recovery objectives.
Business impact analyses need an audit trail.
Continuity and recovery plans need governed records distinct from where they’re stored as documents.
Recovery tests (tabletop exercises, technical failover tests, full disaster recovery drills) need records of conduct and outcome.

You don’t reach for this for the actual recovery infrastructure (replication, backups, failover orchestration). Those are engineering. Resilience is the governed posture on top.

What lives in the module

Five record types:

Business impact analysis (BIA) captures a structured analysis of disruption impact on a critical service: financial impact, operational impact, regulatory impact, reputational impact, the service’s dependencies and criticality, and the recovery objectives (recovery time and recovery point targets) derived from impact.
Continuity plan captures a documented plan for maintaining a service through disruption, with its ownership, communication, and dependencies.
Recovery strategy captures the recovery approach for a service after disruption: recovery objectives, dependencies, workarounds, and resources.
Continuity exercise captures the conduct and outcome of a continuity exercise (tabletop or scenario drill): scenario, participants, results, and lessons learned.
Restore test captures the conduct and outcome of a backup/restore validation: target, backup source, results, and recovery metrics.

The critical service, its dependency map, and its committed recovery objectives are captured within the BIA and recovery strategy rather than as separate record types.

A worked example: a national postal operator governs continuity across sorting, delivery, and parcels

A national postal operator runs sorting centers, last-mile delivery networks, postal-vehicle fleets, and parcel infrastructure. Continuity is essential: regulatory commitments to universal service, peak-season volume requirements, customer trust. The head of operational resilience, Joon, sets up Resilience like this.

Step 1: business impact analyses. Joon starts with the services the organization commits to (letter sorting and delivery, parcel intake and sorting, last-mile delivery, the customer-facing tracking platform, the financial settlement service for cash on delivery), and captures a BIA for each. Each BIA records the service’s scope and criticality, its dependencies (people, suppliers, systems, data, facilities), and quantifies impact at various disruption durations: 1 hour, 4 hours, 24 hours, 1 week. Impact dimensions: regulatory commitment (universal service obligations), financial (lost revenue, contractual penalties), operational (backlog), reputational. From the BIA, recovery objectives (recovery time and recovery point targets) are derived: letter sorting tolerates longer disruption than the financial settlement service.

Step 2: continuity plans. For each service, a continuity plan (how to keep going during disruption) is documented, with its ownership, communication, and dependencies. The plan documents live in the DMS through Document Governance; the resilience record references them.

Step 3: recovery strategies. For each service, a recovery strategy (how to return to normal) records the recovery objectives, dependencies, workarounds, and resources.

Step 4: continuity exercises. Quarterly, Joon conducts continuity exercises: tabletop exercises with the operations team on scenarios (sorting center fire, IT system outage, supplier failure). Each exercise record captures scenario, participants, results, and lessons learned.

Step 5: restore tests. Backup/restore validations (for the tracking platform and the financial settlement service) are recorded as restore tests, each capturing the target, the backup source, the results, and the recovery metrics achieved.

Step 6: review. Recovery objectives committed within each BIA and recovery strategy are reviewed annually. Deviations between committed and tested objectives generate findings.

After a year:

Each critical service has a BIA that grounds its recovery commitments in business reality.
Dependencies captured in the BIAs reveal single points of failure.
Continuity plans and recovery strategies are documented and reviewed.
Exercises and restore tests prove the plans work (or surface gaps).
A regulator’s resilience review has documented evidence.

What you’ll see in the product

Resilience lives under Governance → Resilience in the workspace.

Five top-level tabs: Business Impact Analyses, Continuity Plans, Recovery Strategies, Continuity Exercises, Restore Tests.

Every change is captured in the workspace Audit Log.

Common workflows

Analysing a critical service

Business Impact Analyses → New. Capture scope, criticality, dependencies, and impact across disruption durations.
Derive the recovery objectives (recovery time and recovery point targets) from the impact.
Document a continuity plan and a recovery strategy for the service.

Conducting an exercise or restore test

Continuity Exercises → New (for tabletop or scenario drills) or Restore Tests → New (for backup/restore validations). Pick the scope and scenario.
Run the exercise or test.
Capture outcome, lessons learned, action items.
Action items become findings routed for remediation.

Annual review of objectives

Revisit the BIA and recovery strategy for each service. Reconfirm or revise the recovery objectives.
Compare against actual exercise and restore-test results; raise findings for gaps.

Assets - critical services often depend on assets.
Party Engagements - supplier dependencies are party engagements.
Document Governance - continuity and recovery plans live in the DMS.
Incidents - actual disruptions become incidents.
Findings - test gaps and objective shortfalls become findings.
Risks - critical-service risks live in the risk register.