Resource and dependency readiness

The ISO 22301 resource and dependency readiness requirement means your continuity plans must be backed by provable access to the people, technology, facilities, and third parties they depend on, under disruption conditions ¹. To operationalize it, inventory dependencies per critical activity, define minimums and alternatives, test that they work, and retain evidence that readiness checks happen on a repeatable cadence.

Key takeaways:

• Map each critical service to the exact internal resources and third-party dependencies it needs to meet recovery objectives.
• Define “minimum viable” staffing, systems, sites, and supplier capabilities, plus documented fallbacks for each.
• Prove readiness with recurring checks, contract/SLA alignment, and exercise results tied to continuity scenarios.

“Resource and dependency readiness” is the difference between a continuity plan that reads well and one that survives a real outage. ISO 22301 expects your business continuity management system (BCMS) to reflect operational reality: the plan must be supported by available people, workable technology, accessible facilities, and third parties that can actually perform during stress ¹. For a Compliance Officer, CCO, or GRC lead, the goal is not to perfect every contingency. The goal is to produce a defensible, test-backed story that critical activities can meet stated recovery objectives because required inputs are identified, secured, and periodically validated.

This requirement often fails during audits for a simple reason: teams document recovery steps without proving that prerequisites exist. Common gaps include “key person” dependencies with no backfill plan, recovery architectures without licensing or capacity confirmation, and supplier assumptions that are not contractually supported. The fastest path to compliance is to treat readiness as an operating control: assign owners, define measurable readiness criteria, run checks, escalate exceptions, and keep artifacts that show the control works.

Regulatory text

Provided excerpt (framework overview summary): “Baseline implementation-intent summary derived from publicly available framework overviews; licensed standard text is not reproduced in this record.” ¹
Requirement summary: “Ensure required people, technology, facilities, and suppliers support continuity plans.” ¹

What you, the operator, must do:
You must be able to demonstrate that each continuity strategy and plan is supported by (1) identified resources and dependencies, (2) confirmed availability under relevant disruption scenarios, and (3) maintained readiness over time through checks and exercises ¹. Auditors will expect traceability from critical activities to required inputs to evidence that those inputs are viable.

Plain-English interpretation (what “ready” means)

“Ready” means you can point to a specific continuity scenario and show, with current evidence, that:

• People: roles are staffed, alternates exist, on-call and contact methods work, and specialized skills are covered.
• Technology: recovery environments, access, credentials, licenses, backups, capacity, and runbooks are in place and current.
• Facilities: primary/alternate sites are accessible, safe, and equipped for the recovery posture you claim.
• Third parties/suppliers: they can deliver during disruption, your contracts support required timelines, and you have fallbacks if they cannot.

Readiness is not a one-time documentation exercise. Treat it as an operational control that produces repeatable evidence ¹.

Who it applies to (entity and operational context)

This applies to organizations implementing or aligned to ISO 22301, especially:

• Critical service operators (where disruption creates customer harm, safety issues, or material operational impact)
• Service organizations delivering services to clients where continuity commitments exist ¹

Operationally, it applies wherever you have:

• Defined recovery objectives (RTO/RPO or similar targets)
• Concentrated dependencies (single data center, single SME, sole-source supplier)
• Material third-party reliance (cloud, payments, contact centers, managed IT, logistics)

What you actually need to do (step-by-step)

1) Define scope and “critical activities” you will defend

• Confirm the list of critical services/activities covered by the BCMS.
• For each, identify the customer-facing outcome and internal process boundary.
• Tie each critical activity to the continuity strategy you claim (workaround, failover, alternate site, manual processing).

Output: Critical activity register with service owners and continuity strategy.

2) Build a dependency map per critical activity (internal + third party)

For each critical activity, document dependencies in four buckets:

• People: roles, skills, minimum staffing level, decision authorities.
• Technology: applications, infrastructure, identity/access, endpoints, networks, data stores, backups, monitoring, telecom.
• Facilities: offices, branch locations, warehouses, call centers, data centers, alternate work locations.
• Third parties: suppliers, cloud providers, MSSPs, payroll, communications, data providers, logistics, key contractors.

Make this practical: name the system, the team, and the third party, not just “IT” or “vendor.”

Output: Dependency map (table format) with owners for each dependency.

3) Define readiness criteria (“minimum viable”) and acceptable substitutes

Create explicit readiness requirements for each dependency. Examples:

• People readiness: named primary and alternate for each critical role; on-call schedule; knowledge coverage (runbook ownership).
• Technology readiness: recovery environment exists; access is pre-provisioned; backups are restorable; capacity meets expected degraded-mode load.
• Facility readiness: alternate workspace arrangement; access procedure; equipment list; safety and entry requirements.
• Third-party readiness: SLA/contract language supports continuity objectives; escalation contacts; evidence of the third party’s own continuity capabilities; documented workaround if the third party is unavailable.

Decision rule: If a dependency has no substitute, treat it as a single point of failure and drive a risk acceptance or remediation plan.

Output: Readiness criteria matrix, plus exception log.

4) Align contracts and operating procedures to continuity needs (especially third parties)

For critical third parties, confirm:

• The contract supports your continuity expectations (response, recovery support, incident communications).
• You have an escalation path that works outside normal business hours.
• You can operate if the third party is degraded or offline (manual procedure, alternate provider, delayed processing).

If you cannot renegotiate quickly, document compensating controls (stockpiles, manual workarounds, alternate channels) and management sign-off.

Output: Third-party continuity addendum checklist; contract review notes; fallback procedures.

5) Implement recurring readiness checks (make it an owned control)

Create a calendar of “readiness verification” activities, such as:

• Call tree validation.
• Access and credential checks for recovery systems.
• Restore tests or data validation checks.
• Alternate site access verification.
• Third-party contact and escalation tests.
• Runbook currency checks (last reviewed, last exercised).

Assign each check to a named owner and track completion and exceptions.

Output: Readiness check schedule, completed check evidence, exception tickets, and remediation tracking.

6) Exercise dependencies under realistic scenarios and capture outcomes

Tabletop exercises often prove logic, but readiness needs proof of capability. Exercises should test dependency assumptions, such as:

• Staff unavailability (key person out).
• Facility loss.
• Identity provider outage.
• Third-party outage.

Document gaps and feed them into corrective actions. Close the loop with retesting.

Output: Exercise plan, results, after-action report, corrective action log with owners and dates.

7) Make it auditable: traceability from objective → dependency → evidence

Auditors want a straight line:

• Critical activity and recovery objective
• Continuity strategy
• Dependency list and readiness criteria
• Evidence of checks/exercises and current status
• Approved exceptions and remediation

Tools can help. Many teams use Daydream to keep third-party dependency records, evidence requests, and continuity-related attestations tied to critical services, so audits don’t become a scavenger hunt.

Required evidence and artifacts to retain

Keep artifacts that prove both design (you identified what you need) and operation (you verified it works):

Core artifacts

• Critical activity register and owners
• Dependency maps (people/tech/facilities/third parties)
• Readiness criteria matrix and exception log
• Continuity runbooks and contact lists (with review dates)
• Readiness check schedule and completed check records
• Exercise materials: scenarios, attendance, results, after-action reports
• Corrective action plans and closure evidence

Third-party-specific artifacts

• Contract extracts or summaries showing continuity-related commitments
• Third-party continuity documentation you collected (as applicable)
• Escalation contact validation evidence
• Fallback/alternate provider procedures

Common exam/audit questions and hangups

Auditors and assessors tend to probe the same failure points:

1. “Show me evidence this dependency is actually available.”
   Hangup: you have a plan but no proof of access, capacity, or staffing.

2. “How do you know the third party will perform under disruption?”
   Hangup: assumptions are not supported by contracts, testing, or documented alternatives.

3. “What happens if your top two SMEs are out?”
   Hangup: key-person risk with no cross-training or documented procedures.

4. “Do your recovery steps rely on the same identity/network that is down?”
   Hangup: circular dependencies in technology recovery designs.

5. “How do you manage exceptions?”
   Hangup: informal risk acceptance without approver, rationale, or revisit triggers.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Generic dependency lists (“IT systems,” “key vendors”)	Not testable; not auditable	Name specific systems, roles, and third parties with owners
Treating readiness as annual paperwork	Evidence goes stale fast	Put readiness checks on an owned schedule with completion tracking
No fallback for sole-source third parties	Creates brittle continuity posture	Define manual workarounds, alternates, or explicit risk acceptance
Ignoring access/credential readiness	Recovery fails at login time	Pre-provision break-glass access and test it during exercises
Exercises that don’t test dependencies	False confidence	Design scenarios that break your real assumptions

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Operationally, gaps in resource and dependency readiness increase the chance that you miss recovery objectives you have committed to internally or contractually, and they raise the likelihood of extended outages due to single points of failure in people, systems, facilities, or third parties ¹. Treat readiness gaps as operational risk that can become a customer-impacting incident.

30/60/90-day execution plan

First 30 days: establish the control and baseline

• Confirm in-scope critical activities and owners.
• Build first-pass dependency maps for the top critical activities.
• Define readiness criteria for the highest-risk dependencies (key roles, core platforms, top third parties).
• Stand up an exception log and an approval path for risk acceptance.
• Schedule the first readiness checks (call tree, access checks, third-party contacts).

Deliverable: A defensible baseline that ties critical activities to dependencies and named owners.

Days 31–60: validate and close obvious gaps

• Run readiness checks and capture evidence.
• Review contracts and support terms for critical third parties; document gaps and compensating controls.
• Update runbooks to reflect real prerequisites (access, tooling, dependencies).
• Hold a targeted exercise that breaks one major dependency assumption (facility loss, third-party outage, or identity outage).
• Start corrective actions with accountable owners.

Deliverable: Evidence of operation (checks/exercise) plus a tracked remediation backlog.

Days 61–90: operationalize and make it repeatable

• Expand mapping and readiness criteria to remaining critical activities.
• Retest corrected gaps; close actions with proof.
• Implement a steady-state cadence (monthly/quarterly) for readiness checks based on criticality.
• Prepare an audit pack: traceability samples, exception log, exercise results, and third-party artifacts.

Deliverable: A repeatable program with audit-ready traceability and current evidence.

Frequently Asked Questions

How detailed does the dependency map need to be to satisfy the resource and dependency readiness requirement?

Detailed enough that someone outside your team can execute recovery without guessing. Name systems, roles, facilities, and third parties, and assign an owner for each dependency ¹.

Do we need a backup supplier for every third party?

Not always. If there is no feasible alternate, document the workaround, the business impact, and a formal risk acceptance with a plan to reduce exposure over time.

What evidence is strongest in an ISO 22301 audit?

Recurring readiness check records and exercise outputs tied to specific continuity scenarios tend to be persuasive because they show the control operates, not just that documentation exists ¹.

How should we handle key-person dependencies for critical processes?

Define minimum staffing by role, assign alternates, and require runbooks or knowledge transfer artifacts. Then test the scenario where the primary is unavailable during an exercise.

We’re heavily cloud-dependent. What does “facility readiness” mean for us?

It shifts toward workforce location readiness and connectivity: alternate working arrangements, endpoint readiness, telecom, and access paths that still function if a primary office is unavailable.

Where does Daydream fit into operationalizing this requirement?

Use Daydream to centralize third-party dependency records, evidence collection, and exception tracking so your continuity dependency proof stays current and you can produce an audit packet without manual chasing.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control lifecycle management

Footnotes

1. ISO 22301 overview