This is a ready-to-use access recertification record. It captures one periodic review of who has access to a GxP system, what they can do, and whether that access is still justified. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, attach the system access export the review is based on, and route the record through your normal review and approval. A worked filled specimen follows the template so you can see how a completed version reads. Verify each cited regulation against the current source before you rely on it.
1. Purpose of this record
This record documents a periodic recertification of user access to a single GxP system so that every active account, every role, and every privilege is confirmed against a current, authoritative source of what each person should have. The objective is to detect and remove access that is no longer justified, including accounts of people who have left, accounts whose role has changed, accounts no one owns, and standing privileged access that is not warranted. One record covers one system for one review period. The review is evidence-based: it is performed against an access export taken on a known date, and that export is the attachment the conclusion rests on.
2. Scope and frequency
State which accounts are in scope and how often this system is recertified. Set frequency by the criticality of the data and functions the system controls; a system that releases product or holds the electronic batch record is reviewed more often than a read-only reporting tool. Record the basis once here so an inspector sees the review interval was a decision, not a habit.
A recertification is only as trustworthy as the data it compares. Gather and attach the current system access export, the approved role-to-function matrix, and the joiner-mover-leaver feed for the period. The system export is the population; everything else is the expectation it is checked against.
4. Per-user access review (role versus expected)
Review every account in the system export against its expected role and the current matrix. For each account, the line owner (the user’s manager or the function head) confirms the person still needs the system, that the assigned role matches their job, and that nothing extra has crept in. “Confirm” is a positive decision per account, not a single signature over the whole list.
Decision key: Retain = access matches expectation, keep as is. Modify = role or privileges must change to match the job; raise an exception with the corrected role. Revoke = access is no longer justified; raise an exception to remove or disable.
5. Privileged-account review and justification
Privileged accounts (administrator, configuration, database, audit-trail-management, user-management, and anything that can change GxP records or controls) are reviewed line by line and each one is justified. Standing privileged access is the highest-risk access on the system, so the default question is not “is this still active” but “does this person still need this level, and why”. Confirm separation between the people who can change data and the people who review it.
6. Joiner / mover / leaver reconciliation
Reconcile the joiner-mover-leaver feed against the system access export so every change in employment status is reflected in access. A leaver whose account is still active, or a mover who kept the access of a prior role, is the finding inspectors raise most often. Record counts and resolve every mismatch.
7. Orphan and disabled-account check
An orphan account is one in the system export that maps to no current employee, no service-account owner, and no approved access request: no one can say who it belongs to or why it exists. Disabled and dormant accounts are checked too, because a disabled account that gets re-enabled, or a dormant account that never logs in, is a standing entry point. Resolve each one to a named owner and a decision.
Every Modify, Revoke, orphan, mismatch, and unjustified privilege is an exception with an owner and a committed remediation date. An exception is not closed by noting it; it is closed when the access change is made and verified against a fresh export. The review record stays open until every exception is closed or formally accepted with rationale.
High-risk exceptions (active leaver accounts, unjustified privileged or maker-checker conflicts) are remediated immediately, not on the routine schedule. Where an exception cannot be remediated by the due date, the delay and its risk acceptance are signed by QA.
9. Acceptance criteria for closing this record
This record may be closed only when all of the following are true:
- Every account in the system export was reviewed against its expected role, with a Retain, Modify, or Revoke decision recorded for each.
- Every privileged account carries a current, role-based justification, and no unjustified standing privilege or maker-checker conflict remains open.
- The joiner-mover-leaver reconciliation shows zero active leaver accounts and every mismatch resolved or under a dated exception.
- Every orphan account has been assigned an owner or removed, and dormant and disabled accounts are dispositioned.
- All exceptions are either closed and verified against a fresh export, or formally risk-accepted by QA with a rationale and revised date.
- The record is signed by the reviewer(s) and approved by QA, and the access export it relied on is attached.
10. References
21 CFR Part 11 (electronic records and signatures; limiting system access to authorized individuals).
21 CFR 211.68 (automatic, mechanical, and electronic equipment; access controls).
EU GMP Annex 11 (Computerised Systems), sections on access control and security.
MHRA GxP Data Integrity Guidance and Definitions (access management and account control).
PIC/S PI 041, Good Practices for Data Management and Integrity (logical security and user access).
GAMP 5 (Second Edition) for the access-control and periodic-review lifecycle of computerized systems.
ICH Q9 (Quality Risk Management) for the risk basis of review frequency and privileged-access scrutiny.
NIST SP 800-53 (access control family) and ISO/IEC 27001 Annex A (access control), as general references for the control design only.
Confirm the current version and clause numbers of each reference before issue.
11. Reviewer sign-off and approvals
12. Revision history
Filled specimen
The following shows the record completed for an example laboratory information management system reviewed at its half-year interval. The company, system, names, and numbers are illustrative; replace them with your own.
Per-user and privileged review (extract)
Reconciliation, orphan check, exceptions
In this example the review ran against a dated export, confirmed each account against the role matrix, caught a leaver whose account was still active and disabled it the same day, found a mover who kept a redundant role, replaced a shared DBA account with named accounts under change control, and traced an orphan account back to a 2024 audit that was never cleaned up. Every finding became a dated exception that was closed and verified against a fresh export before the record was signed. That sequence, export to per-account decision to reconciliation to dated exception to verified closure, is exactly what a reviewer expects to see.
Common inspection findings this record prevents
- A periodic access review is required by procedure but no completed record shows it was performed, or the last one is long overdue.
- Terminated employees still hold active accounts, and contractors retain access months after their assignment ended.
- A mover kept the access of every prior role (access accumulation) because no one removed the old role when the new one was granted.
- The review is one signature over a printed list, with no per-account decision showing each account was actually examined.
- Privileged and administrator accounts have no documented business justification, and the same person can both change data and review it.
- Shared or generic accounts (including default vendor accounts) are in use with no individual accountability.
- Orphan accounts with no identifiable owner sit active in the system, and dormant accounts that never log in are never challenged.
- The review is performed against a stale or partial export, so it does not reflect the system’s actual current population.
- Exceptions are noted but never remediated; access flagged for removal is still present at the next review with no closure or verification.
How to adapt this record
- Set your record-numbering scheme, the system name and GxP classification, and the review frequency and its risk basis in the header and section 2.
- Name your authoritative source of expected access (HR feed, role matrix, access-request log) and attach the actual system export the review is based on.
- Tune the role and privilege categories in sections 4 and 5 to your system’s real roles, and state your maker-checker separation rule explicitly.
- Set your leaver-deprovisioning SLA and dormant-account threshold to your own policy, and point cross-references to your real change-control and deviation procedures.
- Keep every exception open with an owner and a due date until it is remediated and verified against a fresh export; do not close the record on open high-risk exceptions.
- Confirm every regulation in section 10 against the current published version before issue.
