Role-Based Access in Global EHS Software: Who Sees What

Why access is a design question for groups

A single factory can run its safety records with a handful of users who all know each other. A multinational or a large industrial group cannot. It has thousands of people reporting from dozens of sites in several countries, contractors who need to log in, country managers who should see their own country but not their neighbour's, a sustainability team that needs group totals, and internal auditors who need to read everything but change nothing.

Get access wrong in either direction and the system fails. Too open, and injury details, investigation findings and disciplinary notes leak across companies and countries, which is a data protection problem and a trust problem. Too closed, and people work around the system with spreadsheets and chat groups, so the group dashboard is incomplete. This guide sets out a practical model for who should see and do what in a global EHS (environment, health and safety) system, what the main standards and regulators say, and what to test before you buy or audit one.

Three questions behind every permission

Every access decision in an EHS system answers three separate questions. Mixing them up is the most common design mistake.

Question	What it controls	Example
Role: what can this person do?	Actions: report, review, approve, close, configure	A site HSE officer can review incidents but not change the risk matrix
Scope: where can they do it?	The part of the organization: group, region, country, cluster, site	A country manager for Bangladesh sees Bangladesh sites only
Sensitivity: which details can they see?	Fields inside a record: names, medical details, witness statements	A dashboard viewer sees injury counts, not the injured person's name

Role-based access control (RBAC) handles the first question. NIST describes RBAC as a model in which permissions are grouped into roles and users get permissions only through the roles assigned to them. It was standardized as ANSI/INCITS 359 in 2004 and revised in 2012. Because roles change less often than people, they make access easier to manage and review. Scope and sensitivity are the parts that groups add on top, and they are where most of the real risk sits.

What the standards and regulators say

No single law says how an EHS system must assign roles, but several widely used frameworks point the same way:

GDPR, Article 25(2), data protection by default. Controllers must make sure that by default only the personal data needed for each purpose is processed, which covers who can access it. Personal data must not be made accessible without the individual's intervention to an indefinite number of people. An EHS system where every user can open every incident does not meet that idea.
UK ICO guidance on sickness and injury records. The UK regulator treats sickness and injury records as health information, which is special category data. It says access should be limited to people who need it for their job, that records should not be used when only the length of an absence or the circumstances of an accident are needed, and that publishing individual sickness absences in a league table is not acceptable, while totals by department with no one identifiable are.
NIST SP 800-53, control AC-6 (least privilege). Users and processes get only the access they need for their assigned tasks.
ISO/IEC 27001:2022, Annex A. Controls on access control (5.15), access rights (5.18), segregation of duties (5.3), privileged access rights (8.2), information access restriction (8.3) and logging (8.15) all apply to an EHS system that holds personal data.
OWASP Top 10:2025. Broken access control is again ranked first; OWASP reports that every application it tested had some form of it. Its advice: enforce access in trusted server-side code, deny by default, check that the user is allowed to act on that specific record, and log access control failures.

The common thread: give each person the smallest scope and the fewest actions they need, enforce it on the server, and keep evidence that it works.

A starting role matrix

Every group is different, but this matrix is a sound starting point for a multi-country rollout. Adapt the names to your own structure.

Role	Scope	Typical actions	Injury and health details
Worker / reporter	Own site	Report hazards, near misses and incidents; see own reports	Own reports only
Contractor supervisor	Sites they are assigned to	Report; see their own company's records	Own company's cases, as agreed in the contract
Supervisor / line manager	Own area or line	Review reports, own actions, first-level investigation	Their own team, when needed for the role
Site HSE officer	Site	Investigate, assign and verify actions, run audits	Yes, for the site
Plant head	Site	Approve investigations and closures, sign off reports	Yes, for the site
Country / cluster HSE manager	Country or cluster and below	Review serious cases, approve high-potential investigations	Serious cases; otherwise summary
Group / regional EHS director	Group or region and below	Set standards, review SIF cases, approve configuration changes	Serious cases; otherwise summary
Sustainability / ESG team	Group	Read KPIs and reports	No; counts and rates only
Internal audit / compliance	As agreed for each audit	Read records and history; no edits	Only where the audit needs it
System administrator	Configuration	Users, forms, workflows	No access to case content by default

Two points matter more than the exact rows. First, scope should follow the organizational hierarchy, so a person assigned to a country automatically covers every site in it, including sites added later. Second, being senior does not mean seeing more personal detail: a group director needs to know that a hand injury happened and why, not the injured worker's medical history.

Injury and health details need extra care

Incident records often hold the most sensitive personal data in the company: the injured person's name, the nature of the injury, treatment, days off work, sometimes drug and alcohol test results. Under GDPR-style laws this is health data. Practical rules that follow from the ICO guidance and data protection by default:

Separate the event from the person. Most users need what happened, where and why; far fewer need who was hurt and how badly.
Record absence as dates and days lost, and keep medical detail in a field only a few roles can open.
Build dashboards and league tables from counts and rates. Never show named individuals in group or country rankings.
Decide who sees witness statements and disciplinary notes before the first investigation, not during it.
Check exports and scheduled reports. A filter that hides names on screen is useless if the export includes them.

When you process this data through an EHS vendor, the contract and the vendor's security measures also matter. GDPR Article 28 covers processor contracts, and Article 32 security measures. Our guide to the data processing agreement with an EHS vendor lists what to require.

Separation of duties in EHS workflows

Separation of duties means one person should not be able to carry out a sensitive process alone. In EHS, the classic cases are:

the person who owns a corrective action should not be the only one who verifies it is effective;
the investigator of a serious incident should not be the only approver of the root cause, especially if the incident happened in their own area;
a site should not be able to downgrade the potential severity of its own SIF-potential case without a second review (see our guide to potential SIF reporting);
people who change forms, risk matrices or KPI definitions should not be the ones whose results those changes improve.

NIST notes that RBAC was designed with separation of duty in mind. In practice, it means giving approvals, reviews and configuration to a small set of named roles, and keeping a history of who changed what.

Where access designs fail

Hidden, not enforced. A menu item disappears, but the record can still be opened by changing a link or calling the server directly. This is exactly what OWASP warns about. Ask the vendor how scope is enforced on the server and test it.
Exports and email notifications. Scope works on screen but a scheduled report or notification goes to a distribution list.
Shared accounts. One login per site makes every record anonymous and every audit trail useless.
Contractors with employee roles. Contractors given a standard site role can often see other companies' data. Give them their own role and scope (our contractor safety guide covers the wider process).
Reorganizations. When a site moves to another cluster or a country is merged into a region, scopes built on manual lists break. Scopes built on the hierarchy move with it.
Too many administrators. Every site asks for admin rights to fix a form. Soon nobody knows who changed the risk matrix.

Joiners, movers and leavers

Most access problems appear after go-live. Agree a simple process: HR or site management requests access for joiners with a named role and scope; movers lose their old scope on the day they gain the new one; leavers and contractors at the end of a contract are deactivated, not deleted, so their records and history remain. Review access regularly, for example each quarter, by asking each site and country owner to confirm their user list, and record the review.

Checklist for your RFP or audit

#	Check	Done?
1	Role matrix agreed with EHS, HR, IT and the data protection officer	☐
2	Scope follows the organizational hierarchy, not manual lists	☐
3	Scope enforced on the server; tested by opening another site's record directly	☐
4	Injury and health details limited to named roles; dashboards use counts	☐
5	Exports, reports and notifications respect the same scope	☐
6	Approvals, closures and configuration limited to chosen roles	☐
7	Separation of duties for action verification and serious investigations	☐
8	Contractors have their own roles and scope	☐
9	History of changes kept for records and settings	☐
10	Joiner, mover and leaver process, with regular recorded access reviews	☐

Add these to the access section of our enterprise EHS software RFP checklist and ask every vendor to demonstrate them with three different user roles.

How AccelSafety handles it

AccelSafety, our enterprise HSE software, is built around one organizational hierarchy from group to region, country, cluster and site. Each user's access is scoped to their part of that hierarchy and everything below it, and the scope is enforced on the server, not just hidden in the screens. Approvals, reviews and configuration are restricted to the roles you choose, and dashboard numbers drill back to auditable source records with their history. The system is designed in line with GDPR (Articles 28, 32, 33 and 35). To see how your own structure and roles would look, book a demo or write to info@accelsafety.com.

General information, not legal advice. Check the laws that apply in each country where you operate and take advice from your data protection officer.

Role-based access in global EHS software: who should see what