Compliance checklists are useful when they map to operational reality. Most GDPR checklists do not. They list regulatory requirements in legal language and leave the marketing team to figure out what it means for their CRM, their email platform, and their advertising workflows. The result is a checked box and an unclosed gap.
This checklist is different. It is structured around the six operational areas where PE-backed marketing teams carry the most exposure. Each area describes what compliance actually looks like in practice, what we find when we audit, and what closing the gap requires. This is drawn from direct engagement with portfolio companies across multiple PE firms.
1. Consent Record Integrity
GDPR Article 7(1) states: "Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented." Demonstrating consent requires a timestamped record, per contact, documenting what the individual consented to, when they consented, and how they were informed. This record must be retrievable on demand.
What we find in practice: consent records that exist only as a boolean field in the CRM ("opted_in: true/false") with no timestamp, no record of the consent language presented, and no linkage to the privacy policy version in effect at the time of collection. When a company migrates CRM platforms, consent metadata is frequently lost entirely. The contacts move. The proof of consent does not.
Closing this gap requires a consent management architecture that is independent of any single tool. The CMP should write consent records to a persistent store that includes: the data subject identifier, the timestamp, the specific purposes consented to, the version of the consent language displayed, and the method of collection (web form, in-app prompt, offline). This record must survive platform migrations, CMP replacements, and marketing stack overhauls. If the consent record lives only inside the CMP, it is one vendor switch away from disappearing.
2. Data Processing Agreement Inventory
Every vendor in the MarTech stack that processes personal data on behalf of the company is a data processor under GDPR. Every processor requires a written Data Processing Agreement under Article 28. The DPA must include specific mandatory clauses: the subject matter and duration of processing, the nature and purpose of processing, the types of personal data, the categories of data subjects, and the obligations and rights of the controller.
Marketing teams typically operate 15 to 40 tools that touch personal data. The DPA inventory should cover every one of them. What we find: DPAs exist for the large vendors (Salesforce, HubSpot, Google) because those vendors include DPA terms in their standard agreements. DPAs are missing for the mid-tier and small tools: the enrichment provider, the webinar platform, the chatbot, the survey tool, the CDN with analytics, the A/B testing platform. Each missing DPA represents an ungoverned data flow.
Building a complete DPA inventory is a one-time effort that requires ongoing maintenance. The initial build involves listing every tool that receives personal data, verifying that a DPA is in place, and checking that the DPA terms meet Article 28 requirements. The maintenance requires a process trigger: any time a new tool is procured, a DPA must be executed before personal data flows to it. This sounds obvious. In fast-moving marketing teams with self-serve SaaS procurement, it almost never happens without a formal process.
3. Data Subject Request Workflows
GDPR grants data subjects six rights: access (Article 15), rectification (Article 16), erasure (Article 17), restriction of processing (Article 18), data portability (Article 20), and objection (Article 21). The controller must respond within 30 calendar days. The response must be complete, covering all personal data held across all systems.
The operational challenge is cross-system data discovery. A single contact's personal data may exist in the CRM, the email platform, the analytics system, the advertising platforms (custom audiences), the data warehouse, the support ticket system, and the billing platform. Fulfilling an access request requires querying all of these systems, consolidating the results, and producing a structured response. Fulfilling an erasure request requires deleting or anonymizing the data across all of them and confirming completion.
What we find: marketing teams handle DSARs through email threads. The support team receives the request, forwards it to marketing, marketing manually checks the CRM and email platform, and someone sends a response. The analytics platform is not checked. The advertising custom audiences are not checked. The data warehouse is not checked. The response is incomplete, which means the company is technically non-compliant with every DSAR it fulfills this way. Building a repeatable DSAR workflow requires a documented system inventory, a query procedure for each system, a consolidation template, and a QA step before the response is sent.
4. Retention Schedules and Automated Enforcement
GDPR Article 5(1)(e) requires that personal data be kept "for no longer than is necessary for the purposes for which the personal data are processed." This is the storage limitation principle. It requires a defined retention period for each category of personal data and a mechanism to enforce that period.
What we find: retention policies that exist as PDF documents but have no technical enforcement. The policy states that marketing contact data is retained for 24 months after last engagement. The CRM contains contacts who have not engaged in four years. The email platform contains unsubscribed contacts from 2019. The analytics system retains pseudonymized but re-identifiable user data with no expiration. The policy is written. The data is not managed.
Closing this gap requires automated retention enforcement. Each system in the stack needs a scheduled process that identifies records past their retention period and either deletes or anonymizes them. For the CRM, this means defining "last engagement" precisely, running a query on a regular cadence, and automatically archiving or deleting qualifying records. For the email platform, this means purging unsubscribed and bounced contacts after a defined period. For the analytics system, this means configuring data retention settings at the property level. None of this is technically difficult. It requires operational discipline and a clear retention schedule that maps purposes to periods to systems.
5. CMP Deployment and Configuration Audit
The consent management platform is the front door of GDPR compliance for any company with a web presence. Its configuration determines whether consent collection is legally valid. A misconfigured CMP does not just create a compliance gap. It contaminates every record collected through it. If the CMP collects consent without meeting GDPR's requirements for freely given, specific, informed, and unambiguous consent, every record collected during the period of misconfiguration is legally unconsented.
The deployment audit covers four dimensions. First, scope: is the CMP deployed on every domain, subdomain, and web property that collects personal data? We routinely find companies where the CMP is active on the main website but absent from the blog subdomain, the careers site, the support portal, or the partner-facing documentation site. Each unmanaged property is collecting data without consent. Second, granularity: can users accept or reject specific processing purposes independently? A single "accept all" button without granular options does not meet the GDPR standard. Third, default state: are all non-essential purposes set to off by default? Pre-selected toggles for analytics or marketing purposes are non-compliant. Fourth, decline functionality: can a user decline all non-essential processing and still use the site? Cookie walls that block access unless the user consents are generally non-compliant under EDPB guidance.
The configuration audit should also verify that the CMP correctly signals consent state to downstream tools. If a user declines marketing cookies but the analytics platform still fires because the CMP's tag management integration is misconfigured, the consent architecture is broken at the technical level. This requires testing, not just configuration review. Load the site, decline all non-essential purposes, and verify that no non-essential tags fire. We find failures in this test in more than half of the implementations we review.
6. Breach Response Preparedness
GDPR Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach. Article 34 requires notification to affected data subjects when the breach poses a high risk to their rights and freedoms. These are hard deadlines. They require a pre-built response plan, not an ad hoc reaction.
What we find: breach response plans that exist as untested documents. The plan names roles and responsibilities but the named individuals have not been trained. The plan specifies a notification template but the template has not been reviewed by legal counsel. The plan references an incident classification framework but the marketing team does not know what constitutes a "breach" in the context of their MarTech stack. A misdirected email campaign that exposes personal data to the wrong recipients is a breach. An analytics misconfiguration that sends personal data to an unauthorized third-party domain is a breach. A CRM export saved to a shared drive without access controls is a potential breach.
Breach response preparedness for marketing teams requires three things. First, a clear definition of what constitutes a personal data breach in the marketing operations context, with specific examples drawn from the company's actual tools and workflows. Second, a documented escalation path with contact information for the DPO, legal counsel, and the supervisory authority. Third, a tested response: a tabletop exercise where the marketing team walks through a realistic scenario, from detection to notification, within the 72-hour window. Companies that have never tested their breach response process will not execute it correctly under time pressure. Testing reveals the gaps while there is still time to close them.