Plan a publication backup-and-restore drill that proves recovery

Define recovery before choosing a backup

List the services needed to publish and serve a minimal usable site: content database, media originals, themes or application code, configuration, redirects, DNS records, certificates, forms, feeds, member and suppression state, access roles, analytics configuration, ad tags, and runbooks. Give each asset a source of truth, owner, backup method, retention, encryption control, and dependency. An exported content file may be valuable while still being insufficient to operate the publication.

Set internal recovery point and recovery time objectives as business targets. The recovery point describes acceptable data loss; recovery time describes acceptable restoration time. NIST contingency guidance frames recovery planning and testing as connected activities. The appropriate targets depend on the publisher's obligations and architecture, so record who approved them rather than copying another organization's numbers.

Source notes: Contingency Planning Guide for Federal Information Systems · Automatic backups

Design an isolated drill with stop conditions

Restore into a sterile account, network, domain, and database where possible. Use separate credentials, block outbound email and payments, disable production ad calls, and prevent search indexing. Give the drill leader authority to stop if a test system contacts readers, writes to production, exposes personal data, or consumes an irreplaceable backup. Record the exact recovery point selected and why.

Use a scenario that can fail honestly: loss of the publishing database plus inaccessible primary media storage, for example. Provide the runbook and backup catalog but do not give operators undocumented shortcuts. CISA recommends tested backup procedures and protected backups in its ransomware guidance. A successful file download alone is not a restore test; the drill must reconstruct a service and validate it.

• Approve scope, data handling, and stop authority.
• Isolate domain, credentials, email, payment, ads, and indexing.
• Select a dated recovery point without altering it.
• Log commands, decisions, blockers, and elapsed time.
• Never test by deleting or overwriting the only production copy.

Source notes: #StopRansomware Guide

Restore in dependency order and verify reader tasks

Recover foundations first: infrastructure and secrets references, application and schema, content, media, routing, then integrations. Compare record counts and checksums where appropriate, but also inspect pages as a reader and editor. Test canonical URLs, images, navigation, accessibility landmarks, feeds, search, login with test accounts, forms routed to a sink, redirects, and a draft-to-publish workflow in the isolated environment.

Hypothetically, a target allows four hours of recovery and up to one hour of data loss. The selected backup is 45 minutes before the scenario, and a usable read-only site is restored in three hours 20 minutes. That would meet those two illustrative targets, but the drill can still fail if suppression data is missing, media is corrupt, or the team relied on an unrecorded credential. Grade every acceptance criterion separately.

Hypothetical results demonstrate that a drill is not one pass/fail number.

Source notes: Contingency Planning Guide for Federal Information Systems

Close the drill with evidence and a retest

Archive the scenario, participants, timestamps, backup identifiers, environment diagram, runbook version, results, screenshots or logs, data-handling confirmation, and every workaround. For each gap, name an owner, fix, due date, and retest case. Rotate temporary credentials and destroy the test environment according to the approved retention plan after evidence is preserved.

Do not publish 'recovery tested' if only a tabletop discussion or partial export check occurred. State exactly what was restored and validated. Schedule another bounded drill after material architecture or vendor changes and after high-severity failures are fixed. This guide is itself a plan; it makes no claim that a drill has been performed for this publication.

Source notes: #StopRansomware Guide · Automatic backups