This is a ready-to-use pair of matrices that document what each role on a GxP system may do, and which capability combinations must never sit with one person. Together they are the controlled artifact an inspector asks for when they suspect “administrator” has quietly become a do-everything role. Keep this as a controlled GxP document, version it, and change-control it. Replace every <<FILL: ...>> placeholder. A filled specimen for a laboratory data system follows.
Document control
| Field | Entry |
|---|---|
| System | <<FILL: SYSTEM NAME / ID>> |
| Document number | <<FILL: e.g. MTX-CSV-CDS-01>> |
| Version / effective date | <<FILL>> |
| Owner | <<FILL: system/process owner>> |
| SoD matrix owner | <<FILL: QA>> |
| Last review | <<FILL: date>> |
How to use these matrices
- Define the capabilities. List the atomic, security-relevant capabilities the system exposes (generate data, approve data, edit configuration, administer users, edit audit-trail settings, and so on).
- Define the roles. List every role the system will grant.
- Fill the role-to-permission matrix. Mark which capabilities each role carries. Enforce least privilege: a role holds only what its job needs.
- Fill the SoD conflict matrix. Mark capability pairs that must never be held by one person.
- Run the role-level check. Confirm no single role lights up a forbidden pair.
- Run the user-level check. For each individual, combine all of their assigned roles and confirm the combined set violates no forbidden pair. This is the check teams forget, and where role creep hides.
- Re-run on every change to roles, permissions, or assignments, and at each periodic access review.
1. Capability definitions
| Capability | Meaning |
|---|---|
| Generate data | Acquire, run, or enter GxP data or results |
| Approve data | Review and electronically sign or approve results |
| Edit configuration | Change validated settings: methods, calculation parameters, specification limits, integrations |
| Administer users | Create accounts, assign roles, reset credentials |
| Edit audit-trail / time settings | Change audit-trail configuration, enable/disable it, or change the system clock |
| Delete records | Remove data, files, or sequences |
<<FILL: add system-specific capabilities>> | <<FILL>> |
2. Role-to-permission matrix
Mark each cell Y (role has the capability) or blank. Enforce least privilege.
| Role | Generate data | Approve data | Edit configuration | Administer users | Edit audit-trail / time | Delete records |
|---|---|---|---|---|---|---|
<<FILL: Operator/Analyst>> | Y | |||||
<<FILL: Reviewer/Approver>> | Y | |||||
<<FILL: Config/Method Owner>> | Y | |||||
<<FILL: System Administrator>> | Y | |||||
<<FILL: QA Oversight>> | ||||||
<<FILL: add roles>> |
3. Segregation-of-duties conflict matrix
An “X” means the two capabilities must not be held by the same person.
| Generate data | Approve data | Edit configuration | Administer users | Edit audit-trail / time | Delete records | |
|---|---|---|---|---|---|---|
| Generate data | - | X | X | X | X | X |
| Approve data | X | - | X | X | ||
| Edit configuration | X | - | X | |||
| Administer users | X | - | X | |||
| Edit audit-trail / time | X | X | X | X | - | X |
| Delete records | X | X | X | - |
4. Role-level check
For each role in section 2, confirm its marked capabilities do not include any forbidden pair from section 3. Record the result.
| Role | Capabilities held | Forbidden pair present? | Result |
|---|---|---|---|
<<FILL: role>> | <<FILL>> | <<FILL: none / list>> | Pass / Fail |
5. User-level check
For each individual, combine all assigned roles and confirm no forbidden pair emerges. A person with two clean single-purpose roles can still recombine into a conflict.
| User | Roles assigned | Combined capabilities | Forbidden pair present? | Result / action |
|---|---|---|---|---|
<<FILL: user>> | <<FILL>> | <<FILL>> | <<FILL>> | Pass / remediate |
6. Compensating controls (where native separation is not possible)
Where the product cannot separate a conflicting pair natively (a common problem with a built-in administrator that can also edit data and the audit trail), record the compensating control and confirm the residual risk is documented as controlled: minimal named privileged accounts, no routine work under them, administrator activity logs exported to a location administrators cannot alter, and independent QA review of those logs on a defined cadence.
| Unavoidable conflict | Compensating control | Residual risk owner |
|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> |
References
21 CFR Part 11 (limiting access, 11.10(d); signatures, Subpart C). EU GMP Annex 11 (clause 12, security and role-based access). FDA Data Integrity and Compliance With Drug CGMP (2018); MHRA GXP Data Integrity Guidance; PIC/S PI 041.
Confirm the current version and clause numbers of each reference before use.
Filled specimen
The following shows the matrices completed for an illustrative laboratory data system. The roles and marks are illustrative; replace them with your own.
Role-to-permission (Y = capability held):
| Role | Generate data | Approve data | Edit configuration | Administer users | Edit audit-trail / time | Delete records |
|---|---|---|---|---|---|---|
| Operator/Analyst | Y | |||||
| Reviewer/Approver | Y | |||||
| Method/Config Owner | Y | |||||
| System Administrator | Y | |||||
| QA Oversight (read-only) |
Role-level check: no role holds a forbidden pair. The administrator holds only Administer users, deliberately separated from data generation, approval, and audit-trail editing. Pass.
User-level check (extract):
| User | Roles assigned | Forbidden pair present? | Result / action |
|---|---|---|---|
| A. Patel | Operator/Analyst | No | Pass |
| R. Gomez | Reviewer/Approver + QA Oversight | No (both are review/oversight, no generate) | Pass |
| K. Doyle | Operator/Analyst + Method/Config Owner | Yes: generate data + edit configuration | Remediate: remove Config role; assign a non-operating config owner |
The user-level check caught the real conflict: K. Doyle held two individually reasonable roles that combined into “generates data under configuration they can change,” which the role-level check alone would have missed. That is exactly the recombination the user-level check exists to find.
Common inspection findings these matrices prevent
- An “administrator” role that can do everything, including edit data and disable the audit trail.
- An analyst who can approve their own results.
- Role creep where an individual accumulates a forbidden capability combination across job changes.
- No documented SoD matrix, so the firm cannot show who can do what.
- Unavoidable product conflicts with no documented compensating control or residual-risk decision.
How to adapt these matrices
- Set the system, document number, and owners in the control block.
- Replace the capabilities in section 1 with the actual security-relevant capabilities your system exposes.
- Define your real roles and fill sections 2 and 3, then run the role-level and user-level checks.
- Record any compensating controls in section 6 where native separation is not possible.
- Change-control this document and re-run the checks at every role change and periodic access review.