---
title: Business continuity and disaster recovery for websites
description: "Set RTO and RPO per service, convert uptime into hours and require a tested restore: business continuity and disaster recovery for public sector sites."
image: https://insights.axistwelve.com/hubfs/business-continuity-disaster-recovery.png
---

[Skip to content](https://insights.axistwelve.com/business-continuity-and-disaster-recovery-for-websites#main-content)

[![a12-logo-black](https://insights.axistwelve.com/hubfs/a12-logo-black.svg)](https://www.axistwelve.com/)

- [Contact us](https://www.axistwelve.com/contact-us)
- [Work](https://www.axistwelve.com/our-work)

Open main navigation

Close main navigation

- [Contact us](https://www.axistwelve.com/contact-us)
- [Work](https://www.axistwelve.com/our-work)
- [More insights](https://insights.axistwelve.com/)

[More insights](https://insights.axistwelve.com/)

 Oct 5, 2026, 11:00:01 AM

# Business continuity and disaster recovery for websites

[Axistwelve](https://insights.axistwelve.com/author/axistwelve)

Share: [facebook-f icon](http://www.facebook.com/share.php?u=https://insights.axistwelve.com/business-continuity-and-disaster-recovery-for-websites) [linkedin-in icon](http://www.linkedin.com/shareArticle?mini=true&url=https://insights.axistwelve.com/business-continuity-and-disaster-recovery-for-websites) [Twitter icon](https://twitter.com/intent/tweet?url=https://insights.axistwelve.com/business-continuity-and-disaster-recovery-for-websites) [pinterest-p icon](http://pinterest.com/pin/create/link/?url=https://insights.axistwelve.com/business-continuity-and-disaster-recovery-for-websites) [envelope icon](mailto:?body=https://insights.axistwelve.com/business-continuity-and-disaster-recovery-for-websites)

Business continuity and disaster recovery for a public sector website start with two targets the organisation sets for each service: how long it can be unavailable, and how much recent data it can afford to lose. The contract then needs dated evidence that the supplier has restored the site within both.

Public sector website tenders commonly ask for an uptime percentage and a backup schedule, and score the answer inside the hosting section. Neither figure says how quickly the site comes back after a ransomware attack or a failed upgrade, or whether the backups restore at all.

## What do RTO and RPO mean for a public sector website?

A [recovery time objective](https://csrc.nist.gov/glossary/term/recovery_time_objective), or RTO, is the longest a website can stay in recovery before the outage starts to harm the organisation’s work. NIST defines a recovery point objective, or RPO, as [“the point in time to which data must be recovered after an outage”](https://csrc.nist.gov/glossary/term/recovery_point_objective). Both definitions come from NIST SP 800-34 Rev. 1, published by the US federal standards body.

A page of reference information, such as a published policy or a set of opening hours, changes rarely. The GOV.UK Service Manual describes ways to keep a service partly working, including to [“introduce a read-only mode where users can look at information but not change it”](https://www.gov.uk/service-manual/technology/uptime-and-availability-keeping-your-service-online). A copy of that page from yesterday loses nothing of value, so an illustrative target might be an RTO of four hours and an RPO of 24 hours.

An online application form is a different case. Every submission lost between the last backup and the failure belongs to someone who believes they applied, and nobody may notice until they chase it. As an illustration, that form might justify an RPO of 15 minutes, while an RTO of eight hours could be acceptable if the page says plainly that the form is unavailable.

Set the targets per service tier from what the organisation and its users would lose, and write them into the tender.

## How much downtime does 99.9% uptime allow?

A 99.9% uptime target allows 43 minutes 12 seconds of downtime in a 30-day month, or 8 hours 45 minutes 36 seconds across a 365-day year. The table converts other common figures the same way, using a month of 720 hours and a year of 8,760 hours.

| Uptime | Permitted downtime, 30-day month | Permitted downtime, 365-day year |
| --- | --- | --- |
| 99.0% | 7 h 12 min | 3 days 15 h 36 min |
| 99.5% | 3 h 36 min | 1 day 19 h 48 min |
| 99.9% | 43 min 12 s | 8 h 45 min 36 s |
| 99.95% | 21 min 36 s | 4 h 22 min 48 s |
| 99.99% | 4 min 19 s | 52 min 34 s |

A monthly target resets each month, so a site can lose 43 minutes in every month of the year and still comply. An annual target at the same percentage lets the full 8 hours 45 minutes arrive as one outage.

The Service Manual’s [uptime and availability guidance](https://www.gov.uk/service-manual/technology/uptime-and-availability-keeping-your-service-online), published in May 2016, warns that “a service could claim 100% uptime even though it shuts down every Monday evening for maintenance”, and says “You should not hide uptime problems behind multiple maintenance periods.” An SLA that excludes planned maintenance permits more real downtime than the table shows. Ask any supplier how planned maintenance is counted against the uptime figure, and when the windows fall.

The same page notes that suppliers “may offer you money or service credits as compensation” and asks buyers to consider whether that “really offsets the effect of the downtime on your users”.

## An uptime SLA says nothing about getting the site back

An SLA sets a ceiling on downtime and a penalty for going over it. A disaster recovery plan describes how the service returns: in what order, from which backup, on whose decision and against which target. [Point 14 of the Service Standard](https://www.gov.uk/service-manual/service-standard/point-14-operate-a-reliable-service), last updated in January 2026, asks teams to “Minimise service downtime and have a plan to deal with it when it does happen”, because “If a service is unavailable or slow, it can mean those users are unable to get the help they need.”

The Service Manual says “You should understand your dependencies and their dependencies”. In our view, for most websites that list includes the domain name records, the certificates, any forms or search tool plugged into the site, and any payment or identity service it calls. For our own private cloud, the list starts with The Bunker’s data centres in Kent and Newbury, both former military sites.

## What should a website backup include?

A website backup should include everything needed to rebuild the live site on new infrastructure, and that is much more than the database. The NCSC’s small organisations guide to [backing up your data](https://www.ncsc.gov.uk/collection/small-organisations-guide-to-cyber-security/backing-up-your-data) names “your website” among the things to back up. In our view a usable backup also covers the application code, server and platform configuration, uploaded media and documents, DNS records, TLS certificates and the credentials needed to run them.

The NCSC’s [principles for ransomware-resistant cloud backups](https://www.ncsc.gov.uk/collection/ransomware-resistant-backups/principles-for-ransomware-resistant-cloud-backups) say keys used to encrypt data at rest “should therefore be protected, to make sure that backup data can be decrypted when necessary”.

NCSC guidance on [mitigating malware and ransomware attacks](https://www.ncsc.gov.uk/guidance/mitigating-malware-and-ransomware-attacks) advises offline backups kept “in a different location (ideally offsite)” from networks and systems, or “in a cloud service designed for this purpose”, because “ransomware actively targets backups to increase the likelihood of payment”. It also warns against relying on “multiple copies in a single cloud service”. An [NCSC blog from 2019](https://www.ncsc.gov.uk/blog-post/offline-backups-in-an-online-world) gives the 3-2-1 rule as “at least 3 copies, on 2 devices, and 1 offsite”.

The same ransomware guidance says to scan backups before restoring, since ransomware “may have infiltrated your network over a period of time, and replicated to backups before being discovered”. Retention should therefore be written as a time period. The cloud backup principles recommend storing backups “according to a fixed time period, rather than a fixed number of backups”, and give the example of keeping “daily backups for a month, and monthly backups for a year”.

## How should disaster recovery testing work, and what proves it?

Disaster recovery testing proves that a backup can rebuild the service within its targets, and a dated record of a restore that actually happened is the only evidence of it. The NCSC ransomware guidance tells organisations to “regularly test that it is working as expected”, and the cloud backup principles say system owners “should monitor and test the state of their backups regularly”.

A restore test is the core of it: rebuild the site from backup into a clean environment and time the whole process. Where the contract includes standby infrastructure, a failover exercise moves traffic across and back. People need rehearsal as well, and the NCSC’s free [Exercise in a Box](https://www.ncsc.gov.uk/section/exercise-in-a-box/overview) includes “Table-top group discussion exercises” for working through a cyber incident as a group. Exercising an incident management plan, the ransomware guidance says, helps “clarify the roles and responsibilities of staff and third parties”.

After a restore test, the report worth asking for records:

- the date and who carried out the test
- what was restored, including code, configuration and media, and into which environment
- the measured time from starting the restore to a working site, against the RTO
- the point in time the restored data reached, against the RPO
- anything that failed or needed manual work, and what was changed as a result
- RTO and RPO for each service tier, set by the organisation, with the supplier showing how its hosting meets them
- a written disaster recovery plan covering restore order, dependencies and the backup each service is rebuilt from
- a restore test with a written report before go-live, then at an interval the contract states
- backup retention as a time period, where each copy is held, and how copies are kept separate from the live hosting
- who can declare a disaster, and how the organisation is told
- communication during an outage, including a status page, since the Service Manual says “You should have a status page you can update when there’s downtime you did not anticipate”
- continuity if the supplier is the incident, including the organisation’s independent access to backups
- how planned maintenance is counted against the uptime figure

None of the NCSC or GOV.UK pages cited here sets a frequency; NCSC says “regularly”. We recommend a full restore test before go-live and at least once a year after that.

## When the supplier is the incident

The supplier can itself be the cause of an outage, if the people who run the hosting are unavailable or the company fails. The Service Manual advises teams to “avoid single points of failure (eg having only one vendor could be a single point of failure)”.

Write the contract so the organisation can reach its own backups without the supplier. The NCSC cloud backup principles describe customer access to the backup service “even if all existing corporate IT systems and assets are unavailable”. For a website, the equivalent in our view is a recent copy of the site held somewhere the organisation controls, with the credentials and domain name control needed to bring it up elsewhere. The NCSC also asks organisations to plan for when “onsite systems and cloud backup servers are unusable, and you need to rebuild from offline backups”.

Check that more than one named person at the supplier can run a restore, and that the plan says what happens if none of them is available. Keeping the organisation’s own route to its site is also part of [avoiding vendor lock-in on a public sector website](https://insights.axistwelve.com/avoiding-vendor-lock-in-public-sector-website).

## Writing business continuity and disaster recovery into the tender

Public sector website tenders commonly ask suppliers to describe their backup and disaster recovery arrangements, or to set out a disaster recovery strategy and the infrastructure behind it. Those questions invite a description. A requirement that produces comparable, testable answers asks for:

Point 14 also asks teams to “actively work towards fixing any organisational or contractual issues which make it difficult to maximise availability”, and at tender stage the terms of a new contract are still open.

| Area | A weak answer sounds like | A strong answer contains |
| --- | --- | --- |
| Backups | “We take daily backups.” | What is backed up beyond the database, where each copy sits, how copies are separated, and retention as a period |
| Targets | “We aim to restore service as quickly as possible.” | Confirmation of the RTO and RPO per tier, and the design that meets each |
| Testing | “Our procedures are tested regularly.” | The date of the last restore test, measured recovery time against target, and what changed afterwards |
| Uptime | A percentage with maintenance excluded and no further detail | How maintenance counts, notice periods, and whether the target is monthly or annual |
| Incident roles | “Our experienced team will respond.” | Who declares a disaster, the escalation route, and who updates the status page |

## Before you write the hosting requirement

Agree the RTO and RPO for each service with the people who run those services before drafting starts, because a supplier cannot design to a target nobody has set. Convert every uptime figure in the draft into hours for a month and a year, and decide how maintenance should count.

Then ask each bidder for its most recent dated restore test report on a comparable site, with measured times. Weight the business continuity and disaster recovery score towards that report, and state that weighting in the evaluation criteria.

## Frequently asked questions

### Is disaster recovery part of business continuity?

Disaster recovery is usually treated as the technology part of business continuity. Business continuity keeps the organisation’s services running through a disruption, and disaster recovery restores the systems behind them. [ISO 22301:2019](https://www.iso.org/standard/75106.html) is the international requirements standard for business continuity management systems.

### Should the RPO be shorter than the RTO?

Neither has to be shorter, because they measure different things: the RPO is how much data can be lost, and the RTO is how long the service can be down. An online form may need an RPO of minutes, since a lost submission may exist nowhere else, while tolerating an RTO of several hours behind a clear notice.

### Does an ISO 27001 certificate prove a supplier’s disaster recovery works?

A certificate records that an auditor assessed the supplier’s information security management system, and it does not show that any particular site has been restored. [ISO/IEC 27001:2022](https://www.iso.org/standard/27001) includes Annex A control 5.30, “ICT readiness for business continuity”, according to the certification body [DQS](https://www.dqsglobal.com/en/explore/blog/ict-security-for-business-continuity). Ask for the restore test report alongside the certificate, and run the [supplier ISO 27001 certificate checks](https://insights.axistwelve.com/supplier-iso-27001-certificate-checks). We have held [ISO 27001](https://www.axistwelve.com/certifications) since 2013 and recertified to ISO 27001:2022 in 2023, through BSI. 

[About us](https://www.axistwelve.com/about-us)

[Services](https://www.axistwelve.com/services)

[Careers](https://www.axistwelve.com/careers)

[Net Zero](https://www.axistwelve.com/net_zero/Carbon_Reduction_Plan_Axis12_2025.pdf)

[Work](https://www.axistwelve.com/our-work)

[Products](https://www.axistwelve.com/products)

[Privacy Policy](https://www.axistwelve.com/privacy)

[Modern Slavery](https://www.axistwelve.com/modern-slavery-statement)

3 Southern St  
London  
N1 9AY  
United Kingdom

Phone: +44 (0)203 397 8514  
Email: info@axistwelve.com

[Contact us](https://www.axistwelve.com/contact-us)

![a12-square-white](https://insights.axistwelve.com/hubfs/a12-square-white.svg "a12-square-white")

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Axistwelve",
    "url" : "https://insights.axistwelve.com/author/axistwelve"
  },
  "dateModified" : "2026-10-05T10:00:01.305Z",
  "datePublished" : "2026-10-05T10:00:01.000Z",
  "headline" : "Business continuity and disaster recovery for websites",
  "image" : [ "https://insights.axistwelve.com/hubfs/business-continuity-disaster-recovery.png" ],
  "mainEntityOfPage" : {
    "@id" : "https://insights.axistwelve.com/business-continuity-and-disaster-recovery-for-websites",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://insights.axistwelve.com/hubfs/a12-logo-black.svg"
    }
  }
}
```

```json
{
  "@context" : "https://schema.org",
  "@type" : "FAQPage",
  "mainEntity" : [ {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "Disaster recovery is usually treated as the technology part of business continuity. Business continuity keeps the organisation’s services running through a disruption, and disaster recovery restores the systems behind them. ISO 22301:2019 is the international requirements standard for business continuity management systems."
    },
    "name" : "Is disaster recovery part of business continuity?"
  }, {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "Neither has to be shorter, because they measure different things: the RPO is how much data can be lost, and the RTO is how long the service can be down. An online form may need an RPO of minutes, since a lost submission may exist nowhere else, while tolerating an RTO of several hours behind a clear notice."
    },
    "name" : "Should the RPO be shorter than the RTO?"
  }, {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "A certificate records that an auditor assessed the supplier’s information security management system, and it does not show that any particular site has been restored. ISO/IEC 27001:2022 includes Annex A control 5.30, \"ICT readiness for business continuity\", according to the certification body DQS. Ask for the restore test report alongside the certificate, and run the supplier ISO 27001 certificate checks. We have held ISO 27001 since 2013 and recertified to ISO 27001:2022 in 2023, through BSI."
    },
    "name" : "Does an ISO 27001 certificate prove a supplier’s disaster recovery works?"
  } ]
}
```