Ransomware Readiness Before an Incident Begins

A team can have a backup plan, a provider-responsibility record, a restore-test result, and an incident-role matrix while still carrying important unknowns between them. Evidence in separate records does not automatically show that the combined dependencies would remain usable during ransomware.

This guide helps a 1–50-person team assemble a restrained evidence map before an incident begins. The title phrase Before an Incident Begins means preparation only. If ransomware or another incident is suspected, stop this workflow and use separately authorized qualified response. This guide does not determine whether an incident exists or authorize any response action.

What the sources support — and what PlainFort adds

CISA’s current #StopRansomware Guide and March 2025 PDF support maintaining offline encrypted backups, regularly testing backup availability and integrity, exercising an incident-response and communications plan, and prioritizing restoration around critical services. The same document also contains a live response checklist. This article uses only its preparation statements and does not reproduce that checklist or convert it into action steps.

NCSC’s small-business incident-preparation guidance supports identifying essential information and critical processes, assigning roles and backup coverage, exercising plans, and documenting trigger points.

Those documented statements support the preparation categories in this guide. The fourteen concepts, eight stages, eleven states, evidence threshold, handoff model, 18 fields, tabletop method, completion boundary, and review triggers are PlainFort editorial judgment. They are not CISA or NCSC requirements, a ransomware-response standard, legal or insurance advice, forensic guidance, certification, compliance evidence, a universal plan, or a guarantee.

Keep fourteen readiness concepts separate

1. Pre-incident boundary and stop trigger: a preparation scope that ends immediately when ransomware or another live incident is suspected.
2. Business scope and critical-capability reference: the bounded capability and dependency context consumed from BR-21, not a new inventory or risk score.
3. Internal accountability, genuine backup, and escalation authority: category-level ownership without proof of availability, competence, access, independence, or authority during an incident.
4. BR-21 recoverability evidence: business objectives, dependencies, and restore-order evidence, not a redesigned strategy or proof of achievable recovery.
5. BR-25 provider/customer evidence: the dated responsibility boundary, not an inference about a provider, plan, tenant, contract, or recovery behavior.
6. BR-22 restore-test evidence: one bounded inspected or reported result with its limitations, not a new test or proof that every recovery path works.
7. BR-24 role-matrix evidence: accountability, authority, coordination, communications, deputies, and handoffs, not activation of a team or contact with anyone.
8. Identity, MFA, and administrator dependency: an inert dependency category and AA-07/AA-08 handoff, not method selection, enrollment, recovery, privilege change, or account access.
9. Device, network, and location dependency: category-level DN-16/DN-20 evidence and trigger handoffs, not inspection, configuration, tracking, isolation, or remote-work approval.
10. Backup separation and protection evidence: a dated evidence category, not inspection of storage, cleanliness, immutability, encryption material, or recovery media.
11. Safe communications and continuity category: an approved communication and continuity category without contacts, messages, channels, workarounds, or claims that it will remain usable.
12. Qualified technical, forensic, and external-decision handoffs: stop categories for specialist, legal, privacy, records, insurance, law-enforcement, notification, negotiation, and payment questions.
13. Evidence state, unresolved gap, exception, and residual risk: calibrated truth about what was inspected, merely reported, unknown, blocked, deferred, exceptional, or stale.
14. Tabletop-only evidence, completion boundary, escalation, and review: non-live review evidence and change triggers, not proof of readiness or a rehearsal plausible enough to be live response.

Do not collapse these concepts into one Ransomware ready, Covered, Backed up, Tested, Protected, Secure, Compliant, Recoverable, or Complete checkbox. A strong state in one concept cannot silently compensate for a reported-only, unknown, blocked, deferred, exception, sibling-decision-required, or qualified-review state elsewhere.

Use evidence states, not a readiness score

Use exactly these states:

• Documented — dated evidence referenced
• Reported — evidence not inspected
• BR-21 decision required
• BR-25 decision required
• BR-22 test required
• BR-24 role decision required
• Unknown — follow up through approved route
• Blocked — qualified help required
• Deferred — owner and review trigger required
• Exception — scope, reason, owner, expiry or exit condition required
• Qualified review required

These states show preparation and evidence position, not ransomware likelihood, a security score, maturity, severity, incident status, recovery grade, compliance, insurance fitness, or a guarantee. Documented — dated evidence referenced does not mean clean, current, complete, available during an incident, or sufficient for safe recovery. Do not hide, average, weight, or convert a state into an overall readiness result.

The eight-stage PlainFort process

The following sequence is an editorial method. It does not authorize ransomware investigation, backup inspection, evidence work, account or device access, contact, recovery, negotiation, payment, or notification.

1. Set the pre-incident boundary and stop trigger

Define one category-level business scope and state that the worksheet applies only before an incident is suspected. Record the internal accountable owner, a genuine backup, and an escalation role as categories. Do not record names, contact details, systems, locations, schedules, or response instructions.

If ransomware or another incident is suspected or active, stop. Do not use this guide to confirm the suspicion, inspect a device or backup, collect evidence, contact anyone, or decide what happens next.

2. Consume the four BR records without reopening them

Reference the approved records rather than copying their contents:

• BR-21 owns business recoverability strategy, objectives, dependencies, and restore order. This guide consumes its evidence without redesigning or validating the strategy.
• BR-25 owns provider/customer SaaS responsibility. This guide consumes dated responsibility evidence without inferring provider behavior, contract meaning, or recovery capability.
• BR-22 owns one bounded restore-test plan and result. This guide consumes the result and limitations without planning, executing, or generalizing a test.
• BR-24 owns general incident roles and communications. This guide consumes role-matrix evidence without activating roles, assigning people, contacting anyone, or reproducing the matrix.

Preserve every unknown, blocker, exception, limitation, and review trigger. Evidence does not become readiness by aggregation. BR-21 evidence does not prove that a method can meet an objective; BR-25 evidence does not prove a provider will restore the workflow; BR-22 evidence does not prove backup cleanliness or every recovery path; and BR-24 evidence does not prove that roles will be unaffected, available, authorized, competent, independent, or safely reachable.

3. Map identity, administrator, device, network, and location dependencies

Record only inert dependency categories. AA-07 owns MFA-method choice, fallback, and recovery tradeoffs. AA-08 owns everyday and administrator account separation. A label for either decision does not show that an identity or administrator will remain usable.

DN-16 owns the laptop and device baseline. DN-20 owns the general remote-work baseline and consumes the bounded VPN-fit decision. This guide does not inspect or configure a device, approve remote work, choose a connection method, or infer that a device, network, or location is safe.

A suspected mailbox compromise belongs to EP-15, and a lost-or-stolen-device trigger belongs to DN-18. Either suspicion stops this preparation workflow. It does not become a ransomware action sequence here.

4. Check backup separation and protection evidence categories

Record a dated reference and the narrow statement it supports. Terms such as offline, encrypted, separated, immutable, tested, available, and integrity-checked must never be inferred from a product label, configuration report, prior result, provider statement, or assumption. If the applicable evidence has not been inspected, use Reported — evidence not inspected or a more restrictive state.

Do not inspect storage, backup contents, encryption material, recovery media, destinations, logs, or configurations. Do not prescribe a backup count, topology, isolation method, encryption design, schedule, retention period, or test frequency.

5. Check safe communications, continuity, and genuine coverage

Record an approved communication category and continuity or workaround category without copying routes or operational details. A normal channel may be unavailable or unsafe during an incident. A workaround may depend on the same identity, administrator, device, provider, or network being considered.

Naming an owner or deputy does not prove availability, authority, competence, independence, capacity, or safe contactability. Missing genuine coverage, a disputed owner, or an unavailable safe-channel category blocks completion and requires escalation.

6. Route technical, forensic, and external decisions

Keep qualified technical and forensic handoff separate from legal, privacy, records, insurance, law-enforcement, notification, negotiation, and payment stop categories. The map may show that a qualified decision is required; it cannot make the decision, recommend a contact, supply wording, or set a deadline.

Stop before privileged or destructive work, clean-backup determination, evidence preservation, legal hold, emergency communication, last-administrator action, only-recovery-path action, ransom handling, insurer or regulator engagement, notification, negotiation, payment, containment, eradication, restoration, or recovery ordering.

7. Exercise the evidence map without a live or plausible incident

Use a category-only tabletop review. Ask whether each evidence reference has an owner, whether each unresolved state remains visible, whether a genuine backup category exists, whether the stop trigger is understood, and whether the qualified-handoff categories are distinguishable.

Do not use a real account, mailbox, device, provider, system, contact, evidence item, backup, message, demand, or incident. Do not fabricate a scenario plausible enough to be treated as live response. The exercise tests only whether the preparation record can expose its own gaps.

8. Close only with visible gaps, residual risk, escalation, and review

Every field needs a truthful value or visible state. Record unresolved gaps, exceptions, residual risk, an accountable follow-up category, completion evidence, and a change-based review trigger. A missing sibling decision remains required; a blocker remains blocked.

Closing the map does not determine ransomware presence, absence, likelihood, scope, attribution, backup cleanliness, recoverability, legal duties, insurance coverage, or safe response order. It does not grant the label ransomware ready.

Minimum ransomware-readiness evidence map

Use this ordered vertical record with exactly 18 fields:

1. Bounded scenario and business scope: preparation-only category; no incident facts.
2. Internal accountable owner: role category; no identity or contact details.
3. Genuine backup and escalation role: coverage category and unresolved limitation.
4. BR-21 recoverability-map evidence: BR-21 evidence held in approved record — content not copied plus state.
5. BR-25 SaaS-responsibility evidence: inert reference, applicability, limitation, and state.
6. BR-22 restore-test evidence: bounded result reference, scope limitation, and state.
7. BR-24 role-matrix evidence: inert reference, coverage limitation, and state.
8. Critical access, MFA, and administrator dependency: category and AA-07/AA-08 handoff.
9. Device and network dependency: category and DN-16/DN-20 or trigger-specific handoff.
10. Safe communications category: Safe communication category recorded — details not copied plus limitation.
11. Backup separation and protection evidence category: Backup-protection evidence held in approved system — content not copied plus state.
12. Continuity or workaround category: dependency category, evidence state, and unproved assumption.
13. Qualified technical or forensic handoff: category only; no contact or procedure.
14. External-decision stop category: legal, privacy, records, insurance, law-enforcement, notification, negotiation, or payment review.
15. Current state and evidence reference: one approved state and inert dated reference.
16. Unresolved gap, exception, and residual risk: visible issue, owner category, and exit or review condition.
17. Tabletop-only exercise evidence: category-level record and explicit non-live limitation.
18. Escalation and review trigger: stop condition, accountable follow-up category, completion evidence, and change trigger.

This record is not a table, scorecard, dashboard, architecture, backup inventory, restore record, evidence repository, incident timeline, contact directory, response checklist, notification form, insurer record, negotiation worksheet, or activation form.

Fictional example — do not copy as a completed backup or recovery record

Example Co. is a non-operational label. The example contains no real or plausibly fabricated incident, provider, system, identity, contact, evidence content, backup location, response action, or recovery result.

1. Bounded scenario and business scope: one fictional business-capability category; preparation only.
2. Internal accountable owner: internal ownership category recorded; identity not created.
3. Genuine backup and escalation role: backup availability is unknown; Blocked — qualified help required.
4. BR-21 recoverability-map evidence: BR-21 evidence held in approved record — content not copied; Documented — dated evidence referenced.
5. BR-25 SaaS-responsibility evidence: responsibility decision unresolved; BR-25 decision required.
6. BR-22 restore-test evidence: reported result reference only; Reported — evidence not inspected.
7. BR-24 role-matrix evidence: inert role-matrix reference; one safe-channel limitation remains visible.
8. Critical access, MFA, and administrator dependency: category recorded; applicability requires follow-up through the approved AA route.
9. Device and network dependency: category recorded; no device, network, or location detail supplied.
10. Safe communications category: Safe communication category recorded — details not copied; availability unknown.
11. Backup separation and protection evidence category: Backup-protection evidence held in approved system — content not copied; scope not independently confirmed.
12. Continuity or workaround category: fictional category exists; dependency evidence remains unknown.
13. Qualified technical or forensic handoff: qualified-review category recorded; no person, provider, or procedure named.
14. External-decision stop category: legal, privacy, records, insurance, law-enforcement, notification, negotiation, and payment questions remain outside the guide.
15. Current state and evidence reference: Blocked — qualified help required; inert references only.
16. Unresolved gap, exception, and residual risk: genuine backup and safe-channel evidence are unresolved; no false completion.
17. Tabletop-only exercise evidence: category-only review reported; no incident or live system used.
18. Escalation and review trigger: accountable follow-up category must resolve the blocker and record completion evidence before a later review.

Stop before live response

Stop immediately when ransomware or another incident is suspected or active; a backup, provider, identity, administrator, device, network, or communication system may be affected; privileged or destructive action may occur; an owner or genuine deputy is unavailable; a safe channel is unavailable; evidence would need to be collected, copied, preserved, inspected, analyzed, transferred, or disclosed; sensitive or regulated data may be involved; a financial demand appears; or a legal, privacy, records, insurance, contractual, law-enforcement, notification, negotiation, payment, forensic, containment, eradication, recovery, or external-contact judgment is required.

This guide does not investigate, triage, isolate, contain, eradicate, recover, restore, reconnect, reset, revoke, change an account or privilege, act on a device, preserve or collect evidence, perform forensics, negotiate, pay, notify, communicate publicly, contact a provider, insurer, regulator, or law-enforcement body, or make a legal determination. Those are separately authorized qualified-response matters.

Review when evidence or dependencies change

Review the map when any sibling record, provider/customer boundary, restore-test result, role or deputy category, access or administrator dependency, device or network dependency, communication category, continuity assumption, official source, external obligation, or qualified-handoff category changes. Preserve prior limitations and unresolved states; do not rewrite them into readiness after the fact.