Privacy Due Diligence in M&A Transactions

This article accompanies Hour 4: Vendor Management Oversight in our full-day CPD programme on XpertAcademy. Completion of the full one-hour session, including the related learning materials, contributes to the one-hour CPD certificate issued for that session. You can access the course here: CPD Event A: Full-Day Regulatory Privacy Training.

A buyer is reviewing a fast-growing SaaS business that serves health and education customers. The target has strong recurring revenue, a valuable customer database, a credible product roadmap and an AI-enabled analytics feature in development. The commercial story is attractive. The data room is less reassuring.

The privacy folder contains a generic privacy notice, a short vendor list, a few customer DPAs, one old penetration test summary, an incomplete record of processing, and a breach log that appears to stop eighteen months ago. The target says the gaps are normal for a business of its size. The buyer’s deal team wants to know whether privacy is a signing issue, a price issue, a warranty issue, a completion condition or a post-completion integration action.

That is the real value of privacy due diligence in M&A. It is not there to produce a long list of theoretical GDPR points. It is there to help the buyer understand what data it is acquiring, what obligations come with it, what cannot lawfully or safely be done with it, what risks may transfer with the business, and what must be fixed before or after completion.

This article is general guidance, not legal advice on any specific transaction. M&A privacy risk depends on deal structure, sector, jurisdictions, data categories, contractual commitments, target maturity, regulatory history and the intended post-completion operating model.

Privacy due diligence should answer a commercial governance question: can the buyer use, protect, integrate and govern the target’s data in the way the deal model assumes?

Why privacy due diligence is not just a compliance checklist

In a transaction, personal data can be part of the value story and part of the risk story at the same time. Customer lists, user accounts, product analytics, employee records, clinical or learning data, marketing audiences, support tickets, vendor platforms, AI training inputs and usage logs may all affect valuation, integration planning and future growth.

The legal issue is not only whether the target has a privacy notice or a data processing agreement. The practical questions are sharper. Were the data collected for the purposes now assumed? Can the buyer receive and use the data after completion? Are customers, employees, students, patients or service users likely to be surprised by the new use? Are there contract restrictions on onward transfer, AI use, hosting location or subprocessors? Are there unresolved breaches, complaints or data subject requests? Are retention practices defensible? Are international transfers documented? Are processors and subprocessors understood?

The ICO’s M&A data-sharing guidance frames the issue in those terms: where a merger, acquisition or restructuring involves a transfer to a different or additional controller, data sharing should be considered as part of due diligence, including the original purposes, lawful basis, transparency, governance, accountability and security. The EDPB has also warned that mergers can have wider privacy implications, particularly where sensitive data, accumulation of data or changed use creates risk for individuals.

That means privacy due diligence should run early enough to influence the transaction. If privacy review starts only after completion, the buyer may inherit data it cannot use as planned, vendors it cannot evidence, transfer risks it cannot explain, or remediation work that should have been priced into the deal.

Phase the data sharing before completion

Data-room access is itself a data-sharing exercise. The target should not simply upload every customer, employee or user record because the buyer asks for detail. Pre-completion diligence should use phased disclosure, minimisation and access controls.

At the first stage, the buyer often needs aggregated facts: volumes, categories, jurisdictions, data subject groups, high-risk processing, customer commitments, vendor architecture, complaints, breach history and known remediation. The target should normally avoid sharing identifiable customer, patient, student or employee records unless there is a clear need.

At the second stage, where the buyer needs more detail, the parties can use redacted samples, anonymised or pseudonymised extracts, controlled access, clean-team review, narrowed reviewer lists and specific data-room permissions. Sensitive material such as special category data, employee relations files, safeguarding notes, health records, children’s data, support tickets, complaint details or breach evidence should be subject to tighter controls.

At the final stage, once signing or completion conditions are clearer, the parties can plan lawful handover, transparency updates, customer notices, employee communications, processor notifications and system integration steps. This is where the buyer should avoid assuming that completion automatically cures earlier data-sharing weaknesses. The legal basis, fairness, transparency, security and purpose-limitation questions still matter.

Phasing is commercially useful as well as privacy-preserving. It forces the deal team to ask what evidence is actually needed now, what can wait, and what level of detail is proportionate to the decision being made.

The data room should show how the business really runs

A privacy data room should not be judged by volume. A full folder can still hide weak governance if the documents do not connect to live processing.

The buyer should expect to see enough evidence to understand the target’s current data estate, not just its policy intent. That includes customer data, employee data, vendor data, product data, marketing data, analytics data, support data, security data and any special category or children’s data. In a SaaS, health, education or managed-service business, the same platform may hold several of those categories at once.

The review should also test whether records match reality. If the record of processing says the business has no special category data, but support tickets include health disclosures, accessibility needs, safeguarding details or employee medical notes, the record is not reliable. If the vendor register lists the main hosting provider but omits analytics, support, AI, CRM, monitoring, ticketing, payment and email tools, processor oversight may be thinner than the data room suggests.

The buyer does not need perfection. It does need candour. A target that can explain its gaps, show active remediation and give reliable ownership is usually in a stronger position than one with polished policies and no operational evidence.

A practical due diligence evidence pack

The evidence pack should be tailored to the transaction, but a buyer usually needs a structured view across data assets, legal basis, vendors, transfers, risk history and integration. The table below is a practical starting point.

This pack should produce a judgement record, not just a folder. The buyer should be able to say which risks are accepted, which are priced, which require warranty protection, which need pre-completion remediation and which become Day 1 or first-100-days actions.

Worked scenario: SaaS acquisition with health and education customers

Assume the buyer is acquiring a SaaS provider used by private clinics and education providers to manage appointments, progress notes, messages and service analytics. The target has around 180 business customers, including organisations in the UK, Ireland and several EU member states. It also has a small US support team, a cloud hosting provider, a CRM, a helpdesk platform, a product analytics tool and a trial AI feature that summarises support tickets for account managers.

The first data-room review identifies five gaps. The record of processing does not mention health-related notes entered by some customers. The vendor list does not include the AI summarisation tool or product analytics SDK. Marketing consents have been migrated twice and the target cannot easily distinguish customers, prospects, webinar attendees and bought-in event lists. The breach register records only notifiable breaches, with no evidence of lower-level incident triage. International transfers are described as “covered by standard terms”, but the file does not identify support access locations or onward transfers.

The privacy team should resist turning this into a generic red-amber-green exercise too early. The first job is to separate confirmed facts from unknowns.

The confirmed facts are that the platform can contain health and education-related data, the vendor register is incomplete, marketing provenance is weak, incident records are thin and transfer evidence is not yet sufficient. The unknowns are whether the target is a processor or controller for each relevant processing activity, whether customers have uploaded special category data outside the target’s intended design, whether the AI tool has been used on personal data, whether data has been used for model improvement, whether any incidents should have been notified, and whether customer contracts contain stricter terms than the standard DPA.

The deal question is not simply “is this compliant?” It is: what does this change about value, timing, contractual protection and integration?

The DPO or privacy lead would usually ask for targeted follow-up. For the product, request data-flow diagrams, sample customer configurations, support-ticket field lists, AI-tool terms, logs and retention settings. For customer contracts, sample the largest, most regulated and highest-risk customers rather than only reviewing the template. For marketing, request source files, consent wording, opt-out history, suppression handling and campaign segmentation. For vendors, request the live subprocessor list, contracts, transfer terms, support-access model and change-notification history. For breaches, request the security incident log, not only the formal personal-data-breach log.

The evidence created should be a transaction privacy note with a short risk register, a list of missing evidence, proposed warranty and indemnity points for legal counsel to consider, pre-completion questions, and a post-completion remediation plan. The DPO’s role is not to decide whether the deal proceeds. The DPO should help the controller understand data protection risk, residual uncertainty and the controls needed if the transaction goes ahead.

Red flags and deal impact

Privacy red flags do not all have the same deal consequence. Some are ordinary maturity gaps. Some change integration effort. Some create customer or regulator exposure. Some affect whether the buyer can use a data asset in the way expected.

The table should not be used mechanically. A red flag becomes material when it affects the transaction thesis, customer obligations, regulatory exposure, ability to integrate, or the buyer’s risk appetite.

Customer, employee and vendor data need separate treatment

M&A privacy reviews often blur different data groups together. That is a mistake.

Customer and user data usually receives the most attention because it may be part of the valuation story. The buyer should understand what was collected, from whom, for what purpose, under which contract and privacy notice, and what the target is allowed to do with it. In SaaS and service businesses, the target may process customer-controlled data as a processor while also acting as controller for account management, billing, analytics, security, marketing and product improvement. Those roles need to be separated.

Employee data raises different issues. Pre-completion sharing of identifiable employee records should be minimised. After completion, the buyer needs a lawful and fair route for HR integration, payroll, benefits, immigration checks, equality monitoring, employee relations, health and safety, occupational health, whistleblowing records and access controls. Employee data can include special category data and sensitive internal context, and staff may have strong expectations about who can see it.

Vendor data sits between privacy and operational resilience. The target’s processors, subprocessors and cloud providers may become the buyer’s risk on completion. EDPB Opinion 22/2024 is useful here because it emphasises that controllers should have readily available information about processors and subprocessors, and that verification of sufficient guarantees remains part of the controller’s accountability even where information is obtained through the processor. In a transaction, a thin vendor file is therefore not a tidy-up issue. It may be evidence that the target cannot fully explain its processing chain.

Marketing consents and data value

Marketing data deserves its own review because it is often treated as a commercial asset before anyone has tested whether it can lawfully be used.

The buyer should ask how each marketing segment was built: customers, free-trial users, newsletter subscribers, webinar attendees, event leads, bought-in lists, referral contacts, business contacts, abandoned registrations and product users. It should ask which lawful basis and ePrivacy or PECR route the target relies on, what consent wording was used, whether the soft opt-in is being claimed, whether the marketing relates to similar products or services, how opt-outs are captured, and whether suppression lists will transfer.

The risk is not only enforcement. It is commercial disappointment. A database valued as a growth asset may turn out to be partly unusable, poorly segmented or dependent on consent records the target cannot prove. Bought-in lists and old event leads are especially vulnerable to weak provenance. So are combined CRM records where customer service, account management and marketing history have been merged without clear preferences.

The practical answer may be segmentation rather than deletion of everything. Some records may be usable for service communications, some for B2B account management, some for marketing with consent, some under a soft opt-in route, some only after repermissioning, and some not at all. The diligence note should make those distinctions visible before the buyer relies on the data for revenue forecasts.

Special category data, AI and cloud tools

In health, education, HR, care, financial vulnerability and safeguarding contexts, special category data can appear even where the product was not designed as a clinical or high-risk system. Free-text fields, support tickets, uploaded documents, accessibility notes, complaint narratives and account-manager notes often contain more sensitive material than the product taxonomy suggests.

The buyer should test whether special category data has been anticipated in notices, contracts, security controls, DPIAs, access permissions, retention rules and customer instructions. If the target says “customers should not upload that data”, the buyer should ask whether the platform design, training, monitoring and support history make that statement credible.

AI and cloud tools add another layer. The buyer should identify any AI features inside the product, AI tools used by staff, AI-assisted support, automated analytics, profiling, customer scoring, transcription, summarisation, code assistants and document review tools. The review should cover data inputs, prompts, outputs, logs, model improvement, retention, human review, role mapping, subprocessors and international access. If AI or cloud diligence becomes the main publication angle later, this article can sit beside XpertDPO’s cloud AI due diligence guidance rather than replacing it.

The practical question is whether the buyer can explain what personal data went into the tools, who controlled the purpose, who processed the data, whether customers or employees were told, whether high-risk processing was assessed, and whether the tools can be governed after completion.

International transfers and global integration

International transfer risk is often hidden in support access rather than hosting. A target may say data is hosted in the EU or UK, while support, security operations, analytics, development or subprocessors operate from elsewhere. The buyer should separate storage location, processing location, remote access, onward transfers and emergency support.

For each material system, the evidence should show where data is stored, where it can be accessed from, which transfer mechanism is used, whether a transfer assessment or data protection test exists, what supplementary measures are relied on, and whether customer contracts impose stricter requirements.

Transfer diligence also matters for integration. The buyer may want to move the target onto its own cloud stack, CRM, identity provider, helpdesk, analytics platform or global support model. That change can alter the transfer position, the processor chain and the transparency story. If the target’s customers are in regulated sectors, transfer commitments may be commercially sensitive even where the legal mechanism is technically available.

This is why M&A privacy diligence should connect to the buyer’s global operating model, not stop at a pre-completion checklist.

Breach history, complaints and rights requests

A target’s breach file is one of the best tests of privacy maturity. A blank breach register is not automatically reassuring. It may mean the target had no incidents, or it may mean staff did not escalate incidents, only notifiable breaches were recorded, or security incidents were handled outside the privacy record.

The buyer should ask for the personal-data-breach log, lower-level incident triage records, security incident summaries, processor notifications, customer notices, regulator correspondence, complaints, DSAR records and open remedial actions. The aim is not to punish ordinary incidents. It is to understand whether the target can recognise, investigate, document and learn from them.

Rights requests and complaints can reveal integration risks too. A backlog of access requests, deletion disputes, marketing objections or customer privacy complaints may indicate weak records, weak deletion capability or unclear role allocation. If the buyer inherits those processes, it needs to know whether Day 1 operational support is required.

Where breach or complaint evidence is material, the deal team may need specific warranties, disclosure schedules, remedial undertakings, customer communications or integration controls. The privacy team should keep those recommendations factual and tied to evidence, not speculation.

Retention, deletion and post-completion integration

Post-completion integration is where privacy assumptions become operational. The buyer may want to combine CRMs, migrate users, merge HR systems, consolidate cloud providers, apply group retention rules, introduce a new identity provider, centralise support, switch analytics tools, train AI features or cross-sell to the target’s customers.

Each of those steps may change the privacy position. Integration can create new purposes, new recipients, new transfers, wider access, changed retention and different transparency obligations. It can also expose data quality issues. Duplicate records, stale prospects, old support tickets, archived employee data and customer-uploaded files may be expensive and risky to migrate if no one has tested whether they are still needed.

The buyer should create a post-completion privacy integration plan. It should identify Day 1 controls, first-30-day evidence gaps, first-100-days remediation, customer communication, employee communication, vendor rationalisation, transfer updates, DPIA or assessment reviews, record-of-processing updates, retention cleanup, deletion testing and governance ownership.

The plan should also say what will not happen immediately. If customer data cannot yet be combined with the buyer’s CRM, if marketing use needs cleansing, if AI features need assessment, or if sensitive customer data must remain ring-fenced until access controls are improved, those limits should be explicit. Good integration planning is often as much about restraint as action.

What the final diligence note should say

The final privacy diligence note should be short enough for the deal team to use and specific enough for legal, security and integration colleagues to act on. It should not bury the judgement under a long catalogue of documents reviewed.

In practice, it should describe the target data estate, the main privacy dependencies in the deal model, the key evidence reviewed, the evidence still missing, the material risks, the recommended deal treatment, and the post-completion remediation plan. It should separate issues that affect signing from issues that affect completion, price, warranties, indemnities, customer communications or integration sequencing.

The note should also preserve assumptions. If the target has not provided a complete subprocessor list, if marketing consent evidence has not been reconciled, if AI-tool use has not been technically verified, or if breach history is based only on management confirmation, the note should say so. Assumptions are not failures. Hidden assumptions are.

How XpertDPO supports M&A privacy diligence

XpertDPO supports organisations that need privacy due diligence to be practical, evidence-led and commercially useful. That may include reviewing a transaction data room, preparing targeted follow-up questions, assessing vendor and transfer evidence, reviewing marketing-data value, testing DPIA and AI governance gaps, preparing a privacy risk register, or helping the buyer plan post-completion integration.

For transaction-specific work, Data Protection Due Diligence for Corporate M&A is the natural service route. Where the issue is broader supplier governance, Vendor / Third-Party Privacy Governance and the articles on vendor oversight and legal characterisation and defensible vendor privacy lifecycles are useful companion pieces.

For multinational deals, Global DPO Operating Model can help align transfer, local-law and integration assumptions. For in-house privacy teams that need an independent challenge point during a live transaction, DPO Support can provide focused review without displacing internal ownership.

The aim is not to make privacy the department of deal hesitation. It is to make sure the buyer understands what it is acquiring, what it can safely do with it, and what must be fixed before inherited privacy debt becomes an integration problem.

This article is intended to support the learning covered in Hour 4 of our XpertAcademy CPD programme. The relevant CPD certificate is issued for completion of the full one-hour session on XpertAcademy, rather than for reading this article on its own. You can return to the course here: CPD Event A: Full-Day Regulatory Privacy Training.

Sources

• Information Commissioner’s Office, Due diligence when sharing data following mergers and acquisitions: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/data-sharing-a-code-of-practice/due-diligence/
• European Data Protection Board, Statement on privacy implications of mergers: https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_statement_2020_privacyimplicationsofmergers_en.pdf
• European Data Protection Board, Opinion 22/2024 on certain obligations following from the reliance on processors and sub-processors: https://www.edpb.europa.eu/system/files/2024-10/edpb_opinion_202422_relianceonprocessors-sub-processors_en.pdf
• Data Protection Commission, Data Protection Impact Assessments: https://www.dataprotection.ie/en/organisations/know-your-obligations/data-protection-impact-assessments
• European Data Protection Board, Guidelines 07/2020 on the concepts of controller and processor in the GDPR: https://www.edpb.europa.eu/documents/guideline/guidelines-072020-on-the-concepts-of-controller-and-processor-in-the-gdpr_en
• Data Protection Commission, Guidance for Organisations Engaging Cloud Service Providers: https://www.dataprotection.ie/en/dpc-guidance/guidance-organisations-engaging-cloud-service-providers
• Information Commissioner’s Office, International transfers: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/
• Information Commissioner’s Office, Direct marketing guidance: https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/direct-marketing-guidance/
• Information Commissioner’s Office, Guidance on direct marketing using electronic mail: https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-direct-marketing-using-electronic-mail/