GDPR DPA for EHS Software: What Groups Should Require

Why the DPA matters more for EHS data

Most software contracts come with a standard data processing agreement (DPA) that procurement signs without much debate. For an EHS (environment, health and safety) system, that is a mistake. An EHS platform in a multinational holds incident reports with the names of injured workers, the nature of their injuries and days off work, witness statements, investigation findings, photos taken on site, training and licence records for drivers and equipment operators, and visitor logs. Much of it concerns employees and contractors, and injury and sickness details are health information, which the UK regulator, the ICO, treats as special category data.

The DPA is where you fix, in writing, what the vendor may do with that data, how fast it must tell you about a breach, who else touches the data, and how you get it back when the contract ends. This guide walks through what a group DPO, IT security lead and EHS director should require, clause by clause, with the EHS-specific details that standard templates miss.

Controller, processor and the group

In a typical software-as-a-service arrangement, your company decides why and how the EHS data is processed, so it is the controller, and the vendor processes the data on your behalf, so it is the processor. Article 28 of the GDPR then applies: you may use only processors that provide sufficient guarantees of appropriate technical and organisational measures, and the processing must be governed by a binding contract.

In a group, decide early which entity signs. Often a parent company contracts for the whole group, while each country company remains controller for its own employees' data. Your legal team should document how that works, because it affects who instructs the vendor, who receives breach notices and who answers data subject requests in each country.

Describe the processing properly

Article 28(3) requires the contract to set out the subject matter and duration of the processing, its nature and purpose, the types of personal data and the categories of data subjects. Vague descriptions such as "customer data" make every later question harder. For an EHS system, a useful description looks like this:

Data subjects	Typical personal data in an EHS system
Employees	Name, ID, site, role; incident, hazard and near-miss reports they made or were involved in; injury type, treatment and days lost; training and competence records
Contractor workers	Name, employer, site access, inductions, permits, incidents involving them
Drivers and equipment operators	Licences, authorizations, vehicle and equipment checks
Visitors	Name, host, time on site, safety briefing
Witnesses and investigators	Statements, interview notes, roles in the investigation
Committee members and auditors	Names, minutes, audit findings and actions assigned to them

Mark which fields are health data, and state that photos and attachments are in scope too: a site photo can show a person's face or a vehicle number plate.

Article 28, clause by clause, for EHS

Article 28(3) lists what the processor must commit to. Here is each point with the question to ask an EHS vendor:

Article 28(3)	What it requires	EHS-specific question
(a)	Process only on your documented instructions	Does the vendor use incident data for anything else, such as benchmarking or product analytics? If so, is it in your instructions?
(b)	Staff bound by confidentiality	Which vendor staff can open case records, for example during support, and how is that logged?
(c)	Security measures under Article 32	Are the measures written in an annex, not just "industry standard"? (See below.)
(d)	Rules for engaging sub-processors	Where is the list, and how are you told about changes?
(e)	Help with data subject rights	Can the vendor find and export everything about one injured worker across sites and modules?
(f)	Help with Articles 32 to 36	Will the vendor support your DPIA and breach notifications with facts and documents?
(g)	Delete or return data at the end, at your choice	In what format, how fast, and with what confirmation?
(h)	Information to show compliance; audits and inspections	What reports, certificates or audit rights do you get, and at what notice?

The processor must also tell you immediately if, in its opinion, one of your instructions infringes data protection law. Some groups base their DPA on the European Commission's standard contractual clauses for controllers and processors (Implementing Decision (EU) 2021/915 of 4 June 2021) and add the EHS details in the annexes.

Sub-processors and the chain

An EHS vendor rarely works alone. Hosting, email delivery, backups and support tools may all be sub-processors. Under Article 28(2) the processor may engage another processor only with your prior written authorization, specific or general; with general authorization it must tell you about intended changes and give you the chance to object. Under Article 28(4) it must pass the same data protection obligations down the chain, and it remains fully liable to you if a sub-processor fails.

In October 2024 the European Data Protection Board (EDPB) adopted Opinion 22/2024 on this topic. Its main points for buyers:

controllers should have information on the identity (name, address, contact person) of all processors and sub-processors readily available at all times;
the duty to check that processors and sub-processors give sufficient guarantees applies regardless of the risk, although how far you check can vary with the risk;
the processor proposes sub-processors, but the final decision and responsibility for engaging one remains with the controller;
you do not have to ask for every sub-processing contract as a matter of routine, but you should decide whether you need to see them to demonstrate compliance;
where a processor transfers data outside the EEA to a sub-processor, the processor prepares the transfer documentation, but you must still assess it and be able to show it to your regulator.

In the DPA, ask for a current sub-processor list with locations, a notice period for changes that gives you real time to object, and the right to see transfer documentation.

Breach notification: set the clock

Under Article 33 the controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless it is unlikely to result in a risk to people. The processor must notify the controller without undue delay. The GDPR gives the processor no fixed number of hours.

The EDPB's Guidelines 9/2022 on breach notification (version 2.0, March 2023) add three practical points. The processor does not need to assess the risk before telling you; it only needs to establish that a breach has happened. In principle you are aware once the processor has told you, so your 72 hours start then. And the contract can require early notification, with details provided in phases as they become available.

For EHS data, write a concrete target into the DPA, a named contact on both sides, and the minimum content of the first notice: what happened, which sites and data categories are affected, whether health data is involved, and what the vendor has done so far.

Security measures for the annex

Article 32 requires measures appropriate to the risk and gives examples: pseudonymisation and encryption; the ongoing confidentiality, integrity, availability and resilience of systems; the ability to restore access to data quickly after an incident; and regular testing of how well the measures work. Article 32(4) adds that anyone acting under the controller's or processor's authority may process the data only on instructions.

For an EHS system, the annex should also cover access control: how access is scoped to each user's part of the organization, whether that is enforced on the server, who can see injury details, and how changes are logged. Our guide to role-based access in global EHS software gives a role matrix you can attach.

Do you need a DPIA?

Article 35 requires a data protection impact assessment (DPIA) before processing that is likely to result in a high risk. It is always required for large-scale processing of special categories of data, such as health data. The guidelines of the former Article 29 Working Party, endorsed by the EDPB, list nine criteria that point to high risk, including sensitive data, large-scale processing and data about vulnerable data subjects; the Maltese regulator's list, built on those criteria, names employees among vulnerable data subjects. As the ICO explains, meeting two criteria usually indicates that a DPIA is needed. A group-wide EHS system holding injury data on thousands of employees will often meet several, so plan the DPIA before go-live and use Article 28(3)(f) to get the vendor's input on hosting, security and sub-processors.

Exit: getting your records back

Article 28(3)(g) gives you the choice to have data deleted or returned at the end of the service. For EHS records, return usually matters more than deletion: incident, training and inspection records may have to be kept for years under local laws, and the history behind a closed investigation is evidence. Specify in the DPA the export format (for example structured files plus attachments), what is included (records, history, photos, documents), the time frame, and a written confirmation of deletion afterwards, unless law requires the vendor to keep a copy.

Outside the EU

Many groups run sites in the GCC, South Asia and elsewhere. Other laws set their own processor rules. For example, the UAE's Federal Decree-Law No. 45 of 2021 on personal data protection requires a processor that becomes aware of a breach to inform the controller promptly, and it does not apply to free zones that have their own data protection laws. Map each country's law with local counsel, and write the strictest common requirements into one group DPA where you can.

DPA checklist

#	Check	Done?
1	Signing entity and controller roles across group companies documented	☐
2	Processing described: subjects, data types, health data, photos and attachments	☐
3	Use of data limited to your instructions; no other use without written agreement	☐
4	Vendor staff access to case records limited and logged	☐
5	Security measures written in an annex, including access scoping	☐
6	Current sub-processor list with names, addresses and locations	☐
7	Notice period and right to object to new sub-processors	☐
8	Transfer documentation available for any transfer outside the EEA	☐
9	Breach notice: target time, contacts, minimum content, phased updates	☐
10	Support for data subject requests and the DPIA	☐
11	Audit rights and compliance information	☐
12	Exit: export format, scope, time frame and deletion confirmation	☐

Use it alongside the data protection section of our enterprise EHS software RFP checklist.

How AccelSafety fits

AccelSafety, our enterprise HSE software, is designed in line with the GDPR, including Articles 28, 32, 33 and 35. Every user's access is scoped to their part of one organizational hierarchy, from group to site, and enforced on the server; approvals, reviews and configuration stay with the roles you choose; and dashboard numbers drill back to auditable source records with their history. Read our data protection page, then book a demo or write to info@accelsafety.com to go through your DPA questions with us.

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

The GDPR data processing agreement for EHS software: what groups should require