DPIA for Workplace Video Analytics: A Step-by-Step Template for UK and EU Sites

A data protection impact assessment (DPIA) is the written risk assessment that UK and EU data protection law requires before you start processing personal data in a way likely to put people's rights at high risk. AI video analytics that watches a workforce for unsafe acts and conditions almost always meets that threshold, so the DPIA should be one of the first documents in a safety technology project, written before cameras are connected. This article explains when the duty applies and gives a section-by-section template you can adapt for a warehouse, port, plant or construction site.

This is general information for safety and operations teams, not legal advice. Have your data protection officer or counsel review your DPIA before you rely on it.

When is a DPIA legally required for safety cameras?

Article 35(1) of the GDPR requires a DPIA before processing that, "in particular using new technologies", is likely to result in a high risk to the rights and freedoms of individuals ^[1]. Article 35(3) lists three cases where one is always required, including "systematic monitoring of a publicly accessible area on a large scale" ^[1]. Most factory floors and yards are not publicly accessible, so that specific trigger often does not apply. The general test in Article 35(1) still does.

European regulators gave that test practical shape in the Article 29 Working Party's DPIA guidelines (WP248 rev.01). They list nine criteria that point to high risk, including systematic monitoring, sensitive data, data about vulnerable data subjects and innovative use of technology ^[5]. Employees count as vulnerable data subjects because of the power imbalance with their employer ^[5]. The guidelines say that, in most cases, processing meeting two criteria will require a DPIA ^[5]. An AI system that continuously analyzes video of employees meets at least three.

In the UK, the ICO's published list of processing that requires a DPIA includes "innovative technology", explicitly including AI, along with tracking an individual's "geolocation or behaviour" and any processing of biometric data, where combined with other criteria ^[2]. Its worker monitoring guidance names biometric monitoring and monitoring that may lead to financial loss, such as performance management, as examples of high-risk processing ^[4]. The ICO also encourages a DPIA for monitoring even where high risk is not certain, because it helps the decision ^[4].

The practical rule: assume a DPIA is needed for any AI safety camera, wearable or proximity system that processes data about identifiable workers in the UK or EU. If you conclude one is not needed, write down why.

A note on UK law in 2026

The UK GDPR keeps the same DPIA structure. The ICO states that its DPIA guidance and its worker monitoring guidance are under review because of changes made by the Data (Use and Access) Act ^[2][10]. Check the ICO site for updated text before you finalize a UK DPIA.

Who does what in a safety analytics DPIA?

The employer is normally the controller, because it decides why the cameras are analyzed and what happens with the alerts. The vendor is usually a processor that handles data on the employer's instructions. Responsibility for the DPIA sits with the controller.

The template: what to write in each section

The ICO describes a DPIA process in steps: identify the need, describe the processing, consider consultation, assess necessity and proportionality, identify and assess risks, identify mitigations, and sign off and record outcomes ^[3]. GDPR Article 35(7) sets the minimum content ^[1]. The template below follows that order and adds what a safety video project needs.

Section 1: Need for a DPIA

State which high-risk indicators apply (systematic monitoring, employees, new technology, biometrics if any) and cite the ICO list or WP248 criteria you relied on ^[2][5]. Note the date and the project stage. The DPIA must be complete before live processing begins, so a pilot on real workers counts as processing.

Section 2: Description of the processing

This is the longest section and the one regulators read first. Article 35(7)(a) asks for "a systematic description of the envisaged processing operations and the purposes" ^[1]. For a safety analytics deployment, cover:

• Sites, camera count and locations, with a site plan showing fields of view. Exclude rest areas, toilets, changing rooms and prayer rooms.
• What the model detects, listed by detection type (for example: pedestrian in forklift aisle, missing high-visibility vest, blocked fire exit).
• Whether the system identifies individuals. State whether it uses face recognition, re-identification across cameras, badge or tag matching, or none of these.
• Where inference runs (on site, in the cloud or both) and where clips and metadata are stored, including country.
• Who receives alerts and dashboards, and who can view raw footage.
• Retention for continuous footage, event clips, metadata and aggregated statistics.
• Recipients: the vendor, its sub-processors and any transfers outside the UK or EU.
• Whether footage is used to train or improve the vendor's models.

Section 3: Purpose and lawful basis

Write the safety purpose in concrete terms. "Improve safety" is too vague to test. "Reduce vehicle and pedestrian interactions in the dispatch yard, where we recorded a specific number of near misses last year" can be tested. Link the purpose to your own incident and near-miss data.

Name the lawful basis. Most employers rely on legitimate interests, sometimes alongside legal obligations under health and safety law. Avoid consent: the ICO says consent "is not usually appropriate in the employment context" because of the imbalance of power ^[4]. If you rely on legitimate interests, attach the balancing test.

If the system processes biometric data to identify people, you also need an Article 9 condition ^[1], and the case for it must be strong. The ICO's February 2024 action against Serco Leisure, which had used facial recognition and fingerprint scanning to record attendance for more than 2,000 employees at 38 leisure facilities, turned on the employer's failure to show necessity and to offer less intrusive alternatives such as ID cards or fobs ^[7].

Section 4: Necessity and proportionality

Article 35(7)(b) requires "an assessment of the necessity and proportionality of the processing operations in relation to the purposes" ^[1]. This is where weak DPIAs fail. Answer these questions in writing:

1. What controls already exist for the targeted hazards (segregation, barriers, speed limits, training, supervision)?
2. Why are they not enough? Use incident data, audit findings or near-miss trends.
3. What less intrusive options did you consider? Examples: engineering controls, proximity tags instead of video, fewer cameras, hazard-only detection with no person identification, privacy masking.
4. Why was each rejected or combined with the system?
5. How is collection limited to what the purpose needs (camera coverage, detection types enabled, retention)?

Keep the answer specific to each site. A system justified for a busy port yard may be disproportionate in a quiet office warehouse.

Section 5: Risks to workers

Article 35(7)(c) asks for an assessment of the risks to the rights and freedoms of data subjects ^[1]. Score each risk for likelihood and severity. Risks that come up in almost every safety analytics deployment:

Section 6: Measures to reduce risk

Article 35(7)(d) requires the measures envisaged to address the risks, including safeguards and security measures ^[1]. Map each measure to a risk from Section 5. Typical measures:

• Hazard-only detection with face blurring or masking by default; no face recognition.
• A written use policy that limits disciplinary use, for example to serious, deliberate violations, and requires human review of any alert before action.
• Short retention for continuous footage. The EDPB's video guidelines say personal data should in most cases be erased, ideally automatically, after a few days, and that "the longer the storage period set (especially when beyond 72 hours), the more argumentation" is needed ^[6]. Keep event clips for a defined, justified period.
• Role-based access, logging of who viewed what, and periodic access reviews.
• A processor agreement with the vendor that bars model training on your footage unless you agree, names sub-processors and sets breach notification terms.
• Signage and privacy notices before go-live. The ICO says employers "must" make sure workers know how and what information monitoring collects, and that covert monitoring is unlikely to be justified in most circumstances ^[4].
• Accuracy checks during the pilot, including false positive rates by area and shift.

Section 7: Consultation

Article 35(9) asks controllers, where appropriate, to seek the views of data subjects or their representatives ^[1]. The ICO goes further for workers: employers "should seek and document the views of your workers or their representatives (such as trade unions), unless there is a good reason not to" ^[4]. Record who you consulted, what they raised and how you responded. In countries with works councils, such as Germany, consultation often becomes formal negotiation, so start it early.

Section 8: Outcome and sign-off

Record the DPO's advice, whether you followed it and why, the residual risk level and the name of the person who accepted it. If high risk remains after mitigation, Article 36 requires prior consultation with the supervisory authority before processing starts ^[1]. The authority has up to eight weeks to give written advice, which it can extend by six weeks for complex processing ^[1]. Build that time into the project plan if you think you may need it.

Section 9: Review triggers

Article 35(11) requires a review at least when the risk represented by the processing changes ^[1]. For safety analytics, set explicit triggers:

• Adding cameras, sites or detection types
• Switching on any feature that identifies individuals
• Changing retention or storage location
• Changing how alerts feed into HR or discipline
• A data breach, a complaint or a works council objection
• A new vendor model version that changes what is detected

Add a calendar review as well, for example every year.

How does the DPIA connect to the EU AI Act?

The AI Act does not replace the DPIA. Where an AI system counts as high-risk, Article 26(9) says deployers shall use the information the provider supplies to carry out their GDPR DPIA ^[8]. Ask the vendor for its instructions for use and technical description now, so the same text supports both duties. Separately, Article 5(1)(f) of the AI Act prohibits AI systems that infer the emotions of people at work, except where intended for medical or safety reasons ^[9]. Record in the DPIA that no such features are enabled, or document the exception you rely on.

Common mistakes

• Writing the DPIA after the pilot. A pilot with real workers is processing and needs the DPIA first.
• Copying the vendor's template without site-specific necessity analysis.
• Describing the purpose as "safety" without naming hazards or using incident data.
• Leaving footage retention at the platform default.
• Allowing "temporary" access for HR investigations that is never written into the use policy.
• Treating sign-off as final. A DPIA for a system that keeps adding detection types goes out of date quickly.

Summary

For AI safety video at UK and EU sites, plan on a DPIA every time and finish it before any live processing, pilots included. Follow the GDPR Article 35(7) structure: describe the processing in detail, prove necessity with your own incident data, score the risks to workers, map a measure to each risk, consult workers, and record the DPO's advice and the residual risk. Keep retention short, rule out emotion inference and face recognition unless you have a documented case, and set clear triggers for review. A well-written DPIA also gives you most of the material needed for works council talks, vendor contracts and any future AI Act obligations.