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

Multiple record types:

Critical service captures one service the organization has identified as critical: its scope, owner, business purpose, recovery posture commitments.
Dependency map captures the upstream and downstream dependencies of a critical service: people, suppliers, systems, data, facilities.
Business impact analysis (BIA) captures a structured analysis of disruption impact on a critical service: financial impact, operational impact, regulatory impact, reputational impact, recovery objectives derived from impact.
Continuity plan captures a documented plan for maintaining a critical service through disruption.
Recovery plan captures a documented plan for recovering a critical service after disruption.
Recovery test captures the conduct and outcome of a continuity or recovery test.
Recovery objective captures a committed recovery time objective (RTO) and recovery point objective (RPO) per service.

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: identify critical services. Joon catalogues 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.

Each becomes a critical service record with scope, owner, business purpose.

Step 2: dependency maps. For each critical service, dependencies are mapped:

People (number of operators per shift, qualifications required).
Suppliers (vehicle leases, fuel, sorting machinery, IT vendors).
Systems (the sorting platform, the tracking platform, the financial settlement service, the dispatch system).
Data (address registry, customer database, route optimization data).
Facilities (the sorting centers, the depots, the distribution warehouses).

The dependency map becomes the basis for impact analysis.

Step 3: business impact analyses. For each critical service, a BIA 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 are derived: letter sorting tolerates longer disruption than the financial settlement service.

Step 4: continuity and recovery plans. For each critical service, a continuity plan (how to keep going during disruption) and a recovery plan (how to return to normal) are documented. The plans live in the DMS through Document Governance; the resilience record references them.

Step 5: recovery testing. Quarterly, Joon conducts tests:

Tabletop exercises with the operations team on scenarios (sorting center fire, IT system outage, supplier failure).
Technical failover tests on the tracking platform.
Annual full-scale disaster recovery drill on the financial settlement service.

Each test is a recovery test record with scope, methodology, outcome, lessons learned, action items.

Step 6: recovery objectives. RTO and RPO are committed per critical service and reviewed annually. Deviations between committed and tested objectives generate findings.

After a year:

Critical services are identified.
Dependency maps reveal single points of failure.
BIAs ground the recovery commitments in business reality.
Continuity and recovery plans are documented and reviewed.
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.

Multiple top-level tabs: Critical Services, Dependency Maps, Business Impact Analyses, Continuity Plans, Recovery Plans, Recovery Tests, Recovery Objectives.

Every change is captured in the workspace Audit Log.

Common workflows

Identifying a critical service

Critical Services → New. Scope, owner, business purpose.
Build the dependency map.
Conduct a BIA to derive recovery objectives.
Document continuity and recovery plans.

Conducting a recovery test

Recovery Tests → New. Pick the scope (which critical service, which scenario).
Run the test (tabletop, technical, full drill).
Capture outcome, lessons learned, action items.
Action items become findings routed for remediation.

Annual review of objectives

Recovery Objectives → review. Reconfirm or revise RTO/RPO per service.
Compare against actual 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.