Government
How should a public body evaluate a technology vendor’s security claims?
Three artifacts separate a vendor who has been audited from one who is about to be.
The answer
Ask for artifacts rather than assurances: the last incident post-mortem, the recovery procedure with the date it was last rehearsed, and the subprocessor list with residency stated. A vendor who answers those three from published material has operated under scrutiny before; a vendor who assembles them for your questionnaire is answering them for the first time, and the difference matters more than any certification logo on the cover.
What a certification does and does not tell you
A certification says a control set was assessed against a standard at a point in time by someone the vendor paid. That is genuinely useful and it is not the same as evidence the controls work under load today. Read the scope statement — what was actually in it — before reading the badge.
This practice publishes its own certification position, including what is not held and what has not been started, on its trust centre. A vendor that documents its gaps is a vendor whose claims about everything else are worth more.
Checklist
The last post-mortem
Not the uptime figure — the write-up of what broke, what was done, and what changed. A status page with no incident history describes software with no users.
The recovery rehearsal date
An unrehearsed recovery procedure should be treated as absent. Ask when it was last executed, on what environment, and who ran it.
The subprocessor register
Who else touches the data, doing what, hosted where. Categories in advance; the specific list at onboarding.
The disclosure policy
How a researcher reports a flaw and what the vendor commits to in return. Its absence tells you how the first report will go.
Read next
Talk to the practice
Tell us what you are trying to build and what has to be true for it to work.
Contact