How UK GDPR and PECR shape a web design agency contract

What to take away

Where UK GDPR, PECR and the Data Protection Act 2018 meet a web design agency contract

Three instruments collide on a typical website build. The principles, lawful bases and rights of individuals are established by the UK GDPR. PECR governs cookies and electronic marketing.

The Data Protection Act 2018 sits alongside UK GDPR, filling in the enforcement and exemption detail. The Data Protection Act 2018 is the companion statute you will see cited in ICO notices and in contract warranties.

The Information Commissioner's Office enforces all three. It can act on a complaint from a single site visitor, and it can act on its own initiative after a breach report. The ICO also runs the annual data protection fee register, which most controllers must join.

A contract that ignores this split leaves gaps. The agency builds the forms, the cookie banner and the analytics tags. You own the site, the customer relationships and the liability. Without clauses that allocate each task, both sides assume the other has it covered.

Most disputes we see described in agency forums are not about a breach itself. They are about who pays for the fix, who talks to the ICO and who rewrites the privacy notice at short notice. Contracts prevent that argument, or they fail to.

Start with a plain question: what personal data will the site actually touch? Enquiry forms, newsletter signups, booking systems, live chat, payment pages and analytics all qualify. Each one creates a processing activity that the contract should describe.

Controller or processor: fixing the agency's role before drafting clauses

The ICO's guidance on controllers and processors is the reference point here. It falls to a controller to determine the purposes and means of processing personal data. A processor acts on the controller's documented instructions.

For most brochure and lead generation sites, the client is the controller and the agency is a processor. The agency hosts, maintains and sometimes analyses data on the client's behalf. That is a processor relationship, and UK GDPR Article 28(3) requires a written contract containing specific processing particulars and obligations, set out in the checklist below.

Some engagements flip the roles. If the agency runs its own analytics product across many clients, or uses client data to train its own tooling, it becomes a controller for that activity. Say so in the contract, because the roles can differ by activity within one project.

Agency marketing is the usual trap. The agency wants to feature the new site in its portfolio and write a case study. That uses the client's brand and sometimes the client's data. It needs a separate permission, not a line buried in the main services clause.

Sub-processors matter too. Hosting providers, email platforms, form handlers and CDN vendors are all sub-processors. The contract should require the agency to name them, to flow down equivalent obligations and to give notice before adding more.

Our guidance on data duties on a website project breaks the roles down further by purpose and technology, which helps when a single project spans several processing activities.

Cookie consent and storage and access technologies in the build scope

Cookies sit under PECR, not UK GDPR, although the data they collect may also engage UK GDPR. PECR regulation 6 sets out the rules for storing information on, or accessing information from, a user's device. The ICO's Guide to Privacy and Electronic Communications Regulations covers the cookie rules and the e-marketing rules that shape consent clauses.

PECR requires consent for storing information on, or accessing information from, a user's device, unless the storage is strictly necessary to provide the service the user asked for. Analytics cookies are not strictly necessary. Nor are advertising or social media pixels.

The ICO's Guidance on the use of storage and access technologies explains how this applies to cookies, pixels, local storage and device fingerprinting. Consent means a clear affirmative action, freely given, specific and informed.

Cookie consent clauses should cover the following, in the build scope rather than a side schedule:

Add these cookie controls to the build scope as well:

A worked example helps here. A client asks for a Google Analytics tag and a Meta pixel on a new brochure site. The agency installs both, and the banner defaults to accept. Under PECR that default is not valid consent, and the client carries the risk as controller.

The fix is a clause requiring prior consent before any non-essential tag fires, plus a change control step for adding tags later.

Tag managers make this worse. A marketing manager can add a new pixel without telling the agency or updating the cookie list. A good contract requires written approval before any new tag goes live, and a review of the cookie schedule at agreed intervals.

Consent mode settings in analytics tools are useful, but they are a technical control, not a legal one. The contract still needs the consent clause, the record keeping and the withdrawal route.

Privacy policy, lawful basis and subject access request clauses

The privacy policy is the public face of the processing. It must be accurate, specific and written in clear language. The contract should say who drafts it, who approves it and who publishes updates.

Many agencies supply a template policy. That is a starting point, not a finished document. The client knows its retention periods, its suppliers and its complaint routes. The agency knows the site build. Both inputs are needed, and the contract should say so.

Lawful basis is the client's decision as controller. Consent, contract, legal obligation, vital interests, public task and legitimate interests are the six bases. The contract should require the client to confirm the basis for each processing activity, and the agency to build the site so the basis is reflected in the notices and the consent flows.

Subject access requests are a common flashpoint. A visitor emails the client asking for a copy of their data. The clock starts when the request arrives, and the client has one month to respond in most cases. If the data sits in a form plugin the agency controls, the client needs the agency to retrieve it quickly.

Contract clauses should cover:

Our piece on commercial contracts for web design agencies sets out the records that keep a commission honest, and the same record keeping discipline applies to data requests.

Retention is the other half. Forms, logs and backups all hold personal data for different periods. The contract should state the retention rule for each store, and who enforces deletion. Without that, data accumulates quietly and the client's privacy policy becomes inaccurate.

International transfers and hosting location in the contract schedule

Where the site and its data physically sit matters. A UK client with UK customers may still have hosting in the United States, the European Union or elsewhere. Each destination carries different transfer rules under UK GDPR.

The contract should name the hosting region, the provider and the sub-processors involved. "Cloud hosting" is not enough. A schedule entry should list the data centres, the backup locations and the support locations where staff may access data.

Transfers to countries without UK adequacy regulations need a transfer mechanism. The International Data Transfer Agreement and the UK addendum to the EU standard contractual clauses are the usual routes. The contract should say who puts that mechanism in place and who keeps it current.

Support access is easy to miss. A hosting provider's engineers may be based outside the UK and may access data during a fault. That is a transfer, and it belongs in the schedule.

Our guide to mapping regulations by jurisdiction covers how the devolved administrations and different regulators interact, which matters if the client operates across the UK.

Change control is the practical safeguard. Hosting providers move regions, add sub-processors and change terms. The contract should require notice before a material change, and a right to object if the new location creates a transfer problem.

ICO enforcement action and the data protection fee as commercial risks

The ICO publishes its enforcement action, including fines, reprimands and enforcement notices. Reading a few recent entries shows the pattern: nuisance marketing, insecure storage, unlawful cookie practices and slow breach responses.

Fines under UK GDPR can reach 17.5 million pounds or 4 per cent of annual worldwide turnover, whichever is higher, for the most serious breaches. The ICO rarely applies the maximum, but the ceiling shapes the risk conversation.

The data protection fee is separate and simpler. Most controllers that process personal data must pay an annual fee to the ICO and appear on the register. The fee is tiered by size and turnover, and non-payment itself can attract a penalty.

Contract clauses should deal with both risks. Indemnities should be mutual where fault is shared, and capped where the agency's exposure is disproportionate to the fee. Insurance is worth checking: many professional indemnity policies exclude regulatory fines, and some cover defence costs only.

A breach notification clause is essential. UK GDPR requires notification to the ICO within 72 hours of becoming aware of a personal data breach, where it poses a risk to rights and freedoms. The agency may be the first to notice. The contract must require immediate notification to the client, with the facts needed to assess the incident.

Our quality checklist treats privacy and security as separate gates, which is a useful way to test a build before launch and to frame the warranty period in the contract.

A clause-by-clause contract checklist for UK agency engagements

Use this as a review list before signing. Each item should appear in the contract or an attached schedule.

The contract also needs a change control mechanism, because websites change after launch. New forms, new analytics and new plugins all create new processing. A short written approval step, with the cookie schedule updated at the same time, keeps the paperwork honest.

Finally, keep the contract and the live site in step. A policy that describes cookies the site no longer sets is as much a problem as one that misses new ones. An annual review, tied to the data protection fee renewal, is a simple way to remember.

Common questions