Methodology · Pillar

You Already Own the Fix

The CAN vs. IS gap in security tools. By Arien Seghetti · April 2026.

Most organizations use 30–50% of what their security tools can do. The rest sits unused, not because the capability is missing, but because the deployment is partial. Comparing what tools can do with what they are doing surfaces gaps closable without new spend — the fastest measurable ROI in any security rationalization effort.

The claim

Every enterprise security engagement I've run for the past decade surfaces the same pattern. The organization bought a tool for a specific reason — a ransomware scare, a compliance audit, a new threat the CISO saw at a conference. They deployed it for the use case that drove the purchase. Then the project closed, the team rotated, and the tool sat doing 30–50% of what it was capable of doing.

When the next budget cycle comes around and someone asks "do we need new detection?" — the honest answer is often no, we need to finish deploying what we bought three years ago. Nobody says that because nobody can see it. The tools are buried in different consoles, the licenses are enterprise-wide but the deployment manifests are project-scoped, and the person who understood the full feature set left for another company in 2024.

"You Already Own the Fix" is the observation that you can surface this pattern systematically if you have the right framework, and that when you do, the results are consistent: 35–60% of identified gaps close without new spend.

The CAN vs. IS distinction

The methodology rests on two layers rendered against the same Cyber Defense Matrix 2.0 grid.

Capability layer

CAN

What a tool is capable of doing — sourced from the vendor database, reflecting marketing claims validated against field deployment. If you own Vendor X's endpoint platform, the CAN layer shows every cell that platform can cover under its license terms.

Deployment layer

IS

What the tool is actually doing in this organization, captured during the questionnaire. IS coverage requires three things: the tool is deployed to the asset row in question, it is actively licensed, and the capability is turned on (not just "enabled on paper").

The gap between the two — cells green on CAN, red or amber on IS — is the set of recommendations you can close without procurement. That's where "Do This Now" blocks come from.

Why under-utilization happens

Four patterns recur across organizations of every size. Most stacks show all four simultaneously.

1. Project-scoped deployment

Tools are deployed for the use case that drove the purchase. A DLP platform bought to stop the next data breach gets deployed on Data but never on Users, even though the same platform covers both. The project closed, the deployment team demobilized, the capability sits dormant.

2. Knowledge decay

The person who understood the tool's full feature surface moved to another role or another company. Their successor operates the subset that's running and assumes that's the whole product. Vendor enablement sessions are rarely re-delivered for successors; the knowledge loss is silent.

3. Quiet vendor upgrades

The vendor ships a new capability in a minor release. The upgrade runs through automation. The feature is shipped but not enabled. Release notes are scanned for breaking changes, not new value. Two years later the feature still hasn't been turned on — in a customer who's actively considering buying a separate tool for exactly that capability.

4. Licensing mismatched to deployment

The license is enterprise-wide; the rollout was scoped to the laptop refresh project. The platform can cover servers, VMs, and cloud workloads under the existing license, but nobody went back to expand scope. The invoice is the same regardless — the organization is paying for all of it either way.

How to find your own fix

The process is simple to describe and tedious to do by hand. It's why we built a platform for it.

  1. Inventory the tools you own. Vendor, product, license type, environments under contract. Not what's deployed — what's licensed.
  2. Map capabilities to the CDM 2.0 grid. For each tool, identify which of the 63 cells the product can cover. The SecurityStack vendor database does this from the product name; doing it by hand requires reading every data sheet.
  3. Capture actual deployment, not intended deployment. "We have CrowdStrike on laptops" is deployment. "We plan to roll it out to servers" is not. The matrix rejects wishful thinking.
  4. Diff the two layers. Every cell green on CAN and red/amber on IS is a candidate fix. Sort by the severity of the underlying gap — RESPOND gaps get priority over NICE-to-have PROTECT extensions.
  5. Validate the license. Before promising the fix, confirm the license actually covers the extension. A common trap: the license allows 500 endpoints; extending to 2,000 triggers a true-up. The fix is still cheap but it's not free.
  6. Schedule the work. Most fixes are 1–4 weeks of focused configuration, not months of procurement. Treat them as operational projects, not capital ones.

What this approach won't fix

After the "You Already Own the Fix" pass, real gaps remain. They tend to cluster in three places:

  • ANTICIPATE capabilities. Threat intelligence, attack surface management, and threat exposure management are rarely bundled into existing platforms. Most stacks have no coverage here and closing the gap requires a new vendor.
  • Specialized RESPOND tooling. SOAR, forensics platforms, and IR retainers exist as standalone categories. Existing XDR suites partially cover them but the specialized vendors remain the market leaders.
  • Emerging asset rows. Coverage for AI/ML and OT/IoT is thin in most established security product lines. If your assessment shows gaps there, closing them usually requires a purchase.

The value of the pass isn't that it eliminates new purchases. It's that it makes the remaining purchase conversations clean — unmixed with gaps that didn't need a purchase at all. Procurement becomes shorter and more defensible.

A concrete example

A mid-market organization with ~35 security tools ran the assessment. Headline findings:

  • Overall coverage: 58% on IS, 76% on CAN. Gap: 18 percentage points of coverage available without any new purchase.
  • Biggest fix: existing endpoint platform licensed enterprise-wide but only deployed on laptops. Extending to servers and VMs closed 6 of 11 open DETECT cells.
  • Second fix: DLP platform configured for Data row but never enabled on email. Two configuration changes closed PROTECT × Applications and PROTECT × Users.
  • Remaining real purchases: two — attack surface management (ANTICIPATE) and a specialized OT monitoring tool. These went into the 90-day plan with defensible justifications.

How SecurityStack operationalizes it

The insight only matters if it produces a report someone can act on. SecurityStack surfaces "You Already Own the Fix" recommendations three ways:

  1. A dedicated callout block in the gap analysis view, separating closable-without-spend gaps from gaps that require a purchase.
  2. "Do This Now" recommendation blocks in the AI-generated executive report, each naming the specific tool the recommendation leverages.
  3. A 30/60/90 day roadmap in the PDF export — 30 days for configuration-only fixes, 60 for fixes that need a license true-up, 90 for the remaining real purchases.

Frequently asked questions

What does 'You Already Own the Fix' mean?

Most organizations use only 30–50% of the capabilities in the security tools they've already purchased. By comparing what a tool CAN do (its capability surface) with what it IS doing (its actual deployment), you surface gaps that can be closed by configuring or extending tools you already own — no new purchases, no new procurement cycles, no new vendors to manage. The phrase was coined by Arien Seghetti after repeatedly finding this pattern across $50K–$150K consulting engagements.

How is this different from tools rationalization?

Traditional tools rationalization is consolidation-first — inventory, find overlap, retire redundant tools. 'You Already Own the Fix' is coverage-first — inventory, find gaps, close them with tools you already have before considering any new purchase or consolidation. It's the step that most consulting engagements skip because it takes longer than the audit itself.

Why do organizations under-utilize the tools they own?

Four patterns recur: (1) tools are deployed for the use case that drove the original purchase and never extended; (2) the team that deployed the tool left or rotated off, and institutional knowledge of its full capability went with them; (3) newer features were added by the vendor but never enabled because the upgrade ran on autopilot; (4) the product was licensed for one environment (for example, Devices) but never rolled out to others (Cloud, OT/IoT) even though the license covered them.

How do you measure the CAN vs. IS gap?

Against the Cyber Defense Matrix 2.0 grid. For each of the 63 cells (7 functions × 9 asset rows), the CAN view marks cells where at least one tool you own is capable of providing coverage. The IS view marks cells where a tool is actually deployed and active. The difference — cells green on CAN, red or amber on IS — is the set of gaps closable without new spend.

What's an example of a tool you already own covering a gap?

An endpoint protection platform licensed enterprise-wide but deployed only on laptops. The same platform can be extended to servers, containers, and (depending on vendor) cloud workloads at no additional license cost — closing DETECT × Cloud and DETECT × Applications without a new purchase. The gap existed because the original rollout targeted the 'laptop refresh' project, and nobody went back to extend it.

Can this replace new tool purchases entirely?

No. After the 'You Already Own the Fix' pass, real gaps remain — usually in ANTICIPATE (threat intel, attack surface management), specialized RESPOND capabilities, or emerging asset classes like AI/ML. The value is that those remaining gaps are the actual purchase decisions, unmixed with gaps that didn't need purchases at all. Procurement conversations become shorter and more defensible.

How does SecurityStack surface 'You Already Own the Fix' recommendations?

After the questionnaire completes, the engine compares the CAN and IS layers cell by cell and generates 'Do This Now' blocks for each closable gap. These always precede any new-purchase recommendation. The PDF report groups them into a 30/60/90 day roadmap so the organization can close quick wins first and schedule the heavier configuration work.

Isn't this just 'use what you have' — why does it need a methodology?

Because 'use what you have' without a framework devolves into feature-checklist exercises that miss the structural gaps. The CDM 2.0 matrix gives the comparison a rigorous shape: you can SEE which cells are closable because a specific tool covers them on the CAN layer. Without the matrix, 'use what you have' is a slogan. With the matrix, it's a process.

What percentage of an average stack is actually closable this way?

Across the engagements that informed this methodology, the typical range was 35–60% of identified gaps closable without new spend. The exact number depends on vendor mix, license type, and how recently the stack was purchased. Organizations that bought enterprise-wide licenses tend to have the most un-redeemed capability; organizations that bought per-use-case tend to have less.

Try it

Find your own "Do This Now" list in 30 minutes

Add your tools, answer the questionnaire, and see which gaps you can close with what you already own. Free tier available.