Shared responsibility in hosting: who owns each layer, and where the gaps are

Assumptions and when this guide does not apply

This guide describes the typical split for each hosting type. Your contract, order form or quote is what actually decides it; where the two disagree, the contract wins. Read this guide to know which questions to ask, not as a statement of what any provider does.

It does not cover:

• Software as a service, where you rent an application rather than infrastructure. The same principle applies (you still own your data and accounts), but the provider owns almost everything else.
• Legal allocation of liability, indemnities and insurance. Those belong with your lawyer and are separate from who does the operational work.
• Specific compliance frameworks. A framework may require you to show evidence for controls the provider runs; ask the provider which independent audit reports they can share, and map them to your obligations.

The NIST definition of cloud computing (SP 800-145) gives the underlying model: the more of the stack the provider runs (infrastructure, then platform, then software), the less you control and the less you are responsible for. Hosting products sit at different points on that line, and some, like managed hosting, sit wherever the contract puts them.

The split by hosting type

The table shows the usual owner of each layer. "Check contract" means providers differ enough that you must confirm it in writing.

Two rows never move: physical hardware stays with the provider, and data, accounts and keys stay with you. Even on fully managed hosting, the provider cannot know whether a login is your new developer or an attacker using a phished password. The bottom rows are where most incidents start.

Bare metal deserves a note. You get the whole machine, so you also inherit things a VPS hides: RAID or disk health monitoring, firmware updates where the contract allows, and the server's out-of-band management interface (BMC or IPMI). A BMC reachable from the public internet is a serious exposure; keep it on a private network or VPN. GPU hosting adds a driver and toolkit layer (for example the GPU driver and CUDA versions) that must match your frameworks; decide whether the provider's image or your own build owns it.

A RACI table for the work itself

"Who owns the layer" is not enough; for each recurring task you need one person or party who does it (Responsible), one who answers for it (Accountable), who is asked (Consulted) and who is told (Informed). This example is for a managed server where the provider patches the OS and runs nightly backups. It is a template, not a description of any provider's service.

Note the pattern: even where the provider does the work, you stay Accountable for outcomes that affect your business, like restores, certificates and incident decisions. The provider cannot be accountable for whether your data is recoverable to the point your business needs.

How to read a provider's responsibility statement

Large cloud platforms publish shared responsibility models; smaller providers put the split in their terms, service descriptions or quotes. Read them with these tests:

1. Look at the verbs. "Provides", "performs", "maintains" and "monitors" describe duties. "May", "can", "makes available" and "commercially reasonable efforts" describe options or best effort. A backup feature that is "available" is not a backup that is running.
2. Find the boundary. Every statement has a line where the provider's duty ends: at the hypervisor, the OS, the control panel, the network edge. Locate it for each layer in the matrix above.
3. Separate included from add-on. Backups, monitoring, DDoS protection and managed patching are often priced extras. Confirm which ones your order actually contains.
4. Check the numbers behind each duty. Backup frequency, retention, where copies are stored, how a restore is requested, how long it takes and whether it costs extra.
5. Read the incident and notice terms. How and when will the provider tell you about a security incident affecting your service, and what will they need from you?
6. Read the exit terms. How you get your data back, in what format, and how long it is kept after cancellation.

For BroadNet Cloud services, the security and reliability page explains how responsibilities are divided, and each written quote lists the supplier, region and inclusions.

The gaps that cause incidents

Backups nobody owned

The provider takes snapshots; the team assumes that means backups. Then a restore is needed and the snapshots are on the same storage system as the server, kept for only a few days, not application-consistent for the database, or deleted with the server when the account was cancelled. Or the backup add-on was never enabled. The fix is ownership: one named person accountable for a backup that is off the platform, inside your retention needs, and restored in a test on a schedule. The backup and recovery guide and recovery feasibility tool help set those targets.

Certificates that expired

A certificate installed by hand, renewed by someone who left, or tied to an email inbox nobody reads. This gap is getting wider: under CA/Browser Forum Ballot SC-081, the maximum validity of publicly trusted TLS certificates fell to 200 days from 15 March 2026 and is scheduled to fall to 100 days in 2027 and 47 days in 2029. Manual renewal will not keep up. Automate with the ACME protocol (RFC 8555), monitor expiry independently of the renewal job, and record who owns each certificate.

Images that were never patched

A server built from a provider template or marketplace image starts with whatever packages the image had when it was made, which may be months old. The provider patches the hypervisor; your OS is yours from first boot. Update immediately after provisioning and turn on automatic security updates (see the Linux hardening baseline). The same applies to your own golden images: rebuild them on a schedule.

Keys and accounts nobody reviewed

SSH keys of former staff still in authorized_keys. API tokens committed to a repository. A hosting control-panel login without multi-factor authentication. The provider account itself, which can delete every server and backup, owned by one person's personal email. Treat the provider account as the most privileged credential you have: MFA on every user, named accounts rather than shared ones, a second administrator so access survives one person leaving, and a quarterly review of keys and tokens.

Things outside the server

Domain renewal, DNS hosting and the billing contact sit outside every hosting matrix, and an expired domain or a lapsed card takes the service down as surely as a hardware fault. Give each one an owner and a renewal date in the same register.

Questions to ask any provider

Ask for answers in writing, attached to the quote or contract:

• Which layers do you operate for this service, and where exactly does your responsibility end?
• Are backups included? How often, kept how long, stored where, and how do I request and pay for a restore?
• Who patches the operating system, on what schedule, and how are reboots arranged?
• Who renews TLS certificates, and how is expiry monitored?
• Which data-center or platform supplier runs the hardware, and in which region? (At BroadNet Cloud this is confirmed in each written quote Confirmed at quote.)
• How will you notify me of a security incident affecting my service, and how quickly?
• What access do your staff have to my servers and data, and how is it logged?
• Which independent audit reports or attestations can you share, and do they cover this service?
• For bare metal: is the BMC on a private network, and who updates firmware?
• For GPU servers: who owns the driver and toolkit versions, and how are local disks wiped between tenants?
• When I leave, how do I get my data back, in what format, and when is it deleted?

Ownership checklist

• A responsibility register with one row per layer in the matrix above and a named owner for each.
• The provider's written split attached to the register, with the date and contract version.
• Backups: owner, frequency, retention, off-platform copy, last successful test restore date.
• Certificates: list of hostnames, renewal method (ACME or manual), expiry monitoring, owner.
• OS and image patching: who, how often, how reboots happen.
• Provider account: MFA on every user, at least two administrators, no personal email as the owner.
• SSH keys and API tokens reviewed in the last quarter; leavers removed.
• Domain, DNS and billing: owner and renewal dates recorded.
• Incident contacts on both sides, tested with a dry run.
• Exit plan: how data comes back and how long it takes.

Common mistakes

• Treating snapshots as backups. They often share the failure domain of the server they protect.
• Assuming "managed" means everything. Managed contracts vary widely; the application, data and accounts are almost always yours.
• Owning a task without being able to do it. A team "responsible" for restores but without the credentials or runbook to perform one.
• One person holding every credential. Access should survive anyone's holiday or departure.
• Reading the split once. Re-check when you add a service, change plan or the provider updates its terms.
• Leaving out domains and billing, which take services offline without any technical fault.

Related