Government website backup checklist: prove recovery works

A government website backup checklist should establish what can be recovered, how much recent work could be lost and how long restoration takes. Ask the provider to restore a copy in a protected test environment, then have staff check the tasks residents depend on. Save the results with the website contract.

For a township or village manager, the useful evidence is specific: last week's meeting packet opens, an older ordinance can be found, and an authorized employee can publish a correction. A report saying "backup completed" leaves those questions unanswered.

What should the website backup include?

Start with an inventory of the community's website and the services it uses. Ask the provider to identify the recovery method for each item, including anything excluded from its contract.

New Zealand's National Cyber Security Centre recommends identifying data owners and covering the systems and data sets an organization holds (opens in a new tab). For a municipal website, that means checking beyond the files visible on the home page.

A link to a payment provider does not put that provider's transaction records inside the website backup. Record that boundary. Staff should know which organization to call when the website loads but the payment service does not.

How much recent work can the office afford to lose?

Set a recovery point objective, or RPO, with the provider. NIST defines RPO (opens in a new tab) as the point in time to which data must be recovered after an outage. In a contract discussion, ask how much recent content or submitted information could need to be recreated.

Consider a hypothetical example. The last usable backup finished at 2 a.m. Staff upload a revised meeting packet at 10 a.m., and the website fails at noon. Restoring that backup brings back the earlier version. The recovery process needs to identify and republish the revision.

A saved copy of the packet helps staff do that. Resident submissions received during the same gap might be much harder to reconstruct. Set objectives for each kind of information rather than assuming one nightly backup suits every function.

Ask how failed or incomplete backups are reported. A schedule describes the intended work; the provider should also show when the last usable copy was created.

How long can residents wait for service to return?

Set a recovery time objective, or RTO: the target recovery period before the interruption harms the work the system supports. NIST's RTO definition (opens in a new tab) connects recovery time to the organization's operations.

Have the provider spell out when its recovery clock starts and stops. Does the estimate include reaching support after hours, obtaining a backup, rebuilding the website and checking that it works? Does it depend on access to a domain account held by someone who has left?

Use the exercise to measure the actual elapsed time. Record delays as well as the time spent copying files. Staff review is part of deciding whether the restored website is ready for residents.

Choose a separate communication method for an outage, with an assigned person who can post a service update. Keep a protected offline copy of response contacts and instructions so staff can reach them when the website or office email is unavailable.

Could the same incident destroy the backups?

Ask how backup copies are protected from the accounts and systems used to run the live website. A copy that an attacker can erase with the same stolen credentials leaves an obvious recovery risk.

CISA's StopRansomware guide (opens in a new tab) recommends offline, encrypted backups and regular tests of their availability and integrity. It warns that ransomware can delete or encrypt accessible copies. CISA also discusses immutable cloud storage, which restricts changes or deletion, and cautions that its configuration matters.

Have the provider explain the protection in its actual setup. Who can delete a backup? How are recovery credentials and encryption keys protected and made available to authorized responders? How long are older copies kept if a problem is discovered weeks later? A backup retention period answers how far back restoration can go; review public records retention separately with the staff responsible for those records.

Avoid accepting "stored in the cloud" as the whole answer. Ask what remains recoverable if the live hosting account becomes unavailable or compromised.

What should a government website recovery test prove?

Request a restore into an isolated, access-controlled test environment. The provider should prevent it from sending real alerts, charging payments or exposing private submissions. Use approved test data for form checks. Keep the live website serving residents while the exercise runs.

Choose the backup and test items before the exercise. Include a recent document, an older archive item and a form the office depends on. A successful home page load is only the first check.

Keep the report short enough for the manager to review. It should name the tester and date, say which checks passed, and assign each failure an owner and retest date. A screenshot can support a result, but should not expose private information or credentials.

The New Zealand NCSC's backup testing guidance (opens in a new tab) recommends testing different recovery scenarios, including individual files and applications with their databases. The worksheet above applies that approach to municipal website tasks. Agree on a recurring test schedule and repeat affected checks after substantial changes.

What changes when the outage follows a cyberattack?

Bring in the incident responder before treating restoration as permission to reopen the website. CISA's guide calls for investigating compromise, rebuilding clean systems and addressing vulnerabilities. It also warns against reinfecting systems during recovery.

The responder needs to assess which copies are suitable and preserve evidence. Restoring an older version will not recall data an attacker has already taken. The documented government WordPress attacks illustrate why recovery and investigation need separate attention.

Routine restore exercises should establish who makes that decision during an incident. Staff should have a named contact, an alternate and a way to reach them outside the affected systems.

What should the board ask before renewing the contract?

Request the recovery report before the renewal discussion. Ask the provider to put backup coverage, retention periods, restoration fees and support responsibilities in writing. Confirm how the municipality can obtain its content if the relationship ends.

Muniway includes hosting, backups and software updates in its municipal website service. Ask us, or any prospective provider, to explain the recovery arrangements for the proposed website and its connected services.

If the current arrangement has never been tested, start by scheduling the exercise. Give staff a small set of real website tasks to check and bring the unresolved failures to the contract discussion.