Privacy and sensitive data
Video, access and alarm records can contain sensitive information. Limit collection and access to the workflow's needs, and obtain the required privacy and governance review.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Research and static guidance only; product and deployment specific behaviour requires controlled environment validation and authoritative product evidence.
On this page
Overview#
Physical security data can reveal identity, movement, associations, schedules, facility layout, access rights, behaviour, health related inferences, and response capability. Global technical guidance can't determine whether collection or use is lawful in a particular jurisdiction; obtain local legal and governance review.
Data classes#
| Class | Examples | Special risk |
|---|---|---|
| Media | Live/recorded video, audio, intercom calls | Captures bystanders and sensitive spaces; secondary use is easy |
| Biometric | Face, fingerprint, iris, voice template and quality data | Difficult to replace; matching and demographic performance concerns |
| Credential | Card/mobile identifiers, keys, access rights, revocation state | Enables tracking, impersonation or access policy inference |
| Location and behaviour | ANPR/LPR, UWB/BLE position, occupancy, access history | Creates detailed movement and association records |
| Identity | Names, photos, directory identifiers, visitor records | Links system events to people and organizations |
| Security telemetry | Alarms, camera health, blind spots, topology, response | Can expose facility weaknesses and operational patterns |
Data flow questions#
For every field ask: why is it needed, who is the subject, where is it collected, which systems receive it, which identifiers join it, how long is it retained, who can query/export it, which vendors/subprocessors handle it, what leaves the site/region, how is deletion propagated, and what happens if the purpose ends.
Engineering controls#
- Collect the least resolution, duration, area, audio, biometric feature set, and metadata required for the declared purpose.
- Apply privacy masks and exclusion zones at the earliest reliable stage, while documenting whether raw data exists upstream.
- Separate operational viewing, investigation, export, analytics training, administration and bulk search permissions.
- Default APIs to narrow time/site/object ranges; rate limit bulk enumeration and export.
- Encrypt data in transit and at rest with separately managed keys and auditable access.
- Redact logs and support bundles; use synthetic data in documentation and development.
- Make retention and deletion explicit across edge storage, VMS, cloud replicas, caches, analytics stores, backups and exports.
- Record model/version and evaluation limits for biometric or analytic decisions; keep human review where consequences warrant it.
- Design for subject correction, revocation, deletion and account closure without corrupting audit integrity.
Developer anti patterns#
- using a stable card number as a cross system analytics identifier without necessity;
- placing faces, plate numbers or raw credential values in broker topic names or URLs;
- returning unrestricted historical search results to a broad operator role;
- retaining debug media or full API bodies indefinitely;
- silently repurposing security footage to train analytics;
- claiming anonymization while stable device, location and time fields permit re identification.
Sources#
- NIST PRIVACY, NIST Privacy Framework 1.0, risk management framework, accessed 25 August 2026.
- NIST FACE, NIST Face Technology Evaluation, official evaluation programme and reports, accessed 25 August 2026.
- OECD PRIVACY, OECD Privacy Guidelines, globally recognized principles, accessed 25 August 2026.