Uptime, backups, updates: who is responsible for what

Provider, registrar, partner, you: four parties, and the question is who restores the site after a bad day. The table, filled in.

3 minread 732words last updated

The short answer

Four parties touch a business website: the hosting or platform provider, the domain registrar, the partner or developer, and you. Each is responsible for a different layer, and the incidents that hurt happen in the gaps between them: the provider kept the server running but nobody renewed the domain; the backup existed but nobody had tested it; the update was available but nobody owned applying it. The table below fills in the cells. Write it for your own site. Any cell that says “nobody” is the next incident.

The responsibility table

AreaProvider or platformRegistrarPartnerYou
Servers, network, their own uptimeResponsibleMonitors, escalates
Your site’s code workingResponsible
Uptime monitoring of your siteResponsibleReceives reports
CertificatesUsually automatedVerifies, fixes failures
Domain renewal and DNSProvides the serviceManages, watches expiryOwns the account, pays
Recovery of your content and configurationOwn infrastructure onlyResponsible: the recovery route, whether that is scheduled backups with restore tests or a repository plus previous deploysOwns the storage or repository account
Framework and dependency updatesResponsible
Platform updatesResponsibleAdapts the site when needed
Security configuration of the siteBaselineResponsible
Access managementProposes, executesDecides who has access
Content correctnessAdvisesResponsible
Paying the billsRemindsResponsible
Deciding prioritiesAdvisesResponsible

Where the gaps usually are

  1. Domain renewal. The registrar sends reminders to an address nobody reads. The provider is not involved. The partner may not have access. The site and email go dark on the anniversary.
  2. Backups. The provider has snapshots of their infrastructure. Nobody has a copy of your content elsewhere, and nobody has restored one. The first restore attempt is the real one.
  3. Updates. The platform updates itself. The site’s own dependencies age for years because updating them is nobody’s Monday task.
  4. Monitoring. The provider monitors their servers. Nobody monitors whether your form delivers or your certificate renewed on a subdomain.
  5. Access. The provider does not know who should have access. The partner inherited a list. You never reviewed it.

Filling in your own table

Take the table above and write a name in every cell that applies to your site. Not a company: a person or a contract clause. Where the answer is a provider, check that the provider actually promises it in writing. Where the answer is “we do that ourselves”, check that it has happened in the last month. Where the answer is nobody, decide today whether it becomes yours or a partner’s.

What this means for you

Uptime, backups and updates are not one party’s job; they are four parties’ jobs, and the gaps between them are where the damage happens. Fill in the table with names, verify the provider’s promises in writing, and give every empty cell an owner. A partner’s core value is being the name in most of those cells and knowing which other party to call for the rest.

Written by the CivSec S.M.A.R.T team

We build and run websites, software and AI systems for businesses. We write about what we see in that work, in plain language, and we update articles when things change.

Last checked . Spotted something outdated? Tell us.

Frequently asked questions

Our hosting provider does backups. Are we covered?

Provider backups protect against the provider's failures and are on the provider's schedule and retention. They do not protect against your own deletions discovered later, and they are lost if you leave or the account is closed. You need your own copies, elsewhere, tested. Provider backups are a bonus, not the plan.

If the site goes down, who do we call?

The partner, always. The partner determines whether the cause is the provider, the code, the domain or something else, and deals with the right party. If you have no partner, you are the one who has to work that out at 2 a.m., which is the strongest argument for having one.

Who is responsible for updates on a static site?

The partner: framework, dependencies, build tooling and integrations. The platform handles its own infrastructure. There is no plugin layer for you to update, which removes the most common responsibility gap on traditional sites.