Program
AI-native defensive security
AI makes some attacks cheaper and gives defenders more ways to watch systems continuously. This program asks which neglected defensive jobs machines can now do, and which decisions still need a person.
Research program
Zero Security Theatre
A control does not count just because it is there. Test it against a real attack and see what happens. This program studies whether security, privacy, compliance, resilience, and governance work as claimed. Unknown is red.
How can we tell whether security, privacy, and compliance work changes what happens during an attack?
A control does not count just because it is there
Claim: recommendation
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
Claim: unknown
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
Claim: observation
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 program 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, and 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.
Programs inside this one
Program
Attack-and-recovery engineering
Engineering disciplines specify an outcome, instrument the system, attack the assumption, measure what happens, and improve. This program applies that sequence to cyber resilience and collects the evidence needed before any composite score can honestly be defined.
Program
Compliant Insecurity
Compliant Insecurity is the condition of an organisation that holds every certificate its market asks for and still cannot detect, contain, or recover from an ordinary intrusion. This program studies how regulatory and contractual obligations move from periodic attestation to continuous operational evidence.
Program
GRC engineering
Governance, risk, and compliance teams write policies, maintain spreadsheets, collect screenshots, and answer questionnaires. This program asks how much of that evidence the systems themselves can produce.
Program
Human error without human blame
A large part of security practice asks employees to remember instructions and behave correctly under time pressure. This program studies what happens when that expectation is replaced with technical arrangements that make the safe action the default.
Program
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 program studies whether recovery capability is systematically underinvested relative to its effect on total loss.
Program
The dangers of data privacy theatre
Most privacy programs are documentary. Notices, consent language, contractual clauses, and a data inventory maintained by interview. This program studies privacy as an engineered property of running systems, where the claim in the notice can be checked against the behaviour of the data.
Program
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 program tests the controls and measures what happens.
Program
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 program asks what those parties actually do when trouble starts.
Research notes
Let machines watch; keep consequential decisions with people
Machines can watch systems and prepare evidence. People remain responsible for decisions that cannot be reversed. This note recommends that machines take the high-volume, repetitive work where errors can be corrected, and that the line between machine and person move only when measured performance supports it.
Backups are usually out of scope, and usually full of the data
Retention and deletion policies often exclude backups for practical reasons. The exclusion is defensible. Leaving it unstated in the notice is not. Backups usually hold the data a policy says is deleted, so a privacy notice that is silent about them misleads the people it describes.
Consent language without enforcement is a claim about intent
If withholding consent does not change what a system does with a record, the consent mechanism only keeps a record of the choice. It does not enforce it.
Credential reset at scale is required and almost never rehearsed
Serious intrusions usually end with rotating every credential, key, token, certificate, and service account. Most organisations have never attempted this even partially. Full rotation is disruptive, which is why it is skipped, but a bounded drill on one class of secret shows what breaks before an intrusion forces the issue.
Deletion is the sharpest privacy test
A verified end-to-end deletion exercises the data map, the vendor list, the backup policy, and the derived-data problem at once. Few organisations pass it on the first attempt.
Put the last demonstrated RTO beside the target
A recovery objective is a statement of intent written during planning. The useful number is the one produced by the last real restore, with the date attached.
Design out the memory dependency
For each control that depends on a person recalling guidance under pressure, look for a technical arrangement that makes the safe action the default or the only one.
Do not publish a resilience formula yet
People often ask for one weighted score. Publishing it before the measures are validated would give an untested formula the look of certainty. This note recommends publishing the measures and the unanswered questions until results show which measures tell us something on their own.
Escalation paths decay quietly
Contacts leave, numbers change, portals replace phone trees, and contracts renew with different terms. An untested escalation path is an assumption with a date on it.
Keep evidence that can be reproduced
A screenshot is a claim about a moment. A stored query with provenance can be re-run by the reader, which changes what the evidence is worth.
What a findings dashboard leaves out
Counting open findings measures the discovery process. It says nothing about detection speed, containment, or recovery, and it falls when scanning stops. An executive dashboard should therefore show detection time, containment time, and demonstrated recovery, because a falling finding count does not show a safer company.
Fluent output is not evidence
A generated security assessment reads better than a human one and is harder to doubt. Readability and correctness are unrelated properties. The risk is that AI output raises confidence faster than it raises capability, so every generated claim should carry its source record.
Requirements with no evidence source are more common than failed controls
When requirements are mapped to operational data sources, the largest category is usually requirements that no system can currently answer at all. These gaps matter more than failures, because a failed control is visible while a requirement with no data source produces a narrative that passes. The claim is untested.
Governance runs short of time for judgment
The note's claim, a hypothesis, is that judgment is the scarce part of governance, risk and compliance work, because evidence collection takes the hours that decisions need. When collecting and formatting evidence takes most GRC hours, little time remains for decisions. Automating the clerical work may give that time back.
Measure the time between each response step
The note recommends measuring the time between response steps rather than counting incidents, because intervals can be generated on demand and compared quarter to quarter, which incident counts cannot. Incident counts depend on how hard an organisation looks. Detection, containment, and recovery intervals can be generated on demand and compared over time.
Phishing resistance belongs in the credential
Origin-bound, hardware-backed authentication removes a whole class of failure regardless of how convincing the message was. This is the clearest available example of design beating vigilance.
Generate the policy from the enforced rule
Where a platform enforces a setting, produce the written policy from that configuration. Then the rule and the document cannot drift apart. Keep the enforced rule as the source of record, mark policy without enforcement as unenforced, and report how many policy statements are actually enforced.
Adversarial simulation may replace part of annual training
Generated, varied, current scenarios delivered continuously and measured behaviourally are a plausible substitute for a yearly module. Plausible is not proven. Three things would need to be true, and all are testable: simulation measures predict real behaviour, simulation does not damage reporting culture, and scenarios stay within ethical and employment boundaries.
The audit passed and the network was flat
Certification scope is negotiated. A clean report describes the environment that was examined against the controls that were selected, at the time of the examination.
The restore worked and took four days
A restore can return all the data and still come too late. Time, sequence, and hidden dependencies often cause the loss. Restore order, recovery credentials, network capacity, and staff availability do not appear in a backup report, but all of them appear in a timed drill.
The tool was purchased. Was it tested?
The note's observation is that a security purchase is judged on deployment, not on evidence that the tool changes an attack outcome. The fix is to add a named production test as an acceptance condition. Procurement produces a deployment date. Nothing in the ordinary purchase process produces evidence that the tool changes an attack outcome in this environment.
Unknown is red
If nobody can show that a control works, score it as failing. Amber and blank let an untested control sit quietly beside a tested one.
What happens if the vendor is the one compromised?
The note recommends assessing what a compromised vendor's own access could reach, not only whether the vendor protects your data, and how you would sever that access without the vendor's cooperation. Third-party risk programs assess whether a vendor protects your data. They rarely assess the blast radius of the vendor's own access to your systems.