Bcm Disaster Recovery Specialist

BCM & Disaster Recovery Specialist (Security-Focused)

When to Use

• Run business impact analysis for security-critical and IT services (IdP, SIEM, EDR, SOAR, KMS, CASB, PKI)
• Set RTO/RPO and recovery tiers for security tooling, identity, logging, and evidence retention
• Author or refresh BCP/DRP with cyber-resilience (isolation, rebuild-from-gold, segmented recovery)
• Build ransomware and destructive-attack recovery playbooks (decrypt vs rebuild decision tree)
• Design backup, immutability, and air-gap patterns; schedule restore tests with pass/fail criteria
• Coordinate crisis comms cadence with IR and executive stakeholders during prolonged recovery
• Facilitate tabletop exercises (cyber, regional loss, identity outage, logging loss)
• Map high-level regulatory BCM expectations to program artifacts (not legal advice)

When NOT to Use

• Lead active security incident war room, containment, or evidence preservation → incident-responder
• Triage SOC alerts or execute detection playbooks → soc-analyst
• Define SEV matrices, paging, or status-page program → incident-management-engineer
• Operate SLIs, SLOs, error budgets, and burn-rate alerts → site-reliability-engineer
• Execute snapshot restores and access tickets without BCM program ownership → cloud-system-administrator
• Build VPC, clusters, or new platforms → infrastructure-engineer, cloud-engineer
• Enterprise security strategy without BCM/DR lens → cybersecurity
• Implement SIEM/EDR/IdP controls → information-security-engineer
• Control-by-control audit evidence automation → compliance-engineer
• Org-wide infra portfolio and multi-year capex → vp-of-infrastructure
• Deep forensic acquisition and super-timelines → digital-forensics-analyst

Related skills

Core Workflows

1. Scope and program charter

Define BCM/DR boundaries, ownership, and alignment with IR and resilience functions.

See `references/bcm_dr_scope.md`.

2. Business impact and criticality

Identify processes, dependencies, and security-service criticality; classify tiers.

See `references/business_impact_and_criticality.md`.

3. RTO, RPO, and recovery strategies

Set objectives; choose strategies (active/active, warm standby, rebuild, manual workaround).

See `references/rto_rpo_and_recovery_strategies.md`.

4. Cyber incident and ransomware recovery

Playbooks for encryption, wiper, identity compromise, and supply-chain recovery sequencing.

See `references/cyber_incident_and_ransomware_recovery.md`.

5. Backup, immutability, and restore testing

Retention, isolation, validation criteria, and evidence for auditors and leadership.

See `references/backup_restore_and_immutability.md`.

6. Tabletop exercises and governance

Exercise design, findings tracking, regulatory touchpoints, and continuous improvement.

See `references/tabletop_exercises_and_governance.md`.

Outputs

• BIA summary — tiered services, dependencies, max tolerable downtime, data classes
• RTO/RPO register — per service with owner, strategy, and last test date
• BCP/DRP pack — activation criteria, roles, comms tree, recovery sequences
• Cyber recovery playbook — ransomware/wiper/IdP paths with decision gates
• Restore test report — scope, RPO achieved, integrity checks, gaps, remediation
• Tabletop report — scenario, injects, decisions, gaps, action register
• Executive BCM brief — posture, test results, top risks (for leadership; not legal advice)

Principles

• Recover security first — identity, logging, and detection before convenience features
• Assume compromise — prefer clean rebuild and immutable backups over in-place decrypt
• Test restores, not backups — successful backup job ≠ recoverable data
• Align with IR — BCM activation and comms complement, not duplicate, CSIRT runbooks
• Document decisions — tiering and accepted gaps need explicit risk acceptance

Backup, restore, and immutability

Table of contents

1. Backup scope 2. Immutability and isolation 3. Retention and legal hold 4. Restore test program 5. Restore procedure pattern 6. Evidence for audit 7. Common failures

Backup scope

Include in BCM backup inventory (minimum):

Exclude from standard DR backups: ephemeral caches, non-prod unless tiered.

Align scope with RPO register—every tier-0/1 row must map to a backup job or replication stream.

Immutability and isolation

Implement defense against ransomware touching backups:

1. Object lock / WORM — minimum retention aligned to longest RPO + investigation window 2. Separate admin account — backup admins not in domain users; MFA on backup plane 3. Network isolation — backup network unreachable from corp VLAN except required ports 4. Air-gap or offline copy — periodic for tier-0 (tape, vault, second cloud account) 5. Immutable snapshots — cloud snapshot lock; verify delete API cannot bypass without break-glass 6. Versioning — protect against poisoned backup chains; test restore from older point

Document break-glass procedure to shorten retention (requires two-person approval).

Execution partners: cloud-system-administrator, information-security-engineer.

Retention and legal hold

On hold: freeze automated lifecycle deletion; tag affected backups in catalog.

Restore test program

Cadence

Test types

1. Tabletop restore — walkthrough with timestamps (quarterly for tier-0) 2. Technical restore — actual data/system recovery 3. Failover — DNS/regional flip where applicable 4. Cyber-specific — restore from pre-dwell backup sample; malware scan restored image

Pass criteria

Record for each test:

• Target RPO achieved (Y/N; actual data timestamp)
• Target RTO achieved (Y/N; RTA minutes)
• Integrity checks — auth, ingest, agent check-in, sample queries
• Issues — ticket IDs, owners, due dates

Failed test = risk acceptance or remediation by due date—escalate tier-0 failures to leadership.

Restore procedure pattern

Standard runbook sections (delegate execution to ops):

1. Authorize — change ticket, incident link, approvers 2. Isolate target — recovery VLAN, no production routes until validated 3. Select recovery point — document timestamp and reason 4. Restore — per vendor steps; verify checksums where available 5. Validate — functional tests from service owner checklist 6. Scan — AV/EDR on restored systems before join production 7. Cutover — maintenance window, rollback plan documented 8. Report — RPO/RTO achieved, logs attached

For SaaS: document export/import limits; test vendor restore support annually.

Evidence for audit

Maintain 6–12 months of:

• Restore test reports with pass/fail and approver
• Backup job success dashboards (tier-0/1)
• Immutability configuration screenshots or IaC references
• Risk acceptances for known gaps

Route control mapping to compliance-engineer or compliance-specialist—this skill supplies operational proof, not control matrices.

Common failures

After real incident, compare actual RPO to test results; update test scope if gap > 1 tier.

BCM and disaster recovery scope

Table of contents

1. Program purpose 2. In scope 3. Out of scope 4. Roles and RACI 5. Lifecycle and cadence 6. Handoffs

Program purpose

Establish security-focused continuity and recovery so the organization can:

• Restore identity, detection, and logging within agreed RTO/RPO after cyber or infrastructure events
• Execute documented recovery for ransomware, wipers, and prolonged identity or SaaS outages
• Prove restore capability through tested backups and exercised playbooks
• Coordinate prolonged recovery comms with incident response without owning the war room

This skill addresses program design, analysis, playbooks, and exercises—not live operations.

In scope

Out of scope

Roles and RACI

A = accountable, R = responsible, C = consulted, I = informed.

Lifecycle and cadence

1. Annual — refresh BIA, RTO/RPO register, executive brief 2. Semi-annual — restore tests for tier-0/1 security and identity systems 3. Quarterly — tabletop (rotate cyber, regional, IdP, logging-loss scenarios) 4. Per major change — update dependencies when IdP, logging, or SOC stack changes 5. Post-incident — feed real RTO/RPO and gaps into plan updates within 30 days

Handoffs

From IR (`incident-responder`): After containment, provide recovery sequencing, rebuild criteria, and comms templates for prolonged outage.

To IR: During BCP activation for security incidents, IR owns timeline and evidence; BCM owns recovery milestones and service restoration order.

To SRE (`site-reliability-engineer`): Customer-facing SLO impact and mitigation; BCM owns security-service recovery order and backup validation.

To cloud ops (`cloud-system-administrator`): Execute restores per runbook; BCM defines scope, success criteria, and test schedule.

Business impact and criticality

Table of contents

1. BIA objectives 2. Process and service inventory 3. Impact dimensions 4. Dependency mapping 5. Tiering model 6. Workarounds 7. BIA outputs

BIA objectives

Produce a defensible criticality ranking for security and IT services that drives RTO/RPO, backup scope, and exercise priority. Focus on:

• Security outcomes — authentication, authorization, detection, response, evidence retention
• Regulatory and contractual — logging retention, breach investigation capability, access control
• Operational coupling — what breaks if IdP, SIEM, or EDR is unavailable for 4h vs 24h

Do not treat all SaaS as tier-0; justify tiers with impact evidence.

Process and service inventory

Capture each item in a single register:

Security-critical examples: IdP/MFA, PAM, KMS/HSM, SIEM, log archive, EDR, SOAR, email security gateway, CASB, secrets manager, certificate authority, vulnerability scanner, GRC tool storing control evidence.

Impact dimensions

Score each service 1–5 per dimension at defined outage durations (e.g., 1h, 4h, 24h, 72h):

Security-specific: prolonged loss of logging or IdP often escalates impact non-linearly—document compound effects (cannot investigate while attackers remain active).

Dependency mapping

For each tier candidate, diagram:

1. Upstream — IdP, DNS, network, hypervisor, SaaS status page 2. Downstream — apps, SOC workflows, automation that fails closed or open 3. Shared fate — single region, single admin account, single backup controller 4. External — identity federation, MSP SOC, cloud control plane

Flag single points of failure and circular dependencies (e.g., MFA via system that requires MFA to administer).

Tiering model

Assign tier from highest impact dimension at MTPD threshold. Document risk acceptance when tier and budget disagree.

Workarounds

Define manual or degraded modes before disaster:

Workarounds require pre-approval in policy and tabletop validation.

BIA outputs

Deliver:

1. Criticality register (CSV or GRC tool) — all fields above, versioned 2. Dependency diagram — tier-0/1 subgraph 3. Gap list — missing workarounds, unknown owners, untested dependencies 4. Recommendations — RTO/RPO proposals, backup scope changes, exercise priorities

Route tier-0 gaps with due dates to information-security-engineer or platform owners; track in BCM action register.

Cyber incident and ransomware recovery

Table of contents

1. Recovery vs IR boundaries 2. Decision tree 3. Ransomware playbook 4. Wiper and destructive attacks 5. Identity compromise recovery 6. Logging and evidence preservation 7. Crisis comms coordination 8. Return to normal

Recovery vs IR boundaries

Never pay ransom or negotiate without legal and executive decision—document options only.

Decision tree

Confirmed encryption or destructive malware?
├─ NO → Follow standard DR/BCP for outage; IR may still run parallel
└─ YES →
    ├─ Backups verified clean + immutable? (test hash/sample restore)
    │   ├─ YES → Prefer RESTORE to isolated env → validate → cutover
    │   └─ NO → REBUILD from gold images / new tenants; assume compromise
    ├─ Domain-wide admin compromised?
    │   └─ YES → Identity recovery BEFORE broad restore
    └─ Exfiltration suspected?
        └─ Coordinate legal/regulatory prep; preserve logs per hold

Restore-in-place only when IR and forensics confirm no attacker persistence in restored images.

Ransomware playbook

Phase 0 — Preparation (before event)

• Maintain offline/immutable backups; separate admin for backup plane
• Document gold images, IaC baselines, and SaaS tenant rebuild steps
• Pre-approve isolation actions (VLAN, disable sync, disable GPO scripts)
• Store critical runbooks outside primary domain (out-of-band access)

Phase 1 — Mobilize (0–2 h)

1. IR declares incident; activate cyber recovery annex 2. Freeze backup deletion and replication jobs; snapshot backup catalog metadata 3. Identify patient zero timeline; map encrypted scope 4. Preserve logs off affected systems (forwarders, cloud audit)—see logging section 5. Establish recovery bridge separate from potentially compromised chat/IdP if needed

Phase 2 — Assess backups (2–8 h)

1. Identify last clean backup per system (before dwell time) 2. Test restore to isolated network; scan restored images 3. Record achievable RPO per system; compare to register 4. If backups encrypted or poisoned, switch to rebuild track

Phase 3 — Recover (hours–days)

1. Recover identity and network controls first 2. Restore or rebuild tier-0 security stack (SIEM, EDR management) 3. Restore workloads in waves; validate each wave before next 4. Rotate all secrets post-cutover (API keys, service principals, DB passwords) 5. Enhanced monitoring for 30+ days; document RTA vs RTO

Phase 4 — Close

• Executive sign-off on restoration completeness
• Feed gaps to PIR; schedule restore test and tabletop within 90 days

Wiper and destructive attacks

• Assume no reliable decrypt; focus on rebuild and data loss acceptance
• Prioritize business-critical data recreation paths (not only IT restore)
• Coordinate with digital-forensics-analyst if attribution or legal hold required
• Document permanent loss items for leadership and legal (not legal advice)

Identity compromise recovery

1. Disable compromised accounts and federation paths if needed 2. Revoke refresh tokens, app passwords, API keys tied to IdP 3. Reset KRBTGT / tier-0 recovery per AD best practice if domain affected 4. Rebuild or restore IdP from known-good backup to isolated environment 5. Re-enroll MFA devices; treat prior MFA as untrusted 6. Validate conditional access and admin roles before general user login

Handoff to information-security-engineer for control hardening post-recovery.

Logging and evidence preservation

During recovery:

• Do not delete logs for "cleanup" without legal/IR approval
• Redirect ingest to clean SIEM or cold storage; note gap in investigation timeline
• Export cloud audit, IdP, EDR, and email logs to immutable store early
• Document detection gap period if SIEM down (for PIR and regulatory prep)

Forensic depth → digital-forensics-analyst; war-room timeline → incident-responder.

Crisis comms coordination

BCM provides prolonged recovery messaging support:

Use separate fact and hypothesis sections; update on cadence tied to severity.

Return to normal

Criteria to exit DR mode:

• Tier-0/1 services at or above agreed minimum function
• No active uncontained encryption spread
• Monitoring and identity trust validated
• Action register for hardening owned and dated

Conduct hot wash within 5 business days; update cyber recovery annex and restore tests.

RTO, RPO, and recovery strategies

Table of contents

1. Definitions 2. Setting RTO and RPO 3. Security service targets 4. Recovery strategies 5. Activation criteria 6. Recovery sequencing 7. Metrics and reporting

Definitions

RTO/RPO must be approved by service owner and risk/compliance where regulatory logging or identity is involved.

Setting RTO and RPO

1. Start from BIA tier and MTPD 2. Subtract time for assessment, decision, and team mobilization (often 30–120 min for major events) 3. Set RTO ≤ remaining MTPD budget for restoration work 4. Set RPO from backup frequency, replication lag, and legal log retention minimums 5. Validate with restore test or tabletop—adjust if RTA consistently exceeds RTO

Document exceptions (e.g., "RPO 24h accepted for dev SIEM with risk ID").

Security service targets

Use as starting points; calibrate to your BIA:

Recovery strategies

Cyber bias: after confirmed compromise, default to rebuild from known-good rather than restore-in-place unless forensic and IR (incident-responder) approve.

Activation criteria

Declare DR mode when any trigger is met (customize in BCP):

• Tier-0 service outage exceeding 50% of RTO with no ETA
• Ransomware or wiper affecting production or backups
• Identity platform compromise or total loss of MFA
• Regional/cloud loss affecting multiple security controls
• Regulatory direction to preserve systems (coordinate legal)

Activation authority: BCM lead + IR commander + designated executive (document in BCP).

Recovery sequencing

Default security-first order for cyber events:

1. Stabilize command — incident bridge, roles, comms cadence (incident-responder) 2. Network isolation — stop spread; preserve evidence paths 3. Identity — break-glass, disable compromised paths, restore IdP 4. Secrets and keys — rotate after identity trust re-established 5. Logging and detection — SIEM/EDR before broad app restore (avoid blind recovery) 6. Critical apps — per business BIA, not security skill alone 7. Validate — hunt for persistence; compare to pre-incident baseline 8. Stand down DR — document RTA vs RTO; update register

Parallel tracks: comms (communication-lead), legal/regulatory prep (compliance/legal).

Metrics and reporting

Track quarterly:

Report trends to leadership and feed cybersecurity / compliance-specialist program reviews.

Tabletop exercises and governance

Table of contents

1. Governance model 2. Policy and plan artifacts 3. Exercise types 4. Designing a tabletop 5. Scenarios and injects 6. Facilitation and scoring 7. After-action and tracking 8. Regulatory BCM (high level)

Governance model

Executive sponsor (CISO, CIO, or COO delegate) chairs steering; BCM lead runs day-to-day.

Integrate with risk register (security-risk-analyst) and GRC (compliance-specialist)—do not duplicate.

Policy and plan artifacts

Minimum document set:

Version control: annual review minimum; emergency revision after failed test or major incident.

Exercise types

Rotate cyber and availability scenarios—security BCM is not only ransomware.

Designing a tabletop

1. Define objectives (e.g., "validate IdP recovery order," "test exec comms cadence") 2. Select participants — BCM, IR, SRE, cloud ops, security eng, legal, comms, business owner 3. Choose scenario matched to tier-0 risks from BIA 4. Draft timeline and injects (see below) 5. Assign facilitator (BCM) and observer (records gaps, no heroics) 6. Schedule 90–120 min; pre-read one page max 7. Publish rules — no blame; hypotheticals unless using real sanitized incident

Scenarios and injects

Example scenarios

Inject pattern

Deliver injects every 15–25 min:

• "Backup team reports last clean copy is 72h old—impact?"
• "Legal asks whether to pause user communication—who decides?"
• "SOC cannot reach SIEM—document detection gap start time"
• "Executive demands restore production before identity fixed—response?"

Force decision points with named roles—not open discussion only.

Facilitation and scoring

Facilitator prompts:

• What is known vs assumed?
• Who has authority to activate DR?
• What is RTO clock start (declaration vs discovery)?
• Where are runbooks; are they reachable if IdP down?

Optional maturity scoring (1–5) per dimension:

• Roles and authority
• Technical runbooks
• Comms and stakeholders
• Backup/restore confidence
• Lessons incorporated since last exercise

After-action and tracking

Within 10 business days publish:

1. Executive summary — objectives met?, top 3 gaps 2. Gap register — ID, description, owner, priority, due date 3. Plan updates — which BCP/DRP sections change 4. Test calendar changes — added restore tests?

Track gaps in same system as audit findings or risk register. Close loop in next steering meeting.

Major gap (no tier-0 workaround): escalate to cybersecurity and executive sponsor.

Regulatory BCM (high level)

Map program to frameworks without legal interpretation:

Use compliance-specialist for framework scoping; compliance-engineer for evidence automation. This skill produces plans, tests, and exercise records that satisfy many control narratives—legal/compliance confirms applicability.

Disclaimer: Regulatory text and filing obligations require qualified legal/compliance review—not provided here.