Privilege Matrix
How to Verify Roles and Responsibilities

A validation protocol typically confirms access controls exist and function as designed at one point in time, while a Privilege Matrix is the living reference document that maps every role to its exact permissions and is maintained and reviewed throughout the system's operational life, not just during initial qualification.

Treating the protocol's one-time access control test as sufficient ongoing evidence is a common gap — user roles, joiners, leavers, and permission changes happen constantly after go-live, and the protocol doesn't get re-executed for every one of them. The privilege matrix is what closes that gap.

Each GxP system generally needs its own privilege matrix, because roles and permission structures rarely map cleanly across different systems — but a single master document with one section per system is an acceptable and common way to organise multiple matrices without creating separate standalone files.

The system owner should define the required roles and business justification for each, IT configures and confirms the technical permissions that implement those roles, and QA reviews and approves the finished matrix to confirm it reflects a risk-appropriate segregation of duties.

A common failure mode is IT building the matrix alone based on what's technically easy to configure, without the system owner defining what access each role actually needs for their job — this tends to produce over-privileged roles that are hard to unwind later.

No regulation or GAMP 5 itself mandates a document called a "Privilege Matrix" by that exact name, but GAMP 5's risk-based approach to access control and EU GMP Annex 11's personnel and access clauses both expect a documented, role-based access structure — the privilege matrix is the industry-standard way to evidence it.

The Privilege Matrix documents what access each role actually has; the segregation-of-duties assessment analyses that access to identify combinations of permissions — such as someone who can both create and approve the same record — that create an unacceptable risk of undetected error or fraud.

In practice these are often combined into one document, with SoD conflicts flagged directly against the relevant rows of the matrix, but they answer two different questions: what access exists, and whether that access is safe in combination.

A privilege matrix should be granular enough to show exactly what each role can do — create, read, update, delete, approve, or administer — for each relevant function or record type, not just a role name with a vague description of general access.

Role-level granularity alone ("Analyst," "Supervisor") is not enough to detect a segregation-of-duties conflict or confirm least-privilege access. The matrix needs to break access down to specific functions or permission types, even if the underlying roles group multiple functions together.

A segregation-of-duties conflict exists when a single role or individual holds two permissions that, combined, would let them create and approve the same action without independent oversight — for example, being able to both enter a result and release the batch based on it.

• Creating a record and approving or releasing the same record.
• Making a configuration change and approving that change without independent review.
• Administering user access and being able to grant themselves elevated privileges.
• Executing a test step and reviewing or approving their own execution.

It's generally discouraged and should be treated as a segregation-of-duties risk requiring justification and additional controls — such as a fully attributable audit trail and periodic independent review — rather than a routine role assignment, because an administrator account can typically bypass the controls a regular user account is subject to.

Where this combination is unavoidable, for example in a small team, the mitigating control is usually strict logging of all administrative actions and a documented periodic review by someone outside that person's reporting line.

Generic or shared accounts should not appear as a normal row in the privilege matrix representing an individual's access — they should be separately identified, risk-assessed, and either eliminated in favour of individually attributable logins or tightly restricted to a documented, justified purpose such as read-only reporting access.

Test and training environment access is usually documented in a separate matrix or a clearly separated section, because the risk profile is different — broader access is often acceptable in a non-production environment — and merging them without clear separation makes it harder to verify production access specifically during an inspection.

Verification means pulling the actual user and role configuration directly from the system — not from a change request log or memory — and comparing it line by line against the documented matrix, confirming both that everyone listed still needs that access and that no one has access that isn't documented at all.

• Export the live user list and assigned roles or permissions directly from the system.
• Compare it against the current approved privilege matrix, entry by entry.
• Investigate and resolve any discrepancy in either direction — undocumented access or stale matrix entries.
• Document the verification, including who performed it and the date, as reviewable evidence.

Excess or unauthorised access found during a review should be treated as a deviation — the access should be removed or corrected promptly, and the investigation should assess whether that access was used and whether any GxP records need to be reviewed for possible impact during the period the excess access existed.

The scope of the follow-up review depends heavily on what the excess permission actually allowed. Someone with unnecessary read-only access is a lower-risk finding than someone who could approve or delete records they shouldn't have been able to touch.

There's no fixed regulatory frequency, but most quality systems require a periodic access review at least annually, aligned with or referenced from the system's periodic review, with additional triggers for role changes, terminations, and significant system reconfigurations that happen in between scheduled reviews.

The system owner should approve the business justification for the access change, and QA or an independent access-control owner should confirm it doesn't introduce a segregation-of-duties conflict, before IT implements the change in the live system.

Role-level access changes and any change that could introduce a segregation-of-duties conflict should go through change control; routine, pre-approved onboarding or offboarding of standard roles with no permission-level ambiguity is often handled through a lighter-weight access-request procedure instead, provided that procedure itself was validated and is periodically reviewed.

Inspectors typically pick a handful of live user accounts, trace them back to the privilege matrix to confirm the documented role matches actual system access, check for segregation-of-duties conflicts, and confirm terminated employees or role changes were removed or updated promptly.

A frequent finding is a terminated employee whose system access was never deactivated, or a privilege matrix that hasn't been updated to reflect a reorganisation that happened months earlier — both suggest the matrix is a one-time document rather than an actively maintained control.

The privilege matrix and its periodic review evidence should be retained for at least as long as the records generated by the system it governs, since it's the document that establishes who was authorised to create, modify, or approve those records at any given time.

An inspection-ready privilege matrix should let a reviewer confirm, for every role, exactly what functions and record types that role can access and at what permission level, along with who currently holds each role and when access was last reviewed.

• System name and scope covered by the matrix.
• Every defined role and its business justification.
• Permission level per function or record type: create, read, update, delete, approve, administer.
• Named individuals currently assigned to each role.
• Identified segregation-of-duties conflicts and their mitigations, if any.
• Date of last review and the reviewer or approver.

The privilege matrix should be referenced from the validation package — typically from the qualification protocol that tested access controls — but it's usually maintained as a separate, living document outside the static validation package, since it changes far more frequently than the validation records themselves.

The key requirement is traceability: the validation package should point to where the current matrix lives and confirm it was in place and verified at the time of system release, even though the matrix itself continues to be updated afterward.

The most common mistake is treating the privilege matrix as a one-time deliverable completed for system go-live, rather than a living control that's actively reviewed and reconciled against the real system on a regular schedule — access drifts from what's documented far faster than most teams expect.

By the time an inspector asks for it, a stale matrix is often worse than having no formal matrix at all, because it creates a documented mismatch between what the organisation claims and what the system actually shows.