Operating Theory · 2026-09-15
The tool was purchased. Was it tested?
Procurement produces a deployment date. Nothing in the ordinary purchase process produces evidence that the tool changes an attack outcome in this environment.
Under the pillar The dangers of security theatre
Where the gap opens
A product is evaluated against a feature list, deployed against a project plan, and reported against a coverage percentage. At no point does the standard process require somebody to perform the behaviour the tool is supposed to stop and record what happened.
Coverage percentages are especially misleading because they measure agent installation. They do not measure detection quality.
A cheap correction
Add one acceptance condition to every security purchase: a named test, run in production, that demonstrates a changed outcome, repeated quarterly. This is far cheaper than the purchase and frequently changes the renewal decision.
Put this to work
The tool was purchased. Was it tested? challenge record
Test the claim behind The tool was purchased. Was it tested? against a real case and look for where it fails.
- For
- Practitioners, researchers, founders, and operating leaders.
- What you keep
- A the tool was purchased. was it tested? challenge record you can review, revise, and send.
- What counts as sound
- Makes the claim testable
- Includes contrary evidence
- Preserves competing explanations
- States uncertainty
- Names what would change the conclusion
The result is a working analysis. Check it against source evidence and qualified judgment.
Nothing entered here is stored or sent. Review the prompt before sharing confidential, personal, patient, or privileged information.
Review the prompt
You can leave any field blank. The prompt will mark it as not provided.
If the record survives your review, send the question, evidence, unknowns, and requested next step.