This is a ready-to-use worksheet for assessing a GxP system, or a manual record-keeping process, against each of the nine ALCOA+ elements, so a data integrity risk assessment states a specific, checkable basis for every element rather than a single generic assertion that the system is “compliant.” Replace every <<FILL: ...>> placeholder with your own specifics and attach the completed worksheet to the system’s computerized system validation plan or, for a paper-based process, to the parent procedure. A filled specimen follows.
Document control header
| Field | Entry |
|---|---|
| Document title | ALCOA+ Data Integrity Risk Assessment for <<FILL: system or process name>> |
| Document number | <<FILL>> |
| Version | <<FILL>> |
| Assessment date | <<FILL>> |
| System or process owner | <<FILL>> |
| GxP-impact risk tier assigned by the parent VMP | <<FILL: e.g. Tier 1>> |
| Linked VMP and risk classification matrix reference | <<FILL>> |
1. Purpose
This worksheet records, element by element, whether <<FILL: system or process name>> supports each ALCOA+ principle natively, through its own design and configuration, or depends on a manual or compensating control, and names that control. It exists so a data integrity risk assessment has a specific, auditable basis rather than a blanket statement that invites exactly the follow-up question an inspector is trained to ask: compliant according to what evidence.
2. Scope
Applies to <<FILL: system name and version, or the manual process name>>, used for <<FILL: intended GxP function, e.g. release testing data capture, batch record execution, environmental monitoring, manual logbook entries>>. Data integrity is not a separate risk tier; this worksheet is run at the depth the parent VMP’s risk tier for this system or process already calls for, heaviest for Tier 1, proportionate for Tier 2, and not required at all for a Tier 3 item the VMP’s own scoping test has already excluded.
3. Methodology
For each ALCOA+ element, state whether the system or process supports it natively, through its own design, access controls, or audit trail, or depends on a manual or compensating control, and name that control specifically. A blank or a one-word “yes” is not an acceptable entry; the basis column has to name the actual mechanism, a timestamped audit trail, an individually badged login, a second-person verification step, or whatever the real control is. An element with no native support and no named compensating control is a finding, not a pass.
4. ALCOA+ assessment table
| # | Element | Native support, manual control, or gap | Basis | Finding, if any |
|---|---|---|---|---|
| 1 | Attributable, traceable to the specific person or system that generated it | <<FILL>> | <<FILL>> | <<FILL>> |
| 2 | Legible, readable and understandable for the full retention period | <<FILL>> | <<FILL>> | <<FILL>> |
| 3 | Contemporaneous, created at the time the activity happened | <<FILL>> | <<FILL>> | <<FILL>> |
| 4 | Original, the first recording or a true copy, not a transcription | <<FILL>> | <<FILL>> | <<FILL>> |
| 5 | Accurate, reflects what actually happened, with any correction visible | <<FILL>> | <<FILL>> | <<FILL>> |
| 6 | Complete, includes every result including a failing or out-of-specification one | <<FILL>> | <<FILL>> | <<FILL>> |
| 7 | Consistent, timestamps and sequence of events hold together internally | <<FILL>> | <<FILL>> | <<FILL>> |
| 8 | Enduring, will survive the full retention period including a system or media migration | <<FILL>> | <<FILL>> | <<FILL>> |
| 9 | Available, can actually be retrieved and reviewed on demand within the retention period | <<FILL>> | <<FILL>> | <<FILL>> |
5. Findings and remediation
| Finding # | Element affected | Description | Owner | Due date |
|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
An element with a finding is not closed by updating this worksheet alone; close it by implementing the control the finding identifies as missing, retesting, and recording the retest here.
6. Residual risk statement
<<FILL: state plainly whether, after remediation, every element is supported natively or by a named, implemented control, and whether any accepted residual risk remains, with the rationale for accepting it>>
7. Roles
| Role | Responsibility |
|---|---|
| System or process owner | Completes this worksheet, implements remediation for any finding |
| Validation lead | Confirms the risk tier used in section 2 matches the parent VMP’s current risk classification |
| Quality Assurance | Reviews and approves the completed worksheet, makes the final call on any accepted residual risk |
| Computerized systems owner, where applicable | Maintains the technical controls, audit trail configuration, access control, this worksheet relies on as the native-support basis |
8. References
FDA guidance, “Data Integrity and Compliance With Drug CGMP: Questions and Answers” (December 2018). MHRA, “GxP Data Integrity Guidance and Definitions,” revision 1 (March 2018). See the paired article, Validation Master Planning for a Clinical-Stage Biotech, for how ALCOA+ connects to the VMP’s own GxP-impact risk tiers.
Confirm the current version of each reference before issue.
9. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL>> | <<FILL>> | Initial issue. |
10. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Author (System or process owner) | <<FILL>> | ||
| Reviewer (Validation) | <<FILL>> | ||
| Approver (Quality Assurance) | <<FILL>> |
Filled specimen
Two contrasting assessments from an illustrative clinical-stage biologics program: an electronic batch record system, Tier 1, and the paper logbook it replaced in one suite still transitioning off paper.
Electronic batch record system, Tier 1
| # | Element | Support | Basis | Finding |
|---|---|---|---|---|
| 1 | Attributable | Native | Individual badge login required; shared credentials disabled at system configuration | None |
| 2 | Legible | Native | Data stored in the system’s own database, rendered on screen and in PDF export, no print-only or thermal media involved | None |
| 3 | Contemporaneous | Native | Each step time-stamped by the system at the moment of entry, not editable after the fact | None |
| 4 | Original | Native | System is the point of first entry; no transcription step exists in the workflow | None |
| 5 | Accurate | Native | Corrections require a documented reason code and preserve the original entry in the audit trail | None |
| 6 | Complete | Manual control | Procedure requires the operator to record an out-of-range reading and route it to a deviation, rather than the system blocking entry of an unfavorable result | Audit trail review confirmed no suppressed entries in the sampled period; control effective |
| 7 | Consistent | Native | System sequence logic blocks a review step from being signed before the preceding execution step is complete | None |
| 8 | Enduring | Manual control | Vendor-committed data migration plan exists for the system’s next major version, not yet executed | Open finding: migration plan execution tracked as a program gap, not closed by this worksheet alone |
| 9 | Available | Native | Audit trail export function tested and demonstrated to Quality Assurance during this assessment | None |
Paper logbook, same manufacturing suite, Tier 2 interim process pending full electronic conversion
| # | Element | Support | Basis | Finding |
|---|---|---|---|---|
| 1 | Attributable | Manual control | Procedure requires each entry to be initialed, with an initials-to-name key maintained separately | None, control effective and verified during this assessment |
| 6 | Complete | Gap | No reconciliation step confirms no page of the bound logbook is missing before archiving | Finding: add a page-count reconciliation step to the archiving procedure, owner Quality Assurance, due before the next periodic review |
Residual risk statement: the electronic batch record system is accepted with one open finding, the vendor migration plan, tracked to closure outside this worksheet. The paper logbook carries one accepted finding pending the reconciliation step described above; no other residual risk is accepted for either record-keeping method.
Common findings this worksheet prevents
- A data integrity risk assessment that states a system is “ALCOA+ compliant” with no element-by-element basis, so a later reviewer cannot tell which elements were actually checked.
- A vendor’s own platform-level testing evidence cited as the basis for every element, when the vendor’s testing speaks to the platform’s design, not to how this site’s specific configuration and use pattern actually produces records in practice.
- A manual compensating control named in the narrative but never verified as actually working, rather than tested and recorded as this worksheet requires.
- The “complete” element assessed only for whether passing results are captured, with no check for whether a failing or out-of-specification result could be excluded from the dataset undetected.
How to adapt this worksheet
- Run this worksheet at the depth the parent VMP’s risk tier for this system or process already calls for; do not run full element-by-element rigor on a Tier 3 item the VMP has already excluded from formal validation scope.
- Name the actual mechanism behind every “native support” or “manual control” entry; a basis column with no named mechanism is not a completed assessment.
- Treat any gap as a finding with an owner and a due date, not a narrative caveat buried in the assessment’s prose.
- Re-run this worksheet when the system is upgraded to a new major version, when a manual process it covers changes, or on the parent VMP’s periodic review cycle.