GDPR due diligence assesses whether a target company can explain, protect and lawfully use the personal data an acquirer will inherit. It reviews UK GDPR evidence such as lawful basis, retention, processor contracts, breach history, international transfers and technical controls, then translates gaps into deal risk, remediation effort and post-close priorities.
For investors and acquirers, data protection is not just a compliance checklist. Personal data often sits inside the product, customer success workflows, analytics stack, marketing systems and operational tooling. If the target cannot show where that data is, why it is held, who can access it and how long it is retained, the buyer may inherit an obligation it has not priced.
FoundationState's technical due diligence service treats GDPR and data protection as an evidence-led risk workstream: scope the data-bearing systems, review the data room, test policies against operational practice, interview technical and operational owners, calibrate findings and turn the output into a readout the deal team can act on. This is not legal advice. It is technical and operational assessment that supports the legal diligence process.
What should GDPR due diligence cover?
GDPR due diligence should test whether the target has a credible operating model for personal data. The review should cover the data inventory, lawful basis, records of processing, retention rules, processor agreements, international transfers, breach history, data subject rights handling and the technical measures that protect the information in practice.
The ICO Guide to UK GDPR is the authoritative UK reference point for organisations handling personal data. In diligence, the question is not whether the target can quote the rules. It is whether it has evidence that the rules are understood, owned and embedded into day-to-day systems.
| Evidence area | What to request | Deal risk it helps test |
|---|---|---|
| Data inventory | Systems holding customer, employee, prospect and user data | Whether the buyer knows what personal data it is acquiring |
| Lawful basis | Records explaining consent, contract, legitimate interests or legal obligation | Whether core processing can continue after completion |
| Retention | Policy, deletion schedules and product behaviour | Whether old data is retained beyond need or policy |
| Processor contracts | DPAs, subprocessors and security schedules | Whether third parties create unpriced compliance or vendor risk |
| Breach history | Incident records, ICO correspondence and customer notifications | Whether historic issues require disclosure or remediation |
| Technical controls | Encryption, access control, audit logging and backups | Whether policies are reflected in the platform and tooling |
The output should separate legal interpretation from operational evidence. Counsel may advise on liability, contractual protection and disclosure. The technical diligence team should show whether the systems, people and controls make the target's position credible.
Do acquirers inherit data protection liabilities?
Data protection risk can survive the acquisition because the buyer inherits the business, systems, customer relationships and data-handling practices. A historic breach, weak retention practice, missing processor agreement or unlawful processing pattern does not disappear because ownership changes. The new owner may also create fresh risk if integration changes who accesses data or where it is processed.
This is why privacy diligence needs to connect with cyber security due diligence. A target may have reasonable policies but weak access control, no MFA coverage, unmanaged administrator accounts or limited incident logging. Those weaknesses affect whether the company can prove it protected personal data appropriately.
The risk is not always binary. Some findings are housekeeping: update a processor register, remove dormant accounts, or document a legitimate interests assessment. Others affect value: unclear lawful basis for a core revenue workflow, customer data stored in unsupported systems, unmanaged health or children's data, or an undisclosed incident that could trigger contractual and regulatory consequences.
In our diligence engagements, the most useful framing is inherited obligation plus remediation effort. What personal data does the buyer receive on Day 1? Which obligations continue? Which gaps need action before integration? Which findings should become conditions, warranties, disclosure points or post-close workstreams?
Which records and policies should the data room include?
A strong data room gives reviewers a clear line from policy to practice. It should include records of processing activities, data maps, privacy notices, retention policy, deletion procedure, breach register, data subject access request records, processor agreements, subprocessor lists, transfer impact assessments, security policies and evidence of governance ownership.
The absence of a document is not automatically a severe finding, especially in smaller or earlier-stage companies. The bigger concern is when the team cannot explain how personal data moves through the business. If nobody owns the data map, nobody can reliably answer what is in scope for deletion, breach response, customer migration or integration.
Reviewers should also ask how policy changes reach product and engineering teams. A retention policy is weak evidence if the application has no deletion workflow. A privacy notice is weak evidence if analytics tools collect events that are not listed. A processor agreement is weak evidence if engineering can add new tools without review.
This links to the broader pattern of technical due diligence red flags: policy theatre, undocumented ownership, manual workarounds and undisclosed incidents often appear together. They suggest that the target treats data protection as a document set rather than an operating discipline.
How should processors, transfers and breach history be tested?
Processor review should start with the systems that matter commercially: hosting, analytics, CRM, support tooling, payment systems, marketing automation, product telemetry, identity providers and outsourced development environments. The diligence question is whether the target knows which processors handle personal data, what they do, where they process it and whether appropriate agreements are in place.
International transfers deserve practical attention. Many UK software companies use global cloud and SaaS providers. That is normal, but the target should be able to explain its transfer mechanism, subprocessor review and customer commitments. If the company sells into regulated sectors or enterprise customers, weak transfer evidence may become a contract risk as well as a compliance risk.
Breach history should be reviewed with care. A company that records incidents honestly and can show containment, notification decisions and remediation may be lower risk than a company claiming no incidents without logs, tickets or ownership. The aim is to test incident maturity, not punish transparency.
Data subject rights are another useful signal. DSAR, deletion, rectification and objection workflows reveal whether privacy rights are handled manually, systematically or not at all. Manual handling can be acceptable at small scale, but the buyer should understand the operational burden if customer volume grows after completion.
What technical measures prove data protection practice?
Technical measures are the point where privacy claims meet operational reality. Reviewers should look for encryption in transit and at rest, access control, role separation, MFA, audit logging, backup protection, vulnerability management, environment separation, secrets handling and secure deletion. These controls show whether personal data is protected in systems, not just described in policy.
The evidence should be sampled. For example, if management says access is role-based, reviewers can inspect identity groups, administrator lists and production access patterns. If the target says data is deleted after a defined period, reviewers can test whether the database, backups and analytics exports follow that rule. If the target says sensitive data is encrypted, reviewers can ask where keys are managed and who can use them.
Some data needs extra scrutiny. Children's data, health information, financial data, precise location data and employee records may increase sensitivity and commercial exposure. Diligence should identify where special category or sector-sensitive data appears, who has access, and whether the controls are proportionate to the risk.
Data governance also overlaps with AI and analytics. If the target uses customer data for machine learning, enrichment or automated decision support, reviewers should test provenance, consent or lawful basis, retention, model dependency and whether customer contracts restrict secondary use. FoundationState's work on AI readiness and data governance in product due diligence covers that adjacent product and data-governance risk in more depth.
How do findings translate into deal decisions?
Data protection findings should be mapped to commercial action. A missing register is not the same as unlawful processing of a core dataset. A weak processor review is not the same as an undisclosed breach. The report should identify severity, likelihood, evidence confidence, ownership and remediation effort, then show which findings matter before close and which can sit inside a 30-60-90 day plan.
Common remediation paths include consolidating the data inventory, updating privacy notices, completing processor agreements, removing unnecessary data, tightening administrator access, improving audit logging, formalising DSAR handling, reviewing international transfer mechanisms and assigning clear ownership to a named leader.
For boards and investors, the important question is whether the risk changes deal confidence. Does the target need a disclosure update? Should warranties or indemnities be revisited? Is there a Day-1 access or deletion issue? Does the remediation budget belong in the investment model? Do integration plans need to avoid moving data into new systems until lawful basis and processor terms are clear?
FoundationState's experience with Finex Advisory reflects the same operating principle: diligence should turn complex technology risk into decisions that investors, boards and management teams can sequence. Data protection findings are most useful when they are specific enough to own and practical enough to fix.
Get an independent view before inherited data risk becomes a post-close surprise. Contact FoundationState to scope GDPR due diligence around data protection evidence, technical controls, processor risk and remediation planning for your next acquisition or investment.
Frequently Asked Questions
Do GDPR liabilities transfer in an acquisition?
They can. The buyer may inherit systems, records, processing practices, customer commitments and historic issues that continue after completion. Legal counsel should advise on liability and contractual protection, but technical diligence should test the evidence behind data handling, access control, breach history and remediation effort so the deal team can price and plan the risk.
What data protection documents should due diligence request?
Request records of processing, data maps, privacy notices, retention policies, deletion procedures, processor agreements, subprocessor lists, breach registers, DSAR logs, transfer assessments, security policies and governance ownership evidence. The goal is to understand both the documented position and whether product, engineering and operational teams actually follow it.
How far back should breach history be reviewed?
Review enough history to understand incident maturity, recurring patterns and any unresolved customer, contractual or regulatory exposure. The exact period depends on sector, data sensitivity and deal risk. Reviewers should compare breach records with security tickets, support incidents, audit logs and leadership interviews rather than relying only on management's summary.
