Knowing What You Have

You cannot govern what you have not counted, and video analytics accumulates through projects, pilots and vendor upgrades that nobody tracked centrally.

What to record

Per deployment, not per camera.

What it detects, specifically.

Which cameras and zones.

The purpose, in a sentence someone could evaluate.

The tier: detection, counting, or identification.

Legal basis, and the additional condition if biometric.

Whether an impact assessment exists, and where.

Notice given: what, where, when.

Retention, per data category.

Who has access, by role.

Owner, a named person.

Last evaluated, with the result.

Review date.

Twelve fields. Sparse is fine; absent is not.

Building it the first time

Start from the camera estate, which someone has.

Ask each site and each function what analytics they run. Expect to find deployments nobody central knew about.

Check the vendor consoles, which frequently reveal enabled features nobody chose — demographic estimation and face detection are commonly on by default.

Check what the software can do, not just what you think it is doing. A counting product with identification available is a decision waiting to be made accidentally.

Expect the first inventory to surprise you. It always does.

The findings it produces

Consistently, in order of frequency.

Deployments with no owner.

Features enabled that nobody requested, particularly demographic and face detection.

Pilots still running years later.

No impact assessment, for systems that require one.

Notices that describe recording but not analysis.

Retention configured at the vendor default, which is usually longer than intended.

Access held by people who changed role.

Each is actionable and cheap to fix once visible.

Keeping it current

A gate before any new deployment: it enters the register, with a purpose, an owner and an assessment, or it does not go live.

Annual review of every entry, which is where decommissioning candidates surface.

Re-check vendor features after upgrades, because new capabilities arrive enabled.

A named owner for the register itself, or it decays within a year and the next inventory starts from nothing.

What it enables

Answering "what do you run" in minutes rather than in a fortnight of asking around.

Responding to an access request, which requires knowing where someone might appear.

Responding to a regulator, who will ask exactly these fields.

Deciding what to decommission.

Noticing scope creep, because a deployment whose purpose has quietly widened shows up when the register is compared against reality.

The register is unglamorous and it is the artefact that makes governance possible, which is why it is worth the fortnight it takes to build.

The console check

The step that finds capability nobody chose, and it should be the first thing done.

Open every vendor console.

List every feature: enabled, available, licensed.

Compare against what the register says the deployment does.

Compare against what the notice says.

Expect three mismatches: features on by default, features licensed and unused, and notices describing less than the system can do.

Repeat after every upgrade, because new capabilities arrive enabled.

The twelve fields

Sparse is acceptable; absent is not.

Detection, cameras, purpose, tier, legal basis, assessment location, notice details, retention by category, access by role, owner, last evaluation, review date.

One row per deployment, not per camera.

Owned by a named person, or it decays within a year.

Compared annually against reality, which is where scope creep becomes visible.

These are also the fields a regulator asks for, which makes the register both an operational tool and the audit answer.