What to check in UK marketing automation software contracts

What to take away

Why the contract, not the demo, decides your ICO breach exposure

When reviewing marketing automation software, assess the contract alongside the platform itself. A demo shows dashboards. A contract shows what happens at 2am on a Saturday when a vendor's email platform leaks a suppression list. UK buyers in Greater London, the South East and the North West increasingly run procurement exercises where the security questionnaire is scored and the data processing agreement is an afterthought. That ordering is backwards.

The ICO enforces against controllers. If your firm is the controller and the automation vendor is the processor, the regulator's first letter still arrives at your door. You then have to show what you instructed, what you monitored and what your contract required. A weak contract turns a vendor's mistake into your enforcement risk.

The same logic applies to PECR. Consent records, soft opt-in evidence and unsubscribe handling sit inside the automation platform. If the contract is silent on how those records are exported and preserved, you cannot answer an ICO query about how consent was obtained.

Procurement officers should treat the schedule of processing as the core commercial document. It defines categories of data, purposes, duration and security measures. Everything else, including price, is secondary to whether that schedule is accurate.

There is also a due diligence angle. Companies House records, director histories and filed accounts tell you whether the counterparty will exist in three years. Our guide to corporate identity to exit evidence sets out how to check a vendor before you sign anything.

The 72-hour ICO notification duty and who owns the clock

Under the retained UK GDPR, a controller must notify the ICO of a personal data breach within 72 hours of becoming aware of it, where the breach is likely to result in a risk to rights and freedoms.

The ICO's own guidance on Personal data breaches: a guide | ICO explains the risk test and the information a report must contain.

The clock starts when the controller becomes aware, not when the vendor finishes its investigation. That single sentence is the most commercially important line in any marketing automation contract. If your processor can sit on a suspected incident for a week while it runs internal checks, your 72 hours may already be gone.

The retained UK GDPR also places a duty on the processor. The processor shall notify the controller without undue delay after becoming aware of a personal data breach. That duty runs alongside the controller's own 72-hour clock, and the statutory wording sets no fixed number of hours.

So the contract must impose a shorter processor deadline. Common drafting is 24 hours from awareness, or immediately where the incident involves special category data or a large volume of records. The processor should notify a named UK contact, not a generic support queue.

The ICO's breach reporting route is its online “Report a breach” service, described on its Report a breach | ICO page. Your contract should require the processor to supply the facts you need to complete the report: nature of the breach, categories and approximate numbers of data subjects, likely consequences, and measures taken.

Where a breach is likely to result in a high risk to individuals, the controller must also tell those individuals without undue delay. The vendor must therefore provide affected-contact data fast enough for you to send that message. Test this in the pilot, not during an incident.

What the clause should say

A workable breach clause names the deadline, the recipient, the content of the notice, the evidence the processor must preserve, and who pays for forensic work, credit monitoring and regulator liaison. It also states that the processor may not notify data subjects or the press without your written approval, unless law compels it.

UK GDPR Article 28 processor terms to demand from a vendor

Article 28 of the retained text, available as Regulation (EU) 2016/679 (UK GDPR as retained), sets out what a processor contract must contain. It is not a menu. Each element is mandatory where a processor handles personal data on your behalf.

The ICO's Controllers and processors | ICO guidance is the practical companion. It explains that the controller determines purposes and means, while the processor acts only on documented instructions. Read it before you accept a vendor's standard terms, because many SaaS agreements blur the two roles.

Article 28 terms to demand, in plain terms:

That is seven items, and vendors routinely water down at least three. Sub-processor lists are often a URL the vendor can change at will. Audit rights are often replaced by a security page. Deletion is often a 90-day backup retention note buried in an appendix.

Controller and processor roles under ICO guidance matter most where a vendor uses your data for its own purposes, such as product analytics or benchmark reporting. If it does, it is acting as a controller for that activity and needs its own lawful basis.

Your contract should either prohibit that use or carve it out explicitly with a separate lawful basis and transparency wording.

Resellers and agencies complicate this further. A UK agency reselling a US platform may be a processor to you and a controller in its own right for its client list. Get the chain in writing. Our piece on processing instructions to exit walks through the eight contract issues that recur in these arrangements.

UK data residency clauses and the international transfer question

UK data residency clauses should say where data is stored, where it is processed and where support staff can access it. "Hosted in the EU" is not the same as "not accessible from outside the UK". Access is processing.

Ask for a data flow map. It should name the primary region, the disaster recovery region, the sub-processors in each, and the support locations. For a UK retailer with customers in Wales and Scotland, a failover to a US region is a transfer even if the primary database never moves.

The ICO's International transfers | ICO guidance sets out the mechanisms available. These include adequacy regulations, the International Data Transfer Agreement, the UK Addendum to the EU standard contractual clauses, and the transfer risk assessment that sits alongside them.

Adequacy is the simplest route where it applies. For US transfers, the UK Extension to the EU-US Data Privacy Framework can work for organisations that have certified, but you must verify current certification rather than accept a logo in a slide deck.

Where transfers rely on the IDTA or the Addendum, the contract should attach the signed version as an annex, not reference it. It should also require the vendor to tell you if the mechanism changes and to cooperate with a fresh transfer risk assessment if the legal position shifts.

Public-sector buyers on Crown Commercial Service frameworks will usually find residency and transfer terms already constrained. Private buyers in the West Midlands or Yorkshire and the Humber have more room to negotiate, and should use it. Residency is a commercial term as much as a legal one.

Residency questions to put in writing

Ask which sub-processors can access production data, whether support sessions are recorded, whether test environments use production data, and what happens to data in a failover event. Vendors answer these differently once the question is in a tender document.

Exit, deletion and return-of-data obligations in writing

Exit is where most automation contracts are weakest. The platform holds contact records, consent histories, engagement scores, suppression lists and campaign assets. Losing any of them creates operational and compliance harm.

Exit and deletion obligations should cover four things: what is returned, in what format, by when, and what happens to copies. Return should be in an open, documented format, with field definitions, and should include consent and suppression records, not just the contact table.

Deletion should be certified. A certificate of destruction, signed by an authorised officer, is worth more than a clause saying data "will be deleted". Where backups cannot be purged immediately, the contract should state the maximum retention period and confirm the data will not be restored except for disaster recovery.

The contract should also address derived data. Scores, segments and model outputs generated from your contacts are still personal data if they relate to identifiable people. Confirm they are deleted or returned on the same timetable.

Pricing for exit deserves attention. Some vendors charge professional services rates for exports, or release data only after final payment. Our analysis of where budgets leak across data, labour, assurance covers the exit fees that appear late in the relationship.

Finally, exit should be tested. A documented export run at month three proves the process works and reveals format gaps while you still have room to push back. Treat it as part of onboarding, not as a break-glass exercise.

A clause-by-clause checklist for a UK marketing automation contract

Use this as a redline guide. Each line maps to a term the ICO or a UK court would expect to see.

Then work through the operational checklist:

That last point matters. Uptime credits are standard. Credits for late breach notification are rare and worth asking for. Tying remedies to service standards tied to harm rather than round numbers gives you a lever when a vendor misses a deadline that mattered.

Where the vendor will not move on liability, consider a side letter or a parent company guarantee. A UK subsidiary with limited assets is a thin counterparty for a breach affecting a million contacts.

Negotiating points when the vendor is a US processor

US vendors usually start from their own template, drafted for US law. Expect the data processing agreement to be an addendum, the breach clause to be vague, and the deletion clause to reference backup cycles rather than certification.

The first negotiation is the breach clock. Ask for notification within 24 hours of awareness and define awareness to include any employee of the vendor or its sub-processors. US templates often say "without undue delay" and leave it there.

The second is the transfer mechanism. If the vendor relies on the UK Extension to the EU-US Data Privacy Framework, verify certification and require notice if it lapses. If it relies on the IDTA, get it signed and annexed rather than incorporated by reference to a webpage.

The third is deletion and exit. US templates frequently allow the vendor to retain data for product improvement or aggregated analytics. Carve that out or define aggregation so that re-identification is impossible.

The fourth is governing law and forum. Many US vendors propose their home state. For a UK contract, English law and the courts of England and Wales are the sensible default, particularly where the data subjects are in the UK.

The fifth is liability. Expect a cap tied to fees paid in the previous twelve months. Push for a carve-out for breach of data protection obligations, or at least a higher sub-cap. Without it, the remedy is smaller than the harm.

Practical sequencing

Run the legal review alongside the security review, not after it. Ask for the data processing agreement, the sub-processor list and the transfer documents before the commercial proposal is finalised. Vendors negotiate hardest before the deal is signed, and that is your window.

Common questions