4.8 Mergers, Acquisitions & Divestitures Data Risk
Key Takeaways
- M&A is a high-risk privacy event because privacy debt acquired is privacy risk inherited — the acquirer becomes liable for the target's prior unlawful collection, missing DPAs, expired consents, and unrecorded transfers
- Pre-deal privacy due diligence must verify the target's data inventory, consents, vendor DPAs, breach history, transfer mechanisms, retention enforcement, and regulatory actions before signing
- Post-close integration must not dump target data into acquirer systems for new purposes — that creates unlawful secondary use; re-notice, re-paper DPAs, and align access before migration
- Divestiture requires tagging every dataset attributable to the carved-out business, returning or deleting it, and updating notices because a change of controller triggers notification obligations
- Pricing privacy debt into the deal and building business-unit data tags at integration (not at divestiture) are the two operational moves that make later separation tractable
Why M&A Is a Privacy Risk Event
Mergers, acquisitions (A), and divestitures (D) are among the highest-risk events in the privacy operational lifecycle because they transfer large volumes of personal data — often inherited without clean consent, inventory, or control alignment. The CIPM body of knowledge treats M&A due diligence (DD) as a distinct competency (III.E) because privacy debt acquired is privacy risk inherited: the acquirer becomes liable for the target's prior unlawful collection, missing data processing agreements (DPAs), expired consents, and unrecorded cross-border transfers.
The three phases a privacy manager must drive:
- Pre-deal due diligence — assess the target's privacy posture before signing.
- Integration — align controls, policies, contracts, and notices post-close.
- Divestiture / separation — return or delete data and disentangle systems.
Pre-Deal Privacy Due Diligence Checklist
| DD Area | What to Verify | Red Flags |
|---|---|---|
| Data inventory | Does an up-to-date record of processing activities (RoPA) or data map exist? | None exists, or only in the seller's head |
| Lawful basis & consents | Are collection notices accurate, current, and matched to actual processing? | Notice not updated since 2018; consents bundled |
| Vendor / sub-processor DPAs | Are DPAs and SCCs in place for every processor? | Spreadsheets of vendors with no contracts |
| Breach history | Breach register, regulator notifications, litigation | Undisclosed breaches; "we didn't notify because…" |
| Cross-border transfers | Transfer mechanisms and TIAs for each destination | Reliance on the invalidated Privacy Shield |
| Retention & deletion | TTL enforcement, legal holds, DSAR backlog | Indefinite retention by default; 90-day DSAR backlog |
| Security controls | Encryption, key management, access reviews, pen tests | No CMK; no MFA for admins |
| Privacy program maturity | Policies, training, designated privacy lead | "The CFO handles privacy" |
| Regulatory actions | Open investigations, fines, consent decrees | Outstanding GDPR Art. 58 orders |
| AI / ADMT use | Models trained on personal data, ADMT disclosures | Training data origins unknown |
The output of DD is not a checklist but a remediation plan with costs and dates that the deal team can price into the transaction or use as a walk-away condition.
Integration Phase — Risk and Control Alignment
After close, the acquirer must align the target's controls to the combined entity's standard — but not by simply dumping target data into acquirer systems. Bulk migration can create new unlawful secondary uses. The correct sequence:
- Re-notice or align notices — if processing changes (new purposes, new recipients, new jurisdiction), re-notify data subjects where required (GDPR Arts. 13/14, CCPA notice-at-collection).
- Re-paper DPAs — vendors inherited from the target must sign the acquirer's DPA template; SCCs may need re-issuance if the acquirer is in a different jurisdiction.
- Access alignment — revoke target access for terminated employees, map target roles to acquirer roles, and enforce least privilege.
- Control gap remediation — close encryption, MFA, logging, and retention gaps identified in DD; set a remediation timeline (e.g., 90 / 180 / 365 days).
- Data minimization at integration — do not migrate data the acquirer has no purpose for; delete or archive instead.
Divestiture — Data Separation, Return, and Deletion
Divestiture (carve-out, sale of a business unit, or wind-down) is the reverse problem: the seller must separate the divested business's personal data from its own and either return it to the buyer, delete it post-transition, or convert it to anonymized form. The transaction agreement should specify each step:
| Divestiture Step | Privacy Action | Common Pitfall |
|---|---|---|
| Data identification | Tag every dataset attributable to the carved-out business | Commingled ERP data with no business-unit field |
| Extraction & return | Clone and transfer to buyer; verify completeness | Backups and log archives forgotten |
| Ongoing access | Stand up a transitional service agreement (TSA) with explicit data-use scope | TSA used for unrelated analytics |
| Deletion at seller | Delete and crypto-shred originals and backups after TSA | "Soft delete" only; data still recoverable |
| Notice to data subjects | Update notices; honor objection rights | Silent change of controller without notice |
| Vendor re-papering | Re-direct DPAs to buyer or terminate | Processor keeps serving seller on stale DPA |
| Regulator notification | Notify authorities where control transfer triggers obligations | Filing missed because "it's just a sale" |
A CIPM-relevant legal hook: a change of controller generally requires notice to data subjects (GDPR Arts. 13/14 updated, CCPA notice-at-collection update). Some jurisdictions treat the sale of a business as a "sale" of personal data triggering opt-out or opt-in rights; the CCPA's sale-of-business exemption has conditions and a limited window, so verify the current scope rather than assuming the exemption always applies.
Worked Scenario — Acquiring an EU Payments Startup
A US fintech acquires a smaller EU payments startup. Due diligence reveals: (a) the target's privacy notice was last updated in 2019 and does not mention fraud-scoring automated decision-making (ADMT); (b) the target relies on a US sub-processor with no SCCs; (c) the target retains transaction data indefinitely "for analytics"; (d) no RoPA exists.
Pre-close: require remediation as a condition of close — execute SCCs with the US sub-processor, draft a notice update for post-close re-notification, and order a RoPA within 60 days. Price the privacy debt into the deal so the acquirer is paid for the remediation cost.
Post-close: re-notify EU customers of the ADMT use and the new controller; migrate vendors to the acquirer's DPA template; set a 7-year retention TTL with legal-hold override; align access to acquirer roles; and do not use target data for acquirer marketing — that is a new purpose requiring fresh consent.
Divestiture variant: if the acquirer later sells the unit, it must tag transaction data by business unit now, during integration, so the data can be cleanly separated later. Building the tag at integration is far cheaper than reconstructing it at divestiture. The privacy manager's deliverable is a separation plan that names every system, backup, and sub-processor holding the unit's data and the action (return, delete, anonymize) for each.
During pre-deal privacy due diligence, which finding most strongly indicates "privacy debt" the acquirer would inherit at close?
After acquiring a company, the acquirer wants to email the target's existing customer list to promote the acquirer's own (different) product. What is the correct privacy action?