A head start
on the DPIA.
Flying a thermal camera over a street is personal-data processing before it is anything else. This is the DPIA a Fire & Rescue Service's data-protection officer (DPO) would complete for drone overwatch — pre-reasoned for Drone-as-First-Responder. It is a head start for the service's own assessment, not a finished sign-off.
This is a starter, not legal advice, and not a completed DPIA for a live service. It shows how Warden reasons about data-protection risk and pre-fills the parts a deployment shares — but a real DPIA is authored and owned by the deploying service's DPO, consulted with stakeholders and, where high residual risk remains, with the Information Commissioner's Office (ICO). Use it as scaffolding, not a substitute.
01 Why a DPIA belongs here
Treat it as a precondition of the first flight, not paperwork after it.
Drone thermal overwatch is monitoring of a publicly accessible area with a novel technology. The UK General Data Protection Regulation (UK GDPR) Article 35(3)(c) requires a DPIA for systematic monitoring of a publicly accessible area on a large scale, and Article 35(1) requires one wherever processing is likely to result in a high risk. Whether this deployment meets that test is the DPO's call; the safe course is to complete it before processing begins, not after an incident.
The assessment is easier when the software is built with it in mind. Several of the risks a DPO would otherwise have to argue away are addressed in how Warden is designed; the sections below say which, and where the work is not finished.
02 The processing, described
A DPIA starts by saying plainly what is done, to whom, and why.
What Data & purpose
Live thermal imagery of an incident scene (which may include people) and flight telemetry. Purpose: fire & rescue scene assessment and life safety — overt, incident-linked, time-bounded.
Who Data subjects & recipients
People at or near the incident scene. Seen live by the incident commander under role-based access; no third-party sharing by default. Sign-in and record data are held on a hosted backend in Ireland (eu-west-1), not the UK. If casualty health information is processed, the service's DPO decides the Article 9 condition; vital interests, Art 9(2)(c), is one candidate.
03 Necessity & proportionality
The two questions a DPO must be able to answer yes to.
Necessary? Yes — and no gentler way
Thermal sensing and speed achieve the life-safety aim where slower ground methods cannot — locating people and hotspots before crews arrive. The processing is the means to a statutory fire & rescue function.
Proportionate? Yes — minimised by design
Overt; incident-only; live-only by default (no imagery stored); no facial recognition; bystanders minimised, not identified. The least-intrusive posture that still does the job.
04 The risk register
Every DPIA turns on the residual risks — what's left after the controls.
Low Bystander capture
Imagery may incidentally include people near the scene. Control: overt, incident-scoped, live-only; no identification performed.
Low Re-identification
Footage could in principle be matched to identities. Control: no facial-recognition or biometric model is integrated, and adding one would have to be a documented governance decision.
Med Function creep
Pressure to reuse the capability beyond fire & rescue. Control: governed console; any scope change is a documented governance decision, on the record.
Med Excessive retention
Any opt-in recording outliving its purpose. Control: a retention job designed to delete it on schedule and log the deletion in the ledger. That schedule is not yet switched on.
Low Unlawful disclosure
Imagery reaching the wrong hands. Control: role-based access and an access trail. The console connects to Warden's hosted backend for sign-in and the record, and that backend sits in Ireland (eu-west-1), not the UK: a data flow the DPO should record.
Med Record tampering
The audit trail being quietly altered. Control today: an append-only ledger, each entry chained to the one before with SHA-256, which needs no key, and signed with Ed25519 under a key whose fingerprint Warden publishes, so anyone holding an export can check it against that pinned fingerprint without Warden. Also in place: external time-stamping. A digest of the whole ledger, an anchor, is time-stamped by an outside authority (FreeTSA, RFC 3161); the first was made on 1 November 2026. Events up to the cutoff of the latest anchor whose token verifies and whose time-stamp is minutes after that cutoff cannot be altered undetected after that time-stamp, even by whoever holds the signing key, checked with both verifiers, a comparison of the record and ledger exports (the same events up to the cutoff, none missing, each with the same chain_hash and ts), and openssl (verification page, sections 04 and 05). Limits: events written after that cutoff, or an incident opened since, are not covered, so the key holder could still alter or remove them undetected until the next anchor. An anchor is attempted once a day, at 03:10 Coordinated Universal Time (UTC), with no retry, so the newest events usually wait up to about a day for one, and longer after a day with no anchor. FreeTSA is a free service with no service guarantee: on a day when it does not answer, or its token fails the checks Warden's anchor function runs before writing, the scheduled run writes no anchor. And someone with owner rights could rebuild the ledger and anchor it again from scratch, which shows only against a copy of an earlier anchor kept outside Warden. The signing key is a server-side secret, not held in a hardware security module.
05 The controls, and where they stand
Where a control is part of the software, the DPIA can point to it rather than to a promise.
A DPO's hardest job is trusting that the controls named in a DPIA are actually enforced. Warden is designed so most of them are properties of the software rather than lines in a policy: no facial recognition, live-only by default, a retention job with a logged purge and role-based human-in-command authorisation. Four things are not settled, and the DPIA should say so: Warden has had no independent security assessment or penetration test; the retention job's schedule is not yet switched on; the ledger can be checked from an export against Warden's published key and, up to its latest anchor, against an outside RFC 3161 time-stamp, but the newest events are not covered until the next anchor (one is attempted once a day, with no retry), and the time-stamp authority (FreeTSA) has no service guarantee; and the console talks to a hosted backend in Ireland (eu-west-1), not the UK. The DPIA can cite mechanism where it exists, and name the gap where it does not.
06 DPO sign-off checklist
Work through it — it saves and totals as you go. When it's full, you have the outline of a DPIA for your own review.
Many UK fire services already fly drones. The open question is whether each flight's use of data can be signed off and shown afterwards, and this starter is a head start for the service's own DPO to copy and own. Warden is designed to reach services through the suppliers they already work with, not directly. If you supply drones, training or assurance to UK fire and rescue and want a walkthrough, see For suppliers or write to joe@wardendfr.com.