User access reviews are one of those controls everyone agrees with and few do well. The review happens, a list is signed, and six months later an inspector finds an account belonging to someone who left the company last year, still active, still able to approve records.
Here is how to make access review a real control rather than a signature.
Why inspectors care
Access control is the foundation of attributability. If you cannot be sure who could act in a system, you cannot be sure who did. Shared accounts, generic logins and leftover access for leavers all weaken the link between a record and a named person, which is the first letter of ALCOA.
Annex 11 asks for physical and logical controls that restrict access to authorised people, and for changes to access to be recorded. Part 11 asks for authority checks so that only authorised individuals can use the system, sign records or change them. Neither is new, and findings in this area are still common.
What a good review actually compares
The weak version of an access review is a system owner reading a list of names and confirming they look familiar. The useful version compares three things:
- Who has an account, and with which roles, taken directly from the system.
- Who should have access, based on current job role and an approved access matrix.
- Who is still employed, taken from HR or the identity system, not from memory.
Every difference between those lists is a finding to resolve: remove the access, correct the role, or document why the exception is justified.
Roles matter more than names
Most access problems are not strangers in the system. They are the right people with the wrong permissions. A quality reviewer who still has data entry rights from a previous job. An analyst who was given administrator access to fix one problem and kept it. A super-user account that several people know the password for.
Review roles against the separation of duties you designed: people who create data should not be able to approve it, and system administrators should not be routine users of the data they administer. If those rules were never written down, the review is a good moment to write them.
Leavers and movers
Periodic reviews catch problems late. The better control is at the event: when someone leaves or changes role, their access is removed or changed within a defined time. The periodic review then checks that this process worked, rather than being the process.
If your review regularly finds leavers with active accounts, the fix is upstream, in how HR and system owners talk to each other, not in reviewing more often.
Administrator and service accounts
Two kinds of account are easy to forget. Administrator accounts, which can often change configuration, audit trail settings or data directly, should be few, named, and reviewed more closely than anything else. Service accounts used by interfaces should not be usable by people, and their activity should be identifiable in the audit trail.
How often
Base frequency on risk. Systems that hold release-relevant data or allow approvals usually justify a quarterly review. Lower-risk systems can be reviewed less often, as long as the frequency is written down and kept. A defined interval that is reliably met is better than an ambitious one that slips. Our pieces on periodic review and audit readiness cover how access review fits into the bigger picture.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.