Security teams usually add controls faster than they remove them. After a few years the stack holds tools nobody tunes, rules nobody owns and alerts nobody reads. The question for a leader is not ‘what else should we buy’ but ‘which of what we run is earning its place’. This framework gives a way to decide, control by control, whether to tune, replace or retire.
Why optimization is a distinct discipline
A control can fail in three ways that deployment metrics do not show: it is not working as designed, it is working but nobody acts on its output, or it works and duplicates another control. The public record has examples of the first two.
| Case | What the primary source records | What it shows |
|---|---|---|
Equifax, 2017 House Oversight report, December 2018 |
A device that monitored traffic to the affected application sat inactive for 19 months because of an expired certificate (GAO: ten months). The report says Equifax allowed over 300 security certificates to expire, including 79 for monitoring business-critical domains. | A control can be present, paid for and blind. |
Target, 2013 Senate Commerce staff report, 26 March 2014 |
The staff report says Target appears to have failed to respond to multiple automated warnings from its anti-intrusion software. The report relies on media reports and uses hedged wording. | A control can work and its output can still go unused. |
The decision framework
For each control, answer four questions with evidence. Do not answer from the vendor’s feature list.
-
What risk does it address? Name the threat or the requirement. A control with no named purpose is a candidate to retire.
-
Does it work today? Show a test, not a coverage percentage. NIST SP 800-55 Volume 1 separates implementation measures (how far a control is deployed) from effectiveness measures (how well it meets the desired outcome). Optimization depends on the second kind.
-
Does anyone act on it? Trace one real alert from firing to closure. Count how many alerts closed with no action.
-
What else covers the same risk? Map overlaps. Defense in depth is a design principle in NIST SP 800-160, but the barriers should differ in kind. Two tools that fail the same way are not depth.
| Finding | Decision | Typical next step |
|---|---|---|
| Works, acted on, not duplicated | Keep | Schedule the next test |
| Works, not acted on | Tune | Fix thresholds, routing and ownership before replacing anything |
| Does not work, risk still real | Replace or repair | Define the test first, then evaluate options against it |
| Works, duplicated by a control that fails differently | Keep both | Document why |
| Works, duplicated by a control that fails the same way | Retire one | Plan the removal and re-test the remaining control |
| No named risk and no test | Retire | Record the decision and the date |
Retiring a control safely
-
Confirm what the control protects before removing it. Check logs, dependencies and contracts that rely on it.
-
Re-test the remaining coverage. Run the same attack-path or detection test before and after.
-
Keep evidence required by regulation. For UAE licensed financial institutions, CBUAE regulation C 1/2026 Article 8.7.2 expects ICT and cybersecurity risk management to be regularly tested to identify gaps against Risk Tolerance. Removing a tool does not remove that duty.
-
Record the decision. Who agreed, on what evidence, and the review date.
Where optimization goes wrong
-
Cost drives the decision. Cutting a control to save money, with no test of what it covered, moves risk to a place nobody is watching.
-
Optimization becomes a tool bake-off. The question is the control’s effect, not the product’s feature list.
-
No baseline. Without a pre-change test result you cannot show that retiring or tuning a control left coverage intact.
Decision
Decision: run the four questions on the ten controls you spend the most on. Write the answer for each in one line. Any control where you cannot answer question two goes on a test plan first.
What this evidence does not show
Two breaches show that controls can fail quietly. They do not show how common it is. We have not cited a figure for average tool counts or tool-related breach cost. The decision table is Cybrilliant analysis, not a standard.
A short test
Take one detection control. Find the last time someone proved it would catch a known technique. If nobody can say, that is the first test to write.
Sources
-
NIST SP 800-55 Vol. 1, Measurement Guide for Information Security, December 2024. Accessed 9 October 2026. nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-55v1.pdf
-
NIST SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems, November 2022. Accessed 9 October 2026. nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v1r1.pdf
-
Central Bank of the UAE, Operational Risk Management Regulation C 1/2026, Rulebook. Accessed 9 October 2026. rulebook.centralbank.ae/en/rulebook/operational-risk-management-regulation
-
US House Committee on Oversight and Government Reform, Majority Staff Report, The Equifax Data Breach, December 2018. Accessed 9 October 2026. oversight.house.gov/wp-content/uploads/2018/12/Equifax-Report.pdf
-
US Senate Commerce Committee, Majority Staff Report, A Kill Chain Analysis of the 2013 Target Data Breach, 26 March 2014. Accessed 9 October 2026. commerce.senate.gov/wp-content/uploads/media/doc/2014%200325%20Target%20Kill%20Chain%20Analysis.pdf
How we label evidence
Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.
Part of the solutionBuild & Transform CybersecurityTurn a long list of projects into a lasting program.See how we work →Related service
Security Engineering & Optimization
Use this to put your ten most expensive controls through the same three questions.