Role-Based Access Control (RBAC)

What role-based access control is

Role-Based Access Control (RBAC) is the controlled assignment of system access by defined role rather than directly per user. Roles are defined to match operational responsibilities — Lab Analyst, QA Reviewer, Document Approver, Audit Lead, Risk Assessor. Each role carries a defined permission set. Users are assigned to one or more roles, and the system grants access based on role membership, not individual rights.

In a regulated context, RBAC is the operational mechanism that makes most Part 11 access controls workable at scale. Without it, firms typically resort to per-user permission management that drifts within months, accumulates excess privileges, and fails to satisfy 21 CFR §11.10(d) under inspection.

RBAC is closely tied to segregation of duties, periodic access review, joiner-mover-leaver provisioning, and audit trail attribution. The five concepts together form the access-control discipline regulators expect to see operating in any GxP electronic system.

Why RBAC sits behind nearly every Part 11 inspection

The first questions an inspector asks about any computerised GxP system are about access. Who can do what? How is it controlled? Who reviews it? What happens when people change roles? The answers come out of the RBAC implementation. Programs with clear role definitions, documented assignment processes, and evidence of periodic review give clean answers. Programs without can't answer at all, and that itself is the finding.

RBAC weaknesses drive a recurring pattern of inspection findings. Shared accounts that defeat unique attribution. Users holding conflicting roles that violate segregation of duties. Excessive privileges that grant rights well beyond the role description. Delayed removal of access after termination. Missing periodic access review. Each of these surfaces in current FDA, MHRA, and EU inspections, and they featured heavily in the FDA chromatography enforcement actions that ran from 2017 onward.

Inspector perspective: a common inspector technique is to pick three users at random and trace each one's access through the system. What roles do they hold? Do those roles match their job responsibilities? When was the access provisioned and by whom? When was it last reviewed? If those four answers come together with documented evidence, the program holds. If any one is missing, the sample expands and the conversation gets serious.

Where RBAC obligations come from

RBAC isn't named directly in most predicate rules; the framework wraps several distinct expectations:

• 21 CFR §11.10(d): limiting system access to authorised individuals. The principal U.S. predicate for RBAC.
• 21 CFR §11.10(g): authority checks to ensure only authorised individuals can use the system, electronically sign records, access the operation or computer system input or output device, alter a record, or perform the operation at hand.
• 21 CFR §11.100: unique-signature attribution. RBAC is how firms operationally enforce unique-identity-to-role-to-action.
• 21 CFR §11.200(a): authentication using at least two distinct identification components — the technical baseline RBAC sits on top of.
• 21 CFR §11.300: identification code and password controls. RBAC governs what those credentials grant access to.
• EU GMP Annex 11 §12 — Security: physical and logical controls to restrict access to computerised systems to authorised persons; authority to enter, change, or delete data should be defined; access control should reflect role.
• EU GMP Chapter 4: documentation controls that depend on appropriate access being defined.
• MHRA "GxP" Data Integrity Definitions and Guidance for Industry (March 2018, updated September 2021): access control and segregation of duties as data integrity controls.
• PIC/S PI 041-1 (July 2021): §6 covers data lifecycle and access; §9 covers audit trail and review; the framework presumes RBAC is operating.
• ICH Q10 §2: management responsibility for resources including access governance.
• ISO 13485 §5.5: responsibility, authority, and communication — the QMS-side predicate for role definition.
• ISO 27001: while not specifically GxP, often cited in regulated firms as the broader access-control framework GxP RBAC sits inside.
• NIST SP 800-53 AC family: access control framework referenced by firms with U.S. government context.

What a working RBAC program contains

A defensible RBAC program contains these elements operating together:

• Defined role catalogue. Each role is documented with name, scope, permissions granted, intended job functions, and segregation-of-duties constraints. Stored as a controlled document.
• Role design that reflects SoD. Role definitions designed so no single role lets a user both create a record and approve its release, or both make a change and audit it. Where business need allows a combined role, the segregation gap is justified and signed.
• Provisioning workflow with approval. Role assignment requires a documented request from the user's manager, approval by the role owner, and a recorded action. Self-service assignment of GxP roles isn't supported. Provisioning events go to the audit trail.
• Joiner-mover-leaver lifecycle. A defined process for new hires (joiner), role changes (mover, including removal of prior role rights), and termination (leaver). The mover step is the one most commonly missed; programs that handle it well have automated triggers from HR systems.
• Privileged-access controls. Administrator and super-user roles get tighter controls: limited assignment, additional approval, more frequent review. Privileged actions surface in audit trail review.
• Periodic access review. Scheduled re-confirmation (typically quarterly for critical systems, longer for lower-risk) by the role owner. Documented decision per user per role: keep, modify, or revoke. Records retained as controlled records.
• Exception handling. A documented procedure for emergency access (break-glass), with mandatory post-event review. Temporary elevation tracked and time-bound.
• Audit trail integration. Every role assignment, modification, removal, and authentication event captured in the audit trail with identity, action, timestamp, and authorisation basis.
• External and contractor access governed. The same provisioning, review, and termination discipline applies to vendors, consultants, auditors, and any external party with system access.
• System validation includes access controls. CSV or CSA evidence specifically addresses RBAC implementation, role definition, and §11.10(d) / §11.100 / §11.200 controls.

What strong RBAC programs do that weak ones don't

Programs that hold up under inspection share these patterns:

• Role definitions are controlled documents. Not maintained in a spreadsheet someone updates ad-hoc. Versioned, approved, periodically reviewed.
• SoD analysis is documented and revisited. Not just at initial role design but re-confirmed when roles change or new roles are added.
• Provisioning approval is documented before access is granted. Not after the fact. Manager and role owner sign-off captured as a controlled record.
• Leaver process is fast and complete. Termination triggers immediate access removal across all GxP systems, not days later. Documented evidence of the removal.
• Mover process removes prior rights. When a user changes role, the prior role's rights are removed, not left in place. This is the most-missed step.
• Periodic access review actually happens. On the documented schedule. By the documented owner. With a documented disposition per user per role. Not a tick-the-box exercise.
• Shared accounts eliminated. No "lab" or "admin" generic accounts in any GxP workflow. HR offboarding and IT provisioning enforce uniqueness.
• Privileged access tightly governed. Admin and super-user roles get a separate, more rigorous lifecycle.
• Emergency / break-glass process defined. With mandatory post-event review and access reversal.
• RBAC included in audit trail review. Periodic checking for unusual access patterns: after-hours role assignment, role assignment without approval, role assignment that violates SoD.
• External user access on the same discipline. Contractors, consultants, and auditors held to the same standards.

How Complere supports RBAC

Complere is built around roles from the ground up. You don't assign permissions to people one by one — you define roles that match how your team actually works, and your users inherit what those roles allow. Two people in the same role get exactly the same rights, every time. When someone changes role, you update the assignment rather than re-engineering their permissions.

Inside every regulated workflow, your roles map to the actions that workflow supports — drafting, reviewing, approving, signing, viewing — and to which signature meanings each role can apply. When one of your users tries to act, the system checks at that moment whether they actually hold the authority. Rights removed yesterday don't linger today. Logins stay individual; shared accounts aren't a pattern Complere supports.

Every role assignment, change, and removal is recorded — who granted it, who received it, when, and why — so you can answer the inspector who asks "when was this person given this access?" without reconstructing it from email. Your data stays inside your own space; a role inside your account has no reach into anyone else's.

What stays your work: the role catalogue itself (which roles exist, what each one lets a person do, where SoD constraints apply), your provisioning approval workflow, your periodic access review cadence, and the joiner-mover-leaver discipline that connects to your HR processes. Complere gives you the access infrastructure; the governance discipline is your RBAC program.

Related access control and Part 11 terms

RBAC sits at the centre of the access-control discipline:

• Electronic Signature — depends on RBAC for role-based signature authority
• Audit Trail — every RBAC event goes to the audit trail
• 21 CFR Part 11 — §11.10(d) and §11.100 sit on RBAC
• Data Governance — RBAC is a key technical control in any data governance program
• Data Integrity — RBAC supports Attributable, the first ALCOA+ principle
• Audit Trail Review — RBAC events are reviewed as part of audit trail review