GxP integrity, 21 CFR Part 11, and GDPR: what happens when three regulatory regimes collide

The concept in question is what practitioners call the "regulatory collision": the moment when GxP data integrity requirements, 21 CFR Part 11 electronic records rules, and the GDPRGDPREU regulation governing how organizations collect, store and use personal data, with fines tied to global revenue for breaches.View full definition →'s right to erasure demand incompatible things from the same dataset. This is not a compliance edge case. For any pharma company running clinical trials in the EU with US FDA oversight, it is a structural condition of daily operations.

The confusion comes from treating these three frameworks as parallel columns in a checklist. They are not parallel. They contradict each other in specific, predictable ways, and the CDO who has not mapped those contradictions will discover them during an inspection rather than in a gap analysis.

Why pharma CDOs face GxP, Part 11 and GDPR together

A CDO in consumer retail or financial services deals with privacy law and perhaps some sector-specific data rules. The pharma CDO deals with something categorically different: data records that are simultaneously subject to scientific integrity law, electronic systems regulation, and fundamental rights law, sometimes governing the same row in the same database.

GxP, the family of Good Practice guidelines covering manufacturing (GMP), laboratories (GLP), clinical trials (GCP), and distribution (GDP), requires that data be attributable, legible, contemporaneous, original, and accurate. The acronym is ALCOA, and every major regulatory body from the FDA to the EMA and MHRA treats it as the baseline for data integrity. ALCOA means you cannot delete a record without leaving a trace. Every change must show who made it, when, and why.

21 CFR Part 11, the FDA's rule for electronic records and electronic signatures, operationalises GxP integrity for digital systems. It mandates audit trails that capture the date and time of operator entries, computer-generated date and time stamps, and records of any changes to records. The record must be retained for as long as required by the relevant predicate rule, which for clinical data can mean decades.

The GDPR, specifically Article 17, gives EU data subjects the right to have their personal data erased. Article 5(1)(e) requires that personal data not be kept longer than necessary. Both provisions are enforceable by national data protection authorities who have no jurisdiction over clinical data integrity and no particular awareness of what a predicate rule is.

The collision is not theoretical. A clinical trial subject enrolled in a Phase III trial in Germany has GDPR rights over their personal data. That same data, linked to efficacy and safety records, may be required by the FDA as part of the NDA (New Drug Application) dossier for 15 years after approval. Honoring an erasure request in its conventional form would corrupt the audit trail and could render the trial data unacceptable to the FDA.

How do you honour GDPR erasure without breaking the GxP audit trail?

The legal basis that resolves most of this tension is GDPR Article 17(3)(b), which allows retention "for compliance with a legal obligation which requires processing by Union or Member State law." Clinical trial data retained under EU Clinical Trials Regulation No. 536/2014 and ICH E6(R2) GCP guidelines qualifies. The erasure right is suspended for that data, not waived entirely.

The practical architecture that follows from this has three components.

First, you separate identity from clinical record at the point of data capture. The sponsor holds a code-to-subject mapping; the clinical site holds the identifiable record. The trial database holds pseudonymised data linked by code. This is standard practice, but it matters here because it creates a data architecture where GDPR erasure can be partially honored (by destroying the linkage key) without touching the scientific record.

Second, you build consent and purpose registries that are legally distinct from the trial record itself. The consent form, the subject identification log, and the audit trail of consent withdrawals are personal data under GDPR and are subject to different retention schedules than the efficacy or safety data they relate to. Conflating them in a single table is a design error with real regulatory consequences. For a detailed treatment of how consent architecture interacts with de-identification limits in clinical data,the mechanics of consent and de-identification are worth working through carefully.

Third, you document every retention decision with explicit legal basis citations. When the CNIL, the German BFDI, or the ICO asks why you are holding a named patient's data, "because FDA said so" is not an answer. The answer is a mapped chain: predicate rule, retention schedule, legal basis under GDPR Article 6(1)(c) or (b) for clinical trial participants, and the Article 17(3)(b) exception applied specifically to the GxP record.

A concrete example: Roche's global clinical data management teams, like those at most large sponsors, maintain separate data domains for subject identifiers and trial observations, linked by randomisation codes held in validated systems under 21 CFR Part 11 controls. The audit trail on those systems is immutable. The consent registry sits outside the trial database and has its own retention schedule aligned to GDPR. Erasure requests are processed against the consent registry; the clinical record itself is legally protected from erasure under the exception above.

Limits of separating identity from the clinical record

This architecture handles the standard case well: a subject who withdraws consent after completing participation. The clinical record is retained; the consent documents follow their own schedule; the code-to-subject mapping may be destroyed if the trial is complete and re-identification is no longer operationally required.

It does not handle every case. A subject who requests erasure during an ongoing trial creates a data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.View full definition → problem that no architecture fully solves. The FDA expects complete datasets. Removing a subject from an ongoing trial mid-stream affects statistical integrity and must be reported in the clinical study report regardless.Understanding what GxP actually requires at the system level makes clear why partial deletion is almost never a permissible outcome once data has entered a validated system.

The framework also struggles with legacy systems. Many pharma companies still hold clinical data in systems that were designed before GDPR existed and whose audit trail architecture was built purely around 21 CFR Part 11. Retrofitting a GDPR consent layer onto a CTMS or EDC that stores subject identifiers and observations in the same schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → is expensive and sometimes requires a full data migration validated under GAMP 5. That validation itself generates records subject to Part 11.

The CDO who understands these collision points can make real architectural decisions before systems are built rather than after inspectors arrive. Separation of identity from observation at the schema level, explicit legal basis mapping for every retention class, and validated audit trails that satisfy both FDA and GDPR documentation requirements are not competing choices. They are the same governance problem approached from different directions, and the job is to design a single data model that answers all three at once.

The full course on this sector:Data in Pharmaceuticals.