Ceremonial Security Controls: How to Find and Fix Them
Ceremonial security controls cost budget and analyst time but do not reduce risk. How to find them, measure them and replace them with controls that work.
Loading...
Ceremonial security controls cost budget and analyst time but do not reduce risk. How to find them, measure them and replace them with controls that work.
What AI-driven security solutions really do: alert triage, behavior-based detection, risk ranking and automated response, and how to test the AI claims.
Most security programs have a graveyard of controls that nobody questions. Think of the quarterly access review that takes 40 hours of analyst time and produces zero remediations, or the vulnerability scan that feeds a backlog nobody works. These controls exist because someone added them once and they passed an audit. Now removing them feels like a risk, so they stay.
This is ceremonial security, and it comes from a lack of measurement rather than bad intent. Your team stays busy performing for auditors and for the quarterly board slide that shows green in every category, while the controls that actually reduce risk go underfunded or missing.
The question that matters is whether your controls work, and working means a measurable drop in the likelihood or impact of a real threat. If you cannot answer that for every major control in your program, you have some ceremonial security. This guide shows how to find it, measure it and replace it.
Browse the Full Cybersecurity Market. Every Category.
Every category on CybersecTools, from AI Security and Cloud Security to Threat Intelligence and Offensive Security. Filter by use case, industry, or company size.
Ceremonial controls are sticky because they are visible. They produce reports and audit evidence, auditors like them, and your GRC platform shows them as green. That visibility builds a lot of inertia once you try to cut something that looks like security.
Underneath it is risk aversion pointed the wrong way. Nobody wants to be the security leader who said "we stopped doing X" right before X became the way in. So controls pile up, because each one made sense when it was added and none of them ever get retired. Every year the team spends more time keeping up the ceremony than building real defenses.
Budget cuts make it worse. Leaders protect the visible controls because those are tied to audit findings, so the invisible work like threat hunting and detection tuning goes first. You end up with a program that looks complete on paper and is hollow in practice.
Ceremonial controls tend to fall into four patterns, and most mature programs have all of them.
The first is compliance theater, where a control satisfies a framework requirement but is scoped so narrowly that it covers almost nothing. A SOC 2 access review that covers 12 production accounts and ignores 400 developer workstations is one example, and a penetration test that hits the same three applications every year because they are in scope is another.
The second is metric washing, where a control produces numbers but no insight. Phishing click rates go to the board with no link to real credential compromise, and patch compliance counts patches applied rather than the patches that matter.
The third is the ritual review: a recurring meeting or report that eats analyst time but has no decision rights attached. The classic case is the weekly vulnerability review where the same 200 critical findings have sat for six months because nobody owns remediation.
The fourth is vendor-driven activity. Some controls only exist because a vendor sold you a product and somebody has to use it to justify the contract, like daily DLP scans that generate 10,000 alerts and lead to zero policy changes.
None of them can answer one simple question: what would be different if this control failed? If the honest answer is "nothing would change", you have found a ceremonial control, and you can either redesign it around a real threat and a measured outcome or retire it.
Start with your control inventory, and if you do not have one, that is the first problem. Every control should have an owner, a threat it addresses, a way to measure it and a last-reviewed date. Most programs have the first two, but very few have the last two.
For each control, ask three questions. First, which threat scenario does it reduce? Be specific, so "a privileged user copying customer data to USB" rather than "insider threat". Second, how do you know it works? "It ran" is not an answer, but "it detected or prevented X incidents last quarter" is. Third, what does it cost in analyst hours, product spend and the work it pushes aside?
Run this with your team leads rather than alone. Your analysts know which controls are theater because they have been performing them for years, so give them permission to say so. You will surface more ceremonial controls in one working session than in six months of solo analysis.
The output can be a simple scoring matrix. The rows below are an example of what one might look like, not measured data:
| Control | Threat addressed | Measurable outcome | Annual cost (hours + $) | Recommendation |
|---|---|---|---|---|
| Quarterly access review | Privilege creep | Zero remediations in 4 quarters | 160 hrs + $0 product | Redesign or retire |
| Weekly vulnerability scan | Known exploits | 12% patch rate on criticals | 40 hrs + $18K/yr | Fix the remediation process |
| Phishing simulation | Credential phishing | 8% click rate, no link to incidents | 20 hrs + $12K/yr | Connect to incident data or cut |
Access reviews are the classic example. Every compliance framework requires them, every security team dreads them, and in many organizations they lead to very few actual access changes. Findings sit in ticketing systems or get marked "accepted" by managers who did not understand what they approved.
The problem is the design, not the control. Most access reviews are point-in-time snapshots that ask managers to certify access they did not grant and do not understand. The manager clicks approve because the alternative is a conversation they do not want, the auditor sees a completed review, and nothing changes.
A working access review has three things the ceremonial version lacks. It runs continuously instead of quarterly, it focuses on high-risk access instead of all access, and it revokes clear violations automatically instead of opening a ticket that waits for a manager. If yours is missing any of the three, you are performing a ritual rather than managing risk.
The fix is a redesign around outcomes, not more products. Define what "access that should not exist" looks like, build detection for it, automate revocation for the clear cases and save human review for the unclear ones. That control reduces risk, and the quarterly spreadsheet does not. The quarterly access review guide goes deeper on this one.
Compare Ceremonial Security Controls: How to Find and Fix Them solutions side by side
Features, integrations, NIST coverage and deployment for every Ceremonial Security Controls: How to Find and Fix Them solution we list, in one table.
Compare Ceremonial Security Controls: How to Find and Fix Them solutions →
Most organizations scan for vulnerabilities on a regular schedule, and most also have a critical backlog that has been growing for years. Both are true at once because scanning and remediation are run as separate programs, with separate owners and no shared accountability.
The cycle looks like this. The scan runs, the report goes to security, security sends tickets to IT or engineering, and the tickets sit until the next scan makes the backlog bigger. Meanwhile the board slide says "vulnerability management: active" and the CISO knows the number means nothing.
Vulnerability management only works as a control when the loop is closed. That means you scan, rank by exploitability and business impact, assign with SLAs, track to closure and measure mean time to remediate by severity. If any link in that chain is broken, you are measuring your exposure without reducing it.
Prioritization is where most programs fail. If you treat every critical the same, your team ends up fixing a CVSS 9.8 issue in a dev environment while a CVSS 7.2 with a public exploit sits in a customer-facing system. Risk-based ranking that uses threat intelligence, such as the known exploited vulnerabilities list, and asset criticality is what turns a reporting exercise into a working control.
Phishing simulations became a standard control because they are easy to run, easy to report and satisfy awareness requirements in most frameworks. The click rate is clean and fits on a board slide. It is also mostly disconnected from real phishing risk.
Click rate does not tell you whether your email security catches real phishing, or whether the people who click simulations are the ones who click real attacks. It also says nothing about whether your process for reported phishing works, or whether credential compromise from phishing is going down. Many programs have tracked this proxy for years and called it a security outcome.
A phishing program that reduces risk connects simulation data to real incident data. It measures reporting rates as well as click rates, and it tracks whether people change their behavior on later simulations. It also feeds into email security tuning, so the controls that catch real phishing get better over time.
Your board does not want to hear that controls it approved and funded are not working. It still needs to hear it, and how you frame it decides whether you get support or doubt.
Lead with the opportunity rather than the failure. For example: "We found $400K a year in spend on controls that do not measurably reduce risk. Moving that to detection and response would cut our mean time to detect from 21 days to under 5." Use your own measured figures, but that shape is a business case the board can act on.
Bring the data. Show each control with its cost, its expected outcome and its actual outcome, then show what you would do instead and what you expect to get. Boards respond to specifics, such as: "We are replacing a quarterly manual access review with continuous automated monitoring. It gives the same compliance coverage with a third of the analyst time, and it actually revokes access when it finds a violation."
Expect pushback on compliance risk and have your answer ready. Most ceremonial controls can be replaced with controls that meet the same framework requirement while reducing risk. The access review above satisfies SOC 2 CC6.3 whether it runs quarterly by hand or continuously and automatically, so know your framework requirements well enough to make that case.
Moving from ceremonial to real security is a measurement problem before it is a product problem. You have to define what "working" means for each control before you can tell whether it works.
Start with your top five threat scenarios. These should be real scenarios for your business, not framework categories: ransomware hitting your ERP system, a developer pushing credentials to a public repo, or a vendor getting compromised and pivoting into your environment. For each one, map the controls that should prevent or detect it, then ask whether those controls have ever caught anything like it.
This exercise surfaces gaps faster than any maturity assessment. You will find scenarios with no detective controls, controls that are meant to cover a scenario but were never tested against it, and scenarios where your whole defense is one preventive control with nothing behind it. The control reliability engineering guide shows how to keep testing them once you have the map.
The goal is a program where every dollar and every analyst hour traces back to a threat scenario and a measurable outcome. That program will not be perfect, but it will be defensible, and it holds up under budget reviews, board questions and the incident that finally tests whether your controls are real.
Check a vendor before you sign
Mandos tracks funding, acquisitions, hiring and news for security companies. Look up any vendor on your shortlist before the renewal.
Ceremonial security is what happens when programs grow without measurement, when compliance drives spending, and when removing a control feels riskier than keeping one that does not work. Every mature program has some of it. What matters is whether you look for it, measure it honestly and make the case for change.
Leaders who do this work end up with smaller, faster and more defensible programs. Leaders who skip it end up explaining to the board why the incident happened despite all the green on the dashboard.
Most frameworks specify the outcome, not the method. SOC 2, ISO 27001 and the NIST Cybersecurity Framework all let you meet a requirement with a different mechanism as long as you can show the intent is met. Document the replacement control, map it to the requirement and get your auditor to agree before you change anything. Auditors generally prefer controls that work, as long as the paperwork is clean.
You do not need a separate audit project. Build the question into your existing quarterly reviews and ask each control owner two things: what did this control detect or prevent in the last 90 days, and what would have happened if it had not been running? If neither has a good answer, you have a candidate for redesign. This takes hours, not weeks, and it surfaces the best targets quickly.
Mean time to detect and mean time to respond are the easiest to defend because they tie straight to business impact. Cutting MTTD from 21 days to 5 is a concrete improvement in how fast you can limit the damage from an incident. Pair that with the cost of the ceremonial controls you retired and you have an efficiency story boards understand.
The vendor will have a TCO calculator and a case study ready, so your counter is outcome data from your own environment. Pull the last 12 months of alerts, detections and remediations from the product. If the numbers do not support the contract value, that is your negotiating position. Most vendors would rather renegotiate scope or price than lose the contract, so come with data rather than frustration.
For a single control like access reviews or phishing simulations, expect 60 to 90 days to redesign, pilot and validate the replacement. The design work is quick. The slow part is getting buy-in from the teams that own the systems the control touches, usually IT, HR and engineering, so plan the time for those conversations and not only for the technical work.
Yes, framed as a program improvement plan. Boards that find out later, usually after an incident, that you knew controls were ineffective and said nothing will lose confidence in your judgment for good. Boards that hear "we found underperforming controls and here is our plan to fix them" see a leader who is actively running the program. Being open carries far less risk than staying quiet.
I wrote this guide from my own work running security programs and buying security products. Category and glossary links point to the CybersecTools catalog of 9,168 security products. Read the methodology for how we review products.