DPIA template. For ReID-via-embeddings.

Outcome. A DPIA is mandatory for this processing. ReID-via-embeddings constitutes systematic monitoring of a publicly accessible area on a large scale, which triggers UK GDPR Art 35(3)(c) automatically. The ICO list of operations requiring a DPIA also names "use of new technologies", which applies to embedding-based ReID even where individual elements (CCTV, similarity search) are mature.

Screening questions answered yes:

• Systematic monitoring of a publicly accessible place on a large scale.
• Innovative technological solution (embedding-based ReID, distinct from facial recognition).
• Processing pseudonymous data that could re-identify individuals when combined with operator-held context.
• Processing in a context where data subjects (residents, visitors) have a reasonable expectation of safety but limited practical ability to opt out.

Because two or more screening questions return yes, a DPIA is required before processing begins.

Nature of the processing. Existing IP cameras on the operator's estate stream to a UK-resident edge node. The edge node runs person detection, extracts a 512-dimensional embedding vector from each detection, and forwards only the embedding (plus a content-addressable id and a timestamp) to the embedding store. Similarity search runs against the embedding store on operator query. No source frames are retained beyond the on-camera ring buffer (default 72 hours; configurable shorter).

What is and is not stored.

• Stored: 512-dim embedding vectors, content-addressable ids, timestamps, camera ids, event metadata, audit log entries.
• Not stored beyond on-camera ring buffer: source video frames, bounding-box pixel crops, raw RTSP streams.
• Not extracted into the embedding at all: identifying facial features (the model is trained on whole-body re-identification, not face recognition), biometric templates as defined by UK GDPR Art 9, or any data that on its own would constitute special-category personal data.

Scope. The processing covers the sites listed in the meta block above. PLACEHOLDER — confirm the estimated count of unique persons detected per day across the estate.

Context. The data subjects are residents, visitors and (incidentally) passers-by in publicly accessible parts of the estate. Residents are informed via the operator's privacy notice and via signage at every camera location. Visitors are informed via signage. There is no contractual relationship with passers-by; lawful basis for their incidental processing is Art 6(1)(f) legitimate interest, balanced in Step 4.

Purposes. The processing exists to enable safety-related operational decisions (incident review, missing-person response, repeat-offender detection across the estate). It is not used for marketing analytics, footfall research, or employee monitoring. Repurposing requires a fresh DPIA.

Data flows. Camera → edge node (UK) → embedding store (UK) → operator UI (UK). No data leaves the UK perimeter. The full topology is documented at /sovereignty.

Internal consultation. The DPO is consulted at every stage of this DPIA. The SIRO signs Step 7. The operations team and the procurement team are consulted on the operational realities of the processing.

Resident consultation. Residents are consulted in advance of deployment via the operator's standard channels (resident association, written notice, dedicated email or town-hall session — PLACEHOLDER — confirm channel). The consultation describes the system in plain English, the lawful basis, the retention windows, and the route to raise concerns. Resident feedback is recorded and material objections are addressed before processing begins.

Visitor consultation. Visitors are not consulted individually but are informed via signage at every camera location and via the operator's published privacy notice. The signage names the controller, the purpose, the retention period and the route to a data subject access request.

ICO consultation. Prior consultation with the ICO under UK GDPR Art 36 is not required for this processing on the residual risk profile recorded in Step 5 below. If the residual-risk band moves to high for any individual risk after Step 6 controls are applied, the DPO will trigger prior consultation before processing begins.

Other consultation. Where the site is covered by a joint controller agreement (e.g. a shared forecourt with a neighbouring building), that controller is consulted and the agreement is recorded in the operator's DPA pack.

Lawful basis. UK GDPR Art 6(1)(f) legitimate interest. The legitimate interest is the safety of residents, visitors and staff on the operator's estate. The balancing test below establishes that this interest is not overridden by the rights and freedoms of data subjects, given the controls in Step 6.

Balancing test.

• Purpose test. The interest is legitimate, real and present — incident response on the operator's estate is a routine and lawful activity.
• Necessity test. Less intrusive means (rotating human guards, perimeter signage alone) have been considered and rejected as insufficient at the estate scale. ReID-via-embeddings is the least intrusive means of achieving the purpose because no source images persist and no faces are extracted.
• Balancing test. The data subject's reasonable expectation is that they may be filmed in publicly accessible parts of the estate; the embedding-based approach is materially less intrusive than facial recognition (which is not used) or long-retention CCTV. Risks to the data subject are constrained by the Step 6 controls, particularly retention limits, encryption, audit logging and the human-in-the-loop requirement on consequential actions.

Special-category data. The system is designed to avoid processing special-category personal data under UK GDPR Art 9. Embeddings do not encode identifying facial features and are not biometric templates as defined by Art 4(14). If the operator's deployment context creates a foreseeable path to special-category data (e.g. cameras covering a place of worship or a medical facility), a separate Art 9 assessment is required before deployment.

International transfers. None. All processing is UK-resident. The full topology is documented at /sovereignty.

Residual risk. With the Step 6 controls in place, the residual risk profile is:

• R1 (embedding reverse-engineering) — residual low.
• R2 (model bias) — residual low / medium, monitored quarterly.
• R3 (data breach) — residual low.
• R4 (mission creep) — residual low given C8.
• R5 (disproportionate retention) — residual low.
• R6 (lack of transparency) — residual low if signage and notice are deployed; PLACEHOLDER — confirm.
• R7 (inaccurate match) — residual low given the C7 human-in-the-loop requirement.
• R8 (sub-processor breach) — residual low.

No residual risk is rated high; prior consultation with the ICO under UK GDPR Art 36 is not required.