As CISOs in SMB and mid-market organizations, we’re constantly challenged to deliver security that enables the business, not just protects it. Budgets are finite, attack surfaces grow, and leadership needs us to translate technical controls into business value. That’s why tool assessments must start not with the tools themselves, but with how the business actually makes money.

Here’s a strategic approach we use at Legato Security when advising on stack evaluations. It reframes the process around business context, functional risk, and continuous alignment.

1. Identify and Define Revenue Streams

Before we talk firewalls, EDR, or any other tools, we need to understand what drives top-line revenue.

Key Activities:

  • Map primary revenue streams: key product sales, partner ecosystems, subscriptions, multi-year contracts, subscriptions. This will vary depending on your business type (B2B vs B2C vs DTC, etc.)
  • Prioritize by impact: If a system fails or is compromised, how much revenue is lost, and how quickly?

Considerations:

  • Are your revenue streams digital-first, partner-enabled, or compliance-sensitive?
  • What data (customer, operational, financial) supports them?
  • Who has access to that data, and from where?

This step reveals which systems are truly critical and which risks have direct financial implications.

2. Identify Supporting Systems

With revenue streams mapped, the next step is cataloging the ecosystem that supports them. These aren’t always “security systems,” but they must be secure.

Common Supporting Systems:

  • ERP & CRM: NetSuite, Salesforce,  often hold PII, contract data, and order flows.
  • Cloud environments: AWS, Azure, hosting everything from app workloads to customer portals.
  • CI/CD pipelines: In software organizations, these are the lifeblood of product delivery.
  • Billing & payment systems: Revenue’s point of truth, and prime targets.
  • Data brokers & APIs: Often overlooked, but central to platform integrations.

This inventory gives visibility into dependencies and integration points, and highlights where tool coverage needs to extend beyond traditional security zones.

3. Identify Required System Functionality (Risk Contextualization)

When we’re running an tech stack audit, we’re working to understand what those tools need to protect, and whether our current systems are up to the task.

Start by asking: What functionality is absolutely required to keep revenue operations intact, secure, and compliant? What does your environment already have in place, and what gaps are you trying to fill?

Context: Platform vs. Point Solution

Take identity and access management. You might already use a platform-based solution like Microsoft Entra (formerly Azure AD) for SSO, conditional access, and MFA. The question is: can you extend that platform to cover your privilege access needs as well or do you need to layer in a best-of-breed PAM tool?

Platform tools are great for consolidation, lower overhead, and integration efficiency but they may fall short on depth or granularity. On the flip side, best-of-breed tools bring specialized capabilities but often create friction with overlapping controls or disconnected workflows.

Understanding what the system must do today, and how that might change in six months,  allows you to make smart, scalable tooling decisions.

Approach:

  • Document critical functions: Transaction logging, identity validation, vendor/customer sync, data sourcing, etc.
  • Set performance expectations: Uptime, latency, scalability, automation coverage.
  • Map compliance obligations: PCI for payment processing, HIPAA for patient data, SOC 2 for trust and transparency — each has technical control implications.

Why It Matters:

Security tools should be evaluated in context of the business functions they enable and protect. If a control fails and disrupts authentication, billing syncs, or vendor access — that’s not just a technical glitch. That’s revenue lost, SLAs missed, or audit trails broken.

This is where risk becomes real: not as a theoretical CVSS score, but as an operational consequence with dollars, trust, and reputation at stake.

4. Identify Risks Associated with Those Functions

This is where we shift from functionality to threat modeling. If a system’s job is to protect sensitive data or maintain availability, what can go wrong? Who would want to make that happen?

Common Risk Categories:

  • Confidentiality: Data leaks, stolen credentials, insider theft.
  • Integrity: Tampered records, corrupted logs, malicious code commits.
  • Availability: DDoS, ransomware, cloud misconfigurations.
  • Compliance: Missed audit trails, poor access controls, expired certs.

Risk Evaluation Criteria:

  • Likelihood vs. impact: A useful lens for scoring and prioritizing.
  • Understanding loss events: Think beyond breaches. A corrupted database, a rogue contractor, or IP exfiltration can be just as damaging.
  • External vs. internal threats: Don’t neglect insiders. Malicious or careless employees remain a significant vector.
  • Single points of failure: What happens if one key tool or service goes down?

This exercise contextualizes each tool’s role in addressing real business risks.

5. Identify Tools, Technical Capabilities, and Their Purpose

Finally, we arrive at the stack itself. Now that we understand the business priorities, supporting systems, and functional risks, we can evaluate the toolset based on fit-for-purpose, not just on features or vendor promises.

Think of it like choosing between a hammer and a sledgehammer.

A hammer is versatile. It’s great for roofing nails, finish work, and everyday fixes. A sledgehammer, on the other hand, is built for driving fence posts, breaking concrete, or forcing large objects into place. Technically, you could drive a stake with a regular hammer, or tap a small nail with a sledgehammer but in both cases, you're either underpowered or using unnecessary force.

The same applies to security tooling:

  • Using a full-blown SIEM to solve a lightweight log aggregation problem is like using a sledgehammer for trim work — expensive, noisy, and difficult to finesse.
  • Using a lightweight vulnerability scanner in place of a full VM platform for cloud workloads is like trying to build a retaining wall with a basic claw hammer — it's not built for that scale.

Just because a tool can do something doesn't mean it’s the right tool to do it well, efficiently, or without unintended consequences. Overkill wastes budget and creates complexity. Underkill leaves gaps that quietly erode your risk posture.

The goal isn’t to find the fanciest or most powerful tools. It’s to ensure that each one is aligned to a specific, well-defined job in your environment, with the right scope, integrations, and maturity level to deliver value without friction.

Evaluation Areas:

  • Tool category: EDR, SIEM, DLP, CSPM, IAM, WAF. What buckets are covered?
  • Capabilities: Can tools detect, prevent, alert, and help us respond effectively?
  • Integration: Are they sharing data, or living in silos? Do they integrate with IT and DevOps tooling?
  • Coverage: Are high-value systems and data flows protected end-to-end?
  • Maturity: Are we using advanced capabilities, or just the out-of-the-box defaults?

Purpose Mapping:

Every tool should trace back to a business or technical goal:

  • Is this tool helping us maintain compliance?
  • Does it reduce downtime or detect threats faster?
  • Does it protect customer trust?

If a tool can’t be mapped to a meaningful business outcome, we recommend re-evaluting it’s place in your stack.

6. Circular Reassessment

The tools you chose last year may not fit this year’s threat landscape, tech stack, or business objectives. As your organization grows, enters new markets, adopts new platforms, or shifts strategy, your security stack needs to stay aligned. Reassessments become a regular discipline in the life of a security professional.  

Best Practices:

  • Reassess quarterly: New business units, vendor shifts, or compliance updates can rapidly change the picture.
  • Run incident retrospectives: Did the toolset do its job? Were alerts missed? Was response delayed?
  • Track metrics: MTTR, detection rate, false positives, user complaints, etc.
  • Engage stakeholders: Regularly align with Finance, Legal, Ops, and the Board. Translate risk posture into business language.

By keeping the loop tight, you avoid "set-it-and-forget-it" tools, while staying informed of tech performance as it relates to your business objectives.

Final Thoughts

Tool assessments are often driven by features, dashboards, and vendor pitches. But the best evaluations start from the top: revenue, risk, and real business functionality.

When you evaluate security through a business-aligned lens, you don’t just improve your defenses, you enhance trust, uptime, and the company’s ability to grow securely.

‍