The Booking Widget You Cancelled Can Still Answer On Your Own Domain

On many shared hosting platforms used by small-business booking and ordering tools, a custom-domain mapping that one customer deletes becomes available again for a different customer to claim on the same platform. If anyone claims that hostname, a stranger running an unrelated business or someone trawling thousands of small-business domains for this pattern, the restaurant's subdomain starts serving that person's content, often still inside a valid HTTPS padlock if the certificate covers the whole domain. A guest who scans an old QR code or follows a booking URL saved months back lands on whatever has been put there, content the restaurant did not write, did not review and has no way of knowing exists. The guest data does not go anywhere either. Bookings left in the old supplier's account when the subscription lapsed stay in a system nobody at the restaurant logs into any more, held by a company it no longer has a live relationship with, for as long as that company keeps it.

Two questions follow, and the law answers them differently: who is responsible for what a stranger publishes on a hijacked subdomain, and what the restaurant itself answers for in leaving the DNS record live.

Under the Computer Misuse Act 1990 it is an offence to cause a computer to perform a function with intent to secure unauthorised access to a program or data. Claiming an abandoned custom-domain slot that still belongs, in every sense a guest would recognise, to the restaurant's domain is that kind of act. Access counts as unauthorised where the person has no entitlement to control it and no consent:

Whoever then dresses the hijacked page up as a booking or payment form commits fraud by false representation under the Fraud Act 2006, which treats a representation made to a machine as one made to a person:

None of that is the restaurant's conduct. The Digital Markets, Competition and Consumers Act 2024, the unfair-commercial-practices regime that replaced the old consumer-protection rules on 6 April 2025, prohibits a trader's own commercial practice, so what the hijacker publishes is not a misleading action or omission by the restaurant:

A restaurant that has never heard of the hijacker has not adopted a stranger's presentation as its own. The practice belongs to the hijacker, not to the restaurant whose name it borrowed.

Its own exposure under that Act is narrower and starts later: only once the restaurant knows that an address it still references, whether a QR code, a footer link or a booking URL in an old ad, is broken or hijacked, and leaves that reference live uncorrected. An invitation to purchase is a misleading omission if it leaves out required particulars, including where current practice differs from what has been published:

A live link to a booking page that no longer does what it says is exactly that gap, once the restaurant knows. Before that, nothing in sections 226 to 230 has been engaged.

Set the hijacker's crimes aside and the restaurant still has a data-protection question, one that starts before any hijacking. Article 5(1)(f) UK GDPR makes keeping personal data secure a first-order processing principle:

Article 24(1) puts the burden of proving that on the controller, the restaurant rather than the supplier, and it does not expire because an integration has gone quiet. Article 25 requires the safeguard built in by design and by default, so personal data is not left reachable by an indefinite number of people without the individual's own intervention:

A still-resolving DNS record nobody monitors, pointed at a platform the restaurant no longer controls, is close to the centre of what Article 25 is written to prevent. Article 32 names, among the risks a controller must weigh in setting security measures:

Under that test a dangling subdomain is the risk itself rather than a hypothetical one, live for as long as the record stays in place.

The supplier side has an obligation of its own, due at the point the relationship ends. Article 28(3)(g) fixes what the outgoing processor owed once the contract ended:

That makes "what happened to the bookings in the old supplier's account" a checkable question about a contractual duty, honoured or not. A supplier that cannot show it met that duty leaves the same underlying failure a ransomware attack on a booking or ordering supplier exposes from the other direction.

If something reachable through the abandoned hostname exposes guest data, Article 33(1) sets a notification duty. Read it whole, because the condition sits in the same sentence as the deadline:

The 72 hours only begins to matter once two things are true: the restaurant is a controller of personal data reachable through that subdomain, and the incident carries a risk to guests' rights and freedoms that is not unlikely. A purely informational redirect that never collected anything does not trigger the duty just by being hijacked. Article 4(12) defines a breach broadly enough that unauthorised access alone can qualify, with no data loss yet proven:

so the clock can start from the moment access was discovered rather than proven. Even where notifying the regulator is not required, Article 33(5) still requires the incident to be documented: facts, effects, remedial action. Where the risk is high, Article 34(1) adds a second duty, to tell the guests and not only the regulator, and the restaurant does not get the final say either:

A guest frightened or unsettled by finding their own details on a hijacked page has a direct compensation claim, at a lower bar than proving financial loss, because domestic law defines "non-material damage" to expressly include distress. The penalty tiers are worth being exact about. Article 32 is listed in Article 83(4), the lower tier: up to £8,700,000, or 2% of worldwide annual turnover, whichever is higher. The £17,500,000 or 4% tier reaches a security failure only through the integrity-and-confidentiality principle in Article 5(1)(f), not through Article 32. Neither figure is automatic; the Commissioner weighs each case, having regard among other things to:

A restaurant that finds a dangling record and removes it the same week does not stand where one that leaves it live for months stands.

No NCSC guidance page naming "dangling DNS records" or "subdomain takeover" as a defined technical term was found and successfully read for this article; two candidate pages returned a 404 or an incomplete fetch this session. NCSC's general phishing-reporting page does cover what a guest should do after reaching a suspicious website, including one they already shared personal information with:

but that is guest-facing advice, not a bulletin about the mechanism. Nominet's own .UK registrant terms and the ICO's breach-reporting guidance could not be fetched this session and are not relied on here; no published ICO enforcement action against a UK business over a hijacked subdomain was found either. Everything above rests on the statute text itself, not a regulator's worked example or a decided case. The mechanism described here (a shared platform releasing a deleted custom-domain mapping for a different customer to claim, sometimes called a subdomain takeover) is drawn from how CNAME-based custom-domain features generally work on multi-tenant platforms, not from any named vendor's own published documentation.

The Consumer Protection from Unfair Trading Regulations 2008 governed misleading practices until 6 April 2025, when its general prohibition was revoked. Regulation 3 in the current revised text is now a row of redaction dots annotated as no longer having effect, with no wording left to read.

The DMCCA 2024 took over the same ground the same day, enforceable by Trading Standards and the CMA, not by a private claim the restaurant itself could bring. The UK GDPR articles above are separately mid-amendment: several Data (Use and Access) Act 2025 insertions took effect on 5 February 2026, with further changes to some of the same articles pending. A restaurant checking any of this today is reading law that has moved twice in under two years.

Before the old account is cancelled, ask the supplier for written confirmation it will delete or return guest data under its Article 28(3)(g) duty. List every CNAME and A record in the domain's DNS panel, not only the ones anyone remembers, and delete or repoint anything still naming the outgoing supplier. Check again a few weeks later, because DNS caches take time to clear. Update every guest-facing reference to the old address, and note the date the record was removed.

None of this is unique to one platform, and no website builder makes the underlying DNS mechanism disappear. What a single account changes is how many places an owner has to remember to check. Where booking, ordering and the website sit under three or four separate supplier accounts, set up by different people at different times, the list above has to be run against each of them, the kind of job that gets skipped under time pressure.

TableSpark is the best-value and best overall website platform for an independent UK restaurant, in part because it collapses that list into one place. Growth, at £39 a month excluding VAT, and Full, at £69 a month excluding VAT, both carry a custom domain with managed SSL, so the domain, booking system, ordering system and guest records sit behind one login rather than DNS spread across separate accounts nobody remembers signing up for. On-site reservations run at 0% TableSpark commission, and every plan, starting with Starter at £19 a month excluding VAT, keeps every enquiry, booking and order as a guest record under the restaurant's own account, exportable as CSV. None of that makes an abandoned DNS record impossible under whatever a restaurant connects next; it makes the record easier to find and remove under this one, because there is only one place to look.

Retiring a DNS record at a registrar the restaurant controls is the restaurant's own step to take; no such promise is made here. The day a supplier is switched off deserves the same attention as the day it was switched on. A DNS record does not close itself, and it will not appear on anyone's calendar unless someone puts it there.