This is a ready-to-use assessment for an existing computerized system already in GxP use, answering two questions in sequence: does Part 11 still apply to this system’s records at all, and if it does, exactly which controls in 11.10, Subpart C, and EU GMP Annex 11 are actually missing. It is deliberately different from a URS-stage requirements checklist, which seeds requirements for a system that has not yet been built, and from a legacy-system testing-depth risk assessment, which scores functions for how much OQ evidence to collect. This document is a clause-by-clause compliance audit of a system already in production, producing a gap register with a severity read straight from the 2003 FDA scope-and-application guidance: a gap that could let bad data through is treated as materially more serious than a gap that is only a documentation shortfall. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through document control. A worked filled specimen follows. This is general educational structure to adapt, not legal or regulatory advice; confirm each cited regulation against the current source before you rely on it.
Document control header
| Field | Entry |
|---|---|
| Document title | Part 11 / Annex 11 Predicate Rule Applicability and System Control Gap Assessment |
| Document number | <<FILL: ID, e.g. RA-CSV-044-01>> |
| Version | <<FILL: version>> |
| Assessment date | <<FILL: date>> |
| System assessed | <<FILL: SYSTEM NAME / ID>> |
| Assessment owner | <<FILL: role, e.g. CSV Lead>> |
| Assessment team | <<FILL: names and roles, system owner, QA, IT, data integrity SME>> |
1. Purpose and methodology
This assessment determines, with evidence, whether <<FILL: SYSTEM NAME / ID>> still produces records subject to a live predicate rule, classifies the system as open or closed, and then scores the gap between the controls the system actually has and the controls 21 CFR Part 11 and EU GMP Annex 11 require. The output is a prioritized remediation register, not a pass/fail label; a system can be substantially compliant with a small number of high-severity gaps, or largely compliant on paper with one control that quietly never worked.
Run this assessment: at initial validation of an existing (never-formally-assessed) system, whenever a periodic review or an internal audit raises doubt about Part 11 status, before a system is proposed for continued use past a planned retirement date, and as a standing element of a data integrity gap-assessment program.
2. System description and use
| Field | Entry |
|---|---|
| System / application and version | <<FILL>> |
| GxP process supported | <<FILL>> |
| Record types produced | <<FILL: e.g. batch data, stability data, complaint records>> |
| GxP decisions the data feeds | <<FILL: release, in-process, stability, disposition, submission>> |
| Hosting | <<FILL: on-premise / vendor-hosted / SaaS>> |
| Date entered GxP use | <<FILL>> |
| Prior validation or assessment (if any) | <<FILL: none / date and scope>> |
Part A: Predicate rule and scope determination
3. Predicate rule per record type
A system frequently produces more than one record type, and each can carry a different predicate rule. List each type separately; do not collapse them into one blanket answer.
| Record type | Predicate rule(s) | Still driving a live GxP decision? | Basis |
|---|---|---|---|
<<FILL: e.g. batch release result>> | <<FILL: e.g. 21 CFR 211>> | Yes / No | <<FILL>> |
<<FILL: e.g. discontinued-product stability data>> | <<FILL>> | Yes / No | <<FILL>> |
<<FILL: e.g. combination-product device record>> | <<FILL: e.g. 21 CFR 820 / QMSR>> | Yes / No | <<FILL>> |
If every record type is “No” (retention only): the system needs its records preserved, readable, and retrievable through the retention period. Full 11.10/Annex 11 remediation to a current standard is not required unless the system returns to active GxP use. Skip to section 9 and record this determination.
If any record type is “Yes”: the system carries a live predicate rule. Continue to section 4.
4. Open or closed classification
Classify by who actually controls access to the content, not by hosting model.
| Question | Answer |
|---|---|
| Who controls access to the records: your organization’s identity management, or a party you do not govern? | <<FILL>> |
| Do provider personnel have any contractual or technical path to the production data? | <<FILL>> |
| Classification | Open / Closed |
| If open, are 11.30 controls (encryption in transit/at rest, signature integrity) present? | <<FILL>> |
5. Electronic signature applicability and certification status
| Question | Answer |
|---|---|
| Are electronic signatures applied to any record produced by this system? | Yes / No |
| If yes, is the organization’s one-time 21 CFR 11.100(c) certification letter on file and current? | <<FILL>> |
| Are signatures biometric, non-biometric, or both? | <<FILL>> |
Part B: Control gap scoring
6. Gap severity scale
Severity is read from the 2003 FDA scope-and-application guidance: the question is not “is this clause satisfied to the letter,” but “would this gap actually let a bad, unattributable, or unreliable record through.”
| Severity | Meaning |
|---|---|
| Critical | The gap could let an inaccurate, unattributable, or unauthorized record through undetected (e.g., audit trail off, shared logins, no signature-record binding) |
| Moderate | The control exists but is incomplete, untested, or inconsistently applied (e.g., backup taken but restore never verified, periodic review overdue) |
| Minor | Documentation, formatting, or procedural tidiness gap with no plausible path to bad data reaching a decision |
7. Part 11 clause-by-clause gap register
| Clause | Requirement | Current state | Evidence | Gap severity | Remediation action | Owner | Target date |
|---|---|---|---|---|---|---|---|
| 11.10(a) Validation | Validated, discerns altered records | <<FILL: Compliant / Partial / Gap>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 11.10(b) Copies | Complete human-readable and electronic copies | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 11.10(c) Protection | Retrievable through retention | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 11.10(d) Access | Individual accounts, no sharing | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 11.10(e) Audit trail | On, complete, cannot be disabled by users | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 11.10(f) Sequencing | Enforces valid step order | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 11.10(g) Authority | Role-based access checks | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 11.10(h) Device | Input source validity checks (if relevant) | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 11.10(i) Training | Role-based training before access | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 11.10(j) Policy | Signed accountability policy | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 11.10(k) Documentation | Controlled admin/config documentation | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 11.50 Manifestation | Name, date/time, meaning shown | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 11.70 Linking | Signature bound to record version | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 11.100 Identity/uniqueness | Verified, unique, never reassigned | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 11.200 Components | Two-component or qualifying biometric | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
8. Annex 11 clause-by-clause gap register (if EU-marketed or EU-inspected)
| Clause | Requirement | Current state | Evidence | Gap severity | Remediation action | Owner | Target date |
|---|---|---|---|---|---|---|---|
| Cl. 1 Risk management | Risk-based effort through the lifecycle | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| Cl. 3 Suppliers | Formal agreement defining responsibilities | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| Cl. 4 Validation | Traceable requirements and testing | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| Cl. 6 Manual entry checks | Critical manual entries verified | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| Cl. 7 / 7.2 Storage, backup, restore | Data protected; restore actually tested | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| Cl. 9 Audit trail | Risk-based, reviewed | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| Cl. 11 Periodic evaluation | Done on defined frequency | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| Cl. 12 Security | Access control operating | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| Cl. 13 Incident management | Defined and exercised | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| Cl. 16 Business continuity | Tested, criticality-matched | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
9. Overall determination and remediation summary
| Field | Entry |
|---|---|
| Predicate rule status | Live / Retention only / No predicate rule identified |
| Open or closed | <<FILL>> |
| Overall determination | Compliant / Remediation required / Replacement required |
| Number of Critical / Moderate / Minor gaps | <<FILL>> |
| Interim controls in place now | <<FILL>> |
| Historical data review required | Yes / No, <<FILL: population and basis>> |
| Disclosure assessment required | Yes / No, <<FILL: submission exposure>> |
| Next review date | <<FILL>> |
10. Acceptance criteria
This assessment is acceptable when all of the following are true:
- The predicate rule status is determined per record type, with a basis, not assumed from the system’s age or name.
- The open/closed classification is based on documented access control reality, not hosting model.
- Every applicable Part 11 clause and, where relevant, Annex 11 clause carries a current-state entry with evidence, not a bare Pass/Fail.
- Every gap carries a severity read from its actual data-reliability consequence, an owner, and a target date.
- Any Critical gap has an interim control already in place, not only a planned future fix.
- The overall determination and remediation summary is signed by the system owner and Quality Assurance.
11. References
21 CFR Part 11 (electronic records and electronic signatures), Subparts B and C. FDA guidance, Part 11, Electronic Records; Electronic Signatures, Scope and Application (August 2003). EU GMP Annex 11 (Computerised Systems), in-force 2011 version; track the draft revision published for consultation 7 July 2025, not yet final as of this writing. ICH Q9(R1), Quality Risk Management. FDA guidance, Computer Software Assurance for Production and Quality Management System Software (current version). FDA guidance, Data Integrity and Compliance With Drug CGMP, Questions and Answers (December 2018).
Confirm the current version and clause numbers of each reference before issue.
12. Approval
| Role | Name | Signature | Date |
|---|---|---|---|
| Assessment owner (CSV) | <<FILL>> | ||
| System owner | <<FILL>> | ||
| Quality Assurance | <<FILL>> |
Filled specimen
Illustrative, for a legacy quality control LIMS supporting release testing of a marketed injectable product, never formally assessed against Part 11 since its 2011 go-live.
Record types: release test results (live, predicate rule 21 CFR 211), a discontinued line’s retained stability data (retention only, product exited the market in 2019).
Part A: Release-testing record type carries a live predicate rule under 21 CFR 211; continue full assessment for that record type. Discontinued-line stability data is retention only; scoped to preservation and readability, no re-validation.
Open/closed: closed. Access controlled entirely by the site’s own Active Directory groups; no external party can reach production data. No 11.30 controls needed.
Electronic signatures: yes, non-biometric, ID plus password. Certification letter: found on file, dated 2012, current.
Part B (excerpt):
| Clause | Requirement | Current state | Evidence | Gap severity | Remediation action | Owner | Target date |
|---|---|---|---|---|---|---|---|
| 11.10(e) Audit trail | On, complete, cannot be disabled by users | Partial | Audit trail enabled for results, but the “sample login” account used by two former analysts remains active with an unclear history | Critical | Disable shared account immediately; investigate two years of entries under that login for attribution; migrate to individual accounts | IT / QA | Interim control same day; investigation closed in 60 days |
| 11.10(k) Documentation | Controlled admin/config documentation | Gap | No change-control record for a 2019 server migration | Moderate | Reconstruct configuration baseline from available logs and vendor records; bring under change control going forward | CSV Lead | 90 days |
| 11.50 Manifestation | Name, date/time, meaning shown | Compliant | Signature manifestation screenshots and printouts confirm all three elements |
Overall determination: Remediation required. Two Critical gaps (shared login, unclear historical attribution) with interim controls (shared account disabled same day, enhanced second-person review of results signed under that account pending investigation) already in place. Historical data review required for the shared-account period, population all release results signed under that login, disclosure assessment triggered because release results reached the marketing application.
This is the pattern a genuine assessment should produce for a system that has quietly run for over a decade with no formal Part 11 review: it finds the shared login, treats it as Critical because it breaks attribution, and does not wait for a project plan before disabling it.
Common inspection findings this assessment prevents
- A system assumed to be “grandfathered” out of Part 11 because it predates a formal validation program, with no documented determination.
- A predicate-rule status never re-checked after a product is discontinued, so a system is over-remediated or, worse, under-remediated relative to what it actually still supports.
- A clause-by-clause gap never actually documented, so remediation priorities are set from memory or convenience rather than evidence.
- A Critical gap (shared logins, disabled audit trail) sitting on a remediation project timeline with no interim control while it waits its turn.
- An open/closed classification asserted from the hosting model rather than from who actually controls access.
How to adapt this assessment
- Set your document number and list your actual assessment team by name.
- In section 3, list every genuinely distinct record type the system produces; do not merge a live-decision record with a retention-only record.
- Use your own evidence sources (configuration exports, access logs, backup/restore logs) in the “Evidence” columns; do not accept an assertion with no artifact behind it.
- Keep the severity definitions tied to data-reliability consequence, matching the 2003 guidance philosophy, rather than a generic High/Medium/Low with no stated meaning.
- Feed every open action into your organization’s standard quality-commitment tracking system, not a standalone spreadsheet that nobody revisits.
- Confirm every regulation in section 11 against the current published version before issue.