Role-based access control in OSH

Role-based control groups permissions by responsibility. It separates viewing, editing and administration of preventive information.

In brief

Role-based control groups permissions by responsibility. It separates viewing, editing and administration of preventive information.

Contents
  1. How RBAC works
  2. A job title does not settle the full scope
  3. Separating incompatible functions
  4. Managing job changes and temporary cover
  5. Validation example
  6. Limits of the model
  7. Related concepts
  8. References

A–Z dictionary →

How RBAC works

In role-based access control, or RBAC, permissions are assigned to organisational functions and people are linked to those functions. This avoids configuring every authorisation from scratch for each user. The model requires actions and resources to be described: reading an assessment, editing a measure, approving a record or administering users are different capabilities.

A job title does not settle the full scope

The same role may need limits by company, workplace, team or file. Being a prevention technician does not imply access to the entire organisation. Health information must also be distinguished from operational conclusions. Design starts with health data protection and what each function needs to perform its work.

Separating incompatible functions

Separation of responsibilities can prevent the creator of an operation from being its sole approver or a technical administrator from routinely using clinical information. Incompatibilities are defined according to the process and risk. Adding many roles without reviewing their combinations can have the opposite effect: a person accumulates permissions and gains broader access than intended.

Managing job changes and temporary cover

Account creation is only the beginning. When someone changes workplace or responsibility, previous permissions should be removed and new ones checked. Temporary cover needs a defined scope and duration. Periodic review compares active users, assigned roles and actual needs, including contractor accounts. Exceptions need an owner and justification, avoiding permanent privileges left over from a past emergency.

Validation example

In a hypothetical example, a manager views outstanding measures at their workplace and a healthcare professional accesses the appropriate clinical record. Access that should be denied is also tested, such as changing the workplace in a search or downloading a document through a direct link. Hiding a menu option does not demonstrate that the resource is protected on the server.

Limits of the model

RBAC is a way to organise authorisations, not a certification of compliance. It can be combined with attributes and other rules when context requires. The application must be checked to ensure it applies permissions to queries, exports, APIs and automated processes, and maintains useful evidence of changes and access.

References

  1. NIST: role-based access control model. Official source
  2. NIST: A Revised Model for Role Based Access Control. Official source

Editorial information

Publication date: 1 November 2026.

Editorial responsibility: Sabentis Editorial Team.

Author: Pablo RodríguezLinkedIn

Executive Vice President of the ORP International Foundation and Chief Financial Officer of Sabentis.

Request a Demo

Discover all that Sabentis can do for your organization.

Try Sabentis

request a demo
stars 5
GetApp Software Advice Capterra