This is a ready-to-use risk assessment for setting audit trail criticality tiers across a system portfolio, or for one system at a time. It answers a question that most audit trail review procedures assume is already answered: how do you know a given system belongs in the High, Medium, or Low review category in the first place. Replace every <<FILL: ...>> placeholder, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen with fully scored rows follows the template. Verify each cited regulation against the current source before you rely on it, and treat this as general guidance to adapt to your own systems and quality system, not as legal or regulatory advice.
The output of this assessment feeds three other documents: the criticality column in your GxP system inventory, the review frequency table in your audit trail review procedure, and the scope determination record for review by exception. Keep all of them consistent with the tier this assessment assigns.
Document control header
| Field | Entry |
|---|---|
| Document title | Audit Trail Criticality Tiering Risk Assessment for <<FILL: system, data stream, or portfolio>> |
| Document number | <<FILL: RA-ID, e.g. RA-DI-024>> |
| Version | <<FILL: version, e.g. 1.0>> |
| Effective date | <<FILL: effective date>> |
| Supersedes | <<FILL: prior version or "New">> |
| Document owner | <<FILL: role, e.g. Data Integrity Lead>> |
| System inventory reference | <<FILL: inventory document number>> |
| Assessment team | <<FILL: names and roles, including QA and a system owner who uses the system day to day>> |
1. Purpose
This assessment scores each GxP system or data stream identified in the header against defined criticality factors, converts the score into a High, Medium, or Low audit trail criticality tier, and states the audit trail capture depth and review frequency that tier requires. The objective is a defensible, repeatable answer to the question an inspector asks whenever review frequency varies across systems: why does this one get reviewed every run and that one only at periodic review.
2. Scope
This assessment covers GxP computerized systems and the discrete data streams within them that generate, modify, or store records subject to audit trail requirements. It applies at the point a system is first specified, at any point the tier has not yet been formally assigned, and on re-assessment triggers defined in section 5.7.
It does not replace: the general data criticality and data risk classification of a record stream for purposes broader than audit trail review, governed by <<FILL: SOP-ID for data criticality classification>>; the hybrid record failure-mode risk assessment for the paper-and-electronic seam, governed by <<FILL: SOP-ID or RA-ID for hybrid record risk assessment>>; or the validation risk assessment that scopes testing effort under <<FILL: SOP-ID for CSV/CSA risk assessment>>. Where this assessment and a system-level validation risk assessment reach different conclusions about the same system, the difference is reconciled and the reason recorded rather than left standing.
3. Responsibilities
| Role | Responsibility |
|---|---|
| System / process owner | Provides the factual description of what decisions the data supports and how the system is actually used, not only how it is described in the URS. |
| Data integrity lead | Convenes the assessment, maintains scoring consistency across systems so tiers are comparable, and owns the resulting inventory update. |
| Quality Assurance | Approves the scoring logic, challenges optimistic detectability scores, and approves the assigned tier and any compensating controls. |
| Validation / CSV | Confirms the technical audit trail capability of the system, including whether it can reach the capture tier this assessment requires. |
| IT / system administrator | Confirms what a privileged user can and cannot do outside the application audit trail, which bears directly on the detectability score. |
4. Definitions
- Criticality factor: one of the defined dimensions scored in section 5.2 that together determine how important complete, reviewed audit trail evidence is for a given system or data stream.
- Capture tier: the depth of audit trail logging a system must implement, using the Tier 1 to Tier 3 scale defined in the parent article, where Tier 3 (who, what, when, old value, new value, reason) is the target for anything above Low criticality.
- Criticality tier: the High, Medium, or Low band this assessment assigns, which sets both the required capture tier and the review frequency.
- Review layer: record-level, periodic system-level, or security-event review, as distinguished in the parent article; the criticality tier determines which layers apply and how often.
- Compensating control: a control that substitutes, in whole or in part, for a capture tier the system cannot technically reach, applied only where remediation or replacement is not immediately possible.
5. Method
5.1 Sequence
- Identify the system or data stream and describe factually what decision the data supports, observed in real use, not read from the URS or the marketing material.
- Score the five criticality factors in section 5.2 using the anchored scales.
- Sum the scores, apply the override rules in section 5.3, and assign the criticality tier.
- Map the tier to the required capture depth and review regime using the table in section 5.4.
- Confirm whether the system can technically reach the required capture tier. Where it cannot, apply a compensating control from section 6 and record the residual risk.
- Record actions, owners, and target dates, and update the system inventory, the audit trail review procedure’s frequency table, and the review-by-exception scope determination to match.
5.2 Criticality factors and anchored scales
Score each factor from 1 to 5 using the anchors below. Score the system as it is actually used today, not as it is intended to be used eventually.
Decision impact: what downstream decision the data feeds.
| Score | Anchor |
|---|---|
| 5 | Directly drives batch or lot disposition, release, a stability conclusion, or is itself submitted to a regulator |
| 4 | Feeds a quality decision that is not itself the release decision but materially informs one, such as an in-process hold point or an OOS root cause conclusion |
| 3 | Feeds an internal quality decision with no direct product disposition link, such as deviation trending or CAPA effectiveness data |
| 2 | Supports operational or administrative decisions with indirect quality relevance |
| 1 | No decision rests on this data; informational or historical only |
Regulatory reliance: how directly the record supports a claim made to a regulator.
| Score | Anchor |
|---|---|
| 5 | Data or its summary is routinely included in regulatory submissions, or is a specific, recurring target of inspection requests |
| 4 | Data supports a submitted claim indirectly, or is commonly sampled at inspection though not itself submitted |
| 3 | Data is retained as GxP evidence but is not typically submitted or specifically requested |
| 2 | Data supports internal compliance only, unlikely to be inspection-facing |
| 1 | Data has no regulatory visibility |
Change frequency: how often the data is field-edited or reprocessed in normal use.
| Score | Anchor |
|---|---|
| 5 | Edited, reprocessed, or reintegrated on most records in normal use |
| 4 | Edited or reprocessed regularly, more than a few times per week across the system |
| 3 | Edited occasionally, a few times per month |
| 2 | Edited rarely, a few times per year |
| 1 | Essentially static once entered; edits are exceptional events |
Detectability without the trail: whether a wrong or altered value could be caught another way.
| Score | Anchor |
|---|---|
| 5 | No independent way to know the value ever changed; the audit trail is the only record |
| 4 | An independent check exists but is weak or infrequent, such as a periodic reconciliation rather than a parallel measurement |
| 3 | A parallel record exists but is not routinely cross-checked |
| 2 | A parallel record exists and is routinely cross-checked as part of normal work |
| 1 | A strong independent control exists, such as a physical measurement or a second validated system, that would surface a change on its own |
Finding history: whether this system or a comparable one has produced a data integrity finding.
| Score | Anchor |
|---|---|
| 5 | This exact control has produced a data integrity finding (deviation, inspection observation, internal audit) within <<FILL: look-back period, e.g. 3 years>> |
| 4 | A closely comparable system or control has produced a finding within the look-back period |
| 3 | A related but more distant control has produced a finding |
| 2 | No finding on this or a comparable system, but the system is new or was recently changed |
| 1 | No finding history and the system is stable and mature |
5.3 Combining scores and override rules
Sum the five factor scores. The total ranges from 5 to 25.
| Total score | Criticality tier |
|---|---|
| 18 to 25 | High |
| 10 to 17 | Medium |
| 5 to 9 | Low |
Two override rules apply regardless of the arithmetic total, because a low sum should not be allowed to hide a factor whose consequence alone is severe:
- Decision impact of 5 combined with detectability of 5 is classified High, regardless of the total. A system where nothing but the audit trail would ever reveal a change to release-driving data is High no matter how infrequently it is edited.
- Regulatory reliance of 5 alone sets a floor of Medium, regardless of the total. Data that regulators routinely request or that appears in a submission does not get a Low tier on the strength of low edit frequency.
Record any application of an override rule explicitly in the assessment table so a reviewer can see the tier was set by rule rather than by arithmetic alone.
5.4 From tier to required controls
| Criticality tier | Required capture depth | Record-level review | Periodic system-level review | Security-event review |
|---|---|---|---|---|
| High | Tier 3 on every GxP-relevant field; reason for change enforced on critical fields | Each batch or run, before the data is used, by exception | Monthly | Monthly, for systems feeding release |
| Medium | Tier 3 on the fields that drive the decision; Tier 2 acceptable elsewhere with a documented rationale | Weekly, monthly, or at a defined periodic cycle | Quarterly | At periodic system review, or monthly where the system also carries a High-tier data stream |
| Low | Tier 2 or Tier 3 acceptable with a documented rationale for the lighter tier | At periodic system review only | Annually or at the standing periodic review cycle | At periodic system review |
6. Compensating controls where a system cannot reach its required tier
Some systems, particularly older instruments and single-purpose tools, cannot technically produce Tier 3 logging no matter what is configured. Where the required capture tier from section 5.4 exceeds what the system can do, apply a compensating control and record it here rather than leaving the gap silent.
| Gap | Compensating control | What it addresses | Notes on strength |
|---|---|---|---|
| System logs “modified” with no prior value (Tier 1 or Partial) | Contemporaneous second-person verification of the changed parameter, recorded on the record | Detectability | Moderate; depends on the check being real and documented every time, not just when convenient |
| System has no individual accounts, only a shared or generic login | Controlled physical access with a logged entry record for the room or workstation | Attribution | Compensating only; narrows who could have acted but does not attribute the action to one person |
| Audit trail can be disabled by an ordinary user | Restrict the setting through operating-system or network controls where the application cannot be reconfigured, and monitor for the disabled state | Occurrence | Interim only; escalate for remediation or replacement, do not treat as a permanent answer |
| System retains no audit trail capability at all | Compensating manual logbook reconciled to system output at defined frequency, per your hybrid record control procedure | Partial substitute for Complete and Attributable | Weak; document the residual risk explicitly and prioritize replacement |
A compensating control closes an audit trail configuration gap, it does not close this assessment. Every row using one carries a remediation or replacement action with an owner and a target date in section 8.
7. Assessment table
Complete one row per system or data stream. The rows below show the shape; replace with your own.
| # | System / data stream | Decision impact | Regulatory reliance | Change frequency | Detectability | Finding history | Total | Override applied | Criticality tier |
|---|---|---|---|---|---|---|---|---|---|
| 1 | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL: none, or rule 1/2>> | <<FILL>> |
| 2 | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
8. Residual risk statement and actions
| Field | Entry |
|---|---|
| Systems assessed | <<FILL: count>> |
| High tier | <<FILL: count>> |
| Medium tier | <<FILL: count>> |
| Low tier | <<FILL: count>> |
| Systems unable to reach their required capture tier | <<FILL: count, each with a compensating control from section 6>> |
| Compensating controls relied on | <<FILL: list, with the record that evidences each>> |
| Residual risk statement | <<FILL: plain-language statement of what risk remains where a compensating control is in use, why the system cannot yet be remediated, and what would change the conclusion>> |
| Actions (remediation, replacement, re-tiering) | <<FILL: action, owner, target date, one row per action>> |
| Date this assessment is re-evaluated | <<FILL: date and the trigger events, e.g. a system's use changes, a software upgrade, a new finding>> |
State the residual risk in language a reader outside the assessment team can evaluate. “Residual risk is acceptable” is a conclusion with the reasoning removed, not a statement.
9. Approval
| Role | Name | Signature | Date |
|---|---|---|---|
| Prepared (Data Integrity Lead) | <<FILL>> | ||
| Reviewed (System Owner) | <<FILL>> | ||
| Approved (QA) | <<FILL>> |
10. References
21 CFR Part 11.10(e) (audit trails); 21 CFR 211.68, 211.194. EU GMP Annex 11, section 9 (audit trails). A substantially expanded draft revision was issued for consultation on 7 July 2025, with consultation closing 7 October 2025; confirm the in-force version before issue. FDA guidance, Data Integrity and Compliance With Drug CGMP: Questions and Answers (final, December 2018), for the risk-based scoping of audit trail review. MHRA GxP Data Integrity Guidance and Definitions; PIC/S PI 041, Good Practices for Data Management and Integrity. ICH Q9, Quality Risk Management, for the risk assessment method and terminology.
Confirm the current version and clause numbers of each reference before issue.
Filled specimen
The following shows three systems scored for an illustrative small-molecule QC and manufacturing operation. Names, systems, and numbers are illustrative; replace them with your own.
| # | System / data stream | Decision impact | Regulatory reliance | Change frequency | Detectability | Finding history | Total | Override applied | Criticality tier |
|---|---|---|---|---|---|---|---|---|---|
| 1 | CDS, finished-product assay result | 5 | 5 | 4 | 5 | 2 | 21 | Rule 1 (impact 5 + detectability 5) confirms High | High |
| 2 | LIMS, environmental monitoring trend module | 3 | 3 | 2 | 3 | 1 | 12 | None | Medium |
| 3 | MES, operator training-record display module | 1 | 1 | 1 | 2 | 1 | 6 | None | Low |
Compensating control example. A fourth system, a standalone benchtop balance feeding formulation weights (decision impact 4, regulatory reliance 3, change frequency 2, detectability 5 because it has no audit trail at all, finding history 2), totals 16, Medium by arithmetic, but the balance produces no audit trail capability whatsoever. Because it cannot reach even Tier 2 capture, the assessment applies a compensating control: a controlled logbook capturing each weight with operator initials, date, and a second-person verification against the printed tape, reconciled weekly against the batch record. The residual risk statement records that this is a weak substitute for Complete and Attributable, and the action table carries a CAPA to replace the balance with a networked unit that supports named accounts and Tier 3 logging, target <<FILL: date>>.
Residual risk statement. “Four systems assessed. One High (CDS assay result, Tier 3 confirmed in qualification, reviewed each run by exception). One Medium (LIMS environmental trend, Tier 3 on the trended value, reviewed quarterly). One Low (MES training display, periodic review only). One system unable to reach its required tier (standalone balance) is operating under a documented compensating logbook control with a CAPA to replace the unit; residual risk is accepted at Medium pending replacement because the compensating control is independently verified weekly and no finding has occurred in the look-back period.”
Reviewed by: <<FILL: System Owner>>, signed. Approved by: <<FILL: QA>>, signed, dated.
Common inspection findings this risk assessment prevents
- Review frequency that varies across systems with no documented basis for why, so the schedule looks arbitrary or resource-driven when challenged.
- A high-impact, high-reliance system reviewed on the same light cycle as a reference-only module because nobody scored the difference.
- A system that cannot technically produce Tier 3 logging left silently under-reviewed, with no compensating control and no remediation plan.
- Criticality assigned once at commissioning and never re-visited, so a module that started as reference-only and now feeds a real decision is still reviewed as if it were Low.
- An override condition, such as a system that is rarely edited but where an edit would be undetectable and release-critical, missed because only the arithmetic total was used.
How to adapt this risk assessment
- Set your document number and point the system inventory reference at your real GxP system inventory.
- Assess your systems as they are actually used; interview the people who work in them daily rather than scoring from the URS alone.
- If your organization already uses a different anchored scale for a related risk assessment, align the anchor language so the same evidence supports both without contradiction.
- For every compensating control used in section 6, attach the record that evidences it operated, not just that it is defined.
- Feed the resulting tiers into your audit trail review procedure’s frequency table and your review-by-exception scope determination the same week this assessment is approved.
- Confirm every regulation in section 10 against the current published version before issue, including the pending Annex 11 revision.