Practitioner deep-dive
Every security tool ships with a silent configuration gap
Whatever you bought, it sits somewhere between how it was configured on the day it went in and how it ought to be run today, and that distance is usually invisible, rarely measured, and almost never ranked against anything, so it accumulates as configuration debt nobody has a burndown for. Making that gap legible and rankable across the whole stack is what turns it into a worst-versus-best-practice backlog you can actually work down from the bottom up, and manageability at that scale is a force multiplier in the specific sense that it raises the security you get per analyst-hour rather than the security you get per purchase order.
Evidence tiers are marked inline and they are mixed, which is the honest state of this topic. The framework anchors are Tier A: NIST CSF 2.0, MITRE ATT&CK, MITRE D3FEND, the CIS Controls and their Implementation Groups. The category definition is Tier B and paywalled. The efficiency numbers published by the vendor whose approach I am describing are Tier C, vendor-sourced and directional, and I could find no independent technical evaluation of that product at all, which is a finding in its own right and I say so at length rather than burying it. Nothing here is a first-party measurement, so this essay is an architecture argument and not a benchmark; where I show a grid of numbers to demonstrate the ranking mechanic, the numbers are constructed and labeled as constructed.
The definitions
Manageability is what it costs you to find out where a control stands.
Manageability gets used as a vague virtue, so it is worth pinning to something you could argue about. I mean three properties of a control surface, all of them about cost rather than capability. Legibility is whether the current configured state can be read out without a project. Comparability is whether that state can be set against an intended state that somebody other than you defined. And marginal cost of change is what the second, tenth and hundredth remediation cost once the first one is done. A control that scores well on all three is manageable, and a control you can technically configure any way you like but cannot cheaply read, compare or change in bulk is not, however powerful its feature list.
Force multiplier is borrowed language and it deserves its original meaning rather than the motivational one. In the source usage it is a factor that increases the effect of a given force without increasing the force. Applied here, it is any change that raises output per unit of the scarce input, and the scarce input in a security program is almost never licenses or even headcount in the abstract. It is analyst-hours, which is why the useful metric is a rate rather than a total.
So the metric I would hold this to is control coverage delta per analyst-hour: how much additional coverage of the techniques you care about you obtained, divided by the hours it took to obtain it. I deliberately do not write risk reduction per analyst-hour, and the reason is not fussiness. Risk reduction is the number everyone wants and almost nobody can compute honestly, because it needs a defensible model of likelihood and impact per technique, and most organizations substitute a severity label for that model and then treat the arithmetic as though it were measurement, whereas coverage is the weaker claim but the one you can actually go and check. If you can genuinely compute risk reduction, use it. If you are about to compute it from a five-point severity scale somebody assigned by feel, the coverage rate is the more honest instrument, and this is the same argument I made at length about coverage percentages that overstate what a detection stack really does.
The reason this framing pays is that the work it describes is the work Google's SRE book calls toil, and the definition transfers almost word for word. Toil is "the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows" (Chapter 5, "Eliminating Toil", Rau, 2016, Tier A for the definition itself). Reading a firewall policy by hand to see whether it matches what you meant two years ago is manual, repetitive, automatable, and scales linearly with the number of firewalls. That is toil with a security label on it, and the SRE framing is useful precisely because it refuses to treat the hours as free.
Two denominators
One divides by assets, the other divides by techniques.
The benchmark-conformance category is the older and better understood of the two. CIS-CAT Pro assesses a system against the CIS Benchmarks and maps the results back to the CIS Controls; it is a paid tool requiring CIS SecureSuite membership, free to US state, local, tribal and territorial government (cisecurity.org, Tier A for the framework, Tier B for the product description). Qualys Security Configuration Assessment describes itself in almost exactly the terms the category deserves, as an add-on that lets you "assess, report, monitor and remediate security-related configuration issues based on the Center for Internet Security (CIS) Benchmarks", with a define-assess-report-remediate loop (qualys.com, Tier C, vendor-sourced). Netwrix Change Tracker ships CIS-certified templates and frames its job as establishing a baseline and flagging drift from a hardened state. The shared shape is conformance to a published baseline, scored per asset.
I want to correct my own first draft of that generalization, because it does not fit the whole category evenly. Wiz's cloud posture product does perform CIS-benchmark conformance checks and is CIS SecureSuite-certified, but its own positioning leans away from flat pass-or-fail scoring and toward graph-based context, evaluating a misconfiguration alongside internet exposure, identity permissions, sensitive data and reachable attack paths (wiz.io, Tier C, vendor-sourced). That matters for the argument rather than against it. The category is already migrating toward threat context on its own, which is evidence that the two approaches below are converging layers rather than rival products, and it is a reason to be careful about treating any three vendors as interchangeable illustrations of a type.
The other category is newer and Gartner has given it a name: Automated Security Control Assessment, technology that continuously analyzes and optimizes deployed security controls, identifying configuration drift, policy deficiencies, weak defaults and detection gaps, and prioritizing findings by control context and threat relevance. That definition is Tier B and it comes with a caveat I will not paper over: Gartner's primary research is paywalled, and the wording above is corroborated by several unrelated vendors quoting the same report consistently rather than by my reading Gartner's own page, which returned access errors on every attempt. Reach Security is the exemplar I was asked to examine, and it works on top of the stack you already own, connecting through read-only APIs with no new agents, and recommending changes to controls you have already bought based on the threats actually observed in your environment (reach.security, Tier C, vendor-sourced throughout).
Here is the comparison as a grid. This one is analytical rather than measured, which is a distinction the sibling essay on measured detection coverage holds strictly: there, a measured read meant runtime firing scored against planted ground truth. Nothing in this table is a runtime result. It is a structured reading of what each category can and cannot see, and the evidence-tier column is the part I would defend hardest.
| Dimension | Benchmark conformance | Threat-informed reallocation |
|---|---|---|
| Denominator | Assets | Techniques and threats |
| Question it answers | How far is this asset from the published hardening standard? | Are the controls I already own pointed at what is actually coming at me? |
| Baseline authority | Independent and published; CIS Benchmarks, versioned, community-reviewed | The vendor's threat model applied to your telemetry; not independently published |
| Output unit | Pass or fail, per control, per asset | A recommended change to an existing control, per technique |
| Evidence tier of its own output | B — conformance measured against a baseline you can go and read | C — model-derived recommendation, no published validation found |
| Structurally blind to | Whether a given deviation matters against your adversary; and a fully conformant control aimed at the wrong threat | Baseline hygiene; a perfectly aimed control still running a weak default |
| Which force it multiplies | Scanning and scoring | Aiming |
Read the last row first, because it is the one that resolves the substitutes-or-complements question. The SRE book put it better than I can, and it was written about production automation rather than security controls: "For SRE, automation is a force multiplier, not a panacea. Of course, just multiplying force does not naturally change the accuracy of where that force is applied: doing automation thoughtlessly can create as many problems as it solves" (Chapter 7, "The Evolution of Automation at Google", Murphy, Looney and Kacirek, 2016, Tier A). Benchmark tooling multiplies force, since it scans every asset and scores every deviation, and it will happily generate ten thousand findings without improving by one degree the accuracy of where remediation effort lands. Threat-informed reallocation is an attempt to change the accuracy of aim without multiplying the force at all, since it recommends changes to controls you already bought. An organization that has one and not the other has either a well-aimed weapon it has not maintained or a very well-maintained one pointing somewhere unhelpful.
The evidence-tier row is where I would push back on anyone selling either category as the whole answer. Conformance output is Tier B because the baseline is independent, versioned and readable by you: CIS Controls v8.1 shipped 24 June 2024 with Implementation Groups scoping 56 Safeguards at IG1, 130 cumulative at IG2 and the full 153 at IG3 (cisecurity.org, Tier A). You can disagree with a Safeguard and go and read why it is there. Reallocation output is Tier C because the model that produced the recommendation is not published, not independently validated, and belongs to the party recommending the change.
The burndown
Ranking by configuration distance puts the cheapest work first and the most useful work last.
The mechanic itself is unglamorous, which is a point in its favor. For each control surface you can read, you produce a set of findings shaped as the setting, its current value, its intended value, and the technique or exposure the difference bears on. That set is the gap backlog. It is measured by reading configuration rather than by asking anyone, it is re-read on a schedule so the burndown is a trend and not a snapshot, and it burns down when a finding's current value reaches its intended value and stays there through the next read. Grassroots is the right word for it because the unit of work is one setting on one surface, which is small enough that a single engineer can close several in an afternoon without a program of work forming around it.
The interesting part is the ordering, and this is where a backlog turns into either a force multiplier or a very efficient way to waste a quarter. Below is a worked example of the same five findings ranked two ways. Every number in this table is constructed to demonstrate the arithmetic; it is Tier D, illustrative, and not a measurement of anything. The ATT&CK technique identifiers are real, the findings are plausible, and the numbers are mine and invented for the purpose.
| Finding | Deviations | Bears on | Hours | By distance | By rate |
|---|---|---|---|---|---|
| Legacy TLS ciphers still enabled | 340 | no observed technique | 40 | 1 | 5 |
| Attachment sandboxing off on 3 of 12 mail policies | 3 | T1566 | 2 | 4 | 1 |
| RDP reachable with network-level auth disabled | 2 | T1021.001 | 1 | 5 | 2 |
| MFA not enforced on 4 service accounts | 4 | T1078 | 3 | 3 | 3 |
| Script-block logging off on one server group | 18 | T1059 | 1 | 2 | 4 |
The two orderings disagree almost completely, and they disagree hardest at the top. Ranked by raw configuration distance the legacy cipher finding wins by a mile, because 340 deviations is 340 red cells on a dashboard and closing them all produces the most satisfying single movement in a compliance percentage that any of these five can offer. Ranked by coverage gained per analyst-hour it is last, since forty hours of work bears on no technique anybody has observed coming at this organization. The mail policy finding inverts: three deviations, nearly invisible against a per-asset score, two hours of work, and it closes a gap on the technique that starts a large share of real intrusions.
This is not an argument that the cipher work never gets done, but about what goes first when the input you are spending is a person's week, and about which of the two numbers you put in front of a board. A conformance percentage that moves from 71% to 94% because somebody scripted a cipher change across 340 endpoints is a real number describing real work that bought comparatively little, and the same organization can move from 71% to 72% by closing four findings and materially change what an intrusion would have to get through. The aggregate hides which of those two quarters just happened, in the same way a single coverage figure hides the tactic where the chain breaks.
The honesty discipline
The weight has to come from somewhere that is not selling you the remediation.
If ranking by threat weight beats ranking by configuration distance, then everything depends on where the weight comes from, and this is the point where a good mechanic quietly becomes a bad one. A weight supplied by the vendor whose product will perform the remediation is not an independent prioritization so much as a sales order with arithmetic on it, because the party naming the weight also bills for the fix, and expressing it as a number does not make it a measurement. That is not an accusation aimed at any particular vendor. It is a structural property of the arrangement, and it applies equally to a benchmark vendor scoring you against its own interpretation of a baseline.
The defensible baselines are the ones you can go and read, argue with, and pin to a version. The CIS Controls give you Implementation Groups, so the question "is this Safeguard in scope for an organization of our size and risk profile" has a published answer rather than a vendor's opinion. MITRE ATT&CK (currently v19.2, released 28 April 2026) gives you technique identifiers that mean the same thing in your environment as in an incident report somebody else published, which is what makes coverage claims comparable at all. MITRE D3FEND (1.5.0, released 31 July 2026, funded by NSA's Cybersecurity Directorate, published as an OWL ontology) gives you the defensive half of that vocabulary, and I have written separately about how far those control-layer crosswalks can actually be computed rather than asserted. NIST CSF 2.0 (NIST CSWP 29, 26 February 2024) added GOVERN as a sixth Function alongside IDENTIFY, PROTECT, DETECT, RESPOND and RECOVER, which is the layer at which somebody has to own the decision about what the intended state even is. All Tier A, all readable without a purchase.
For the maturity question specifically, MITRE's Center for Threat-Informed Defense published M3TID, Measure, Maximize and Mature Threat-Informed Defense, on 10 April 2024. It is worth knowing that this is no longer the current article: the M3TID repository was archived read-only on 8 January 2026, and CTID's own note says it "evolved its original M3TID research into INFORM, a practical, measurable approach for assessing and maturing threat-informed defense at the strategic level". If you are reaching for a published maturity instrument rather than inventing one, INFORM is the live one and M3TID is its origin. I mention the archival because a superseded citation is the kind of thing a reader who works in this area will notice immediately, and because it is a small demonstration of the essay's own argument that a baseline is only useful while somebody is maintaining it.
Gartner's Continuous Threat Exposure Management, introduced in a July 2022 report, is the strategic frame most of this sits inside, and it is Tier B with a caveat attached: the primary research is paywalled, so anything specific I could tell you about its five phases or its predictions I'd be relaying from vendors relaying Gartner, which is a chain worth naming rather than hiding behind a citation that looks firsthand. I'm comfortable saying the category exists and roughly what it denotes. I'm not comfortable quoting a statistic from inside a document I haven't read.
What the claims are worth
The efficiency numbers are vendor-sourced and the independent review is missing.
Reach Security publishes a set of efficiency figures, and since the architecture argument above is partly built on their category I should be precise about what those figures are and are not. They claim an 80% reduction in control maintenance workload, 95 hours saved per employee per month, 95% faster threat detection, and detection, investigation and remediation of a misconfiguration inside five minutes, thirty minutes and three hours respectively. A customer case study separately reports an 81% reduction in time spent on manual tasks, which may or may not be the same underlying statistic as the 80% headline figure; I could not establish that it is, so I have not treated them as one number.
I want to be careful that this reads as calibration and not as a hit, because it isn't one. An absence of independent review is the normal condition of a company founded in 2020 that has raised something like $30 million across a Series A and a strategic investment, and it is not evidence that the product fails to do what it says. It is evidence that nobody outside the commercial relationship has checked, which changes how much weight the claims can carry in an argument, not whether the approach is sound. The approach is sound on its own reasoning: if the average security team genuinely uses a fraction of what it has already bought, then pointing existing controls better is obviously cheaper than buying more of them, and that conclusion does not depend on any of the percentages above being accurate.
The reason I labor this is that the claims and the mechanic fail differently. If the 80% figure is optimistic by half, the argument for threat-informed reallocation survives intact, because it was never resting on the number. If the prioritization weight turns out to be derived from the vendor's own product telemetry in a way that systematically favors findings its product can remediate, the mechanic itself is compromised and no amount of measured time-saving repairs it. The first is a marketing question and the second is an architecture question, and only one of them should change what you build. I have written before about what it takes for a vendor-run benchmark to be worth reading, and the same standard applies here.
Where this sits
Layers with different denominators, and priors worth naming.
None of the constituent ideas here are mine and it'd be poor form to imply otherwise. CIS has published prioritized baselines with Implementation Groups for years. Gartner named and defined the Automated Security Control Assessment category and placed it inside Continuous Threat Exposure Management. MITRE's Center for Threat-Informed Defense has been building maturity instruments for threat-informed defense since M3TID in 2024 and continues in INFORM. Google's SRE book supplied both the toil definition and the force-multiplier caution in 2016, and it did it better than the security industry has since. What I think is worth adding is narrower: the observation that the two tooling categories divide by different denominators, that this is what makes them layers rather than alternatives, and that the ranking weight is the place where a manageability program either earns its multiplier or quietly becomes a compliance percentage with better graphics.
The practical shape I would argue for is unremarkable and I think that is fine. Establish the intended state from a baseline you did not buy, scoped by Implementation Group so it is achievable. Read current state automatically and often enough that the backlog is a trend. Rank by what the gap bears on rather than by how many cells are red, and hold the ranking weight to the same evidence standard you would hold a detection claim to. Then measure yourself on coverage gained per analyst-hour, publish that rate internally alongside the conformance percentage, and watch which one your own program optimizes for when the two disagree.
Bottom line: manageability is a force multiplier in the strict sense, because it raises what a fixed number of analyst-hours can cover, and the whole value of it turns on aim rather than on throughput. A stack you can read, compare and change cheaply is worth more than a stack with more controls in it, and a backlog ranked by threat weight against a baseline somebody else maintains is worth more than the same backlog ranked by how far each asset sits from a standard nobody has asked whether you need. The related reading is the cross-tool assurance gap, which is the same problem seen from the detection side: no single tool knows your whole environment, and the interesting question is always how much of the truth the combined view recovers and what stays dark.
