DPIA for people counting: a starter template you can adapt with your DPO

What this template is, and what it is not

A Data Protection Impact Assessment (DPIA) is the document a controller writes before deploying a technology that could affect the rights and freedoms of individuals. Under the GDPR it is required when processing is likely to result in a high risk. People counting is rarely high risk in itself, but a careful DPIA is still the cleanest way to show a board, a landlord, or a supervisory authority that you have thought the deployment through. People counting in a retail store, a shopping centre, an airport, or a museum touches several easy mistakes: the wrong sensor choice can introduce cameras, biometric processing, or identifiers that were never needed. A DPIA is the place to catch that on paper before any hardware ships.

This article is informational and is not legal advice. Use it as a starter you can adapt with your Data Protection Officer and legal counsel for sign-off. Regulatory expectations vary by jurisdiction and by the specifics of your deployment.

The template that follows walks the assessment line by line for a typical camera-free people-counting deployment. Each section explains what supervisory authorities and EDPB guidance generally expect, then gives the actual wording you can lift, adapt, and put in front of your DPO. The closing section is a copy-and-paste version of the same template you can drop into your own document.

When a DPIA is required, and when a simpler record will do

Article 35 of the GDPR requires a DPIA when processing is likely to result in a high risk to the rights and freedoms of natural persons. The European Data Protection Board (EDPB) has published criteria for identifying high-risk processing, and national supervisory authorities (for example the ICO in the UK, the CNIL in France, the BfDI in Germany) publish their own lists of operations that always need a DPIA. The common high-risk markers include systematic monitoring of a publicly accessible area, processing of biometric data, large-scale processing, evaluation of natural persons, and use of innovative technologies.

A camera-free people counter that captures no images, no faces, and no device identifiers by default does not, on its own, sit inside the strictest high-risk categories. Even so, two practical reasons make a DPIA worth writing:

• Evidence of accountability. Article 5(2) requires the controller to demonstrate compliance. A DPIA, even where not strictly mandatory, is the cleanest piece of evidence to produce when asked.
• Internal sign-off. Many boards, landlords, and procurement teams will not approve a new sensor without one. Producing a short, well-reasoned DPIA up front avoids weeks of back-and-forth later.

If after working through this template your DPO agrees the residual risk is low and the processing is outside the high-risk categories, you can keep the document as a record of processing under Article 30 instead of a full DPIA. Either way, the structure below is the same.

Section 1: Context of processing

The first section of a DPIA describes what you are actually doing, in plain language, before any legal analysis begins. This is where most people-counting deployments either pass the privacy test cleanly or expose the wrong choice of sensor.

Suggested wording:

The controller [name of organisation] operates [retail stores / shopping centre / airport terminal / museum] at [list of sites]. To support capacity management, exhibition or store performance reporting, and operational planning, the controller deploys a people-counting system at entrances, exits, and selected zones. The system measures how many visitors enter and leave each zone, how many are present at any moment, and how long, on average, they remain. The system produces aggregate counts only. It does not identify individual visitors and is not used to make decisions about any individual.

How the measurement actually works:

Ariadne measures this with Hybrid Fusion, its patented camera-free method. Time-of-Flight depth sensing counts every visitor at the entrances, capturing geometry rather than images, while patented phone signal sensing follows movement through the interior, detecting the signals a phone emits even in airplane mode. The sensor streams both feeds to Ariadne, where Hybrid Fusion combines them into one trajectory per visit and computes counts, dwell, and paths. The streams carry no identifier: no MAC address, no device ID, no biometric data, and no camera is involved. Identifiers are stored only when a visitor explicitly opts in, which keeps the method GDPR-friendly and outside biometric territory.

List, by site, the sensors deployed, their locations, and the zones they cover. State explicitly whether any other sensing technology (CCTV, facial recognition, Wi-Fi MAC capture, Bluetooth identifiers, demographic inference) is part of the same deployment. For the configuration this template assumes, the answer to all of those is no.

Section 2: Data being processed

Listing the data categories is where most DPIAs fail or succeed. A camera-based system has to declare image data, which is personal data the moment a face is identifiable. A signal-pattern system that stores MAC addresses has to declare device identifiers, which are personal data when they can be linked to an individual. The template below assumes the configuration where neither is captured.

Suggested wording:

• Aggregate counts. Number of entries, exits, and current occupancy per zone, computed centrally from sensor streams. Not personal data.
• Trajectory geometry. A path through the building expressed as anonymous coordinates, with no identifier attached. Not personal data in isolation.
• Dwell time. The average and distribution of time visitors spend in each zone, derived from the aggregated trajectories. Not personal data.
• No images. The Time-of-Flight sensing captures geometry, not pictures, and no camera is involved in the measurement path.
• No biometric data. No face, no fingerprint, no iris, no voiceprint, no gait inference, no demographic detection (no age, gender, or emotion estimation).
• No device identifiers by default. No MAC address, no IMEI, no advertising ID, no Bluetooth address is stored. Identifiers are only ever stored when a visitor explicitly opts in (for example by accepting a guest Wi-Fi terms-of-service), which is a feature the controller may choose not to enable at all.

If your specific deployment differs from this list (for example, you do operate guest Wi-Fi and intend to join opt-in MAC addresses with the counting data), state that here and note that this introduces personal data processing that must be assessed separately.

Section 3: Lawfulness of processing (Article 6)

If the processing does not handle personal data, Article 6 does not formally apply, because there is no personal data to find a legal basis for. The DPIA should still record the controller's reasoning here, partly because it forces the question to be answered explicitly, and partly because internal stakeholders will ask.

Suggested wording:

The processing described above does not involve personal data within the meaning of Article 4(1) GDPR. Counts, trajectories without identifiers, and aggregate dwell statistics, taken together, do not allow the identification of any natural person. Article 6 lawfulness therefore does not need to be relied on for the counting activity itself.

Where, in any future configuration, the controller chooses to enable opt-in identifier capture (for example a guest Wi-Fi login), the lawful basis will be the data subject's consent under Article 6(1)(a), captured at the point of opt-in and recorded as required. No other lawful basis is relied on for the counting deployment.

Some controllers prefer to record legitimate interest under Article 6(1)(f) as a defensive position, on the view that even non-personal data should have a stated basis. This is a reasonable approach and should be discussed with your DPO. The legitimate interest, where stated, is the controller's interest in safe operation, accurate capacity management, and informed commercial planning. The processing is necessary because no equivalent measurement is available without sensors. The interest is not overridden by the rights of data subjects because no personal data is processed in the first place.

Section 4: Necessity and proportionality

Articles 5(1)(b) and 5(1)(c) require processing to be limited to specified, explicit purposes (purpose limitation) and to what is necessary in relation to those purposes (data minimisation). A people-counting DPIA should address each in turn.

Specified purposes:

• Maintaining safe occupancy within the legally and operationally agreed capacity of each zone.
• Reporting attendance and dwell time for operational, commercial, or curatorial review.
• Informing staff scheduling, opening hours, and resource planning.
• Supporting funder, landlord, or board reporting obligations where applicable.

Why these purposes cannot be achieved with less data:

Manual counting (clickers, tally sheets, periodic walkthroughs) does not scale to a multi-zone building and produces estimates rather than continuous figures. A continuous sensor-based count is the minimum that supports live capacity management. Within sensor options, a method that captures no images and no identifiers (this deployment) is strictly less intrusive than the alternatives of CCTV-based analytics or device-identifier tracking. Data minimisation is therefore satisfied by sensor choice, not just by retention policy.

Proportionality:

The intrusiveness of the processing is at the lower end of available options, and the operational, safety, and commercial benefits are concrete. The controller's view is that the processing is proportionate to its purposes. The DPO should record their own view here in writing.

Section 5: Risks identified

Even a low-risk processing activity carries some risks worth recording. The point of this section is not to inflate risks, but to show that they were considered. For a camera-free, identifier-free deployment, the meaningful risks are short.

1. Risk of scope creep. A future operator could attempt to enable identifier capture, integrate the counting system with CCTV, or use the data to evaluate individual visitors. Likelihood: low if governance is in place. Severity: moderate, because it would change the data category being processed.
2. Risk of misperception. Visitors and staff may assume any sensor in the ceiling is a camera and feel watched, even though no camera is present. Likelihood: moderate. Severity: low to the individual, moderate to the controller's reputation.
3. Risk of vendor or sub-processor failure. If the vendor's platform is breached, the data exposed is the controller's count and trajectory data. With no identifiers, no images, and no biometric data in the path, the harm to data subjects from such a breach is structurally limited. Likelihood: low. Severity: low for data subjects, moderate for the controller's operational data.
4. Risk of jurisdictional change. Processing locations and sub-processor arrangements may change over time. Likelihood: low in the short term. Severity: depends on configuration; addressed by the Article 28 processor agreement and data residency commitments below.
5. Risk to vulnerable groups. Children, people with disabilities, and other groups may pass through the monitored zones. Because no identification or evaluation of any individual takes place, no specific additional risk to these groups arises from the counting activity itself. This should still be recorded.

Section 6: Mitigations

Each identified risk should be answered with a concrete mitigation. The DPO will want to see that the mitigations are operational and not just words.

• Sensor choice. Cameras are not used. Time-of-Flight depth sensing captures geometry, not images. Phone signal sensing captures no MAC address by default. This is the structural mitigation that makes most other mitigations easier.
• Configuration lock-down. Opt-in identifier capture, where available, is disabled by default and only enabled through a documented change request approved by the DPO. The DPO record should reflect the current configuration at each site.
• Signage and transparency. Visible signage at entrances should explain in plain language that the building uses anonymous counting, that no cameras and no faces are involved, and that no identifiers are stored. The privacy notice should link to the controller's full statement and to the vendor's privacy policy.
• Staff briefing. Staff who answer visitor questions should know what the sensors do and what they do not do. A one-page brief, refreshed annually, is usually enough.
• Processor agreement (Article 28). Even where the processing does not handle personal data, the controller-processor agreement should still be in place because configuration changes could in future bring personal data into scope. The agreement should specify data residency, sub-processors, security measures, audit rights, and breach notification timelines.
• Data residency. Where the controller is established in the EU or the UK, processing should take place on EU or UK infrastructure. Cross-border transfers, if any, should rely on the appropriate transfer mechanism under Chapter V of the GDPR.
• Retention. Aggregate counts and trajectories without identifiers can be retained for the period the controller needs for reporting and operational analysis. Set the retention period explicitly here (for example, 24 months for granular trajectory data, longer for daily aggregates). State who is responsible for enforcing the policy.
• Access control. Access to the dashboard and exports is limited to named users with documented roles. Access reviews happen on the controller's existing schedule.
• Incident response. Where a security incident affecting the counting platform is identified, the vendor will notify the controller within the agreed window, and the controller will assess whether any notification obligation is triggered. Given the data categories involved, this is unlikely.

Section 7: Residual risk

After the mitigations above, the residual risk to the rights and freedoms of natural persons from the counting activity itself is structurally low. The most useful way to express this in the document is to be precise about why, rather than rely on a single colour-coded label.

Suggested wording:

The residual risk to data subjects from the counting activity is assessed as low. The structural reasons are that the system processes no images, no biometric data, and no device identifiers by default, and the visitor cannot be identified from the aggregate counts, trajectory geometry, or dwell statistics produced. Operational risks (vendor failure, configuration drift, misperception) are addressed by the mitigations in Section 6. The DPO has reviewed and accepted the residual risk.

If, after working through Section 5 honestly, your residual risk is not low (for example, because you do plan to enable opt-in identifier capture, or because your sites operate at unusually large scale), the DPIA should not be treated as a tick-box exercise. Re-open Sections 1 through 4 and either change the configuration to remove the risk or document additional mitigations until your DPO is satisfied.

Section 8: Consultation

Article 35(9) suggests that controllers seek the views of data subjects or their representatives where appropriate. For a public-facing building, that usually means a short consultation with works councils or staff representatives, and consideration of feedback received through standard visitor channels (website, customer services, signage feedback).

Where the controller and the DPO together conclude that no consultation is appropriate, record the reasoning. Article 36(1) consultation with the supervisory authority is only required where the residual risk after mitigations remains high. The configuration this template describes does not, in the controller's assessment, reach that threshold.

Section 9: Sign-off and review cadence

A DPIA is a living document. The closing section names who has signed it off, when, and when it will be reviewed.

• Controller sign-off. Name, role, date. Typically the controller's senior responsible officer for the deployment.
• DPO opinion. Name, date, and a one-paragraph written view from the DPO. Article 39(1)(c) requires the DPO to provide advice on a DPIA where requested.
• Review trigger events. Changes that should trigger a fresh review: any sensor type change, any new site, enabling opt-in identifier capture, any change of processor, any change of sub-processor or data residency, any incident affecting the platform.
• Scheduled review. In the absence of a trigger event, a scheduled review every 12 to 24 months is usual practice. State the cadence here.

Copy-and-paste starter template

The block that follows is a compact version of the template above, suitable for pasting into your own document and adapting with your DPO. Replace bracketed items with your details, and remove any sections that do not apply to your configuration. As above, this is informational and not legal advice.

DPIA: people-counting deployment

1. Controller and DPO

• Controller: [organisation]
• Sites in scope: [list]
• DPO: [name, contact]
• Date of assessment: [date]

2. Context of processing

The controller deploys a people-counting system at [sites] to support capacity management, attendance reporting, and operational planning. The system reports entries, occupancy, and dwell time per zone. It does not identify individual visitors. The sensing method is Time-of-Flight depth at entrances plus patented phone signal sensing in the interior, fused centrally in the vendor platform. No cameras, no facial recognition, no MAC capture by default, no biometric data, no demographic inference.

3. Data being processed

• Aggregate counts per zone.
• Trajectory geometry, no identifier attached.
• Dwell time per zone, aggregated.
• No images. No biometric data. No device identifiers by default.

4. Lawful basis (Article 6)

The processing described does not involve personal data; Article 6 is not formally engaged. Where opt-in identifier capture is later enabled, the lawful basis will be consent under Article 6(1)(a).

5. Necessity and proportionality

Purposes: safe occupancy, attendance reporting, operational planning, sponsor or funder reporting. No less intrusive method delivers continuous, per-zone figures. The chosen method does not capture images or identifiers, which is the minimum intrusion among available sensor options.

6. Risks identified

• Scope creep into identifier capture or CCTV integration.
• Visitor misperception that sensors are cameras.
• Vendor or sub-processor security incident.
• Jurisdictional change in processing location.
• Effect on vulnerable groups (no specific additional risk identified).

7. Mitigations

• Camera-free sensors; no MAC capture by default.
• Configuration changes only via documented, DPO-approved process.
• Signage and privacy notice at entrances; staff briefing.
• Article 28 processor agreement, EU or UK data residency, sub-processor list.
• Retention policy: [period for trajectory data], [period for aggregates].
• Access control, named users, periodic review.
• Incident notification within [agreed window].

8. Residual risk

Assessed as low. The system processes no images, no biometric data, and no device identifiers by default; the visitor cannot be identified from the data produced. DPO has reviewed and accepted the residual risk.

9. Consultation

Internal consultation: [staff representatives, works council, as applicable]. Article 36(1) prior consultation with the supervisory authority is not required at this residual risk level.

10. Sign-off and review

• Controller sign-off: [name, role, date].
• DPO opinion: [name, date, one-paragraph view].
• Review triggers: sensor or site change, opt-in capture enabled, processor or sub-processor change, residency change, security incident.
• Scheduled review: every [12 to 24] months.

How Ariadne fits this template

Most DPIAs become difficult at Section 2 (data being processed) and Section 5 (risks identified), because the underlying sensor choice forces the controller to declare image data, biometric data, or device identifiers. The Ariadne deployment this template assumes is set up to make those declarations short.

No. Ariadne counts with Hybrid Fusion: Time-of-Flight depth sensing plus patented phone signal sensing, never cameras. Time-of-Flight captures geometry rather than images, and signal sensing captures no MAC address by default, so the measurement involves no video, no faces, and no biometric data.

Concretely: there are no cameras in the measurement path, so Section 2 does not have to declare image data. No face, gait, or demographic inference is performed, so biometric data is not in scope. No MAC address, IMEI, or advertising ID is captured by default, so device identifiers are not in scope. The fusion runs centrally in the Ariadne platform, so the controller can require EU or UK data residency in the Article 28 agreement and document it in Section 6. None of this removes the obligation to write the DPIA, but it makes most of the heavy sections trivial to answer honestly. The remainder is governance: configuration lock-down, signage, staff briefing, retention, access control, and review cadence.

If you would like a vendor-side view to attach to your DPIA, the processing detail is set out in the Ariadne privacy policy, and the solution overview sits on the people counting page.

FAQ

Is a DPIA always required for a people counter?

Not always. Article 35 requires a DPIA where processing is likely to result in a high risk. A camera-free, identifier-free people counter does not, on its own, sit inside the strictest high-risk categories that supervisory authorities publish. Even where a DPIA is not strictly required, writing one is the cleanest way to evidence accountability under Article 5(2) and to satisfy boards, landlords, and procurement teams. Speak to your DPO about whether a full DPIA or a lighter Article 30 record is the right artefact for your case.

Does the deployment process personal data at all?

In the configuration this template describes, no. Aggregate counts, trajectory geometry without identifiers, and aggregate dwell time do not, taken together, allow the identification of any natural person. If you choose to enable opt-in identifier capture (for example a guest Wi-Fi login), that introduces personal data processing that must be assessed separately in its own section of the DPIA.

Do we need to consult the supervisory authority?

Prior consultation under Article 36(1) is required only where the DPIA shows that the processing would, in the absence of safeguards, result in a high risk. The configuration this template describes does not, in the controller's assessment, reach that threshold. Your DPO will form their own view and should record it in writing.

How often should the DPIA be reviewed?

Trigger-based and scheduled. Trigger events include changes to sensor type, new sites, enabling opt-in identifier capture, changes of processor or sub-processor, changes of data residency, and security incidents affecting the platform. In the absence of a trigger event, a scheduled review every 12 to 24 months is usual practice. Record the cadence in the closing section so the next reviewer knows what was agreed.

Is this article legal advice?

No. This article is informational only. Use it as a starting point for a conversation with your Data Protection Officer and your legal counsel, who will adapt the wording to your jurisdiction, your specific configuration, and your organisation's existing privacy framework.