Zero Security Theatre
Patterns and anti-patterns
Patterns are practices that help when tested. Anti-patterns are common, usually well-intentioned practices that create paperwork without improving the result.
Patterns
Attach an outcome test to every security purchase
Make a named production test a condition of acceptance and renewal. Run the attack behaviour, record what the control changed, and use the result in the buying decision.
Score unknown as red
Remove the not assessed category. A control whose effect has not been demonstrated is reported as failing until it is tested, which makes the verification backlog visible to the people who fund it.
Under The dangers of security theatre, Attack-and-recovery engineering
Publish the demonstrated result beside the target
Every recovery objective appears with the timed result of the last real restore and its date. Empty cells are the honest output for systems that have never been recovered.
Store the query, not the screenshot
Keep the source, collection time, and query with the result so a reader can reproduce it. The same record is ready when an audit begins.
Replace remembered behaviour with system behaviour
For each thing staff are asked to remember, look for an arrangement that makes the unsafe action impossible, expensive, or automatically reversible. Keep training for the judgment that genuinely cannot be designed out.
Rehearse the out-of-hours call
Exercise every critical vendor escalation path on a schedule and record who answered and how long it took. An unexercised path is unknown, and unknown is red.
Machine prepares, human decides
Automate correlation, reconstruction, testing, and evidence assembly. Keep isolation, disclosure, notification, and risk acceptance with named people, and let authority move only as measured performance supports it.
Anti-patterns
Reporting agent coverage as security posture
A coverage percentage measures software installation. It carries no information about whether anything is detected, contained, or recovered, and it rises fastest on the systems that matter least.
Treating training completion as a control
Completion is an attendance record. Where a technical control could prevent or detect the failure, training is a supplement to it, not a substitute for it.
Reporting backup job success as recoverability
A finished job says the data was copied. Recoverability is demonstrated by a timed restore into a clean environment that the business accepts.
Our vendor handles that
This answer leaves out what the vendor sees and what it may do. Ask for the data received, the detections in place, the permitted actions, and the date the response path was last tested.
Presenting a certificate as evidence of resilience
A report describes a negotiated scope, at a point in time, against selected controls, many of which ask only whether a process exists. It is a procurement artifact and a requirement source.
Under Compliant Insecurity
Writing a narrative where no data source exists
Requirements with no operational evidence source produce prose, and prose always passes. The absence never appears as a failure in any report.
Accepting a fluent AI report as an assessment
A polished report can sound surer than the facts allow. Require a source record for every generated claim so the reader can check it.
Treating the privacy notice as a description of the systems
The notice states intent. Field inventories, access logs, retention queries, and deletion tests state practice. Where they disagree, the systems are the fact.