CCRTS cheat sheet

Cyber resilience = anticipate + withstand + recover + adapt; measure it as reduced downtime and data loss, not as control counts.

Core governance artifacts: resilience policy, risk appetite statement, RACI across business/IT/security, and board-level reporting cadence.

Risk formula: risk = likelihood × impact; treat residual risk after controls as the number the business formally accepts.

Qualitative scale example: 5×5 matrix where impact 4 = >$1M or regulatory notification, impact 5 = life-safety or insolvency.

Tier systems by criticality: Tier 1 (RTO ≤ 4h, mission-critical), Tier 2 (RTO 4–24h), Tier 3 (RTO > 24h); controls and test frequency scale with tier.

Regulatory mapping: financial sector often cites FFIEC and DORA; healthcare HIPAA Security Rule; payments PCI DSS; EU-wide NIS2.

Resilience maturity model stages: ad hoc → repeatable → defined → managed → optimized; evidence of testing is the usual gating criterion.

Board reporting should include top residual risks, test results, open corrective actions with owners and due dates, and trend over time.

RTO = maximum tolerable downtime before impact becomes unacceptable; MTD is the outer limit and RTO must be ≤ MTD.

RPO = maximum tolerable data loss measured in time; it drives backup frequency and replication mode (sync vs async).

WRT (work recovery time) = time to verify and resume business processing after systems are restored; RTO = technical recovery + WRT.

BIA inputs: process inventory, upstream/downstream dependencies, peak-period volumes, revenue per hour of outage, regulatory deadlines.

Impact dimensions to score: financial, operational, legal/regulatory, reputational, safety; record the worst credible case per process.

Dependency mapping must include identity providers, DNS, network, and SaaS APIs - outages often come from shared dependencies, not the app.

Tiering rule: a process inheriting a Tier 1 dependency cannot be Tier 2; the strictest upstream RTO governs.

BIA refresh triggers: major architecture change, M&A, new regulation, or a real incident that disproves assumed RTO/RPO.

3-2-1-1-0 rule: 3 copies, 2 media types, 1 offsite/offline, 1 immutable or air-gapped, 0 errors verified by restore testing.

Backup types: full, incremental (changed since last backup of any type), differential (changed since last full); synthetic full merges incrementals.

Immutability options: object lock in compliance mode (cannot be deleted before retention expires, even by admins) vs governance mode (privileged override).

Air gap = physically or logically disconnected copy; offline tape or a vault with no standing network path defeats ransomware encryption of backups.

Replication is not backup: synchronous replication copies corruption and deletions instantly; async replication bounds data loss to the lag window.

Encryption: encrypt at rest and in transit; keep backup encryption keys outside the backed-up environment so credential theft cannot decrypt archives.

Retention policy must satisfy legal hold and regulatory minimums; verify deletion actually occurs and is logged for audit.

Restore metrics to track: restore success rate, time to restore a single file, time to restore a full tier-1 system, and backup job failure rate.

NIST SP 800-61 lifecycle: preparation → detection and analysis → containment, eradication, recovery → post-incident activity.

Severity matrix example: SEV1 = confirmed data breach or Tier 1 outage; SEV2 = degraded Tier 1 or Tier 2 outage; SEV3 = contained, limited impact.

Crisis team roles: incident commander, communications lead, legal counsel, technical lead, scribe; the commander does not troubleshoot.

Escalation triggers: ransomware encryption, exfiltration evidence, safety impact, regulatory notification threshold, or media inquiry.

Notification clocks vary: GDPR 72 hours to the supervisory authority; contractual and sector rules may be shorter - pre-map them per jurisdiction.

Communications: pre-approved holding statements, single spokesperson, internal cadence (e.g., every 60 minutes), and a log of every external statement.

Evidence handling: preserve volatile data first, hash evidence, maintain chain of custody, and document every action with timestamps in UTC.

Stand up a separate out-of-band channel (phone bridge, secondary email) because attackers often control the primary collaboration tools.

DR plan contents: scope, activation authority, call trees, recovery runbooks by tier, dependency contacts, and return-to-normal criteria.

Recovery site models: cold (space and power only), warm (partial hardware, data restored on demand), hot (mirrored, near-instant failover).

Alternate operations: manual workarounds, paper procedures, alternate site or remote work, and temporary third-party capacity.

Plan must state who can declare a disaster and the objective triggers, e.g., site unavailable > 4 hours or Tier 1 RTO at risk.

Runbooks should be step-by-step with expected outputs and verification checks, not narrative descriptions of architecture.

Maintain a manual contact roster off-network; assume email, SSO, and the intranet are unavailable during activation.

Failover is not complete until business processing resumes; require business-side sign-off, not just IT system availability.

Return-to-normal plan: data reconciliation between sites, reverse replication, and a defined reconciliation window before decommissioning the alternate.

Attack chain: initial access (phishing, exposed VPN/RDP, vulnerable edge device) → credential theft → privilege escalation → lateral movement → staging → exfiltration → encryption.

Double extortion = encryption plus threatened release of stolen data; paying does not guarantee deletion, so assume exfiltrated data is public.

Destructive attacks (wiper malware) target backups, hypervisors, and identity systems first; protect the recovery plane as a Tier 0 asset.

Detection signals: mass file rename or entropy spike, backup deletion or retention-policy changes, disabled security tooling, unusual privileged logons.

Containment decisions: isolate segments, disable compromised accounts, revoke sessions and tokens, and rotate credentials from a clean environment.

Recovery sequencing: rebuild identity and core network first, restore from verified immutable copies, scan before reconnection, then restore business apps by tier.

Decryption tooling is unreliable for modern variants; plan for restore-from-backup as the primary recovery path, not decryption.

Sanction and legal considerations: paying ransom may violate sanctions law in some jurisdictions; involve counsel before any payment decision.

Third-party risk tiers by data sensitivity and operational criticality; require evidence such as SOC 2 Type II, ISO 27001, or equivalent attestations.

Contract clauses that matter for resilience: RTO/RPO commitments, notification timelines, audit rights, data return and deletion, subprocessor disclosure.

Concentration risk: identify single providers or shared dependencies (one cloud region, one DNS provider, one identity provider) that could fail simultaneously.

Shared responsibility: cloud provider secures the cloud; the customer secures what runs in it - backups, identity configuration, and data classification remain customer duties.

Cloud resilience controls: multi-AZ by default, cross-region replication for Tier 1, tested restore from provider-native backup vaults.

Fourth-party risk = your vendor's vendors; request subprocessor lists and assess the critical ones, not just the prime contractor.

Exit strategy: documented data export formats, transition assistance obligations, and a tested ability to migrate within the contract term.

Continuous monitoring: track vendor security ratings, breach disclosures, and SLA performance; reassess on renewal or material change.

Test types in ascending rigor: plan review, tabletop, walkthrough, simulation, parallel test, full failover, and full interruption test.

Tabletop exercise design: scenario, injects, participants with defined roles, stated objectives, and a hot-wash debrief immediately after.

Backup restore testing should be scheduled and sampled: restore random files weekly and a full Tier 1 system at least quarterly.

Test in production with safeguards only under change control; define abort criteria and a rollback path before starting.

Metrics to capture: actual RTO vs target, actual RPO vs target, number of plan gaps found, corrective actions opened and closed.

Corrective action tracking needs an owner, due date, and verification; a finding closed without a re-test is not closed.

Test frequency should scale with tier and change rate; a Tier 1 system with quarterly releases warrants at least annual full failover.

Regulatory and audit drivers may mandate exercise frequency and evidence retention - keep dated after-action reports as proof.

Recovery validation criteria: data integrity checks (record counts, checksums), application function tests, and business-process sign-off.

Forensic order of volatility: CPU registers and cache → memory → network state → disk → remote logs → archival media.

Chain of custody: unique evidence ID, collector identity, date/time in UTC, hash (SHA-256) at acquisition and at each transfer.

Forensic soundness: use write blockers and image copies; work from the copy, preserve the original unmodified.

Post-incident review (PIR) is blameless: focus on control gaps and timeline facts, not individual fault; produce a dated report.

PIR content: timeline, root cause and contributing factors, what worked, what failed, metrics vs targets, and prioritized corrective actions.

Lessons learned must feed back into the BIA, DR plan, and control set; otherwise the same failure recurs.

Retain logs and evidence per legal and regulatory retention rules; confirm log integrity (immutable storage, time sync) before an incident occurs.