The suppliers inside your website

A quick note first. This is general information to help you brief whoever builds and hosts your site, not legal advice. Everything said below about the incident that prompted it comes from the agency's own public statements, reported in the trade press. The regulator has confirmed only that it received a breach report and is assessing it, and has published no finding.

On 9 October 2026 the trade press reported that Webbers, a South West agency with branches trading as Webbers and as Fine & Country across Devon, North Cornwall and Somerset, had contacted clients about an IT incident affecting a third-party service provider. The agency said the information involved could include names, addresses, telephone numbers and email addresses, that its present understanding was that this concerned basic contact details for a subset of its clients, and, in its own words, "I would like to stress that our own security has not been breached." Client notifications went out on 5 October. The provider has not been named, and the agency's managing director described it as a business partner of Webbers and of other estate agents, with reporting at the time saying other firms using the same providers were affected.

On what is public, that reads like an agency doing the right things quickly. The reason to write about it is not the agency. It is the sentence at the heart of it, which almost every agency in the country could truthfully say, and which does less for you than it sounds like it does.

Your own security not being breached does not move the duty

Under the UK GDPR you are the controller of your clients' data. The supplier is your processor. That allocation decides who answers to the regulator, which since 30 September 2026 is the Information Commission, still using the initials ICO, and it does not follow the direction the data leaked in.

Article 33 says the controller notifies the regulator, "without undue delay and, where feasible, not later than 72 hours after having become aware of it". The processor's duty, in Article 33(2), is to notify the controller "without undue delay after becoming aware of a personal data breach". Read those two together and the asymmetry is the whole problem: there is a 72 hour figure on you and no figure at all on them. Your clock starts when you find out, which means a deadline written into law for you is, in practice, controlled by when somebody else picks up the phone.

That is why the notification period in your supplier contract matters more than almost anything else in it. Twenty four or forty eight hours is a reasonable ask, and plenty of suppliers will agree to it. If your contract is silent, the law's answer is "without undue delay", and you will be arguing about what that meant while your own 72 hours runs.

The regulator's guidance is blunt about where the exposure sits. "A controller is primarily responsible for its own compliance and ensuring the compliance of its processors," it says, and "regardless of the terms of the contract with a processor, the controller may be subject to any of the corrective measures and sanctions set out in the UK GDPR." Fines are among those sanctions. A contract allocates risk between you and your supplier. It does not move the regulator's attention.

What Article 28 actually requires you to have

There has to be a contract, or another binding legal act, and it has to be in writing, electronic form included. It has to say what is being processed, for how long, why, what types of personal data, whose, and what your rights and obligations are. It then has to bind the processor to a specific list. Processing only on your documented instructions. Confidentiality for its staff. The security measures in Article 32. Respecting the rules on sub-processors. Helping you with any data subject rights request, not only subject access. Helping you with your own Articles 32 to 36 duties, which includes helping you meet that 72 hour deadline. Deleting or returning the data when the service ends, at your choice. Telling you immediately if, in its opinion, one of your instructions breaches the Regulation. And making information available to demonstrate compliance, and allowing and contributing to audits, which is in most contracts and exercised in very few.

Two more points bite in a website context.

Sub-processors need your authorisation, specific or general, and where it is general the processor has to tell you about changes and give you a chance to object. Your website supplier almost certainly uses a hosting company, which uses a data centre, and may use a form handler, a mail relay, a chat vendor and a search provider. Each is a sub-processor. The one you contracted with "shall remain fully liable" to you for all of them, which is useful, but you still have to know who they are.

And Article 28(10): a processor that starts deciding the purposes and means of processing for itself is treated as a controller for that processing. That is the clause to remember when a supplier offers to do something clever with your enquiry data.

Suppliers do get fined, and recently

The usual assumption is that regulators only pursue the brand name. Two cases say otherwise.

On 15 October 2025 the regulator fined Capita a total of £14m over the March 2023 attack that affected the data of more than six million people: £8m to Capita plc as controller and a separate £6m to Capita Pension Solutions Limited in its capacity as processor. It penalised the two entities separately rather than the group, on the basis that each legal entity is responsible for its own compliance and each had independently breached its own obligations, one as controller and one as processor. The findings were unglamorous: inadequate penetration testing, not enough people in the security operations centre, weak administrator access controls. A "foreseeable and avoidable risk", in the regulator's words. Reporting the breach well inside the 72 hours was not treated as mitigation.

Earlier, in March 2025, Advanced Computer Software Group Ltd was fined £3,076,320 as a processor after a 2022 ransomware attack that affected 79,404 people. The way in was a customer account without multi-factor authentication.

The nearest precedent in our own industry is older and smaller, and the contrast is the point. In July 2019 Life at Parliament View, a London letting agency, was fined £80,000 after tenant data was left on an unsecured server for nearly two years, exposing information on 18,610 people. That was under the Data Protection Act 1998, where the maximum was £500,000.

Today the ceiling is £8.7m or 2 per cent of worldwide turnover for breaches of the security and processor duties in Articles 25 to 39, and £17.5m or 4 per cent for the basic principles in Article 5. A security failure is routinely charged as both: Capita plc as controller was found to have infringed Article 5(1)(f) as well as Article 32, which puts it in the higher tier. For any normal agency the percentages never bite, so the cash figures are the ceiling, and they are not the old £500,000.

As for how common this is in our sector, an analysis by Karis Insurance of regulator data counted 208 reported incidents affecting UK property businesses in 2025, up 17 per cent on 178 the year before. That is an insurer's analysis rather than a regulator publication, so treat the figure as an indication, but the direction is not in doubt.

We could find no publicly reported data protection enforcement action against a UK estate or letting agency in 2025 or 2026. The regulator's register can be filtered by sector, and the only entry under "Land or property services" is a reprimand to a housing association in April 2024. The labelling is applied by the regulator rather than by the business, so that is strong but not conclusive. Note the words "data protection" in that sentence, by the way: HMRC has named plenty of agencies over money laundering in the same period.

Now go and look at what is actually on your site

Most agents have never seen the list. It is usually longer than they expect, and nobody made a decision about half of it.

A typical agency website will be talking to some or all of: the CRM feed that brings in your properties, an enquiry form that posts somewhere, a mail relay that sends the resulting email, a valuation tool, a chat widget, a review widget, an analytics script, one or more advertising pixels, a map, a font service, a newsletter provider, a viewing booking tool, and whatever the previous web company left behind.

Every one of those is either loading code into your visitor's browser, or receiving personal data, or both. For each, three questions. Who is the supplier, and is there a contract that names them as a processor? What do they receive, and how long do they keep it? And how fast are they contractually obliged to tell you when something goes wrong?

If you can answer those three for everything on the list, you are ahead of most of the industry. If you cannot name the list at all, that is the job, and on most sites it is an afternoon rather than a project.

The consent layer is a separate duty, and it moved this year

Regulation 6 of the Privacy and Electronic Communications Regulations was rewritten on 5 February 2026 by the Data (Use and Access) Act 2025. Storing or reading anything on a visitor's device needs consent unless it falls inside the new Schedule A1, which sets out five exceptions: transmission of a communication, strict necessity for a service the user asked for, statistical purposes, website appearance or functioning, and emergency assistance. Each carries conditions.

Two things about it catch website owners out. The new wording explicitly includes "instigating the storage or access", so loading somebody else's tag from your page is your act, not theirs. And the regulator's finalised guidance of 29 April 2026 is unambiguous that online advertising cannot rely on any of the exceptions, including measurement and frequency capping, and that tracking or profiling an individual visitor is outside the statistics exception altogether, which covers aggregate usage only.

The same guidance puts the responsibility where you would rather it did not sit: "as the service provider, you have the primary responsibility for compliance with PECR", including the decision to enable third-party storage and access technologies at all. For some embedded third-party content you and the provider may be joint controllers, which means naming them and explaining the purpose, not just letting the tag fire.

The maximum penalty for a breach of regulation 6 rose on the same day from £500,000 to £17.5m or 4 per cent of worldwide turnover.

A small detail that tells you how fast this is all moving: as at the day this was written, the regulator's own published guide to those regulations still states the old £500,000 figure, under a banner saying it is under review. If the body enforcing the rules has not finished updating its own pages, nobody should feel foolish for having a supplier list they have not looked at since 2023.

The honest gap

The regulator published a review of supply chain attacks on 10 September 2025, as part of a wider retrospective report rather than as formal guidance, and it is sensible: due diligence before you commission, ongoing review rather than a one-off check, documented security agreements, understanding who is responsible for an incident that starts in a supplier's network, and recognising that with hosted software you depend on the vendor even for the logs that would tell you what happened.

What there is not, as far as we can find, is anything addressing the security of third-party scripts and tags loaded by a website: the risk that code you embedded from somebody else changes under you. The consent side of tags is covered thoroughly. The security side is not. That gap is not a reason to do nothing. It is a reason to write down your own answer, because when it goes wrong the question will be what precautions you took, and "there was no guidance" has never been much of an answer.

Six things worth doing

1. Write the list. Every third party your website talks to, including the ones your web company added.

2. Find the contracts. For each supplier, check it names them as a processor with the Article 28 terms.

3. Put a deadline in writing. In hours, with anyone holding your client data.

4. Ask about sub-processors. Who they are, and how you will be told when they change.

5. Decide retention. How long enquiry data lives in each system, and whether anything deletes it.

6. Name the person. Whoever would make the 72 hour call, and make sure they can be reached on a Saturday.

None of that needs a budget. All of it is the sort of thing that is obvious in hindsight.