The Security Controls That Pass the Audit and Do Nothing

The security controls that pass an audit and stop nothing all share one trait: the auditor checks that they exist, not that they work. A control exists when there is a policy, a screenshot, a ticket, or a signed attestation. A control works when it changes what a real attacker can do. Those are two different questions, and most audit programmes only ever ask the first. The repeat offenders I find in almost every estate are the quarterly access review nobody reads, the web application firewall left in log-only mode, the phishing-training completion percentage, the firewall rule that was rubber-stamped rather than reviewed, and the AI "guardrail" that turns out to be a regular expression. Each one produces flawless evidence and blocks nothing.

How do you tell the difference? Ask one question of every control on your register: what attack has this stopped in the last twelve months, and how would you know? If the honest answer is "we have never tested it against the thing it is supposed to prevent," you are looking at security theatre with an audit stamp on it. The fix is not more controls. It is control effectiveness testing: proving each one does its job under attack conditions, not just confirming it is present.

Why a control can pass audit and stop nothing

Audits verify design and existence. An auditor confirms a control is documented, approved, and evidenced, then samples a few records to check it ran. That proves the control is present. It says nothing about whether the control is effective against a live adversary. Existence and effectiveness are separate properties, and the gap between them is exactly where breaches happen.

I have watched this play out for seventeen years across firewall estates, ISO 27001 programmes, and more than two hundred enterprise audits. A company with a fully evidenced control set fails in an incident while a scrappier competitor holds, because one of them tested its controls and the other collected paperwork. Compliance is a floor, not a ceiling, and it was never designed to measure adversary resistance. I made this point at length in what 15 years of enterprise security compliance taught me: passing the audit and being secure are correlated at best, and often not even that.

The quarterly access review nobody reads

The access review passes audit because there is a signed spreadsheet with a date on it. It stops nothing because the reviewer approved 400 lines in eight minutes without recognising a single account. Standing access is the largest quiet risk in most estates, and a rubber-stamped recertification leaves every over-privileged and orphaned account exactly where it was, now with a compliance signature protecting it.

The tell is the approval rate. If a manager certified every entry and revoked none, quarter after quarter, they are not reviewing, they are signing. A working review produces revocations. It flags dormant accounts, service accounts nobody owns, and privilege that outgrew the role. This is the same sprawl I described in the credential is dead, long live continuous verification: access that persists long after the reason for it expired. Test it by seeding the review with a known bad entry, a decommissioned user, a deliberately over-scoped role, and measuring whether the reviewer catches it. If they do not, the control is decorative.

The WAF that has been in log-only mode for two years

The web application firewall is present, licensed, and shows up in the architecture diagram, so it passes. It defends nothing because it has been in log-only or detection mode since the day someone worried a blocking rule might break production. The rules fire, the alerts land in a channel nobody watches, and no request is ever actually stopped. It is a smoke detector with the speaker unplugged.

Detection mode is a legitimate first step. Leaving a control there permanently is not a control, it is a monitoring feature you are counting as prevention. The check is trivial and almost never performed: send a benign but unmistakable attack pattern at the WAF from outside and see whether it is blocked or merely logged. If the malicious request reaches the origin with a 200 response, the WAF is prevention on paper and telemetry in practice. Either promote the high-confidence rules to blocking or stop claiming the control prevents anything.

The phishing-training completion metric

"96% of staff completed security awareness training" is the single most misleading number in most security reports. It passes audit beautifully because completion is easy to evidence and the target is easy to hit. It correlates with nothing an attacker cares about. Completing a training module measures attendance, not resistance. The question that matters is whether people still click, and completion never answers it.

The behaviour it is meant to change is fast and unforgiving. Verizon's 2024 Data Breach Investigations Report found the median time for a user to click a phishing link was under a minute from opening the email, and put the human element in 68% of breaches. Training completion does not move either figure. What does is measured susceptibility: run realistic simulations, track the click and credential-submission rate per team over time, and act on the trend. A completion percentage that only ever goes up while your click rate is unknown is a vanity metric dressed as a control.

The firewall rule "reviewed" by rubber stamp

Firewall change control passes audit on the strength of the ticket: a request, an approver, a timestamp. It fails as a control when the approver never opened the rule. Across 280-plus migrations the pattern is relentless, the review field is filled in, and the rule underneath is an any-any left over from a 2019 project, a shadowed permit, or a path to a decommissioned host. The paperwork is immaculate. The ruleset is a liability.

A real review changes rules. It removes what is shadowed, tightens what is over-broad, and expires what has no owner. If your change process produces approvals but never rejections or reductions, it is a formality, not a control. Test it the way I test client estates: inject a deliberately bad change request, an over-permissive rule with a plausible justification, into the normal queue and measure whether the approver stops it. A process that waves through a known-bad rule will wave through the accidental ones too. This is the automation gap I keep returning to in security consulting ROI: 7 metrics for the board: the value is in the rules you prevent, not the tickets you close.

The AI "guardrail" that is a regex

The newest entry in the theatre catalogue. An AI feature ships with a "safety guardrail" that satisfies a reviewer because the word guardrail appears in the design document. Inspect it and the guardrail is a keyword blocklist or a single regular expression checking output for a few banned strings. Against a determined prompt injection it holds for about one creative rephrasing. It exists as a control and resists nothing.

Regex filters and blocklists have a place as defence in depth, but presented as the control for a system that takes real action, they are the log-only WAF of the AI era. The failure modes are documented: I mapped the ones I find most in the OWASP LLM Top 10 for 2026, and the reason a naive filter cannot cope is the same confused-deputy problem network security solved decades ago. AI risk is measurable now, too. As I set out in from CVSS to ASR, you can put an attack-success-rate on a guardrail. Test the guardrail against a structured injection set with pass and fail criteria, get a number, and defend that number, rather than trusting the word on the slide.

Existence versus effectiveness: the difference at a glance

The pattern is the same across all of them. The evidence an auditor accepts and the test that would actually prove the control works are two different things.

Every left-hand column is trivial to produce and impossible for an attacker to notice. Every right-hand column takes real effort and is the only thing that changes an outcome.

What to do instead: test effectiveness, not existence

Stop asking whether a control exists and start asking whether it works. Control effectiveness testing means, for each control that matters, defining the attack it is meant to stop, running that attack under safe conditions, and recording whether the control caught it. The output is not a tick in a box. It is a pass or fail against a named threat, and a trend line you can defend to a board.

Practically, four moves cover most of it. First, for every control on your register, write the one attack it should stop and the last date you proved it did. Blank dates are your real risk register. Second, convert vanity metrics into resistance metrics: click rate instead of completion, revocations instead of reviews, blocked requests instead of licensed products. Third, red-team the controls you depend on most, seed the bad access entry, send the malicious request, submit the over-permissive rule, and see what survives contact. Fourth, make effectiveness the reported number. A board that sees "phishing click rate down from 14% to 4%" is learning something; one that sees "training 96% complete" is being reassured for no reason. This is the same discipline behind a credible virtual CISO engagement and the pragmatic sequencing in the zero trust Mittelstand 90-day plan: prioritise the control that removes the most risk, prove it, then move on.

None of this replaces the audit. You still need the compliance floor, and for regulated firms under regimes like NIS2 it is not optional. But treat the certificate as the beginning of the security question, not the answer to it. The controls that pass an audit and do nothing are dangerous precisely because the paperwork makes everyone feel safe. Test them, and the silent failures start making noise while you can still do something about it.

If your control set looks strong on paper and you want to know which parts would actually survive an attacker, request a review. I run control effectiveness and AI security assessments anchored in 17+ years of enterprise cybersecurity. Also see FwChange.com for firewall change automation.