Running a privacy and governance audit before regulatory inspection

# Running a privacy and governance audit before regulatory inspection

An FDA inspector arrives at a continuous glucose monitor (CGM) manufacturer. Within two hours they ask for the audit trail showing who accessed patient blood-sugar readings last March. The company pulls the log. It is empty. Nobody enabled logging on the analytics database. That single gap can trigger a Form 483 (the FDA's official list of inspection observations) and, if unresolved, a Warning Letter that halts shipments.

The fix is not luck on inspection day. It is a mock audit you run yourself, months earlier, against a concrete checklist. This lesson gives you that checklist.

Why device data pipelines are a governance minefield

A modern medtech pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition → moves data through many hands: sensor on the patient, mobile app, cloud ingestion, analytics warehouse, and sometimes a machine-learning model that flags anomalies. Each hop is a point where consent can be missing, access can be over-granted, or a breach can go unreported.

Two very different regulators care, and they ask different questions.

• FDA (US Food and Drug Administration): cares about data integrity and device safety. Its lens is 21 CFR Part 11 (rules for electronic records and electronic signatures) and, for the audit-readiness culture, 21 CFR Part 820 (Quality System Regulation, now converging with ISO 13485 under the 2026 Quality Management System Regulation transition).
• Data Protection Authorities (DPAs): cares about personal data rights. In the EU that means GDPR (General Data Protection Regulation); in the US, sector rules like HIPAA (Health Insurance Portability and Accountability Act) plus state laws such as California's CCPA/CPRA.

The trap: teams prepare for one and forget the other. Health data that is fine for the FDA on integrity grounds can still be a GDPR consent disaster.

The core concept: data integrity plus data rights

Think of your audit in two columns.

Data integrity (FDA lens). The industry shorthand is ALCOA+: data must be Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, and Available. If your CGM readings cannot be traced to a specific user and timestamp, they fail "Attributable."

Data rights (DPA lens). Did the patient consent to this specific use? Can they get their data deleted? Was a breach reported in time?

A good mock audit walks the pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition → once and scores every stage against both columns.

The mock audit checklist

Run this as a tabletop exercise with your data, legal, and quality teams in the room. Follow one real record end to end (pick a single patient's data and trace it).

1. Consent and lawful basis

• Is there a lawful basis recorded for every processing purpose? Under GDPR, "we collect glucose data to run the device" and "we use glucose data to train an AI model" are two different purposes needing two different justifications.
• For secondary use (research, model training), is consent specific and revocable? A single blanket checkbox at signup usually fails.
• Concrete gap to hunt: analytics teams pulling identifiable data for a use the patient never saw in the consent form.

2. Access controls

• Pull the actual access list. Who can read raw patient records? Compare against who *should*. This is the principle of least privilege.
• Look for shared service accounts (one login used by five engineers). These break "Attributable" and are a classic Part 11 finding.
• Check for orphaned accounts: former employees or offboarded contractors still active.

3. Audit trails and logging

• Is every read, write, and delete of personal data logged, with user ID and timestamp?
• Are logs tamper-evident (append-only, so nobody can quietly edit them)? Part 11 expects this.
• The CGM scene above is exactly this failure: analytics tier with no logging.

4. Data minimization and retention

• Are you storing more than you need? A model that only needs anonymized trends should not sit on raw names.
• Is there a retention schedule with automated deletion? "We keep everything forever" is a GDPR violation and a breach-blast-radius problem.

5. Breach notification readiness

• GDPR requires notifying the DPA within 72 hours of becoming aware of a breach that risks people's rights.
• HIPAA requires notifying affected individuals without unreasonable delay and no later than 60 days, and reporting large breaches (500+ individuals) to the Department of Health and Human Services (HHS).
• Test it: run a simulated breach. Start a stopwatch. Can your team identify affected records, assess risk, and draft the notice inside the window?

6. Vendor and cross-border transfers

• Cloud providers and sub-processors need signed Data Processing Agreements (DPAs, the contract kind).
• EU patient data landing on US servers needs a valid transfer mechanism (for example, Standard Contractual Clauses or the EU-US Data Privacy Framework). Verify it exists, do not assume.

A solid free reference for the integrity side is the MHRA "GXP Data Integrity Guidance and Definitions", widely used across regulated life sciences even outside the UK.

A worked example: scoring the breach-notification clock

Suppose your mock breach involves EU patients. Timeline of a realistic test:

• Hour 0: security tool flags unusual export from the warehouse.
• Hour 14: team confirms it is a real breach (this is "awareness" under GDPR, the clock starts here, not at hour 0).
• Hour 14 to 72 window: 58 hours to notify the DPA.

If your team took 40 hours just to identify which patients were affected because there was no clean data inventory, you have 18 hours left to assess and file. That is the gap the mock audit exposes. The number to track and improve is time-to-identify-affected-records. Drive it down and the 72-hour clock stops being terrifying.

A quick technical check you can actually run

Auditors love asking "prove least privilege." A simple query against your access-management data surfaces over-privileged accounts before they do:

-- Find accounts with read access to raw patient data
-- who have NOT accessed it in 90+ days (candidates to revoke)
SELECT u.user_id, u.role, MAX(a.access_ts) AS last_access
FROM user_grants u
LEFT JOIN access_log a
  ON u.user_id = a.user_id
 AND a.resource = 'patient_raw'
WHERE u.resource = 'patient_raw'
GROUP BY u.user_id, u.role
HAVING MAX(a.access_ts) < NOW() - INTERVAL '90 days'
    OR MAX(a.access_ts) IS NULL;

Rows returned are your cleanup list. NULL last-access rows are especially damning: access granted, never used, pure risk.

🎬 [VIDEO: "GDPR Explained in 5 Minutes" - youtube.com - a concise plain-language walkthrough of GDPR core principles for non-lawyers]

Turning findings into a remediation plan

A mock audit that produces a scary list and no plan is theater. Convert every finding into a tracked action.

For each gap, record four things:

1. Finding: "Analytics DB has no read logging."

2. Risk rating: high, medium, low (a logging gap on identifiable health data is high).

3. Owner and deadline: named person, real date.

4. Evidence of closure: a screenshot of the enabled log config, a revoked-access ticket, an updated consent form version.

This mirrors how the FDA expects you to respond to a real Form 483: not just "we fixed it," but with objective evidence and a root-cause analysis so the gap does not recur. The same discipline satisfies a DPA reviewing your accountability obligations under GDPR Article 5, which requires you to *demonstrate* compliance, not merely claim it.

Common patterns that fail both regulators at once

• The shared "analytics" account breaks FDA attributionattributionA framework for assigning credit to the touchpoints that contributed to a conversion, so you can measure which channels and interactions actually drive results. *and* GDPR access control.