GDPR procurement checklist for smart glasses in warehouses

Time needed about three days, spread over two weeks

The steps

1. Define the use case and DPIA scopeWrite a one-page use-case that lists where glasses will be used, what personal data may be seen or captured and the business outcome; use that to scope the DPIA.You should see: A one-page use-case document and a DPIA scope statement that names pick-and-pack, camera and speech capture as included.
2. Issue an RFP with mandatory artefactsSend an RFP that requires a completed DPIA, a draft DPA listing subprocessors, data-flow diagrams, pen-test reports and a commitment to supply test units.You should see: Vendor proposals arrive with the required documents attached and any missing item flagged as non-compliant.
3. Request and receive test unitsAsk vendors to supply at least one test unit per model you plan to evaluate, pre-provisioned to your test tenant if applicable.You should see: You have physical units in hand with admin credentials or test accounts and a vendor contact for support.
4. Run paperwork and static checksValidate DPIA, DPA and data-flow diagrams; inspect app permissions, confirm a physical shutter/LED and check that firmware images are signed.You should see: Artefacts match the use case and permission lists show camera and microphone tied to the app; firmware signatures and public keys are provided.
5. Perform network capture testsPlace a packet capture on the test VLAN, exercise features, map outbound endpoints to the vendor's list and confirm TLS certificate details.You should see: Capture shows outbound connections only to listed endpoints, TLS present and no raw frames leaving the device unless explicitly allowed.
6. Verify on-device processingDisable networking for the device and repeat the feature the vendor claims is on-device while observing behaviour and performance.You should see: Functionality the vendor claims runs locally continues to work with networking off, proving on-device processing.
7. Test retention and deletionCreate test records, request deletion via the vendor API or admin portal and verify the records are removed from device storage and cloud backups.You should see: Deletion requests return success and subsequent searches or direct storage checks show the test records absent.
8. Run user-acceptance privacy testsHave line operators use the devices in a simulated shift, confirm recording indicators work and test pause/kill functions and admin blocking.You should see: Workers can see the recording indicator, can pause capture where required and admins can remotely disable a device with confirmation.

Smart glasses GDPR procurement checklist — what to require

Require specific documents, test evidence and contract clauses before you approve any purchase. At minimum demand a DPIA, a Data Processing Agreement naming subprocessors, clear evidence of where processing runs, encryption in transit and at rest, retention and deletion controls, a breach-notification SLA and at least one test unit per model.

Embed those items as pass/fail acceptance criteria in your RFP. Treat vendor slides as advertising; require artefacts (DPIA, data-flow diagrams), runnable tests and an acceptance plan you can execute on supplied units.

Why EDPB guidance removes the wearer-consent fallback

EDPB guidance means wearer consent no longer absolves buyers of responsibility for camera-equipped devices in employer settings. The organisation must act like a controller: scope a DPIA for the workflow and lock down contractual obligations with any vendor that processes footage or extracts personal data.

Practically, that means you must carry out a DPIA for pick-and-pack workflows that include cameras or speech capture and put a DPA in place that names subprocessors and sets testable obligations for processing location and data handling.

Technical checks that prove vendor claims

Demand verifiable answers for where processing happens, what telemetry leaves the device and what controls admins and users have. Require each answer to be backed by an artefact or a hands-on test you can run on a supplied unit so the claim is demonstrable in your environment.

Phrase each requirement as a measurable acceptance criterion you can drop into the RFP and the pilot plan.

• Processing location: vendor states whether raw video/audio ever leave the device; provide a block diagram and runtime proof.
• On-device vs cloud: reproducible test showing features work with networking disabled and with networking enabled.
• Camera/mic controls: physical shutter or hardware LED plus an admin-enforceable software kill-switch.
• Telemetry endpoints: list of FQDNs/IPs, ports, protocols and TLS certificate details.
• Encryption: TLS for outbound connections and encryption-at-rest; vendor supplies cipher-suite and key-management description.
• Storage and retention: exact cloud regions or on-prem locations, retention APIs, automated deletion workflows and proof of deletion.
• Updates: signed firmware images, OTA signature scheme, rollout windows and firmware escrow for critical images.
• Telemetry volume and PII mapping: sample logs showing metadata fields and mapping to personal-data categories.
• Authentication and RBAC: SSO or MFA support, role definitions and admin audit logs retained per your policy.
• Pen testing: independent penetration-test report and an SLA for critical vulnerability remediation.

Vendor evidence to demand in your RFP

Insist on artefacts that prove process and intent, not sales slides. Make a completed DPIA, a draft DPA with named subprocessors and runnable evidence mandatory attachments to any proposal and mark missing items as disqualifying.

Require documents that let you validate vendor claims without relying on verbal assurances.

• Completed DPIA covering the exact use case and naming categories of data processed.
• Data Processing Agreement that lists subprocessors and includes GDPR instruction, data-return and deletion clauses.
• Detailed data-flow diagrams showing device → edge → cloud paths, including third-party analytics vendors.
• Independent penetration-test report and a vendor statement of remediation commitments for open findings.
• Certification evidence for claimed operational standards (ISO/IEC or equivalent) if invoked by the vendor.
• Breach-notification SLA committing to notify you and supply incident forensics within GDPR timelines.
• List of data-centre locations and contractual terms that prevent relocation without notice.
• Firmware-signing documentation and an escrow arrangement for critical firmware images or recovery tools.

Contractual clauses and KPIs to insist on

Turn obligations into measurable commitments. Include audit rights, breach timelines, remote-wipe, firmware-update SLAs and data-location KPIs that trigger remedies when missed. Put these into pass/fail or weighted evaluation items in your procurement.

Make remediation and evidence-sharing obligations explicit so you can enforce the DPIA and DPA in practice.

• Audit rights: on-site or remote audits with vendor support and log access within a specified timeframe.
• Breach notification: vendor must notify you and provide preliminary details within 72 hours of becoming aware and a full forensic report within an agreed window.
• Remote-wipe/disable: tested remote-disable and remote-wipe with observable confirmation codes.
• Firmware update SLA: apply critical patches to test units within an agreed window, provide signed changelogs and a rollback capability.
• Data location and portability KPI: keep data in agreed regions and supply exportable copies on request within an SLA.
• Subprocessor change control: advance notice of new subprocessors and a right to object for lawful reasons.
• Pen-test remediation KPI: defined time-to-remediate critical vulnerabilities and requirement to share remediation evidence.

How to evaluate claims in practice: staged pilot checklist

Run a short, staged pilot with at least one unit per model you plan to buy. The pilot proves artefacts and shows device behaviour in your network, under your policies and with your workers, so you can accept or reject on objective evidence.

Structure the pilot into paperwork review, static inspection, controlled network tests, user-acceptance privacy checks and final acceptance based on the criteria.

• Paperwork review: validate DPIA, DPA, data-flow diagrams and pen-test reports are present and complete.
• Static inspection: check app permissions, physical shutter/LED presence and that firmware images are signed.
• Network capture: run packet captures while exercising features; map outbound endpoints to the vendor's list and cloud regions.
• On-device test: disable networking and repeat features claimed to run locally; note degraded functionality if any.
• Telemetry inventory: collect device logs and map each field to personal-data categories.
• Retention/deletion test: create test records, request deletion via API or admin portal and verify removal from device and cloud.
• User privacy test: have line operators wear devices with test accounts, confirm recording indicators and pause/kill functions.
• Acceptance criteria: pass only if all required artefacts exist and all critical technical tests succeed.

How deployments fail in practice and the sequence that breaks compliance

A common failure sequence starts with a firmware update after go-live that enables extra telemetry or cloud features not reflected in the DPIA or DPA. Teams usually discover the change through a support ticket or unexpected endpoints in a capture, which collapses the compliance position.

Mitigate this by requiring vendor notice and a freeze period for firmware changes during the first production quarter, keeping firmware images in escrow and retaining audit rights.

Operational controls to run once devices arrive

Contracts and tests are necessary but not sufficient. You must operationalise minimisation, signage, role-based access and a process for data-subject requests. Regulators will inspect how you run devices day to day, not just what the contract says.

Assign responsibilities, document retention workflows and install clear pause or kill switches in areas where cameras operate.

• Employee privacy notice and visible signage in camera areas.
• Default minimisation: cameras off by default, capture only during authorised pick events, and auto-purge of non-essential footage.
• Role-based access: narrow admin rights, SSO integration and audit logging of access events.
• Retention and deletion: documented manual or automated deletion steps and logs proving deletion.
• Data subject requests: route requests to your DPO and use the vendor's API clauses to extract or delete subject data.

What to do next

Embed this checklist in your RFP, require test units and schedule a two-week pilot before any purchase order. Mark missing artefacts as disqualifying and require signed contractual commitments for firmware changes and breach notification before you accept a vendor.

Prepare your one-page use case, a test VLAN for packet captures and a short list of candidate devices so you can run the pilot and convert its findings into contract additions.

Where this usually goes wrong

• Packet captures show raw frames being uploaded despite vendor claiming on-device processingVendor misrepresentation or a hidden cloud fallback active in the tested firmwareReject the unit, demand remediation, require signed firmware images and re-run the capture test on a new unit.
• Firmware update after go-live enables telemetry not in the DPIANo contractual change control or firmware escrow; vendor updated behaviour unilaterallyEnforce contractual freeze/notice periods, require firmware escrow, add a rollback path and re-scope the DPIA.
• Vendor refuses to provide pen-test reports or names of subprocessorsVendor intends to hide third parties or has a weak security postureTreat as disqualifying; require named subprocessors and an independent pen-test report before procurement.
• Remote-wipe fails in a theft scenarioDevice lacks a reliable management channel or remote-wipe SLA is inadequateRequire a tested remote-wipe mechanism with confirmation and add it to the acceptance criteria for all devices.

The checklist

• Define the use case and DPIA scope
• Issue an RFP with mandatory artefacts
• Request and receive test units
• Run paperwork and static checks
• Perform network capture tests
• Verify on-device processing
• Test retention and deletion
• Run user-acceptance privacy tests

Frequently asked questions