GxP / Guide 6

Access control for GxP systems

Building an access control program inspectors accept: unique accounts, role design, segregation of duties, joiners and leavers, privileged access, periodic access reviews and electronic signatures.

Access control findings are among the most common in GxP inspections, and most of them are about process, not technology: a leaver still active, a shared login in the lab, an administrator who can also approve data, a review that was signed but clearly not done. This guide describes an access control program for GxP systems on Azure, AWS and Microsoft 365, the same shape I've used for GxP and HIPAA programs.

The principles

• Unique, named accounts. Every action is attributable to one person. No shared accounts with write access, including "lab" or "QC" accounts on instrument PCs. Where a shared login is truly unavoidable (some instruments), document the justification and compensate with a logbook and application-level user identification.
• Least privilege, by role. Access is granted to roles through groups, not to people directly.
• Segregation of duties. People who generate or approve GxP data don't administer the system, and system administrators don't have business rights to create or approve data. IT administrators get the platform, not the data.
• Every change recorded. Who asked, who approved, who did it, when. Annex 11 §12 expects the creation, change and removal of access to be recorded.
• Reviewed periodically. And the review is real: someone who knows the role confirms each person still needs it.

Role design

Define roles per system in its user requirements, then implement each as a group. A typical LIMS:

Keep a role matrix that says which roles conflict (for example, analyst and reviewer on the same result), and enforce it in the application where you can.

Joiners, movers and leavers

• Joiners: access requested and approved by the line manager and the system owner, granted only after training on the system and its procedures is recorded (Part 11 11.10(i)). Use Entra ID access packages or your identity governance tool so approval and grant are one recorded flow.
• Movers: a role change triggers removal of the old access, not only addition of the new. This is where access creeps.
• Leavers: disable in the directory on the last day, driven by HR, not by a ticket someone might forget. Federated sign-in means disabling the Entra ID account cuts off Azure, AWS through IAM Identity Center, Microsoft 365 and any SSO-connected SaaS at once. Check local and application-only accounts separately.

Privileged access

• Just-in-time: on Azure, make admin roles eligible in Privileged Identity Management with approval, justification and a maximum duration. On AWS, use IAM Identity Center permission sets with short sessions, and a temporary elevated access process for production.
• Separate admin accounts for people who administer GxP platforms, with phishing-resistant MFA and sign-in only from managed devices (Conditional Access).
• Break-glass accounts: two, excluded from normal Conditional Access, credentials sealed, every use alerted and reviewed afterwards as an incident.
• No standing Owner on GxP subscriptions, no IAM users with console passwords or long-lived access keys in GxP accounts.
• Service identities (managed identities, IAM roles for workloads) have a named owner and are included in the access review.

Periodic access reviews

A common frequency is quarterly for privileged and administrator access, and every six or twelve months for business users, set by risk in your procedure. Each review should show:

1. The complete list of who has access, including through groups and inherited assignments, taken on a known date.
2. A named reviewer who knows the role (system owner or line manager, not the administrator granting access).
3. A decision for each line: keep, change or remove.
4. Evidence that removals were done, with dates.

For the Azure platform layer, Get-AzGxPAccessReview.ps1 builds the worksheet: every role assignment on GxP-tagged scope, including those inherited from management groups, optionally the members of each group and PIM eligible assignments, with flags for privileged roles, direct user assignments, guests, deleted principals and names that look like shared accounts. It has empty columns for the reviewer's decision, and writes a hash file so the extract itself is evidence.

.\Get-AzGxPAccessReview.ps1 -ExpandGroups -IncludeEligible

Microsoft Entra ID access reviews (part of Entra ID Governance) can run the review itself: send each reviewer their list, collect decisions, and remove access automatically when denied. For AWS, if IAM Identity Center is federated to Entra ID, review the Entra groups that map to permission sets; IAM Access Analyzer's unused access findings help spot roles and permissions nobody uses.

Passwords, sessions and lockout

Part 11 section 11.300 and the Annex 11 draft expect controls that stop misuse of credentials. With cloud identity, most of these are central settings in Entra ID:

• MFA for every user of a GxP system, and phishing-resistant MFA for administrators.
• Smart lockout after repeated failed attempts, with alerts for attacks on privileged accounts.
• Sign-in frequency and idle session time-outs set by Conditional Access for GxP applications; screen lock on shared lab PCs.
• Banned password lists rather than forced periodic changes, which current guidance (including NIST) no longer recommends. Document the rationale if your older procedures still say "every 90 days".

Electronic signatures

Electronic signatures are an application feature, but they depend on identity. For a Part 11 signature, the application must show the signer's printed name, date and time, and meaning; link the signature to the record; and require re-entry of credentials at signing (both components on the first signing in a session). Single sign-on alone doesn't meet this: a signature step needs a fresh authentication. Ask vendors how their signature works with your identity provider before you buy, and test it during validation.