Role-based Process Control: How Authority Shapes Execution

What role-based process control means

In operations, a role name must translate into specific authority. For each function, it must be established which tasks and decisions it may perform on which subjects, and what responsibility this entails.

Unlike general access control, it considers more than whether someone may open a page or read a record. What matters is the process effect: Who may claim a task, confirm a measurement, hand over material, request rework, block a state, or grant approval?

Task orchestration creates and distributes specific tasks based on the process state. Role-based process control determines which people are actually eligible for each task and its possible outcomes.

Example: Substitute authority ends while a task is open

In an illustrative case, P7 covers the review role at the North site until 14:00. At 13:50, P7 claims a task. At 14:05, the person attempts to approve the review result. For this example, it is specified that substitute authority no longer permits any new approval from 14:00 onward.

The earlier permission to claim the task is therefore insufficient. At approval, the authority valid at that time must be checked. The application should reject the action with an understandable reason and offer the designated handoff path. A window that is still open must not extend authority that has ended.

The inputs already made remain attributed to P7 and the context at that time. Under the defined transition rule, the open task passes to a person who remains authorized. Claiming it does not automatically give that person the right to present earlier information as their own observation.

Whether revocation actually takes effect at the moment of action must be tested technically. For a comparison of compliance software, this case provides a concrete permissions test: what matters is rejection of an action that is no longer permitted, not merely the role label displayed.

Permissions are checked at the moment of the process action

Logging in at the start of the working day does not prove that every later action is permissible. Permissions may change, substitute authority may end, or the process subject may move into an area outside the active role's scope.

The check should therefore occur at the action that has substantive effect. Before approval, a hold, handoff, or correction, the system assesses whether identity, role, scope, and, where applicable, separation of duty still meet the requirements.

If the action is rejected, the attempt also remains appropriately traceable. The system should explain understandably which prerequisite is missing without unnecessarily exposing confidential permission structures.

A role describes an operational function

A role is more than a job title. It describes a function in the process with associated responsibilities and authority. Examples include operator, reviewer, authorized approver, warehouse manager, or system administrator.

The NIST model for role-based access control assigns users to roles and roles to permissions. Permissions are thus linked to organizational functions rather than managed separately for each person.^[1]

For actual operational processes, however, a role name is not enough. The role must be defined in substantive terms: Which activity does it cover? Which objects, sites, or product groups does it apply to? What qualification is required? And may it only perform work, or also review its own result?

Permissions apply to specific actions

A role should not receive blanket “full access” when it actually needs only a few process actions. Permissions can be described more precisely as a combination of action and subject: start a task, record a measurement, move inventory, set a review status, or release a specific batch.

The XACML profile for Core and Hierarchical RBAC describes roles as organizational functions with assigned responsibilities and permissions. It also addresses role hierarchies and permissions that may require several roles simultaneously.^[2]

The technical check should therefore ask more than “Does this person have the quality assurance role?” It must also consider the intended action, affected object, and any additional conditions. Permission to review documents does not automatically authorize release of a production batch.

Reading, editing, and making substantive decisions are different rights

Many systems limit permissions to reading, writing, and deleting. This classification is too coarse for controlled processes. Entering a result, confirming its review, and approving a subsequent state have different substantive meanings.

A person may be allowed to record a measurement without conducting its final review. Another role may confirm plausibility but cannot release a batch. Only a function expressly authorized to do so may set the status that enables use, further processing, or distribution.

An approval workflow manages such review, return, and approval as a distinct decision process. Role-based control supplies the eligible participants and prevents a technically possible interface action from automatically counting as a decision with substantive effect.

A role does not necessarily apply in every context

The same person may hold several roles. Which of them they may exercise in a particular situation often depends on the operational context. Site, area, product group, process phase, shift, or organizational assignment may limit the permitted scope.

A warehouse role at site A does not necessarily authorize material movements at site B. A person may be authorized to release one product group without having the same responsibility for other products. A substitute's role may also be activated only for a specific period.

The check therefore connects identity, role, and scope. It must not rely solely on a global role name. Otherwise, roles expand over time and grant authority never intended for the specific task.

Roles and situational attributes can work together

A purely role-based model reaches its limits when every operational detail creates a separate role. “Reviewer” would then generate numerous variants for site, product group, shift, and process phase. Such role explosion becomes difficult to understand and prone to error.

Instead, the role can describe the basic function while attributes constrain its current scope. For example, a person holds the “Review” role; the system additionally assesses whether they are qualified for the affected site, assigned to the product group, and were not involved in execution themselves.

This keeps the decision traceable: role, action, object, and applied conditions are considered together. However, the system should avoid hiding substantive permissions in opaque individual rules. Users and responsible persons must be able to understand why an action was permitted or rejected.

An assigned role does not replace evidence of qualification

An organizational role and a person's substantive suitability are connected but not identical. Certain tasks may require training, instruction, experience, a certificate, or formal appointment.

Process control should be able to check whether the required qualification is valid at the time of execution. If training validity ends or authorization is revoked, new tasks must not continue to be generated solely on the basis of an old role assignment.

Digital work instructions provide the approved procedure appropriate to the task. They do not, however, automatically make an unqualified person suitable. Task guidance and permission checks serve different functions.

Separation of duty limits incompatible roles

Role-based control should not only grant authority but also prevent impermissible combinations. Depending on the process, someone who performed a critical operation may not be allowed to independently review or approve it.

In the NIST RBAC model, static separation of duty restricts assignment of incompatible roles. Dynamic separation of duty, by contrast, limits which roles a person may activate simultaneously within the same session. This does not yet constitute a check of all earlier actions on a batch.^[1]

A rule such as “The person who performed an operation may not independently review the same operation” additionally needs the history of the specific process instance. This history-based separation of duty must also take effect when execution and review occur in different sessions.

The history-based check needs the actual history. Only when it is known who was involved with the specific batch, task, or document version can the independence of a later review be assessed. A mere role list without process context is insufficient.

MHRA section 6.16 also addresses conflicts of interest involving system administration: the number of people with administrator access should be kept to the minimum possible for the organization. Rights such as deleting data or changing databases and system configuration should not be assigned to people directly involved in generating, reviewing, or approving the data. Generic administrator accounts should not be used routinely; administrators need individually attributable credentials.^[7] Technical administration therefore needs to be distinguished from the authority to make substantive decisions about those data.

Task assignment and execution authority must align

A task may initially be offered to a group of potentially responsible people. Only when it is claimed is it assigned for actual handling. WS-HumanTask distinguishes, among other things, potential and actual owners and further human roles in the task lifecycle.^[3]

Weske describes the architectural basis for this selection in human-interaction workflows: the workflow engine can use organizational information, skills, and competencies to offer work to people who are available and capable of performing it.^[8] This supports the selection of suitable participants. For P7, however, the earlier task offer does not establish whether a later approval remains authorized; that requires the process-specific action check described here.

Claiming the task must succeed only if the person is authorized in the current context. If their role changes during a task already in progress, the process needs a clear rule: May they complete it, is the task paused, or must it be reassigned in a controlled manner?

Delegation is not an informal handoff either. The delegating person must be authorized to delegate, the recipient needs the required role, and the change remains visible with its time and reason. Responsibility must not become blurred through hidden rerouting.

Define the end of substitute authority together with open-task handling

Substitute authority needs a defined scope: period, task types, sites, and, where applicable, excluded approvals. It does not necessarily include every authority held by the person being covered.

For its end, it must be determined which further actions are prohibited and how open tasks are handed over. Automatic revocation is one possible implementation; its timely effect, including existing sessions, must be tested.

Role changes need a controlled lifecycle

New roles and permissions should not be made effective directly by the same person requesting them. Depending on risk, request, review, approval, activation, and regular review may be separate steps.

Assignments must be updated promptly when people join, change functions, or leave. Accumulated old permissions are particularly critical: a person changes functions but retains rights from their previous work, unintentionally allowing incompatible roles to be combined.

The workflow engine can control tasks and states in such a change process. However, the substantive decision about which role is required and which other functions it is compatible with remains an organizational responsibility.

MHRA section 6.16 makes this concrete for systems handling GxP data: where individual user access is supported, it must be used. Both current access levels and historical access information must be demonstrable; if the system does not retain that history, it must be recorded outside the system.^[7] For P7, this means being able to establish retrospectively which access rights applied at 13:50 and which no longer applied at 14:05. A list of today’s role assignments would not be sufficient.

Emergency permissions must remain exceptional

In exceptional situations, an action that is normally unavailable may be urgently required. A permanent administrator account alone would be too broad for this purpose. A narrowly limited emergency permission, activated only for a particular purpose and period, is preferable.

Activation may require a justification, an additional confirmation, and immediate notification of responsible functions. Every process action performed under this permission is specially identified and reviewed afterward.

Emergency access does not suspend substantive prerequisites. It must not arbitrarily override missing qualifications or incompatible responsibilities. For the end of the situation, it must be defined how the additional authority is revoked and how the effectiveness of revocation is checked. Open tasks must then be reassessed under the regular roles.

Regulated systems require controlled authority

For closed systems within its scope, 21 CFR Part 11 requires, among other things, limiting system access to authorized individuals and checks ensuring that only authorized individuals can use the system, electronically sign records, access input or output devices, or perform particular operations.^[4]

In the GMP environment, EU-GMP Annex 11 likewise requires restricting access to computerized systems to authorized persons and recording the granting, changing, and revocation of access authorizations.^[5]

These requirements do not prescribe one particular role model for every organization. The specific design depends on the system, process, risk, and applicable legal framework. Role-based process control can support implementation but replaces neither the substantive definition of roles nor system validation.

What role-based process control cannot accomplish alone

• A role does not prove qualification. Substantive suitability and validity must be determined separately.
• A permission does not prove that an action was performed. Organizational responsibility may already exist through a function or task assignment. The specific operation must show who actually acted and what effect resulted.
• RBAC does not replace every aspect of context. Site, object, time, and other attributes may also be required.
• A role assignment must not continue indefinitely. Changes, substitute arrangements, and revocation need a controlled lifecycle.

Regulatory finding

Finding: The FDA cited shared credentials for an HPLC system and administrator privileges that allowed analysts to modify and delete data. Investigators also found deleted GC analytical sequences in the recycle bin.^[6]

Assessment: A role description must be reflected in actual system permissions. Individual accounts make actions attributable; separate permissions limit what personnel carrying out the work can change or delete in the system.

Review question: Do the people performing measurements also have permission to delete data?

Letter dated 14 April 2026 · Source checked on 18 September 2026.

This section presents the selected regulatory finding as stated at the time of the letter. Company responses and subsequent developments are not assessed here; this account does not describe the company’s current compliance status.

Claiming a task at 13:50 does not authorize every later action

In the example, substitute authority ends while the task is still open. A sound process therefore checks the new approval action and, if authority is missing, follows a defined transition.

Role-based process control connects function, scope, and the time of action. Its quality is also demonstrated by a justified rejection that preserves earlier work and makes the next responsibility clear.