Verification is the point at which a data request programme either has a security model or does not. Everything else (intake, triage, scoping, production) assumes the requester is legitimate. Verification is the step that tests the assumption.
Verifying the document versus verifying the person
These are different activities and are routinely conflated.
Document validation asks whether the request is well-formed: is it the right instrument for the data sought, is it signed, does it cite a plausible authority, is it within scope. This catches errors and unsophisticated forgeries.
Requester verification asks whether the human behind it is real and authorised. This is what catches a well-crafted request from a compromised account, which document validation cannot.
| Document validation | Requester verification | |
|---|---|---|
| What it checks | The request artefact | The person making it |
| Catches fabricated agencies | Yes | Yes |
| Catches spoofed domains | Partly | Yes |
| Catches compromised genuine accounts | No | Yes |
| Can be done from the request alone | Yes | No, requires an independent channel |
The bottom two rows are the whole argument. Any check performed entirely on material the attacker supplied can be satisfied by an attacker who controls that material.
What verification actually involves
- Independent channel. Contact the agency through a route the requester did not supply.
- Identity of the individual. Confirm the named officer is serving at the agency named, not merely that the agency exists.
- Authority for this request. A serving officer is not automatically authorised to make every kind of request.
- Consistency with history. Prior legitimate contact from the same agency and officer is meaningful context; a first-ever contact arriving as an urgent emergency request is not.
Why it is hard at scale
A single callback is easy. Several hundred requests a month across dozens of jurisdictions, each with different agency structures, contact directories, and identity conventions, is an operations problem. Teams that verify manually tend to converge on verifying only the requests that already looked suspicious, which inverts the logic. The requests worth verifying most carefully are the ones designed to look routine.
This is the structural argument for verification infrastructure rather than verification procedure: a check that only happens when someone is already worried is not a control.