The site was delivered, it looked great, everyone was happy. Two years on, something goes wrong — and you discover that the question of who was supposed to be looking after it in the meantime was never actually answered by anyone.
A note before we get into this: it is a practical description of how these arrangements usually work, not legal advice. Data protection rules and your own contract both matter here, they do not always point the same way, and if real money or real customer data is involved it is worth half an hour with a lawyer.
This is one of the most common situations in small business, and it is almost never anyone's fault. It is a gap that opens quietly between three parties who each believe someone else is standing in it.
What the three parties usually think
The agency built what was agreed, delivered it, and moved on to the next project. In their understanding the job was completed and signed off. Unless you have a support agreement, nobody there has your site on a list, and nobody is being paid to think about it.
The hosting provider keeps the server running. They will patch the server's own operating system, keep the machine online, and take backups if that is in your plan. What they do not do is look inside your website: they have no idea whether the software your site is built from is out of date, because that is your side of the line.
You reasonably assume that between a professional agency and a professional hosting company, someone is keeping an eye on things.
Everyone is behaving sensibly. Nobody is watching.
What actually falls in the gap
These are the specific things that go unowned, and they are worth reading as a list because each one has caused a bad week for somebody:
- The software your site is built from ages. A website is assembled from a lot of ready-made components, and they were current on the day it launched. They are not current now. Some of them will have had security problems disclosed since — publicly, with enough detail to act on.
- A plugin gets abandoned or withdrawn. Nothing on your site changes, no warning appears, and the piece quietly stops receiving fixes.
- Certificates expire. The thing that makes browsers show your site as secure has an expiry date. When it passes, visitors get a full-page warning telling them your site is unsafe.
- Access is never revoked. The developer who built it, the freelancer who did one job, the agency employee who left last year — each may still have an administrator login.
- The test version stays online. Test copies of the site are frequently left running, sometimes with real customer data, occasionally indexed by Google.
- Nobody agreed who gets the email. When something does break, the alert goes to an address at the agency, or to a person who no longer works there.
None of these announce themselves. That is the whole difficulty: a site with every one of these problems looks completely normal to a visitor, and to you, right up until it does not.
The uncomfortable part: under data protection rules, it lands on you
People assume that if the agency built it, the agency is liable for it. In practice it rarely works that way, for two reasons.
The contract usually does not say. Most web development agreements describe what will be built and when it will be delivered. Many include a warranty period for defects — a few months in which they will fix things that do not work as specified. In our experience, few say anything at all about the years afterwards, because at the point of signing nobody is thinking about year three. Contracts built on a standard industry template are more likely to carry a maintenance annex — worth checking before you assume yours does not.
One exception is worth knowing. All of this is about maintenance — the years after. If something was already broken, or already known to be insecure, on the day it was handed over, that is a defect, and a defect is the agency's problem whether or not you have a maintenance agreement. There is normally a time limit on raising it, so if you suspect that is your situation, put it in writing sooner instead of sitting on it.
Under data protection law, the responsibility is structurally yours. This is the part worth understanding properly. If your website collects information about customers, you are the one who decided to collect it and what to use it for — which under GDPR makes you the data controller. An agency that handles that data on your behalf is usually a data processor — with obligations of its own, and a written agreement it is supposed to have with you. It is not always that tidy: an agency that starts using your customer data for its own purposes stops being merely a processor. But in the ordinary case, the accountability for the whole arrangement sits with you. If customer data leaks because of a flaw in code somebody else wrote, it is still you who has to assess it and — where it is likely to put people at risk — report it to the supervisory authority, normally within 72 hours. Not every incident clears that bar, but the judgement is yours to make, and it is your customers whose trust is affected.
That is not a reason to distrust your agency. It is a reason to be specific with them, because the consequences do not distribute the way people assume.
One thing that is easy to miss: having to report a breach is not the same as having to carry the cost of it. If the agency caused it, data protection rules let you recover their share, and your contract may say more. Reporting is your job. Paying for someone else's mistake is a separate question, and not one you should assume you have already lost.
The questions to ask — and when
The best time is before signing. The second best time is now, in an ordinary email, without waiting for something to go wrong.
- Who applies security updates to the site, how often, and is that included or billed? The single most important question, and the one most likely to reveal that the answer is "nobody".
- If a security problem is published in something my site uses, who finds out, and how do they tell me?
- Do I own the code, and where is it? If the agency disappeared tomorrow, could someone else pick this up? Ask for the code — where it is stored, and access to it — and the hosting login, in writing.
- Who currently has access, and what happens when one of them leaves?
- When the site goes down at 8pm on a Friday, what actually happens? Is there a number, a response time, and a person — or is it "email us and we'll see"?
- Is there a support agreement, and what precisely does it cover? "Support" often means help when you ask, not someone watching on your behalf. Those are very different products.
How to raise it without it sounding like an accusation
Worth thinking about, because the reason this conversation gets postponed is usually that it feels like a complaint about work you were pleased with.
It helps to frame it as a gap rather than a failing, because that is what it is: "We never agreed who looks after the site after launch, and I have realised I do not know the answer. Can we write it down?" A good agency will be relieved — they have been carrying an unspoken expectation they never quoted for, and they would rather it were defined too. If the answer is vague, that is useful information too — not proof of bad faith, but a sign the arrangement was never actually defined.
Where it works best is when you both look at the same information. A shared, dated report of what is actually wrong is a much better basis than a conversation about whether anything is. It stops being a question of trust and becomes a list.
If the agency is gone
A common and stressful variant: the agency folded, the freelancer moved on, or the relationship simply ended, and now nobody knows how the site works.
Three things, in order. Get control of the accounts — domain, hosting, and the site's own administrator login. The domain matters most: everything else can be rebuilt, and a domain you have lost access to is a genuinely hard problem. Find out what it is built on, because you cannot hire someone to maintain a thing nobody can describe. Then decide deliberately whether to find a new maintainer, move to a simpler platform, or rebuild. Any of those is fine. Drifting is the option that ends badly.
The point
Nobody in this story did anything wrong. The agency built what was asked. The host kept the server up. You assumed continuity that was never actually in anyone's remit.
The fix is not to find someone to blame afterwards. It is to make the gap visible now, agree in one email who stands in it, and have something watching in the meantime — so the answer to "how long has it been like that?" is never "we don't know".
Is my web agency responsible for security after the website is delivered?
Your agency is responsible for security after delivery only if your contract says so, and most web development contracts do not. They describe what will be built and when it will be delivered, often with a warranty period for defects, and say nothing about the years afterwards. Unless you have an ongoing support or maintenance agreement, nobody at the agency is being paid to think about your site — which means updates, expiring certificates and newly published security problems have no owner.
Who is legally responsible if my website is hacked?
Under data protection rules it is usually you, even when someone else built the site. If your website collects information about customers, you decided to collect it and what to use it for, which makes you the data controller. An agency handling that data on your behalf is normally a processor with obligations of its own, but assessing a breach and reporting it to the authority is the controller's job — yours. Reporting it is not the same as paying for it: if the agency caused it, you may be able to recover their share. This is a general description rather than legal advice; your contract decides your specific case.
What should I ask my web agency about ongoing maintenance?
Six questions cover most of what matters about ongoing maintenance. Who applies security updates, how often, and is it included or billed? If a security problem is published in something the site uses, who finds out and how do they tell me? Do I own the code and where is it? Who has access, and what happens when one of them leaves? What actually happens when the site goes down outside office hours? And does the support agreement mean someone is watching, or only that they will help when I ask — because those are very different things.
What do I do if the agency that built my website is gone?
If the agency that built your website is gone, do three things in order. Get control of the accounts — domain, hosting and the site's administrator login — with the domain first, because everything else can be rebuilt and a lost domain is genuinely hard to recover. Then find out what the site is built on, since you cannot hire someone to maintain something nobody can describe. Then decide deliberately whether to find a new maintainer, move to a simpler platform, or rebuild. Drifting is the option that ends badly.
Where TrustCtrl fits
This is the gap TrustCtrl was built to stand in. It watches the things that have no owner after launch — whether the site and checkout actually work, whether certificates are about to expire, whether the software behind it has known problems, whether anyone is impersonating your brand, and whether your email is trusted — and it explains each finding in plain language, with a technical version you can forward to whoever maintains the site.
It does not replace your agency. It gives you both the same dated list to look at, which makes for a considerably easier conversation than the one that starts with "I think something might be wrong".