Digital laboratory user roles: access and privileges

A role named “analyst” can authorise very different activities in two systems. In a CDS it might allow acquisition and reprocessing; in a LIMS it could also include master-data changes or approvals. The profile name does not demonstrate that its privileges are correct.

Access control must connect each person to assigned activities, affected records and authorised boundaries. The intended outcome is a verifiable configuration, maintained as people and processes change. The following examples support control design and authorised testing in a test environment.

1. Distinguish responsibilities from technical capabilities

List actual actions: acquire, change a method, reprocess, review, approve, export, manage users or intervene on files. Assign process and system owners; clarify who authorises rights and who implements them. The technical ability to change a database does not confer scientific authority to approve a result.

Analyst, reviewer, administrator, IT and support are starting points, not five universally mandatory profiles. Check the separations required by the process, including second-person review where applicable. For administration, FDA guidance recommends independence from those responsible for record content. Organisational limitations require documented assessment and adequate controls, not an implicit exception.

2. Build the role–action–evidence matrix

This original example does not prescribe an organisational chart. Replace generic names with the actual authorising functions and specify system, project, record type and use conditions. “May modify” without defining what and when leaves the boundary unclear.

3. Govern identity, authentication and special accounts

Identity indicates who or which service acts; authentication verifies that identity; authorisation defines what it may do. Successful login does not prove correct profile permissions. Also assess rights inherited from groups, local permissions and routes to files or databases: the application screen alone may not reveal every access path.

GMP activities requiring individual attribution must not use shared credentials. FDA distinguishes simple read-only viewing from review attributable to a person: a shared viewing account does not become an appropriate account for signing a review.

For service accounts, document purpose, owner, privileges, protected secret management and dependencies. An automated process must be recognisable as such and linked to the relevant transaction; do not present it as an analyst’s approval. For privileged access, separate administrative from routine use and define protections consistent with risk and requirements. There is no universal password lifetime to copy into every laboratory.

4. Follow requests, changes and revocation to their actual effect

A request should identify the person, activity, scope, reason, prerequisites and duration if temporary. Retain approval, implementation and verification of the resulting rights. Do not close the ticket merely because a profile was selected: check what the user can actually do, including combinations of roles.

When duties change, compare old and new rights and remove those no longer justified. For leavers, connect personnel notification to deactivation and verify affected sessions and access according to the defined process. Disabling access does not mean deleting identity from historical records. The author, action and relevant authorisation at the time of the activity must remain reconstructable.

5. Test what the role must not do as well

In an authorised test environment, use representative fictitious identities and data. Check an allowed and a prohibited action at critical boundaries: for example, acquiring a sequence without changing privileges, or viewing a result without approving it. Define the expected outcome beforehand and retain configuration, observed result and any deviation.

A hidden button is insufficient: confirm that the operation is actually denied through the relevant application paths authorised for testing. Assess combined roles, temporary-access expiry and revocation. These are bounded functional checks, not instructions for attacking operational systems. Connect them to LIMS and CDS validation tests.

6. Simulated case and ongoing review

A trained analyst must temporarily cover for an absent reviewer. The owner assesses competence, assigned records and conflicts with analyses performed by that same person. They authorise only compatible scope, with an expiry; the administrator applies the change to the named identity. The analyst does not use the colleague’s credentials.

Tests confirm the required access and necessary separation. At expiry, removal of the additional rights is verified; completed reviews remain attributed to their author. If the system cannot support the required control, the solution must be assessed and authorised before use, without improvising a shared account.

Periodic review compares users, roles, actual activities, inactive accounts and special access. Define frequency and criteria based on risk and requirements, alongside change-triggered reviews. Emergencies require a defined route, reason, bounded access, recording and subsequent oversight; they do not authorise permanent privileges. For regulatory scope, see Annex 11 and Part 11 in the laboratory.

Sources and status — checked: 2 October 2026. EU GMP Annex 11, January 2011 revision current in the official index, §§2, 11–12; FDA Data Integrity, final nonbinding guidance, December 2018, Q4–5; 21 CFR Part 11, regulation where applicable, §§11.10(d), (g) and 11.300; NIST SP 800-53 Rev. 5, September 2020 with December 2020 updates, AC-2, AC-5, AC-6, consulted alongside the official note on release 5.2.0 from 2025. NIST is a technical reference for these controls, not an automatically applicable GMP requirement.