Privacy is an architecture decision - and it is made before the questionnaire arrives

At some point in every procurement process, the questionnaire arrives. Usually late, usually from somebody who has not been in the project so far, and almost always with the same first line: are personal data processed?

Answer that with a policy and you have already lost. A policy describes what somebody is supposed to do. A data protection officer is asking something else: what happens when nobody follows it?

This article answers exactly that - not with an assurance, but with the path a data point takes. It builds on People counting: technologies compared, which already made the point that the choice of method largely decides the privacy question.

Why the question always comes late

A counting installation is initiated by operations, facility management or marketing. The privacy review sits with a different role, and that role gets involved once a quote is on the table - which is to say, at the end.

That is not negligence, it is the sequence in most organisations. It has one uncomfortable consequence: whatever surfaces at that point surfaces after the technology has been chosen. And some of those decisions can no longer be corrected, because they sit in the method rather than in a setting.

Anyone who knows the questions in advance can put them into the tender instead of answering them at the end. That is what this article is for.

Anonymous and pseudonymous are not the same thing

This is the distinction every review turns on, and the market blurs it routinely.

Anonymous means the link to a person is absent and cannot be re-established even with additional knowledge. A figure such as “between 14:03 and 14:04, eleven people entered” is anonymous. There is no row corresponding to a person - there is only a counter.

Pseudonymous means the link has been replaced but the row still exists. Whoever holds the key can trace it back. An identifier that persists across days is pseudonymous - and therefore, legally, personal data, even with no name attached to it.

Between the two there is no grey area; there is the entire review. And it starts not with an assurance but with the question of whether an identifier survives a session.

What leaves the sensor

A 3D sensor processes its image inside the device. What goes out is not a picture but text: event type, position, identifier, a few derived attributes.

The last row is where the methods diverge. Counting via Wi-Fi or Bluetooth signals has to read a device identifier, otherwise it counts nothing. A camera with facial recognition has to form a biometric template. For both, the link to a person is not a setting but the mechanism.

That has a consequence you rarely find in a product description: with those methods the privacy question is not solved by operating them carefully. It is the question of whether they may be operated at all - and that question reopens at every site, at every change of purpose and at every change of operator.

With a count that produces whole numbers, it is asked once and answered.

The record that feeds every dashboard

Here is the actual core, and it is unspectacular: one document per site and minute, every field a whole number.

Visitors, objects, age bands - all counters. No name, no face, no biometric template, no device identifier. Not because those fields are left empty, but because they do not exist in the structure.

A person cannot be represented in a record like that. Not hard to find, not protected, not encrypted - not representable. One row reads “this minute: 11 people, 2 prams”, and no person can be reconstructed from eleven.

That is the difference between a safeguard and a property. A safeguard can be switched off. A property cannot.

Three properties that hold even when nobody is watching

The processing happens inside the device

Image recognition runs on the sensor. Once an image has been through the processing chain, it is removed from volatile memory. There is no outbound path it could travel on - and therefore no transmission to secure and no store for anyone to purge.

Incidentally, this is also why the network load is so low: what travels is text, not a video stream.

The identifier does not outlive the observation

The identifier is created for a single observation. When the person leaves the field of view it disappears - and it is later reassigned, to somebody else.

From that follows something you do not have to promise, because it cannot be circumvented: recognition across days is excluded by construction. Not forbidden, not disabled, but not possible. The same person on Monday and on Tuesday carries two different identifiers, and the same identifier on both days can belong to two different people.

The aggregation sits in the write path, not in the report

This is the point that is easy to skim past, and it carries the most weight.

Counts are not stored as individual events and added up later. They are added into the minute counter as they are written - a single operation, no read followed by a write. So there is no state in which a per-person event row sits in the main store waiting to be aggregated.

The difference is not theoretical. A system that collects first and condenses later always has a window in which the raw material exists. Whoever gains access during that window gains access to individual records. With the condensing in the write path, the count store has no such window.

Four checks before a single number is written

“The sensor sends, the platform stores” is the description you get everywhere. What happens in between is the interesting part - and half the answers to a security questionnaire live there.

1. The transfer. The sensor sends to an address belonging to that site, over HTTPS only and write-only. Plus a rate limit per address and source - a device that suddenly sends a hundred times as much fills no database, it hits a limit.
2. The authentication. The key that comes with the push is checked against that site's key, and checked in constant time. That is not a detail: an ordinary character comparison stops at the first difference, and the length of the response lets the key be guessed one character at a time. A constant-time comparison always takes equally long.
3. The duplicate claim. Tenant, site, serial number and frame number form a key that is claimed exactly once. If the same push arrives a second time - after a network outage, say - it is acknowledged as a duplicate rather than counted again.
4. The atomic increment. Only then is anything counted, and in a single write. No read, calculate, write back - the class of fault in which two simultaneous pushes overwrite each other never arises.

The third and fourth points are why the figures survive a network outage. A sensor catching up often catches up twice. A system without a duplicate claim then counts that minute twice - and nobody notices, because the result looks plausible.

Retention is automatic, not an intention

“We delete regularly” is not a statement. The question is what happens when nobody does.

This is enforced through expiry set on the data itself plus a daily run - not through a task in somebody's calendar. A store whose deletion depends on a person is eventually a store without deletion.

Two of the numbers are deliberate. The 730 days on the minute counter, because a real year-on-year comparison needs two full years - one is enough to compare, not to interpret. And the seven days on the raw intake, because that is how long it takes for a fault to surface and be resolved. After that the store has no purpose, and what has no purpose is not kept.

What comes from outside: seals and statute

What a certification says - and what it does not

The privacy section of a tender almost always contains seals. They are useful and they are overrated, so here is where they fit.

An ePrivacy seal, as Xovis holds for its PC sensor range, is a third-party certification of data protection, not a self-declaration - somebody external has checked. An IEC 62443-4-2 Level 2 concerns something else: industrial cybersecurity at component level, the device as a network participant. According to Xovis, most suppliers in people counting cannot show a 62443 component level at all.

Then there is what has to hold at device level anyway: TLS 1.2 and 1.3 only, a trust store against man-in-the-middle, signed software, the cryptographic key fixed on the chip, SSH and serial console disabled.

What a seal does not say: how the platform behind it handles the data. It certifies the device, not the analysis. Anyone who wants both has to ask for both - and that is the question most datasheets are silent on.

The legal frame, briefly and without advice

Switzerland applies the revised Data Protection Act, the EU applies the GDPR. Both attach to the same point: data relating to an identified or identifiable person.

That is exactly where the architecture lands. Where no per-person row arises in the main store, the chain of obligations does not arise from it either - not because it has been satisfied, but because its point of attachment is missing.

Two practical consequences turn up in projects regularly. In an organisation with employees, consulting the employee representatives is the real bottleneck rather than the supervisory authority - and the question there is almost never “is this permitted” but “could somebody watch individual staff with it”. At a minute counter the answer is short. And in a tenancy or an operator model, it has to be settled who is responsible for the data: that is a contractual question, and it is easier to settle once it is established that what is at stake are counts.

Three questions come up in almost every review, and at a counting installation they are quickly answered:

• Which purpose? Footfall, occupancy, routing, staff planning - and the purpose sits in the configuration, not in a declaration of intent.
• Which legal basis? Without a link to a person in the store, the question is shorter than the template makes it look.
• Which data subject rights? Access, rectification and erasure presuppose that a row can be assigned to a person. At a minute counter that assignment does not exist - and that is the answer, not the excuse.

None of this replaces a legal review. It makes it short.

What belongs in the tender

Seven questions that make the difference between an assurance and an architecture visible:

1. Does an image ever leave the device - and if not, where does image processing technically end?
2. How long does an identifier hold? Does it survive the field of view, the day, the installation?
3. Is aggregation done on write or only on evaluation? Is there a window in which individual records exist?
4. Which stores are there, and which of them carries an identifier? The answer should be a table, not a sentence.
5. How is deletion done - through an expiry on the data, or through a task somebody performs?
6. Which certification does the device carry, and exactly which range does it apply to? A seal for one range says nothing about another.
7. What does the datasheet say about optional functions, and how are they configured as delivered?

How we do it

The ANALYSIT Counting System accepts nothing from the sensor but count records and writes them as an atomic increment into the minute counter. The store that feeds every analysis consists of whole numbers per site and minute - no per-person row, no coordinate, no identifier.

Image processing stays in the sensor. No image, no facial feature and no device identifier ever leaves it. The identifier a sensor uses to hold one observation together applies to that observation and is reassigned afterwards.

Retention runs on expiry set on the data plus a daily pass: counts 730 days, behavioural aggregates 365 days, raw intake seven days. Every site has its own access key, rotatable at the press of a button, and every transfer runs over HTTPS with a constant-time key comparison.

If a security questionnaire is coming your way and you would rather know the answers in advance, talk to us. We will go through the points above before somebody else asks them.