Role-Based Access Control: Who Should See What in Your Laboratory's LIMS

The weakest link isn’t always the computer: it’s the permissions

When laboratory cybersecurity comes to mind, the imagination goes straight to encryption, firewalls, and external attacks. But according to Verizon’s 2025 DBIR — one of the most widely cited breach analyses in the industry, drawing on data from more than 12,000 confirmed incidents — 60% of the breaches analyzed involved the human element, and misused or stolen credentials were, for the second year running, the most common initial access vector: present in 22% of cases.

In a laboratory, that “human element” takes a very specific form: a technician’s account that can view results for clients outside their assignment, a former employee’s login that stays active months after they’ve left, or the habit — common for the sake of convenience — of giving everyone the same level of access “to keep things simple.” None of these scenarios is a sophisticated cyberattack. They are, simply, misconfigured permissions.

Encryption protects data from people who shouldn’t be inside the system. Role-based access control protects data from people who are already inside, but shouldn’t be able to see everything they can.

What is role-based access control (RBAC)?

Role-based access control (RBAC) is a security model in which permissions are not assigned person by person, but according to the role each user performs within the organization. Instead of manually deciding what each new employee can do, they are assigned a predefined role — “laboratory technician,” “quality manager,” “external client” — and automatically inherit the permissions associated with that role.

The principle behind it is known as least privilege: every user should have access only to the information and functions strictly necessary to do their job, no more. Not out of distrust toward staff, but because every additional permission is one more door that someone — an attacker, a mistake, a stolen credential — could end up going through.

The roles every environmental LIMS should distinguish

An environmental or water testing laboratory brings together profiles with very different information needs. A common reference model — and the one Zendo LIMS lets you configure module by module — distinguishes at least these six roles:

The separation between “analyst” and “quality manager” deserves a special mention: it’s not an administrative hierarchy, it’s a quality control. If the same person who enters a result is also the one who validates and issues it, there is no independent second look capable of catching an error, a method deviation, or, in the worst case, intentional manipulation.

Why this is a regulatory requirement, not just a best practice

ISO/IEC 17025: impartiality and confidentiality

The laboratory accreditation standard devotes clause 4.1 to Impartiality, which requires the laboratory to continuously identify and manage risks arising from staff relationships — including internal relationships that could influence a result — and clause 4.2 to Confidentiality, which requires a legally enforceable commitment to managing all information obtained during laboratory activities, unless the client itself authorizes its disclosure. A system where any user can view any client’s results is, in practice, a latent breach of clause 4.2.

Data protection regulations: minimization and access control

Article 32 of the EU’s General Data Protection Regulation (Regulation (EU) 2016/679) requires implementing appropriate technical and organizational measures to ensure a level of security appropriate to the risk, including the ability to guarantee the ongoing confidentiality of processing systems and services. Similar principles appear in data protection frameworks worldwide. Role-based access control is, alongside encryption, one of the most direct technical measures for meeting this kind of requirement: it limits, at the root, who can ever see a piece of personal data, rather than relying solely on the hope that no one decides to look.

Segregation of duties and ALCOA+

We’ve already covered, in the Quality, ISO and Regulatory Compliance series, the ALCOA+ principles and the audit trail as their technical guarantee: every action is logged, along with who performed it, when, and what changed. Role-based access control is the other half of that equation. The audit trail records what happened; access control decides, in advance, who is able to make something happen. A result validated by the same person who generated it — even if it’s perfectly logged in the audit trail — still lacks the value of an independent second review.

How role-based access control works in Zendo LIMS

Zendo LIMS lets you define each user’s security level by configuring their access permissions to every module of the application, so each profile — sampling, laboratory, quality, administration, management — sees and can modify only what their function requires.

Module-by-module permissions: Each user can have read-only, edit, or no access to every area of the system (requests, results, billing, statistics, administration).

Independent Web Portal for clients: External clients request analyses and check their own results and sample traceability, with no access to the rest of the system or to other clients’ information.

Combined with IP-based control and inactivity lockout: Role-based permissions are reinforced by the access layers covered in the previous article in this series.

Traceability of every user action: The system automatically audits the activity performed by each profile, including external users accessing through the web portal.

Frequently asked questions

What’s the difference between role-based access control and user-based access control?

User-based control assigns permissions to each person individually, which becomes difficult to maintain as the team grows. Role-based control assigns permissions to a function (“analyst,” “client”), and each person inherits the permissions of their role; onboarding or offboarding an employee becomes a matter of assigning or removing a role, not reconfiguring permissions one by one.

Is role-based access control mandatory for ISO/IEC 17025 accreditation?

ISO/IEC 17025 doesn’t literally require an RBAC system, but it does require guaranteeing the confidentiality of each client’s information (clause 4.2) and managing risks to impartiality (clause 4.1). In practice, a LIMS where every user can see all the data is hard-pressed to demonstrate compliance with these requirements to an accreditation body such as A2LA, UKAS, DAkkS, or ENAC.

What happens if an employee changes position within the laboratory?

With a role-based model, simply reassigning their role is enough: they automatically lose the permissions of their previous position and gain those of the new one. Without defined roles, it’s common for permissions to keep accumulating with every position change, creating users with more access than their current function requires.

Should the technical director have access to the entire system?

Not necessarily everything, but everything their oversight function requires: result validation, nonconformity management, and audit trail review. Unrestricted full access dilutes the principle of least privilege itself, even for the most senior profiles.