What business continuity response level does this incident require?

{
  "_meta": {
    "schema": "https://www.drawdecisiontree.com/decision-dag.schema.json",
    "source": "https://www.drawdecisiontree.com",
    "description": "DrawDecisionTree.com is a free tool for building, sharing, and embedding interactive decision trees. This file is the machine-readable export of a published decision tree. The `dsl` field contains the original source in the Decision DAG DSL; the `dag` schema is documented at the URL in `schema` above.",
    "links": {
      "interactive": "https://www.drawdecisiontree.com/t/drawdecisiontree/ops-business-continuity.html",
      "embed": "https://www.drawdecisiontree.com/embed/path/drawdecisiontree/ops-business-continuity",
      "dsl_reference": "https://www.drawdecisiontree.com/decision-tree-dsl-reference.html",
      "guides": "https://www.drawdecisiontree.com/guides",
      "schema_docs": "https://www.drawdecisiontree.com/decision-dag.schema.json",
      "author_trees": "https://www.drawdecisiontree.com/trees/drawdecisiontree"
    },
    "generated_at": "2026-05-29T12:05:39.334Z"
  },
  "author": {
    "handle": "drawdecisiontree",
    "first_name": "Andrew",
    "last_name": null,
    "avatar_url": "1d32d828-b6ca-40ec-bdd7-771fe7b9c36a/avatar-1778531481027.svg",
    "display_name": "Andrew"
  },
  "file": {
    "id": "9c85c529-2ac1-4628-865e-e764599bc335",
    "name": "What business continuity response level does this incident require?",
    "public_slug": "ops-business-continuity",
    "updated_at": "2026-05-12T16:53:43.587978+00:00",
    "url": "https://www.drawdecisiontree.com/t/drawdecisiontree/ops-business-continuity.html",
    "json_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/ops-business-continuity/tree.json",
    "dsl_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/ops-business-continuity/tree.dag"
  },
  "meta": {
    "description": "Determine the appropriate level of business continuity response to activate when a disruption — whether technical, environmental, or operational — threatens service delivery. Use this tree at the point an incident is declared or a significant disruption is first identified, before committing resources to a response. Activating the right level of response early prevents both under-reaction that allows disruptions to escalate and over-reaction that wastes resources and creates unnecessary alarm.",
    "mode": "decision",
    "entry": "Q1",
    "tags": [
      "operations",
      "business continuity",
      "disaster recovery",
      "risk management",
      "crisis management"
    ],
    "image": "https://images.unsplash.com/photo-1504711434969-e33886168f5c?w=1200&q=80"
  },
  "questions": [
    {
      "id": "Q1",
      "text": "Are one or more critical services or systems currently unavailable or operating significantly below normal capacity?"
    },
    {
      "id": "Q2",
      "text": "Are customers, regulators, or material third-party partners currently experiencing impact as a direct result of this disruption?"
    },
    {
      "id": "Q3",
      "text": "Has the disruption already lasted — or is it credibly expected to last — more than four hours from first detection?"
    },
    {
      "id": "Q4",
      "text": "Are affected staff able to continue working remotely using pre-established workarounds, backup systems, or manual procedures?"
    },
    {
      "id": "Q5",
      "text": "Is there any evidence or credible risk that data integrity has been compromised — including corruption, unauthorised access, deletion, or ransomware encryption?"
    }
  ],
  "outcomes": [
    {
      "id": "NORMAL_OPS",
      "label": "Normal Operations"
    },
    {
      "id": "MONITOR",
      "label": "Monitor Closely"
    },
    {
      "id": "CONTINUITY_PROCS",
      "label": "Invoke Continuity Procedures"
    },
    {
      "id": "CRISIS_TEAM",
      "label": "Activate Crisis Response Team"
    },
    {
      "id": "FULL_DR",
      "label": "Full Disaster Recovery Declaration"
    }
  ],
  "dsl": "dag: What business continuity response level does this incident require?\nversion: 1.0.0\nimage: https://images.unsplash.com/photo-1504711434969-e33886168f5c?w=1200&q=80\ndescription: Determine the appropriate level of business continuity response to activate when a disruption — whether technical, environmental, or operational — threatens service delivery. Use this tree at the point an incident is declared or a significant disruption is first identified, before committing resources to a response. Activating the right level of response early prevents both under-reaction that allows disruptions to escalate and over-reaction that wastes resources and creates unnecessary alarm.\ntags: operations, business continuity, disaster recovery, risk management, crisis management\nentry: Q1\n\nQ1: Are one or more critical services or systems currently unavailable or operating significantly below normal capacity?\n  hint: Critical services are those whose failure directly prevents customers from receiving what they have contracted for, or prevents staff from performing revenue-generating or regulatory-required functions. A service operating below capacity — for example, processing at 30% of normal throughput — should be treated as unavailable for the purposes of this assessment if the shortfall cannot be compensated by other means. Check your service monitoring dashboards and confirm the status with the relevant system or operations owner before answering; do not rely on anecdotal reports from individual users. If you are uncertain whether a service qualifies as critical, refer to your Business Impact Analysis (BIA) document — if one does not exist, escalate to your BCM lead immediately.\n  yes -> Q2\n  no  -> [NORMAL_OPS]\n\nQ2: Are customers, regulators, or material third-party partners currently experiencing impact as a direct result of this disruption?\n  hint: Customer impact includes inability to access products or services, delayed fulfilment of orders or commitments, incorrect data being presented or shared, or breach of contractual SLAs. Regulatory impact includes failure to meet reporting deadlines, breach of data protection obligations, or inability to evidence compliance with licence conditions. Third-party partner impact includes failure to provide data feeds, APIs, or services that downstream partners depend on to serve their own customers. If you are unsure whether a customer-facing SLA has been breached, check the contract terms and consult your Customer Success or Account Management team before answering.\n  yes -> Q3\n  no  -> [MONITOR]\n\nQ3: Has the disruption already lasted — or is it credibly expected to last — more than four hours from first detection?\n  hint: Four hours is a common Recovery Time Objective (RTO) threshold in business continuity plans and represents the point at which most organisations begin to experience compounding downstream effects, including SLA breaches, manual workaround fatigue, and reputational risk. Use the most conservative estimate of resolution time based on information currently available from the engineering or operations team responsible for the affected system. If the root cause has not yet been identified, assume the disruption will persist until a credible fix is confirmed — do not plan on an optimistic timeline that has not been validated. Document the time of first detection and current elapsed time in the incident log before answering.\n  yes -> Q4\n  no  -> [MONITOR]\n\nQ4: Are affected staff able to continue working remotely using pre-established workarounds, backup systems, or manual procedures?\n  hint: Effective remote working capability requires not just connectivity but also access to the data, systems, and tools needed to perform the critical parts of the role — a staff member who can log in but cannot access the affected system is not operationally available. Check whether documented manual fallback procedures exist for the affected processes and whether staff have been trained on them; undocumented or untested fallbacks carry high failure risk under pressure. Consider whether the remote working capability has been tested in the last 12 months — an untested capability should be treated as unconfirmed until it has been demonstrated in this incident. If only a subset of staff can work remotely, assess whether that subset is sufficient to maintain minimum viable operations at the required throughput.\n  yes -> Q5\n  no  -> [CRISIS_TEAM]\n\nQ5: Is there any evidence or credible risk that data integrity has been compromised — including corruption, unauthorised access, deletion, or ransomware encryption?\n  hint: Data integrity risk includes not just confirmed data loss or corruption but also any scenario where you cannot confidently confirm that data held in affected systems is complete, accurate, and unmodified since the last verified backup. Ransomware, unauthorised access, accidental deletion, failed migrations, and synchronisation failures all represent data integrity events even if the data appears superficially intact. Consult your IT or Security team to establish the last confirmed clean backup timestamp and the volume of data that may be at risk before answering. If data integrity is even possibly compromised, treat this question as yes — a false negative here can result in the propagation of corrupt data through downstream systems, compounding recovery effort significantly.\n  yes -> [FULL_DR]\n  no  -> [CONTINUITY_PROCS]\n\n[NORMAL_OPS]: Normal Operations\n  color: #2E7D32\n  description: All critical services and systems are operating within normal parameters — no business continuity response is required at this time. Continue routine monitoring of service dashboards and operational KPIs, and ensure that any alerts or anomalies detected are logged and reviewed by the relevant team within standard response times. Use this period to verify that your Business Continuity Plan (BCP) is up to date, that contact trees are current, and that any lessons from recent incidents have been incorporated into procedures. Schedule the next BCP exercise if one is not already in the calendar, and confirm that all recovery time objectives and data backups have been validated within the required testing frequency.\n  code: OPS_BC_NORMAL\n\n[MONITOR]: Monitor Closely\n  color: #F9A825\n  description: The disruption is currently contained or low-impact, but the situation warrants close monitoring to detect any deterioration before it escalates. Assign a named incident owner to track the situation, set a review cadence of no longer than 30 minutes, and ensure the incident is logged in your incident management system with a clear description of current status and the conditions that would trigger escalation. Brief your immediate management chain so they are aware and can provide support if the situation changes. Prepare your Continuity Procedures documentation for rapid activation if the disruption extends beyond four hours or customer impact is confirmed — having materials ready reduces escalation time significantly.\n  code: OPS_BC_MONITOR\n\n[CONTINUITY_PROCS]: Invoke Continuity Procedures\n  color: #F57F17\n  description: The disruption meets the threshold for formal activation of Business Continuity Procedures — convene your Business Continuity team or designated deputies and formally declare an incident. Activate the relevant sections of your Business Continuity Plan, initiate manual fallback procedures for affected processes, and brief all affected staff on what they should do and who to escalate to. Issue a formal customer communication within 30 minutes of activation, setting expectations on service restoration timelines and providing a named point of contact for urgent queries. Log all decisions and actions taken with timestamps in the incident log, as this record will be essential for the post-incident review and any regulatory notifications that may be required.\n  code: OPS_BC_PROCEDURES\n\n[CRISIS_TEAM]: Activate Crisis Response Team\n  color: #E65100\n  description: With staff unable to maintain operations through remote working and an extended disruption in progress, immediate activation of the Crisis Response Team (CRT) is required. Convene the CRT in the designated crisis management facility or virtual bridge, appoint a Crisis Manager to chair, and establish a structured communications rhythm with updates every 30–60 minutes. Escalate to executive leadership immediately and issue a holding statement to affected customers and relevant regulators within one hour of CRT activation. Assess whether temporary premises, emergency staffing, or alternative supply arrangements are needed, and authorise emergency expenditure in line with the crisis authority limits set out in your BCP. Document all decisions with timestamps and prepare for a post-crisis review to be completed within five business days of resolution.\n  code: OPS_BC_CRISIS\n\n[FULL_DR]: Full Disaster Recovery Declaration\n  color: #B71C1C\n  description: The confirmed or credible risk of data integrity compromise, combined with an extended customer-impacting outage and inability to maintain operations, requires immediate declaration of a full Disaster Recovery (DR) event. Halt all writes to affected systems immediately to prevent further propagation of corrupted or compromised data, and initiate the DR failover procedure in line with your tested DR runbook — do not improvise steps that deviate from the tested process. Notify your Data Protection Officer and legal team immediately if personal data may be compromised, as GDPR and equivalent regulations impose strict notification timelines to supervisory authorities and affected individuals. Engage your cyber insurance provider and any retained incident response partner at the same time as the DR declaration, and preserve all system logs and forensic evidence before any recovery actions are taken to support root-cause analysis and regulatory investigation.\n  code: OPS_BC_FULL_DR\n"
}