Report: Data Integrity Program Gap Assessment

This is a ready-to-use document structure for the deliverable a data integrity gap assessment actually produces: the diagnostic baseline that tells management where the program stands and what has to happen next. It is not a per-system risk assessment (see the Data Integrity Risk and Gap Assessment (Per System) for that layer) and it is not a warning-letter retrospective review (see the Report: Retrospective Data Review After a Data Integrity Finding for that document). It is the program-level roll-up: what was assessed, what was found, how bad it is, and what happens next, written so a remediation owner and a senior reader can both use it. 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

1. Purpose

This document records the data integrity gap assessment performed across <<FILL: SITE / ENTERPRISE>> to establish an accurate, honest baseline of the data integrity program relative to the architecture described in the organization’s data governance policy: system inventory, criticality tiering, data-flow mapping, the DI risk assessment, governance, and periodic review. It is an internal diagnostic, not a defensive document; its purpose is an accurate picture for the organization’s own management, not a submission to a regulator. Its output is a prioritized remediation roadmap that connects each gap to a business risk, assigns an owner, and sets a realistic timeline.

2. Scope

State plainly what was assessed and what was deliberately excluded, and why. An assessment that quietly narrows its own scope to what was easy to look at produces a false sense of coverage.

3. Methodology and inputs

Describe what was reviewed, who was interviewed, what was observed directly, and over what period, so the reader can judge the assessment’s own rigor. Documentation review alone is not sufficient; state where live configuration and work-practice observation were used.

4. Program-level summary

A short, plain-language statement written for a reader who will not read past this section. State the overall risk posture honestly; a summary with no significant findings on a program never assessed before should invite scrutiny of the assessment, not comfort.

<<FILL: 150-300 words. Cover: overall program risk posture, the number and severity mix of findings, the one or two systemic themes that matter most, and the headline of the remediation roadmap.>>

5. Results against acceptance criteria

Score the program against the acceptance criteria the organization’s DI program architecture defines, not against a generic checklist. This section is where the document earns its credibility: state Met, Partially Met, or Not Met for each, with the evidence, not an assertion.

6. Gap register

One row per finding. Classify severity using the organization’s own defined scheme; the specimen below uses Critical, Major, and Minor. Write each finding to the standard shown in the filled specimen: specific, evidenced, and tied to a regulation or guidance where applicable, not a general impression.

7. Systemic themes

Findings that repeat across otherwise unrelated systems point to a shared root cause, an unfinished onboarding process, an under-resourced review function, a training gap, and deserve a program-level response rather than being closed as isolated local fixes. List each theme and the findings it groups together.

8. Remediation roadmap

Sequence the findings into a realistic, risk-ordered plan. Tier 1 systems and Critical findings lead; do not sequence purely by ease of fix. State interim controls for anything that cannot close immediately, so open items are managed risk, not unmanaged risk.

9. Conclusion

State a single, direct conclusion on the program’s current state, supported by the sections above. This is not a pass or fail grade; it is an honest statement of where the program stands and the basis for believing the roadmap will close the gap to where it needs to be.

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). ICH Q9(R1), Quality Risk Management. ICH Q10, Pharmaceutical Quality System (management review as a continuous quality system element). 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

12. Approvals

Filled specimen

The following shows an illustrative, abbreviated version of the same document for a mid-size manufacturing and QC site running its first formal program-level gap assessment. The company, systems, and numbers are illustrative; replace them with your own.

Document control header (extract): document number DI-GAP-2026-04, assessment window 03 March 2026 to 18 April 2026, mixed internal and external team, trigger: proactive program build ahead of a planned regulatory inspection.

Program-level summary: The site’s GxP system inventory covers 34 systems, of which 29 were directly assessed in this cycle (the remaining 5 were commissioned inside the assessment window and are scheduled for the next cycle). The assessment identified 2 Critical findings, 9 Major findings, and 14 Minor findings. Two systemic themes account for a disproportionate share of the Major findings: shared or generic account use on standalone laboratory instruments, and unverified backup restore across three systems that share the same site IT infrastructure team. The remediation roadmap sequences both themes into Phase 1, ahead of individually lower-severity findings, because each is a root cause behind multiple line items rather than a single local defect.

Results against acceptance criteria (extract):

Gap register (extract):

Systemic themes (extract):

Conclusion: Overall program risk posture is Elevated, driven primarily by the absence, prior to this assessment, of a periodic review calendar and by two systemic root causes rather than by a large number of unrelated defects. Confidence that the roadmap closes residual risk to Controlled within two review cycles is high, contingent on the Phase 1 systemic actions being resourced as program-level fixes rather than deferred to individual system owners.

Common inspection findings this document prevents

• A gap assessment was run but produced only a flat list of findings with no severity ranking, so nothing could be prioritized and remediation stalled.
• Recurring findings across systems were each treated as unrelated local issues, so the same root cause reappeared at the next assessment.
• The document reads as more polished than the evidence supports, understating gaps the organization already knew about, which damages credibility on every other document once discovered.
• No documented acceptance-criteria scoring exists, so “is the program adequate” has no defensible answer beyond a general impression.
• Remediation timelines were set without an interim control, so open gaps sat as unmanaged risk rather than managed risk while work was in progress.

How to adapt this document

1. Set your document numbers, sponsor, and assessment window in the header.
2. Point section 2’s inventory basis at your actual, current GxP system inventory, not a partial or outdated list.
3. Use your organization’s own severity classification scheme in sections 6 and the summary if it differs from Critical/Major/Minor.
4. Score section 5 against the acceptance criteria your own DI program architecture and policy actually define; adjust the criteria list if your program’s documented acceptance criteria differ from the illustrative set here.
5. Feed every remediation item from section 8 into your real deviation, CAPA, or change control system in addition to tracking it here, so remediation is tracked to effectiveness, not just logged in a document.
6. Confirm every regulation in section 10 against the current published version before issue.