Standard commercial and legal due diligence examines contracts, revenue, IP, and litigation exposure. It almost never examines the data estate with the specificity that GDPR requires. The result is predictable: buyers close on assets whose value depends on data that turns out to be partially or fully unusable under EU law. The remediation cost materializes post-close. The purchase price does not reflect it.
This framework covers five investigation areas that we apply in every pre-LOI GDPR review. Each area targets a specific failure mode that we encounter repeatedly in PE-backed acquisitions with EU data exposure. The framework is designed to surface findings that affect deal structure, valuation adjustments, and post-close integration planning.
1. Consent Architecture and CMP Configuration
The first investigation area is the consent management platform and its configuration. This is where the gap between stated compliance and actual compliance is widest. A company may represent that it collects consent for marketing communications. The question is whether the consent collection mechanism meets GDPR's specific requirements: freely given, specific, informed, and unambiguous.
What we look for in practice: CMP deployment scope (is it on every domain and subdomain, or only the primary website?), consent granularity (can users accept analytics but reject marketing, or is it a single accept/reject?), pre-checked boxes (still present in a surprising number of implementations despite being explicitly non-compliant since 2018), and consent record retention (does the CMP store a timestamped, per-user record of what was consented to, or only aggregate statistics?).
The CMP configuration also reveals how the company handles consent for different processing purposes. GDPR requires purpose-specific consent. A consent banner that bundles "analytics, personalization, and marketing" into a single acceptance is not granular consent under the regulation. Many CMP implementations do exactly this, because the default configuration from the vendor ships that way and the marketing team never changed it. The technical implementation matters as much as the policy language.
2. Lawful Basis Documentation and Article 30 Records
GDPR Article 30 requires controllers to maintain records of processing activities. These records must document, for each processing purpose, the lawful basis relied upon, the categories of data processed, the recipients of that data, and the retention period. In theory, every company with EU data subjects has these records. In practice, we find complete Article 30 records in fewer than one in five pre-LOI reviews.
The common failure is not the absence of records. It is the inconsistency between records and actual practice. A company may document "consent" as the lawful basis for email marketing in its Article 30 records but actually rely on "legitimate interest" in its privacy policy. Or the reverse. This inconsistency is not a paperwork problem. It is a legal risk. If the documented lawful basis does not match the actual processing activity, the processing is unlawful under GDPR Article 6, regardless of which basis would have been correct.
We request Article 30 records, the privacy policy, the CMP configuration, and the email marketing platform settings. We then cross-reference all four to identify misalignment. The pattern we find most often: the legal team wrote the privacy policy, the marketing team configured the CMP, the ops team set up the email platform, and the DPO (if one exists) wrote the Article 30 records. Four different teams, four different interpretations of the same legal requirement. The acquirer inherits all four.
Field observation: We reviewed a B2B SaaS target where the Article 30 records listed 11 processing activities. The actual MarTech stack involved 23 distinct data processing operations across 14 tools. Twelve processing activities were undocumented. Seven of those involved cross-border data transfers. None of the seven had Standard Contractual Clauses in place. The seller's data room contained a compliance certificate from an external audit conducted two years prior. That audit had reviewed the Article 30 records, not the actual data flows.
3. Data Processing Agreements and Sub-Processor Governance
GDPR Article 28 requires a written data processing agreement between the controller and every processor that handles personal data on its behalf. For a typical PE-backed company running a MarTech stack, the processor list includes the CRM vendor, the email service provider, the analytics platform, the advertising platforms, the CMP vendor, the data enrichment provider, and every integration middleware that touches personal data. A stack of 20 tools means 20 DPAs. Often more, because many tools use sub-processors.
The diligence question is not whether DPAs exist. Most large SaaS vendors include DPA terms in their standard agreements. The diligence question is whether those DPAs are adequate and current. "Adequate" means they include the mandatory Article 28(3) provisions: subject matter and duration of processing, nature and purpose, data categories, controller obligations, and the right to audit. "Current" means they reflect the actual data processing that is occurring, not the data processing that was planned when the agreement was signed three years ago.
We also examine sub-processor notification mechanisms. GDPR requires processors to notify controllers when adding or changing sub-processors. Most vendors handle this through email notifications that go to a generic inbox and are never reviewed. The result is that the target company's data may be processed by sub-processors the company does not know about, in jurisdictions the company has not evaluated, under contractual terms the company has not reviewed. This is a governance failure that becomes the acquirer's problem on day one.
4. Cross-Border Transfer Mechanisms
Data transfers from the EEA to third countries require a valid transfer mechanism under GDPR Chapter V. Since the Schrems II decision invalidated the EU-US Privacy Shield in July 2020, the two primary mechanisms have been the EU-US Data Privacy Framework (adopted July 2023) and Standard Contractual Clauses with a Transfer Impact Assessment.
The diligence focus here is specificity. It is not enough that a company "uses SCCs." The question is: are SCCs in place for every data transfer to a third country? Does each SCC include the correct module (controller-to-processor, controller-to-controller, or processor-to-processor)? Has a Transfer Impact Assessment been completed for each transfer, evaluating the laws of the recipient country against the protections required by GDPR? Are the supplementary measures documented?
For US-based acquirers, the cross-border transfer question has a second dimension. The acquisition itself may constitute a new data transfer. If the target's EU data was previously processed only within the EEA, and the acquirer's operating model requires that data to flow to US-based systems post-close, a new transfer mechanism must be established. This is an integration planning issue, not just a compliance one. If the acquirer's infrastructure is not DPF-certified and SCCs are not executed before the data moves, the transfer is unlawful from day one of the new operating model. We cover the AI-specific dimension of this problem in detail, particularly where training data crosses borders.
5. Data Subject Rights Infrastructure
GDPR grants data subjects the right to access their data (Article 15), rectify inaccurate data (Article 16), erase their data (Article 17), restrict processing (Article 18), receive their data in a portable format (Article 20), and object to processing (Article 21). The controller must respond to any of these requests within 30 days. The response must cover all personal data held by the controller across all systems.
The diligence question is not whether the company has a process for handling these requests. It is whether the company can actually fulfill them. Fulfillment requires the ability to locate all personal data for a specific individual across every system in the stack: CRM, email platform, analytics, advertising audiences, support tickets, billing records, and any data warehouse or lake. If the company cannot produce a complete data inventory per individual, it cannot fulfill access requests completely. Incomplete fulfillment is non-compliance.
What we evaluate: the intake mechanism (is there a dedicated channel, or do requests arrive via the general support queue?), the identification and verification process, the cross-system data location capability, the response template and QA process, and the tracking and documentation of each request. Companies that handle DSARs through manual email workflows are disclosing two things: they cannot scale the process, and they do not have unified visibility into their data estate. Both findings are relevant to the acquirer's post-close integration plan and cost model.