Business Continuity Dependency Management for SOC 2

What this control should accomplish

The company knows which people, vendors, platforms, facilities, identities, networks, and data flows its critical services depend on and has credible options when one becomes unavailable.

How to implement Business Continuity Dependency Management

1. 1

   Start from critical services

   Identify the customer journeys and internal capabilities whose prolonged loss would create the greatest operational, contractual, or customer impact.

   You should end up with: Prioritized continuity service scope

2. 2

   Map practical dependencies

   Record required people, vendors, cloud services, identity, DNS, networks, data stores, code, facilities, communications, and upstream or downstream services.

   You should end up with: Service dependency map and register

3. 3

   Assess failure impact

   For each dependency, document likely failure modes, affected service, time sensitivity, detection method, recovery role, and whether alternatives share the same failure domain.

   You should end up with: Dependency impact and concentration assessment

4. 4

   Define continuity options

   Document failover, manual workarounds, alternate suppliers, spare capacity, backup personnel, emergency access, or an explicit decision to accept the limitation.

   You should end up with: Owned continuity treatment for each critical dependency

5. 5

   Keep ownership and contacts usable

   Assign primary and backup owners, verify escalation contacts and access, and update the register when architecture, staffing, or vendors materially change.

   You should end up with: Current ownership, contact, and access record

6. 6

   Exercise priority failures

   Test selected dependency-loss scenarios and track missing access, unclear authority, stale procedures, or unrealistic workarounds to closure.

   You should end up with: Continuity exercise and corrective-action record

Evidence to keep, and what it should prove

Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.

Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.

Which records should you prepare for the audit?

How an auditor may test this control

Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.

• Confirm the intended control outcome

  Determine whether the control is designed to achieve this result: The company knows which people, vendors, platforms, facilities, identities, networks, and data flows its critical services depend on and has credible options when one becomes unavailable.

• Confirm ownership and operating cadence

  Compare the documented owner with the intended role (Operations Lead / Infrastructure Owner), then compare dated records with the stated cadence: Continuous for backups/monitoring; quarterly/annual testing as defined.

• Establish the complete audit record set

  Reconcile the scheduled review and exercise calendar plus material changes from architecture, service, vendor, and staffing systems to dependency-register updates and review records; verify removed and added dependencies, changed contacts, missed reviews, and accepted single points of failure are explicitly accounted for.

• Prepare the as-of-date evidence for a Type 1 engagement

  The current critical-service dependency register, ownership and contact information, active continuity treatments, recent dependency review, and evidence that a priority alternate procedure is usable at the review date.

• Prepare period evidence for a Type 2 engagement

  Every scheduled dependency or continuity review due during the review period, every material service, architecture, staffing, or vendor change designated to trigger an update, and every planned dependency-loss or alternate-procedure exercise, including missed, deferred, and closed occurrences.

• Inspect the policy / design artifacts

  Documents that define the control, its scope, ownership, and expected way of working.

  • Inspect Dependency register

    For each selected record, confirm it demonstrates Critical services are mapped to the people, technology, vendors, identity, data, facilities, and communication paths they require, with impact and ownership visible.

    • Critical service
    • Dependency and type
    • Purpose
    • Primary and backup owner
    • Failure impact
    • Alternative or accepted limitation

  • Inspect alternate operating procedures

    For each selected record, confirm it demonstrates A service has a usable failover, manual workaround, alternate supplier, emergency-access, or degraded-mode process with clear activation and return steps.

    • Affected service and trigger
    • Alternative path
    • Authorized activator
    • Required access and dependencies
    • Operating limits
    • Return-to-normal steps

• Inspect the approval / review evidence

  Records showing that an accountable person reviewed, approved, challenged, or accepted the work.

  • Inspect continuity review record

    For each selected record, confirm it demonstrates The team periodically and after material change reviews dependency accuracy, concentration, contacts, alternatives, and unresolved continuity risks.

    • Review date and scope
    • Participants
    • Changes identified
    • Failure-domain assessment
    • Decisions
    • Actions and owners

  • Inspect vendor/dependency review records

    For each selected record, confirm it demonstrates Material external and internal dependencies receive impact-aware review of service changes, continuity capability, contacts, alternatives, and accepted concentration risk.

    • Dependency
    • Service impact
    • Review date and reviewer
    • Continuity information
    • Decision
    • Follow-up or acceptance

• Trace the control from design to operation

  Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.

Common implementation and evidence gaps

• The register lists vendors but misses identity, DNS, communications, key personnel, or internal shared services.
• A stated alternative relies on the same region, account, identity provider, or network path.
• Backup personnel are named but lack access or practice performing the recovery role.
• Emergency contacts and escalation instructions are stale when an outage occurs.
• Single points of failure are known informally but have no accepted decision or treatment owner.

Before you call this control ready

• Can each critical service be traced to its technical, vendor, data, identity, and people dependencies?
• Do proposed alternatives avoid the same failure condition they are meant to address?
• Can backup personnel access the tools and information needed to perform their role?
• Are known single points of failure assigned to treatment or explicit acceptance?
• Have recent architecture, staffing, and vendor changes reached the dependency register?

Trust Services Criteria references

These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.

• CC9.1
• A1.2

Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.

Related controls to review next