This is a ready-to-use pre-deployment assessment form. Complete it for every candidate GxP computerized system before purchase or contract, score each vendor against the same requirements, and route the completed form through your normal document control. It supports the new system assessment element of a data governance program; see the Policy: GxP Data Governance Program for where this fits in the wider program, and the Form: GxP Applicability (System Determination) Assessment for the earlier question of whether the system is GxP at all. Replace every <<FILL: ...>> placeholder. A worked filled specimen follows. Verify each cited regulation against the current source before you rely on it.
Document control header
| Field | Entry |
|---|---|
| Form title | New System Data Governance and DI Capability Assessment |
| Form / record number | <<FILL: FORM-ID, e.g. FRM-QA-041>> |
| Parent policy | <<FILL: POL-ID for the data governance program policy>> |
| Candidate system | <<FILL: SYSTEM / PRODUCT NAME>> |
| Vendor | <<FILL: vendor name>> |
| Intended GxP use | <<FILL: process / decision this system will support>> |
| Assessor | <<FILL: name, role>> |
| Assessment date | <<FILL: date>> |
1. Purpose
This form records whether <<FILL: SYSTEM / PRODUCT NAME>> meets the data integrity requirements <<FILL: COMPANY NAME>> requires of any system before it enters GxP use. It converts the data integrity requirements in the user requirements specification (URS) into a scored, evidence-backed decision, so that a gap is closed by contract negotiation before purchase rather than discovered, at far greater cost, after go-live.
2. When this form is used
Complete this form for every system that will create, process, store, or transmit GxP data, once the GxP applicability determination has confirmed the system is in scope. Complete it before the purchase order or contract is signed. For a significant version upgrade or a new module of an existing system, complete a focused re-assessment covering only the changed capability.
3. Field definitions
| Field | Format | Required | Who completes | When |
|---|---|---|---|---|
| Candidate system / vendor | Text | Yes | Assessor | At assessment |
| Intended GxP use | Text | Yes | Process owner | At assessment |
| Requirement area | One of the seven areas in section 5 | Yes | Assessor | At assessment |
| Vendor response | Text, with evidence reference | Yes | Vendor, verified by assessor | At assessment |
| Score | Meets / Partial / Gap | Yes | Assessor, QA-reviewed | At assessment |
| Gap disposition | Configuration fix / interim control / accepted risk / disqualifying | Yes, where score is Partial or Gap | Assessor and QA | At assessment |
| Overall decision | Proceed / Proceed with conditions / Do not proceed | Yes | QA | At approval |
| Approval | Name, signature, date | Yes | System owner and QA | At approval |
4. Instructions
- Pull the data integrity requirements directly from the URS; do not draft new ones here. If the URS does not yet state DI requirements as testable statements, fix the URS first.
- Send the requirement areas to the vendor in writing and require a specific, evidenced response for each, not a general compliance claim.
- Score each area independently. A single strong area does not offset a gap in another; each gap gets its own disposition.
- Where a gap exists, decide whether it closes by configuration, by a documented interim control, or is accepted as a residual risk with QA sign-off; item-level gaps on audit trail, attributability, and no-silent-deletion are treated as disqualifying until closed, never accepted as residual risk on a Tier 1 system.
- Route the completed form through QA before purchase or contract signature.
5. The assessment
| # | Requirement area | Question | Vendor response / evidence | Score (Meets/Partial/Gap) | Disposition |
|---|---|---|---|---|---|
| 1 | Audit trail | Does the system produce a complete, secure, time-stamped audit trail of create/modify/delete actions, on by default, and can it be disabled, by whom? | <<FILL>> | <<FILL>> | <<FILL>> |
| 2 | Access control | Can individual, unique user accounts be created and managed with role-based privileges and segregation of duties between data originator and administrator? | <<FILL>> | <<FILL>> | <<FILL>> |
| 3 | Electronic signatures | How are e-signatures implemented, and do they meet the signature/record linking and signature-meaning expectations of Part 11 and Annex 11? | <<FILL>> | <<FILL>> | <<FILL>> |
| 4 | Storage, backup, retention | What are the data storage and backup capabilities, and can original records be exported in a complete, readable form for the required retention period? | <<FILL>> | <<FILL>> | <<FILL>> |
| 5 | Interfaces | What interfaces does the system require, and how is transfer integrity verified at each one? | <<FILL>> | <<FILL>> | <<FILL>> |
| 6 | Migration path | Is there a validated or documented migration path if the system is later decommissioned, so data remains retrievable? | <<FILL>> | <<FILL>> | <<FILL>> |
| 7 | Vendor documentation | Does the vendor provide a GxP and Part 11 or Annex 11 compliance documentation package, and will they support a supplier audit? | <<FILL>> | <<FILL>> | <<FILL>> |
6. Gap log
For every item scored Partial or Gap, log the finding separately so it can be tracked to closure.
| Requirement area | Gap description | Disposition (config fix / interim control / accepted risk / disqualifying) | Owner | Target date | Status |
|---|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
7. Decision
| Field | Entry |
|---|---|
| All seven areas scored, with evidence | <<FILL: Yes / No>> |
| Any disqualifying gap open (items 1 to 3 on a Tier 1 system) | <<FILL: Yes / No>> |
| Overall decision | <<FILL: Proceed / Proceed with conditions / Do not proceed>> |
| Conditions, if any | <<FILL>> |
| System owner approval (name, signature, date) | <<FILL>> |
| QA approval (name, signature, date) | <<FILL>> |
8. Acceptance criteria
The assessment is complete when every requirement area has a vendor response backed by evidence rather than a general compliance claim, every Partial or Gap score has a logged disposition with an owner and a target date, no Tier 1 system proceeds with an open disqualifying gap, and the decision is approved by both the system owner and Quality Assurance before purchase or contract.
9. References
21 CFR Part 11 (electronic records and signatures). EU GMP Annex 11 (computerised systems). FDA, “Data Integrity and Compliance With Drug CGMP: Questions and Answers” (December 2018). ISPE GAMP 5 (Second Edition), for the risk-based approach to system categorization and supplier reliance. ICH Q9(R1), Quality Risk Management (2023 revision).
Confirm the current version of each reference before issue.
10. Retention
Retain the completed form, gap log, and vendor evidence with the system’s validation and governance records for the life of the system plus <<FILL: retention period>>.
Filled specimen
The following shows the form completed for an example clinical data management platform under evaluation to replace a legacy system. The company, vendor, and specifics are illustrative.
| # | Requirement area | Vendor response / evidence | Score | Disposition |
|---|---|---|---|---|
| 1 | Audit trail | Full create/modify/delete trail, on by default, disable right restricted to vendor-hosted DBA role with its own logged trail; documented in vendor’s Part 11 package | Meets | N/A |
| 2 | Access control | Role-based accounts, configurable segregation of duties; demonstrated in a sandbox instance | Meets | N/A |
| 3 | Electronic signatures | Signature manifestation and meaning configurable per Part 11; signature/record link demonstrated | Meets | N/A |
| 4 | Storage, backup, retention | Vendor-hosted, nightly backup, export to open format proven; retention configurable to 25 years | Meets | N/A |
| 5 | Interfaces | One planned interface to the safety database; vendor proposes file-based export with no field-level reconciliation check | Partial | Interim control: manual field-level reconciliation by a second person until an automated checksum is built; target 4 months |
| 6 | Migration path | Documented export format, but no prior migration case study provided | Partial | Accepted risk: pilot a test migration during validation before go-live, QA-approved |
| 7 | Vendor documentation | Full Part 11 compliance package provided; vendor agrees to a supplier audit | Meets | N/A |
Decision: Proceed with conditions. The interface reconciliation gap and the unproven migration path are logged, dispositioned, and tracked to closure before go-live; neither is a disqualifying gap because the audit trail, access control, and e-signature items, the ones that would be disqualifying on a Tier 1 system, all met the requirement outright.
Common inspection findings this form prevents
- A system purchased and deployed with no documented pre-deployment DI evaluation, so gaps surface only after go-live when they are far more expensive to fix.
- A vendor’s general compliance claim accepted without specific, evidenced answers to each requirement area.
- A known audit trail or access control gap accepted informally with no QA sign-off and no disposition, then forgotten.
- Interface integrity assumed rather than verified, discovered only when a reconciliation fails after the system is already carrying production data.
- No record of what the organization actually asked the vendor before purchase, leaving the site unable to explain its own due diligence during an inspection.
How to adapt this form
- Set your form number and point the parent-policy field at your actual data governance program policy.
- Pull the seven requirement areas directly from your URS template so this form and your URS stay in lockstep; do not maintain two separate lists of DI requirements.
- Define which requirement areas are disqualifying for your Tier 1 systems before you run your first assessment, so the rule is applied consistently rather than negotiated case by case.
- Feed every completed assessment into the system inventory once the system is deployed, so the disposition of any accepted gap remains visible for the system’s life.
- Confirm every regulation in section 9 against the current published version before issue.