Research area
Zero Security Theatre
A control does not count just because it is there. Test it against a real attack and see what happens. This area studies whether security, privacy, compliance, resilience, and governance work as claimed. Unknown is red.
- Date of record
- Sep 15, 2026
- Identifier
- Not assigned
- Status
- Active
A control does not count just because it is there
Most security, privacy, and compliance programs are described by what they have: tools, signed policies, completed training, closed findings, and certificates. That list does not tell anyone what would happen if a capable attacker tried something this afternoon.
Zero Security Theatre asks people to test the control and see what happens. How long did detection take? Did containment stop the spread? Did the restore work? Could a machine gather the proof without someone building a report by hand?
Compliance, training, and tools all have a job to do. Their presence alone does not prove that the job got done.
The primary question
How can we tell whether security, privacy, and compliance work changes what happens during an attack?
Fourteen secondary questions run underneath it. What would actually happen if the attacker tried this today? Can we prove data is handled the way our documents claim? What evidence shows this requirement is working right now, rather than on the audit date? Which measurements predict survival? Which defensive work should machines carry? Which controls can be designed so that remembering is not required? How quickly could we return to validated operation after a destructive event? What does the vendor actually do at three in the morning? Which governance work can become engineering? What is the blast radius of one ordinary identity? How long does a quietly disabled control survive unnoticed? What is the demonstrated recovery time, not the target? Which unknowns are we currently reporting as acceptable? And what would change if we removed this control entirely?
How claims are labelled
Every section is marked as an observation, a hypothesis, evidence, an inference, a recommendation, or an unknown. The label tells the reader how much weight the claim can bear.
Unknown is red. Until a control has been tested, the organisation cannot say it works. Evidence that cuts against a claim stays in the library, and each pillar says what would prove it wrong.
The Security Theatre Test
Use these seven questions on any security, privacy, or compliance activity. If the answers are missing, the control has not shown that it works.
What measurable bad outcome does this prevent, detect, contain, or recover from?
A category name is not an answer. Name the harm that should change.
How would we know if it stopped working tomorrow?
Without a failure signal, nobody knows whether the control still works.
Can it be tested by attacking it?
Try the behaviour it claims to stop and record the result.
Can the result be measured throughout the year?
An annual check misses changes made during the other eleven months.
Can a machine collect the evidence without a person assembling it?
If gathering the evidence takes months of hand work, it will soon be guessed or skipped.
What happens when it fails, and who is accountable for that decision?
Fail-open, fail-closed, and fail-silent are three different systems with the same control name.
If we removed it entirely, what would change and how would we see it?
If removal changes nothing measurable, ask what the spending buys.
The attack-and-recovery scoreboard
| Area | What is measured | Status | Note |
|---|---|---|---|
| Detection | Time from injected activity to accurate alert | Partial | Measured for endpoint techniques, not for identity or SaaS activity. |
| Containment | Time from detection to spread stopping | Failing | No rehearsed containment action outside business hours. |
| Recovery | Demonstrated RTO and RPO on critical systems | Unknown, treated as failing | No timed restore recorded in the period. Unknown is treated as red. |
| Identity | Blast radius of the most privileged standing identity | Failing | Standing administrative access across production and backup planes. |
| Credentials | Share of staff with phishing-resistant authentication | Demonstrated | Hardware-backed and origin-bound across the workforce. |
| Vulnerabilities | Recurrence rate of the same finding class | Partial | Instances are closed; the cause is addressed inconsistently. |
| Vendor response | Time for the critical provider to act out of hours | Unknown, treated as failing | Escalation path contracted but never exercised. |
| Incident command | Named decision owners reachable and rehearsed | Partial | Roles named; the out-of-hours call has been made once. |
| Privacy enforcement | Verified deletion across every store and vendor | Unknown, treated as failing | Deletion confirmed in the primary system only. |
| Compliance evidence | Share of controls with machine-verifiable evidence | Failing | Most evidence is assembled by hand before an audit. |
Working registers
- Experiments
Tests that produce measured results and state what each result can prove.
- Evidence library
Standards, regulatory guidance, advisories, and public reports, with a note on what each supports.
- Patterns and anti-patterns
Practices that help, along with common practices that create paperwork without changing the result.
Open questions
- Which of the candidate resilience measures carry independent signal once organisation size and sector are controlled for?
- How should unknown values enter a composite score without being treated as neutral?
- Does adversarial testing frequency predict loss magnitude, or only detection speed?
- Where is the point below which encoding controls costs more than the manual effort it replaces?
- What fraction of privacy commitments can be converted into automated tests in a typical healthcare architecture?
- Does crypto-shredding resolve the backup and deletion tension at acceptable recovery cost?
- When phishing-resistant authentication closes one path, does total loss fall or move?
- Do machine-generated incident timelines meet the evidentiary standard regulators and insurers expect?
- How much of the governance function's time is transcription, and is it actually redirected when automated?
- What is the observable difference between an organisation that has tested recovery and one that has not, at the moment of a destructive event?
Planned outputs
These are still being developed. None has shipped.
Zero Security Theatre, a field book
Planned. The measurement discipline, the test, and the scoreboard in one place.
Compliant Insecurity, a field book
Planned. How organisations satisfy their frameworks and still cannot detect, contain, or recover.
Attack-and-recovery engineering, a field book
Planned. The intervals, the drills, and the evidence each one requires.
Assessment method and scorecards
In development. The scoreboard on this page, with instructions for collecting each number.
Audit and board prompts
In development. The questions that replace inventory reporting in oversight conversations.
Implementation patterns and control specifications
In development. The current drafts are in the patterns register.
Research under this area
Active · 3 notes
The dangers of security theatre
Security programs are usually described by what they have: purchased tools, signed policies, closed findings, and certificates. That says almost nothing about what would happen if a capable attacker tried something today. This pillar tests the controls and measures what happens.
Active · 3 notes
The dangers of data privacy theatre
Most privacy programs are documentary. Notices, consent language, contractual clauses, and a data inventory maintained by interview. This pillar studies privacy as an engineered property of running systems, where the claim in the notice can be checked against the behaviour of the data.
Active · 3 notes
Compliant Insecurity
An organisation can hold every certificate its market asks for and still be unable to detect, contain, or recover from an ordinary intrusion. Compliant Insecurity is the name for that condition. This pillar studies how regulatory and contractual obligations move from periodic attestation to continuous operational evidence.
Active · 3 notes
Attack-and-recovery engineering
Engineering disciplines specify an outcome, instrument the system, attack the assumption, measure what happens, and improve. This pillar applies that sequence to cyber resilience and collects the evidence needed before any composite score can honestly be defined.
Active · 3 notes
AI-native defensive security
AI makes some attacks cheaper and gives defenders more ways to watch systems continuously. This pillar asks which neglected defensive jobs machines can now do, and which decisions still need a person.
Active · 2 notes
Human error without human blame
A large part of security practice asks employees to remember instructions and behave correctly under time pressure. This pillar studies what happens when that expectation is replaced with technical arrangements that make the safe action the default.
Active · 2 notes
Recovery as a first-class discipline
Prevention attracts budget and attention. Recovery is usually delegated to infrastructure, measured by job success, and rehearsed rarely. This pillar studies whether recovery capability is systematically underinvested relative to its effect on total loss.
Active · 2 notes
Vendor and supply-chain resilience
Other organisations hold much of a company's security in their hands: managed providers, cloud platforms, software vendors, clinical systems, contractors, open-source maintainers, and AI providers. This pillar asks what those parties actually do when trouble starts.
Active · 2 notes
GRC engineering
Governance, risk, and compliance teams write policies, maintain spreadsheets, collect screenshots, and answer questionnaires. This pillar asks how much of that evidence the systems themselves can produce.
Put this to work
Research application record
Apply a research question to a real case and identify the evidence needed for a decision.
- For
- Practitioners, researchers, founders, and operating leaders.
- What you keep
- A research decision record you can review, revise, and send.
- What counts as sound
- Answers a named decision
- Separates evidence from assumptions
- Includes the strongest contrary case
- Names missing evidence
- Ends with a test, owner, and date
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.