Security Basics 05｜Who actually manages your website: three hosting relationships, three different responsibility lines

The moment your website will not load, or a security advisory lands in your inbox, you pick up the phone to find someone to deal with it. The sentence you least want to hear is this one: that part is not ours, we only look after the server hardware.

Your company pays a fixed sum every month, so why does nobody feel it is their job to act? Because in the world of websites, paying for somewhere to put your site and having someone look after your site are two entirely different things. This is the fifth piece in our security basics series. Having confirmed your versions in Security Basics 01｜An advisory just landed: how do you know whether it affects you, this one draws the line that is most often misread: which hosting relationship is your website in right now, and when something breaks, who is supposed to move first?

Why paying for a server does not mean someone is handling security

Think of a web server as a shop unit you rent. The landlord puts up the building, keeps the power and water on, and has a guard on the front door. That is the landlord's job. Whether the till in your shop is locked, whether your staff shut the windows at closing time, whether the stock on your shelves is past its date — the landlord does not come in and check any of that for you.

Cloud servers work the same way. Take the Shared Responsibility Model published by the global cloud provider Amazon Web Services (AWS): the official documentation splits responsibility cleanly in two. The provider is responsible for Security of the Cloud, meaning physical datacentre security, hardware and the underlying virtualisation. The customer must carry Security in the Cloud, which includes operating system updates and security patching, application software, and firewall configuration.

In other words, if all you did was put a card down for a cloud server, then when your application has a vulnerability or your database has no backups, the provider has neither the obligation nor the access to go into your system and fix it. As Does Your AI Product Have Backups: The Minimum Standard for Database and Files put it: the provider is responsible for the machine staying alive, not for your data staying whole.

Relationship one: you rent the cloud server yourself (including sites you built with AI)

Your company paid for a cloud server or a deployment platform, and you or an in-house engineer put the code up and got it running. Or, as in Projects Built With Cursor, Claude Code, or Lovable: What to Prepare Before Handing Them to Engineers, you clicked a few times in an online tool and shipped the product. In this relationship:

• Where their responsibility ends: the datacentre stays powered, the network stays up, and broken hardware gets replaced.
• Who is responsible for the site and its security: entirely you (or that one engineer in your company). Whether the operating system gets upgraded, whether security updates actually happen, who looks at the site when it goes down, whether the database is backed up somewhere else every day — the platform does none of it for you.
• The trap people fall into: the engineer who set the server up has left, the card is still being charged every month, and the site is still running, so you assume somebody is watching it. In fact that machine has been running un-updated and unwatched since the day they walked out.

Relationship two: a managed host or a hosted site platform

You pay a bit more than for a bare machine, and you are using a managed service that keeps the underlying environment in order, or an off-the-shelf store or site-building platform. In this relationship:

• Where their responsibility ends: beyond the hardware, they look after the base operating system or the platform's shared standard features, and some provide scheduled snapshots of the whole machine.
• Who is responsible for the site and its security: half each. The plugins you installed on top, the custom code you paid someone to write, the back-office accounts you opened for staff and suppliers, the payment and SMS keys you wired up — all of that is still yours.
• The trap people fall into: assuming a managed service makes you safe, then setting a trivial admin password or installing a pile of third-party plugins that have not been updated in years. They kept the underlying server standing, and the attacker walked in through your own admin panel or a plugin hole.

Relationship three: fully outsourced to a development or maintenance vendor

You handed the website to an outside technical company and signed a contract. This is where you need to look closely, because the same word, outsourcing, covers very different places to draw the line:

• A build contract with a warranty period only: as We're Still Here After Launch: Where Helper CTO's Line of Responsibility Runs explains, project work ends when the thing is delivered. Once the warranty lapses, they have no contractual duty to check on it, back it up or patch it. Every incident becomes a fresh quote and a fresh slot in the queue.
• A long-term maintenance contract that only says "system maintenance provided": as unpacked in What a Maintenance Contract Should Actually Say: Response Time, Update Frequency, Exit Terms, Document Ownership and What's Included in Your Maintenance Fee, and What Isn't, some cheap plans only mean there is a phone number that answers. Debugging, security updates and off-site backups are all quoted separately.
• An operations relationship where someone is genuinely accountable: the server is watched, problems get handled without you asking, security updates happen on a schedule, and backups and restore drills are inside the fixed monthly fee — with accounts, domains and source code all owned by your own company.

One table: three hosting relationships, four critical jobs, and who does them

Not sure which one your website is in? Get out the invoices and the contract you pay every month, read them against the table below, and see whose name these four life-saving jobs are sitting under:

Once the line is clear, take these four questions and confirm it

Whichever relationship you are in, the dangerous part is never which one you picked. It is that you assume they are doing it while they assume you are. Following the principles in What a Maintenance Contract Should Actually Say: Response Time, Update Frequency, Exit Terms, Document Ownership, you can put these four questions to whoever is taking your money today:

• If the site goes down at two in the morning, who gets the alert first, and how soon do they start: if no response time is written down, it means on the day it happens you will hear about it from a customer.
• When an advisory comes out, who checks the versions and applies the update: confirm whether that is included in what you already pay and done on a schedule, or whether it simply never happens unless someone raises it.
• Where the database and file backups live, and who tests a restore: do not settle for "the provider takes snapshots". Ask whether the backup sits independently somewhere else, and when a restore was last tested.
• If you stop working together next month, whose name are the server, the domain and the code in: confirming ownership stays with your company from end to end is what stops "having someone to manage it" from turning into having your livelihood tied up in someone else's account.

Nerd Technic is a systems software company that came out of custom development, and what we do now is the long-term maintenance of AI systems. Long-term maintenance is about how soon someone responds when something breaks, how often security updates happen, and who owns the documents and the system — all of which belongs in the contract. Some plans spell it out; others cover it with one line saying system maintenance is provided. If you are not sure whether anyone is currently looking after the system you have, or which responsibilities are still hanging in mid-air, a system health check is a place to start: it looks at code, database, deployment and security, and What a System Health Check Actually Looks At: Code, Database, Deployment, Security sets out the full list. Book a system health check