Security Requirements for Gdpr Visitor Analytics

The moment a people counting project usually stalls is not the pilot. It is week six, when the vendor's security questionnaire lands on the desk of your DPO and the answers to questions 14 through 22 — sub-processors, encryption at rest, deletion procedures — come back vague or contradictory. Procurement has already negotiated the price. Store operations wants the data. And now the whole rollout waits while someone works out whether the sensor on the ceiling is quietly creating a personal-data processing operation nobody signed off.

That scenario is avoidable, but only if security requirements for GDPR visitor analytics are written into the procurement documents before the pilot, not reverse-engineered afterwards. This article sets out what those requirements actually are — at the sensor, in transit, in the platform, and in the contract — for teams who have already read the generic "is people counting GDPR compliant?" explainers and need something they can put into an RFP.

Start at the edge: what does the sensor actually capture?

The single most important security question in visitor analytics is whether personal data ever exists at all. GDPR obligations scale with risk, and the risk profile of a system that produces only anonymous aggregate counts is fundamentally different from one that stores video or biometric templates. Push vendors past marketing language ("privacy-first", "anonymised") to technical specifics:

• Where does anonymisation happen? On the device itself, before anything leaves the store, or on a server after raw imagery has been transmitted? Edge processing dramatically shrinks your attack surface and your Article 32 exposure.
• Is any image or video ever persisted? Some sensors buffer frames for accuracy tuning. If so, for how long, where, and who can access them?
• How does staff exclusion work? If it relies on facial recognition of employees, you have just introduced biometric special-category data and an entirely different legal basis. Exclusion via anonymous tags or zone logic avoids this. Vemco's approach — no personal identification at any stage, staff excluded without identifying them, only aggregate counts leaving the sensor — is the pattern your DPO should demand regardless of vendor.

A practitioner's note here: ask to inspect the sensor's diagnostic mode during the proof of concept. Several deployments have been derailed at audit because a technician-facing debug view could display live imagery, even though the production data flow was fully anonymous. If that view exists, it needs access controls, logging, and a mention in your records of processing — or it needs to be disabled at firmware level.

Network and transport requirements IT should impose

Counting sensors are IoT devices on your store network, and security teams should treat them exactly as they treat any other networked hardware. Minimum requirements worth writing into the contract:

• TLS for all sensor-to-platform traffic, with certificate management the vendor can actually describe, including rotation and revocation.
• Outbound-only connections from the sensor. If the vendor needs inbound access for maintenance, that is a VPN and change-management conversation, not a default open port.
• VLAN segmentation guidance. A serious vendor will tell you which ports and destinations the sensor needs and nothing more, so you can isolate the devices from POS and back-office systems.
• Signed firmware and a documented patching cadence. Ask when the last critical patch shipped and how it was distributed to devices in the field. The answer tells you more than any certification logo.

Platform, hosting and residency: the questions that decide the deal

Even fully anonymous count data has security requirements, because the analytics platform still holds commercially sensitive footfall figures, user accounts, and integration credentials. For enterprise buyers, three areas typically decide whether legal signs off:

• Hosting model. Can the vendor offer both a hosted platform and a private-cloud deployment inside your own environment? For retailers in regulated sectors, or those with strict data-residency policies, private cloud is often the difference between a six-week and a six-month approval. Vemco supports both, and integrates with existing IT systems rather than requiring a parallel stack — which matters because every parallel stack is another set of credentials, backups and audit scopes.
• Data residency and retention. Where is the data physically stored, which sub-processors touch it, and what are the retention and deletion defaults? Get these answered in writing, in the DPA, with named regions — and verify certifications such as ISO 27001 or SOC 2 by requesting the actual report or certificate rather than accepting a claim on a slide.
• Identity and access. Confirm what the platform supports for authentication — SSO integration, role-based access, per-store permissions — and how vendor support staff access your tenant. Ask whether support access is logged and time-limited.

Compliance paperwork that actually protects you

If the system genuinely never processes personal data, some GDPR artefacts become lighter — but not optional. A short DPIA documenting why the data is anonymous (edge processing, no identifiers, aggregation) is your best defence in a supervisory-authority enquiry or a customer complaint. You will also want the vendor's cooperation clause for audits, a breach-notification commitment with a defined timeline, and clarity on what happens to configuration data and historical counts at contract exit. Compliance officers should insist the anonymisation claim is stated as a contractual warranty, not a marketing description; that shifts risk where it belongs.

Security and accuracy are the same procurement question

One trade-off buyers should understand: the most privacy-protective architectures — full edge anonymisation, no image retention — remove the vendor's ability to "check the tape" when counts look wrong. That makes contractual accuracy commitments more important, not less. Vemco commits to a 96% contractual minimum, with 98–99% typically achieved when lighting, store layout and visitor behaviour allow. A vendor who guarantees a flat 99% while also claiming zero image retention is telling you one of those two claims is soft. Put both figures — the guaranteed floor and the typical range — in the contract, alongside the security schedule, and you have a document that satisfies procurement, IT and compliance in one pass.

The teams that move fastest are the ones who hand the vendor a single combined requirements list — sensor behaviour, network rules, hosting model, DPA terms, accuracy floor — before the pilot begins. Everything above fits on two pages. Write it once, and every future analytics procurement gets easier.

If you are preparing a security review or RFP for GDPR visitor analytics and want direct answers on hosting options, anonymisation architecture, staff exclusion and contractual accuracy terms, talk to the Vemco Group team — bring your security questionnaire, and we will complete it with you.