This is a ready-to-use charter for scoping a data integrity gap assessment before any system is touched. Its single job is to fix the boundary in writing and get it signed by a sponsor who can defend it, so that later, when the report is read, nobody can confuse what was deliberately excluded with what was simply missed. It is not the assessment itself, see the Data Integrity Risk and Gap Assessment (Per System) for the per-system evaluation and the Report: Data Integrity Program Gap Assessment for the roll-up output, this document is the gate that has to close before either of those starts. Replace every <<FILL: ...>> placeholder with your own specifics and route it through your normal document control, review, and approval. A worked filled specimen follows. This is educational structure to adapt, not legal or regulatory advice; verify each cited regulation against the current source before you rely on it.
Document control header
| Field | Entry |
|---|---|
| Document title | Data Integrity Gap Assessment Charter and Scope, <<FILL: SITE / ENTERPRISE>> |
| Document number | <<FILL: DOC-ID, e.g. DI-CHARTER-2026-01>> |
| Version | <<FILL: version>> |
| Date | <<FILL: date>> |
| Assessment sponsor | <<FILL: name, role, e.g. Head of Quality>> |
| Lead assessor | <<FILL: name, role>> |
| Trigger for this assessment | <<FILL: proactive program review, new program build, post-inspection lateral check, prior finding follow-up, other, state which>> |
1. Purpose
This charter fixes, before any system review or interview begins, what a data integrity gap assessment will cover, against what frameworks, over what period, at what depth, by whom, and with what deliverables. A scope that drifts during execution produces a report nobody can trust, because the reader cannot tell what was excluded by decision and what was overlooked. This charter is the record that answers that question.
2. Systems and processes in scope
| Item | Entry |
|---|---|
| System inventory basis used to define scope | <<FILL: reference to the current GxP system inventory>> |
| Systems / system families in scope | <<FILL: list, e.g. LIMS, CDS, MES, EDC, standalone spreadsheets>> |
| Processes in scope | <<FILL: audit trail review, access provisioning and deprovisioning, backup and recovery, retention and archival, DI training>> |
| People / work-practice observation in scope | <<FILL: roles and shifts, e.g. QC analysts on day and night shift, production operators>> |
3. Systems and processes explicitly excluded
A gap assessment that quietly narrows its own scope to what is easy to look at produces a false sense of coverage. Name every exclusion and the reason.
| Excluded system / process | Reason for exclusion |
|---|---|
<<FILL>> | <<FILL: e.g. commissioned after the assessment window and scheduled for the next cycle; covered under a separate supplier or clinical-site audit>> |
4. Regulatory frameworks assessed against
| Framework | Applies (Y/N) | Basis |
|---|---|---|
| FDA predicate rules, 21 CFR Parts 210 and 211 | <<FILL>> | <<FILL>> |
| 21 CFR Part 11, electronic records and signatures | <<FILL>> | <<FILL>> |
| EU GMP, EudraLex Volume 4 Annex 11 | <<FILL>> | <<FILL>> |
| FDA Quality Management System Regulation (21 CFR Part 820, harmonized to ISO 13485, effective 2 February 2026) | <<FILL>> | <<FILL: only where a combination product or device constituent is in scope>> |
| Combination-product cGMP, 21 CFR Part 4 | <<FILL>> | <<FILL: only where a combination product is in scope>> |
| MHRA GXP Data Integrity Guidance and Definitions | <<FILL>> | <<FILL>> |
| PIC/S PI 041, Good Practices for Data Management and Integrity | <<FILL>> | <<FILL>> |
| WHO Guideline on Data Integrity (Technical Report Series) | <<FILL>> | <<FILL>> |
| ICH Q9(R1), Quality Risk Management | <<FILL>> | <<FILL: the risk methodology the assessment scores against>> |
5. Time period and sampling window
| Item | Entry |
|---|---|
| Configuration review basis | Current-state as of the assessment date |
| Audit trail review record sampling window | <<FILL: e.g. prior 12 to 24 months>> |
| Access review record sampling window | <<FILL>> |
| Training record sampling window | <<FILL>> |
| Prior findings considered | <<FILL: prior gap assessment, 483, or warning letter findings reviewed as an input, reference>> |
6. Assessment depth per system
Depth is a decision, not a default. State the planned depth, desk review, walkthrough, or full technical testing, for every system named in section 2, and the trigger for any depth above walkthrough. See the parent article’s comparison of assessment approaches for how to make this call.
| System | Data criticality | Planned depth | Trigger for depth above walkthrough |
|---|---|---|---|
<<FILL>> | <<FILL: High/Medium/Low>> | <<FILL: Desk review / Walkthrough / Full technical testing>> | <<FILL: Tier 1, anomaly, prior finding, sponsor direction, or N/A>> |
7. Roles and responsibilities
| Role | Responsibility |
|---|---|
| Assessment sponsor | Signs this charter, removes obstacles, owns the result at management review |
| Lead assessor | Designs and runs the methodology, classifies findings independent of system owners, writes the report |
| Assessors / SMEs | <<FILL: named individuals or functions covering each system family>> |
| System owners | Provide configuration access, user lists, and procedures; do not classify findings about their own systems |
| IT / infrastructure | Provide network, backup, and clock-synchronization evidence |
| QA / document control | Maintains this charter and the resulting report as controlled records |
8. Deliverables and schedule
| Deliverable | Target date |
|---|---|
| Signed charter (this document) | <<FILL>> |
| System inventory reconciliation complete | <<FILL>> |
| Evidence gathering complete (all systems at their assigned depth) | <<FILL>> |
| Draft report issued for factual review | <<FILL>> |
| Final report issued | <<FILL>> |
| Remediation roadmap accepted at management review | <<FILL>> |
9. Acceptance criteria
This charter is complete and ready to govern the assessment when all of the following are true:
- Every in-scope system and process is named, and every excluded system or process has a stated, specific reason.
- The regulatory frameworks section states which frameworks apply and why, not a generic list.
- Every in-scope system has a planned assessment depth in section 6, and any depth above walkthrough names its trigger.
- Every role in section 7 is assigned to a named person or function before work starts.
- The sponsor has signed the charter before any system review, interview, or floor observation begins.
10. References
FDA, Data Integrity and Compliance With Drug CGMP: Questions and Answers (final, December 2018). MHRA, GXP Data Integrity Guidance and Definitions (Revision 1, March 2018). PIC/S PI 041-1, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments (effective July 2021). WHO, Guideline on Data Integrity, Technical Report Series (2021). ICH Q9(R1), Quality Risk Management. 21 CFR Parts 210 and 211; 21 CFR Part 11; EU GMP Annex 11.
Confirm the current version and clause numbers of each reference before issue.
11. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
12. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Author (Lead Assessor) | <<FILL>> | ||
| Approver (Assessment Sponsor) | <<FILL>> |
Filled specimen
The following shows an illustrative, abbreviated charter for a mid-size biologics manufacturing and QC site ahead of its first formal data integrity gap assessment. The company, systems, and numbers are illustrative; replace them with your own.
Document control header (extract): document number DI-CHARTER-2026-02, trigger: proactive program build ahead of a planned regulatory inspection, sponsor Head of Quality, lead assessor the site Data Integrity Lead.
Systems and processes in scope (extract): LIMS, CDS across six chromatography workstations, MES for two manufacturing lines, EDMS, and the standalone spreadsheet inventory maintained by QC (19 files). Processes in scope: audit trail review, access provisioning and deprovisioning, backup and recovery, DI awareness training. Work-practice observation across QC day and night shift and one production shift.
Systems explicitly excluded (extract):
| Excluded system / process | Reason for exclusion |
|---|---|
| Clinical EDC platform | Covered under a separate clinical QA audit scheduled the same quarter; results will be cross-referenced at management review |
| A pharmacovigilance case-processing system commissioned four weeks before the assessment window | Too new for meaningful audit trail history; scheduled for the next assessment cycle |
Assessment depth per system (extract):
| System | Data criticality | Planned depth | Trigger |
|---|---|---|---|
| CDS, release-testing workstations (6) | High | Full technical testing | Tier 1, release-critical |
| MES, production line 2 | High | Walkthrough, escalate if anomaly found | Tier 1, no prior finding |
| Standalone QC spreadsheets (19 files) | Medium to High per file | Walkthrough, full review for stability-supporting files | Known DI concern class, sponsor direction |
| EDMS | Low | Desk review | Recent internal document-control audit on file, low criticality |
Deliverables and schedule (extract): signed charter 3 March 2026, evidence gathering complete 27 March 2026, draft report 10 April 2026, final report 18 April 2026, roadmap accepted at the April management review.
Common inspection findings this charter prevents
- A scope that expanded or contracted mid-assessment with no record of the decision, so a later reader cannot tell exclusion from oversight.
- Every system defaulted to the same shallow depth regardless of criticality, so a Tier 1 system received the same one-hour walkthrough as a reference-only system.
- An assessment that began before the sponsor signed anything, so there was no boundary to hold the assessor accountable to.
- Roles named on paper with no individual assigned, so the assessment stalled waiting for someone to claim a task.
How to adapt this charter
- Set your document number, sponsor, and lead assessor in the header before anything else.
- Pull your actual, current GxP system inventory for section 2; do not scope from memory.
- Score the depth decision in section 6 against your own data criticality determinations, and keep the trigger column honest, a system is not “full technical testing” because it feels important, it is because it is Tier 1, anomalous, previously flagged, or specifically directed.
- Get the sponsor’s signature in section 12 before any floor work starts, not after.
- Confirm every regulation in section 10 against the current published version before issue.