Does your proposal software vendor meet UK GDPR and ICO retention rules?

What to take away

What ICO retention guidance means for proposal and quote records

Proposal records are personal data. A quote usually carries a name, a work email, a job title, a company, sometimes a phone number and notes from a call. That is enough to identify a person, so the retention clock starts the moment the record is created.

The ICO's principle is straightforward: keep personal data no longer than you need it. The UK GDPR guidance and resources | ICO sets out storage limitation as a core principle, and it applies to a pipeline of quotes exactly as it applies to a customer database.

Most sales teams never set a period. Deals go cold, the quote sits in the tool, and nobody deletes it. That is the failure mode the ICO looks for when it receives a complaint from a prospect who asked to be forgotten and found their details still there.

What a defensible retention period looks like

A defensible period is short, written down and enforced by the system rather than by memory. Many UK sales operations settle on a period tied to the sales cycle plus a reasonable tail, then delete or anonymise.

What matters is that you can explain the number. If you keep quote records for two years, say why: contract disputes, HMRC record keeping, or a legitimate interest in re-engaging a prospect.

Where vendors get retention wrong

Vendors often keep deleted records in backups for years. Ask how deletion propagates, and whether a deleted quote disappears from search, exports and analytics as well as the main table.

Some tools keep an audit log of every record forever. That is defensible for security, but the log itself contains personal data. It needs a period too.

Retention is also a procurement question. If your organisation already struggles with this, the piece on what data protection means for England covers how sales teams in the larger English regions handle it day to day.

The UK GDPR lawful basis for holding prospect data in a proposal tool

You cannot put a prospect into a proposal tool because it is convenient. You need a lawful basis, chosen before processing starts and recorded in your privacy information.

For business-to-business sales the usual candidates are legitimate interests and consent. Consent is fragile in a sales context: a prospect who fills in a form has not necessarily agreed to a year of follow-up emails.

Legitimate interests is the common choice, and it comes with a test. You must show the interest is real, the processing is necessary, and it does not override the prospect's rights. A soft opt-in style approach works for existing enquirers; cold outreach needs more care.

Where the Data Protection Act 2018 fits

The Data Protection Act 2018 sits alongside UK GDPR and fills in the domestic detail, including law enforcement processing and the Commissioner's role. The Data Protection Act 2018 gives the ICO its powers and sets out offences, so your retention and security failures have a legal home beyond the GDPR itself.

For sales documents, the Act matters in two practical ways. First, it confirms the accountability principle: you must be able to demonstrate compliance, which means records of your lawful basis and retention decisions. Second, it underpins the enforcement regime if a prospect complains.

The Data (Use and Access) Act 2025

The Data (Use and Access) Act 2025 changes parts of the UK regime, including provisions that affect marketing data and how organisations handle personal data for research and business purposes.

The Data (Use and Access) Act 2025 is worth reading if your team runs outbound marketing from proposal data, because the reforms touch on consent, cookies and the ICO's structure.

The practical point for a vendor review is simpler. Ask whether the vendor's data processing agreement has been updated for the 2025 changes, and whether their retention defaults reflect the current regime.

Documenting the basis per use case

One tool, several uses, several bases. Sending a quote to an enquirer is one thing. Using the same record to improve an AI feature or to enrich a marketing list is another, and it may need its own assessment.

Write the basis down per use case in the DPA schedule or your own record of processing. If the vendor cannot tell you what they do with the data, you cannot complete that record.

Sub-processor lists and why they belong in your vendor review

A sub-processor is any third party the vendor uses to process your data. That includes cloud hosting, email delivery, analytics, CRM integrations, transcription services and AI suppliers.

Under UK GDPR you remain accountable to the prospect. If a sub-processor loses the data, the prospect complains to you, not to the vendor. That is why the sub-processor list clause belongs in every proposal software vendor review.

What the sub-processor list clause should say

A list buried in a help centre page is not enough. You want it in the contract, with a notification mechanism that actually reaches you.

Reading a sub-processor list properly

Look for three things. Where is the data stored? Which providers touch it? Can any of them use it for their own purposes?

The last question is the one that catches people out. A hosting provider that only stores data is low risk. An analytics or AI supplier that can use the data to improve its own systems is a different proposition entirely.

Sharing prospect data with vendors is covered by the ICO's rules on Data sharing | ICO, which set out the need for a clear purpose and a written arrangement before any data moves.

Regional variation in vendor stacks

Vendor hosting choices vary by market. Teams in Greater London and the South East often deal with US-headquartered vendors that host in Ireland or the United States. Firms in the North West, West Midlands, Yorkshire and the Humber, the East of England, Scotland and Wales more often buy from UK-based suppliers with UK data centres.

Neither is automatically better. What matters is that the transfer mechanism is documented and the sub-processor list is accurate. If your team is building this review from scratch, the argument for why vendor due diligence needs a written checklist is worth reading before you start scoring suppliers.

DPA clauses to check before you sign a proposal software contract

A data processing agreement is mandatory when a processor handles personal data on your behalf. It is not a nice-to-have appendix. Under Article 28 of UK GDPR it must contain specific terms, and a vendor that offers only a click-through page may not meet the bar.

Check the following clauses line by line. If a vendor resists any of them, treat that as a signal about how they will behave during an incident.

The clauses that decide the contract

Clauses that quietly weaken your position

The vendor may reserve the right to change the DPA unilaterally. It may cap breach notification at a vague "without undue delay". It may exclude sub-processor changes from the objection right. It may claim ownership of aggregated or anonymised data derived from your records.

Aggregated data sounds harmless. In a small market, a benchmark built from your quotes can be re-identifiable, and that is a personal data problem.

Where the contract sits in the wider deal

A DPA is one document in a commercial relationship that also includes pricing, service levels and exit. Teams that get this right tend to treat the legal pack as a single negotiation, which is the approach set out in the guide to choosing proposal software for commercial contracts without legal blind spots.

If your procurement team uses Crown Commercial Service frameworks or responds to Find a Tender Service opportunities, the DPA will also be checked against public sector requirements. That raises the bar rather than lowering it.

Handling AI features inside proposal software under ICO guidance

AI has arrived in proposal tools as drafting help, summarising, win-probability scoring and content writing. Each feature is a processing activity, and each needs a look before you switch it on.

The ICO's Artificial intelligence | ICO guidance sets out the expectations: a lawful basis, transparency, data minimisation, accuracy and human oversight. Those expectations apply to a sales tool as much as to a hiring algorithm.

The questions to ask about every AI feature

Does the feature send prospect data to a third-party AI supplier? Is that supplier on the sub-processor list? Is the data used to improve or train the AI, and if so, whose?

Can the feature be turned off per user or per workspace? Can you exclude sensitive fields, such as notes about a prospect's personal circumstances, from the AI input?

What happens to prompts and outputs? They are personal data if they identify a person, and they need a retention period.

Accuracy and human review

AI-written summaries of a sales call can be wrong. If a wrong summary drives a pricing decision or a credit assessment, you have an accuracy problem and possibly a fairness problem.

The ICO expects human review where outputs affect people. In a proposal tool that means a person checks AI-drafted content and AI-scored leads before they are used in a decision.

Transparency with prospects

Your privacy notice must explain that AI is used, what it does, and what data it processes. A generic line about "automated tools" is not enough when a prospect asks.

If the vendor cannot explain how their AI feature works well enough for you to write that notice, that is a reason to leave the feature off.

A note on vendor AI claims

Be sceptical of claims that a tool is "GDPR compliant" without qualification. Compliance is a property of your processing, not a badge a vendor can hold. Ask for the DPA, the sub-processor list and a description of the AI data flow instead.

A vendor due diligence checklist for data protection

Use this checklist before you sign, and repeat the relevant parts at renewal. It is designed for a data protection lead working with sales operations, and it assumes you have limited time.

Turning the checklist into a decision

The checklist is not a pass or fail exercise. It is a way to price risk. A vendor that scores badly on retention but well on security may still be usable for a short pilot with tight controls.

What you should not do is sign first and fix later. Retrospective DPAs are common and they rarely improve the vendor's position on deletion or sub-processors.

Who owns this internally

Data protection leads usually own the DPA and the record of processing. Sales operations own the configuration: retention rules, field-level exclusions and AI toggles. Procurement owns the contract terms.

Where those three roles do not talk, gaps appear. A retention period agreed in the DPA but never configured in the tool is not a retention period. A written disclosure policy protects your team when a colleague wants to paste prospect notes into a third-party tool, and it is worth having alongside the vendor review.

Reviewing the vendor after go-live

Due diligence does not end at signature. Set a review date, usually annually, and check the sub-processor list for changes, the DPA for updates after the Data (Use and Access) Act 2025, and the retention rules for drift.

If your organisation works across several UK regions, keep one central record. The rules are the same in England, Scotland and Wales, and a single register is easier to defend than regional variations nobody can reconcile.

Common questions