Define what “the website” includes
Start with a service inventory. For every site, portal, store, or campaign, record the business owner, technical owner, hosting account, domain and DNS control, repository, content and media stores, integrations, and essential credentials. Mark what can be rebuilt from version control and what holds unique records.
Include configuration deliberately: redirects, CDN or firewall settings, scheduled jobs, templates, and infrastructure-as-code files. Do not copy live secrets into a general manifest; point instead to the approved secrets system and emergency-access process. WordPress documentation shows the common gap: a typical site needs both its files and a separate database.
Define the smallest safe version that can provide essential information or transactions.
Give compatible database, files, media, and configuration exports one timestamp or version label.
Set frequency and retention from business tolerance
Choose frequency from the rate and value of change. Write the RPO in plain language, then check that every unique store is captured often enough. A nightly file copy cannot meet a four-hour RPO for a rapidly changing database.
Set the RTO separately. Include approval, clean infrastructure, restoration, validation, traffic changes, and internal communication. Measure it in a drill rather than adopting a vendor claim. Retain older points long enough to reach before an error or delayed discovery, then review retention with privacy, records, or legal specialists where data requires it.
Compare the interval between complete recovery points with each service’s RPO.
Verify an authorized person can find an older approved restore point.
Separate and protect recovery copies
Use multiple copies in different locations or services so one account, local event, or mistake does not remove every option. CISA recommends regular automated backups, an off-site copy, encryption, and offline copies. NCSC advises against permanently connected backup devices and recommends more than one backup solution or location.
Protect backup administration with least privilege, multi-factor authentication where supported, distinct admin accounts, and access reviews. Use deletion protection, version history, or immutable storage only after understanding its cost and recovery behavior. Encrypt stored data and test key custody. Encryption without reachable keys is unusable; broadly shared access weakens every copy.
The copy should have a meaningfully different failure mode from production.
List who can read, change, delete, and restore backups; remove stale access.
Write a recovery runbook and assign authority
A runbook is the tested recovery procedure. Keep a copy reachable without the affected site, production identity provider, or normal chat system. Include contacts and alternates, authority, system priority, backup locations, prerequisites, restore order, validation checks, and stop conditions.
Name an accountable recovery owner and alternate for each critical service. Define who authorizes production restoration, DNS changes, and business-data validation. If payment-card data, sensitive personal data, or regulated records are involved, get qualified security, privacy, legal, and where relevant PCI review before deciding what to preserve, notify, or restore.
Record the chosen restore point, approving person, systems touched, validation result, and exceptions.
Document controlled emergency access; never rely on one employee’s device or memory.
Restore safely after a suspected compromise
Do not automatically overwrite production with the newest copy when unauthorized access, malware, or suspicious deletion is possible. Follow the incident process, assess which accounts and backups may be affected, select a point from evidence, and rebuild or isolate the recovery environment before reconnecting it.
CISA directs recovery in critical-service priority order and warns against reinfecting clean systems. NCSC recommends connecting backups only to known-clean devices and scanning them before restoration. These steps reduce risk, not guarantee cleanliness. Escalate to qualified incident-response help when investigation, evidence preservation, or notification duties may apply.
Restore the highest-priority service on clean infrastructure, validate it, then continue by dependency order.
Check user journeys, data, jobs, integrations, administration, logging, and new backup coverage.
Use drills as proof and remediation input
Run partial restores, isolated full rebuilds, dependency-loss exercises, or tabletop decisions according to risk. Start with a safe, meaningful test and increase realism over time. CISA recommends full and partial restore tests; NCSC recommends exercises to clarify roles, third-party responsibilities, and priorities.
Measure recovery-point age against the RPO and elapsed recovery time against the RTO. Record the set identifier, participants, validation result, failed steps, and an owner for each fix. Retest after closing gaps and after material platform, identity, database, or provider changes. SIU can organize this preventative remediation work; it is not a backup system or live monitoring service.
Keep a concise record of what was restored, where, what passed, what failed, and who accepted it.
Repeat focused testing after material architecture or supplier changes.