SOP: Logical Access Management for GxP Systems

This is a ready-to-use SOP for managing logical access to validated GxP systems across the whole account lifecycle. Access control is a data-integrity control, not only a security control: it is what makes a record attributable to a person. Replace every <<FILL: ...>> placeholder, set your document numbers, and route it through document control. A worked filled specimen follows. Verify each cited regulation against the current source before you rely on it.

Document control header

1. Purpose

This procedure defines how <<FILL: COMPANY NAME>> grants, maintains, reviews, and removes access to computerized systems that create, modify, or store GxP records, so that every account maps to one identified individual, access follows least privilege, and the record of who could do what is complete and defensible.

2. Scope

This procedure applies to all logical (software) access to GxP computerized systems at the sites in the header, including laboratory, manufacturing, quality, and clinical systems, and to human user accounts, privileged accounts, and non-human service accounts. It works with the role and segregation-of-duties design maintained in <<FILL: role/SoD matrix reference>> and does not replace physical access control or the periodic system review.

3. Responsibilities

4. Definitions

• Least privilege: the minimum access needed to perform the role, and nothing more.
• Privileged account: an account able to administer users, change configuration, alter audit-trail settings or the system clock, or delete records.
• Service account: a non-human account used by an integration or scheduled job; controlled with a named owner, no interactive login, and vaulted credentials.
• Deprovisioning: timely disablement of access on a leaver or transfer.

5. Procedure

5.1 Request

A named requester (usually the line manager) raises an access request specifying the individual, the system, and the role(s), with a business justification. Do not accept “give them the same as the last person” requests; the role must be named.

5.2 Authorize

1. The system or process owner approves the request against the role definitions and justification.
2. For privileged roles, a second approver (typically QA) also approves.
3. Confirm the requested role(s) do not create a segregation-of-duties conflict against the SoD matrix, at both role level and the individual’s combined-role level.

5.3 Provision

1. The administrator creates the account with a unique ID and assigns only the approved role(s). Least privilege is enforced here, not assumed.
2. Do not reuse a retired user ID; retire IDs permanently so audit-trail attribution stays unambiguous over time.
3. For a service account, record the owner, disable interactive login, and vault the credential.

5.4 Train before access

Confirm the user has completed the required system and SOP training before the account is enabled for GxP work. The training record must predate account enablement.

5.5 Use and periodic review

1. Review standard accounts on a defined cadence (<<FILL: e.g. every 6-12 months>>) and privileged accounts more frequently (<<FILL: e.g. quarterly>>).
2. Each review compares active accounts to the current HR roster and to business justification, checks for SoD breaches and role accumulation, and remediates exceptions.
3. An independent reviewer (not an administrator) signs the review; the signed record is the evidence.

5.6 Change (mover)

A job change triggers a fresh request and authorization, and the removal of any role no longer needed. Removing old access is as important as adding new access; role creep happens when changes only ever add.

5.7 Deprovision (leaver)

1. Disable access on a defensible clock: <<FILL: e.g. same business day for privileged access, within the SOP window for standard access>>.
2. Confirm disablement (not just an HR ticket) and record it.
3. Reassign or vault any service-account ownership the leaver held.

6. Acceptance criteria

Access management is acceptable when all of the following are true:

• Every active account maps to one identified, current individual or a documented service account.
• Every grant traces to an approved request with a named role and justification; privileged grants have a second approver.
• No role, and no individual’s combined roles, violate the SoD matrix.
• Training records predate account enablement.
• Periodic and privileged-access reviews are performed on cadence, signed by an independent reviewer, with exceptions remediated.
• Leavers and transfers are deprovisioned within the defined window, confirmed and recorded.
• Retired user IDs are never reassigned.

7. References

21 CFR Part 11 (11.10(d), limiting system access to authorized individuals; Subpart C for signatures). EU GMP Annex 11 (clause 12, security; clause 9, audit trails). FDA guidance, Data Integrity and Compliance With Drug CGMP (2018). MHRA GXP Data Integrity Guidance and Definitions; PIC/S PI 041.

Confirm the current version and clause numbers of each reference before issue.

8. Records generated

Access request and authorization records; account provisioning and deprovisioning records; training-before-access confirmations; periodic and privileged-access review records; SoD conflict-check records.

9. Revision history

10. Approvals

Filled specimen

The following shows an access-request record completed for an illustrative new analyst on a chromatography data system. The names and numbers are illustrative; replace them with your own.

In this example the account was created with only the Operator role, the SoD check confirmed the analyst cannot approve their own results, and training was recorded before the account went live. Those three facts are what an inspector confirms first.

Common inspection findings this SOP prevents

• Shared or generic logins, so records are not attributable to a person.
• Access granted with no request, no named role, or no justification.
• Terminated users still active weeks after leaving.
• Role creep: permissions accumulated across job changes and never removed.
• Access enabled before required training was completed.
• A retired user ID reassigned to a new person, making attribution ambiguous over time.
• Periodic access reviews not performed, or signed by the administrator being reviewed.

How to adapt this SOP

1. Set your document number, owner, and effective date in the header.
2. Set your review cadences in 5.5 and your deprovisioning windows in 5.7.
3. Point section 5.2 at your real role and SoD matrix, and the training step at your training system.
4. If you use single sign-on, add how deprovisioning propagates from the identity provider and how signing still re-authenticates.
5. Confirm every regulation in section 7 against the current published version before issue.