Why this matters
Inspections reward clarity and evidence: you understand the process, you followed it, and you can show it quickly. A prepared packet is a curated set of documents—digital or printed—that proves control over your data and systems without hallway hunts or last‑minute stitching. Good packets shorten interviews, reduce scope creep, and build confidence that your team is in control.
Plain‑English goal: If an inspector says “show me,” you can open one folder and hand over the answer in under 2 minutes—with the right context, owner, and approval trail.
What goes in the packet
What is a packet? A role‑specific binder (or read‑only folder) containing the minimum sufficient evidence to demonstrate: governance, training & access, validation & IT controls, and end‑to‑end traceability. Each packet has a cover sheet (purpose, owner, last review date), an index, and frozen copies (or links with version pins) of the artifacts listed below.
Acronym key used here
- DMP: Data Management Plan
- DVP: Data Validation Plan (edit checks/analytics plan)
- CRF: Case Report Form
- CCG: CRF Completion Guidelines (field‑by‑field instructions for completing each CRF from source)
- CSV: Computerized System Validation
- PV: Pharmacovigilance (safety)
- RACI: Responsible, Accountable, Consulted, Informed
- CAPA: Corrective and Preventive Action
- EDC: Electronic Data Capture
- AE / SAE: Adverse Event / Serious Adverse Event
- MedDRA: the coding dictionary for adverse events and medical history
Recommended folder layout (example)
Inspection_Packet/
00_Cover_Sheet_and_Index.pdf
01_Governance/
02_Training_and_Access/
03_Validation_and_IT_Controls/
04_Data_Lineage_and_Traceability/
05_Role_Specific_AddOns/
Governance & documentation
Plans & conventions (versioned):
- SOP index: the standard operating procedures (SOPs) in force during the study, with versions and effective dates, to show which version applied when the work was done.
- DMP (who does what, when, using which SOPs/tools).
- DVP (edit check catalog, risk‑based reviews, listings).
- CRF design spec and CCG (the rules sites follow to enter/transcribe).
- Coding conventions (dictionary versions, synonym lists, adjudication rules).
Role clarity: RACI spanning data review, query lifecycle, reconciliation, coding, interim analyses, and lock.
Change control: Logs and approvals for CRFs, edit rules, coding dictionaries, derivation algorithms, and EDC releases. Include impact assessments and effective dates.
Training & access
- Training matrix mapping roles → required modules/SOPs, with CVs and job descriptions for key staff.
- Completion evidence (dated certificates or learning management system (LMS) reports) before access was granted.
- Role‑based access (RBAC) roster: who has which permissions in EDC, coding tool, safety systems, listings portal; one personal account per user (no shared logins), with only the rights the role needs (least privilege).
- Periodic access reviews (e.g., quarterly, as the SOP sets) and prompt de‑provisioning records (departures, role changes).
- Part 11 awareness (21 CFR Part 11, the FDA rule on electronic records and signatures): short note on how electronic signatures and audit trails are used in your systems.
Validation & IT controls
CSV package: requirements → test scripts/protocol → executed results → deviations → re‑tests → approval.
- Include failed tests and their re‑test evidence (this shows real control).
- For a vendor‑hosted system (most EDC): the vendor assessment or audit, plus your own user acceptance testing (UAT) of the study build. The sponsor stays responsible for the validated state.
Release management: environment inventory (development, test and production: DEV/TEST/PROD), what’s in each, who approved promotion, and the exact version running at database lock.
Backup/restore controls: an approved SOP (backup scope, frequency, retention and restore testing) plus evidence of a successful restore test (dates, who performed/approved, target environment, data set restored, checksum or record counts reconciled).
Business continuity snippet: where to find disaster recovery plans and contact tree.
Data lineage & traceability
As‑received archive for external data (labs/devices/PV/randomization): immutable files with checksums; retain vendor transmittal emails/manifests.
Promotion logs from as‑received → staging → curated (include transformations, QC steps, and approvers).
CRF↔DB audit exemplars:
- Paper studies: a CRF‑to‑database audit of a sample (database values vs the paper CRF that data‑entry staff keyed them from). A difference is a finding unless the CCG justifies it (e.g., a rounding or unit rule) or a signed data clarification form documents the change.
- EDC: audit trail excerpts showing who changed what, when, and why. The site enters data straight into the database, so the check against source is the monitor’s source data verification (SDV).
Reconciliation logs (lab ↔ CRF, PV ↔ EDC, randomization ↔ EDC): owners, issues, routing, and closure.
Derivation catalog: input fields → algorithm (named & versioned) → output field; include a small unit‑tested example for each derivation.
Role‑specific add‑ons
- DM packet: DMP, DVP, query lifecycle metrics, reconciliation tracker, CRF↔DB audit samples, lock readiness checklist, signed lock approval and any unlock records.
- CSV/IT packet: validation plan/report, release notes, change control, backup/restore evidence, environment inventory.
- Coding packet: coding conventions, dictionary version history, auto‑coding rules, coding QC plan/results, re‑coding change log.
- PV packet: safety reconciliation plan, SAE workflow/RACI (sites report each SAE directly to PV; PV and DM reconcile the safety database with EDC), acknowledgements of electronic case transmissions (ICH E2B format), follow‑up aging metrics, narrative QC samples.
Pro tip: Put a one‑page “How to Navigate This Packet” in the cover sheet. It tells an inspector exactly where to find the five most‑asked items.
Typical “show‑me” requests
How to answer in the room:
- Start with a one‑sentence answer (“The site made the change on 2025‑03‑14 to correct an entry error it found in its source; here is the audit trail.”).
- Show the primary evidence (open the artifact; do not summarize it to death).
- Orient to fields inspectors care about: who / what changed / when / why and approvals.
- Offer the adjacent control (e.g., related SOP, training evidence, or change control ticket).
- Log it: record the request and what you handed over in the inspection request log. If you do not know, say so and follow up with the evidence; never guess.
Common requests and what to present
“Show me who changed this AE date and why.” → EDC audit trail entry with user ID, old vs new value, timestamp, reason for change, and follow‑up query/resolution if applicable.
“Prove you can restore the database.” → Restore test report: request/ticket, scope (which DB, which date), steps executed, record count/checksum comparison, tester/approver signatures, and test date.
“What exactly did you receive from the lab on March 10?” → As‑received file (frozen in archive) + checksum + promotion log showing when/where it was loaded and QC notes.
“Why do these two database values differ from the CRF?” → Paper: the CRF‑to‑database audit result; if the CCG does not justify the difference, show the audit finding and CAPA. → EDC: the eCRF entry is the database value, so there is no second copy to compare. If the value was changed, show the audit trail + the site’s reason for change + the query that prompted it.
“Which MedDRA version was used at lock and how did you control changes?” → Coding conventions doc (versioned), change control ticket for any dictionary update, and a freeze note at lock.
“Was anything changed after lock?” → The lock record and audit trail; for any change, the documented, approved unlock, the correction with its reason (the site corrects its EDC data; a vendor corrects and re‑sends its own data), the investigator’s re‑signature, the re‑lock approval and the re‑issued extracts.
Worked examples
Self‑contained scenarios you can practice with your team. Replace the dummy IDs and dates with your study’s.
Example 1 — EDC audit trail for an AE date correction
Scenario. AE start date recorded as 2025‑02‑09 instead of 2025‑02‑19. The site checked the source and corrected it in answer to a DM query.
Artifacts to show (open on screen):
- EDC Audit Trail for subject 012‑001, form AE‑01, field AE_START_DATE.
- Query history showing DM query → site response → closure.
- Excerpt from CCG explaining date capture rules (format, partial and unknown dates).
- Training record for the site user who made the change (to show they were trained before access was granted) and the site’s delegation log entry for that user.
Talking points.
- “User site_jchow changed AE_START_DATE from 2025‑02‑09 to 2025‑02‑19 on 2025‑03‑14 10:21 UTC with reason ‘transcription error; verified against source’. DM reviewed and closed query Q‑7842 on 2025‑03‑15. This aligns with CCG §3.2 on date transcription.”
Example 2 — Database restore test evidence
Scenario. Quarterly restore test for PROD backup into an isolated, access‑controlled TEST environment.
Artifacts:
- Backup/Restore SOP (ID & version).
- Restore test protocol and executed report (TEST environment, snapshot date 2025‑06‑01).
- Record count comparison (by key tables) and a checksum or hash list for file‑based subsystems.
- Approvals (tester, IT lead, quality assurance (QA)).
Talking points.
- “We perform quarterly restores per SOP IT‑BKP‑004 v3.1. Last test on 2025‑06‑10 restored the 2025‑06‑01 PROD snapshot into TEST. Post‑restore record counts matched 100% of the counts logged when the snapshot was taken, on patient, visit, query and audit‑trail tables. Report approved by IT and QA on 2025‑06‑12.”
Example 3 — As‑received lab file provenance
Scenario. Inspector asks what was received on 2025‑03‑10 from Central Lab A.
Artifacts:
- As‑received ZIP:
LabA_2025-03-10_Manifest.csv,LabA_2025-03-10_Results.csv. - Checksums (e.g., SHA‑256) for both files.
- Promotion log from staging to curated with validation notes (e.g., units normalization).
- Reconciliation log entry tying lab subject IDs to CRF.
Talking points.
- “Here is the immutable archive (created 2025‑03‑10 16:03 UTC) with SHA‑256 checksums. Promotion to curated occurred 2025‑03‑11, signed by Data Engineering. Any unit conversions are documented in the promotion log; DM reconciliation ran on 2025‑03‑13; two discrepancies went to the sites as queries and are tracked to closure in the reconciliation log.”
Example 4 — CRF vs database discrepancy handled via CAPA
Scenario. In a paper study, the CRF‑to‑database audit found blood pressure entered incorrectly from three CRFs.
Artifacts:
- CRF‑to‑database audit report listing the three subjects and the discrepancy details.
- CCG section for vital signs (it does not justify the differences).
- CAPA: root cause (data‑entry staff worked from an outdated reference sheet), correction (data‑entry staff corrected their keyed values to match the CRFs, under audit trail; the CRFs, the site’s record, were not changed), prevention (updated reference sheet + retraining).
- Data‑entry training log update date.
Talking points.
- “The three discrepancies were documented as audit findings, because the CCG does not justify them. Under CAPA CDM‑CAPA‑019 the data‑entry staff corrected the database to match the CRFs, the outdated reference sheet was replaced and the data‑entry staff were retrained on 2025‑04‑02. The audit of the next two CRF batches found no recurrence.”
Pitfalls & misconceptions
- “A backup is enough.” Inspectors want proof you can restore—with dates, people, steps, and reconciliations.
- Vendor logs are sufficient. Vendor audit trails are helpful, but you also need your own as‑received archives and promotion logs to prove provenance.
- Protocol text governs CRF behavior. In data entry and transcription, the CCG is the operational authority; the protocol sets intent, not button‑by‑button rules. The CCG must agree with the protocol: if they conflict, the protocol prevails and the CCG is corrected under change control.
- Over‑packing the packet. Quality beats bulk. Include the minimum sufficient artifacts and a clean index; avoid dumping entire shared drives.
- Unpinned versions. Always pin versions (SOPs, dictionaries, EDC releases) relevant to lock and major milestones.
- Unreviewed access. Lapses in periodic access review and de‑provisioning are common—and easily cited.
Practice in the wild (checklist)
- Build role‑specific packets (DM, CSV/IT, Coding, PV). Assign an owner and quarterly review cycle.
- Add restore test reports (latest + one prior) to CSV/IT packet, including failed → re‑test evidence.
- Keep 3–5 CRF↔DB audit exemplars (paper & EDC) ready with short talking points.
- Maintain a packet index with file paths, version pins, and access instructions.
- Confirm training before access and attach last two access reviews.
- Verify as‑received archives contain checksums and promotion logs show approvals.
- Pin dictionary versions and include change control for any mid‑study updates.
Key points to remember
- Inspections reward process control backed by evidence. Have the primary artifact ready to open in under two minutes—no hallway hunts.
- Packets are minimal, indexed, and version‑pinned. Curate only what proves governance, training/access, validation/IT controls, and lineage.
- Audit trails (21 CFR Part 11, ICH E6) capture the four essentials. Who made the change, what changed (old→new), when it changed, and why (reason/comment)—and know exactly where to retrieve and show this in your EDC.
- As‑received provenance is immutable. Freeze vendor files with checksums and use promotion logs to prove lineage from as‑received → staging → curated/analysis.
- Backups ≠ restores—show restore capability. Keep executed restore‑test reports with scope, steps, record‑count/checksum reconciliation, approvals, and dates.
- CCG governs day‑to‑day data entry; protocol sets intent. Use the CCG to defend data‑entry decisions and query outcomes; it must agree with the protocol and never overrides it.
- Traceability on demand. Maintain a few CRF↔DB audit exemplars and reconciliation logs (labs, PV, randomization) with short talking points ready to present.
- Versioning and change control are pinned at lock. Pin dictionary versions (e.g., MedDRA) and route any updates through change control with effective dates and approvals.