How We Build a Security Stack for a New Client

A 30-person CPA firm and a 200-person manufacturer both need cybersecurity. They do not need the same cybersecurity. The tools we deploy, the monitoring we put in place, and the compliance controls we configure depend entirely on what the assessment reveals about each client’s environment, industry, regulatory exposure, and budget.

This is a companion to our earlier post on what we evaluate in the first week of onboarding a new client. That piece covers the assessment. This one covers what happens next: which security tools we deploy, why we pick different combinations for different clients, and where businesses most often end up over-invested or dangerously exposed.

The Assessment Comes First, Always

We don’t show up with a pre-built package and install it. Every engagement starts with a security risk assessment that maps the client’s infrastructure, cloud environment, identity configuration, backup posture, and compliance obligations. That assessment produces the decision framework for everything that follows.

Skipping the assessment and jumping straight to tool deployment is one of the most expensive mistakes an IT provider can make. We’ve onboarded clients paying for a SIEM platform they didn’t need while running endpoint protection that wasn’t actually functioning. Nobody had verified the tools were configured correctly, generating useful alerts, or being monitored.

The assessment tells us three things: what the client actually has today, what gaps exist relative to their risk profile, and what sequence of changes will close those gaps without disrupting operations.

SentinelOne EDR: The Baseline for Every Client

Regardless of size, industry, or budget, every client gets endpoint detection and response (EDR). We deploy SentinelOne across all endpoints and servers as a non-negotiable baseline.

Traditional antivirus compares files against a database of known threats. EDR uses behavioral analysis to detect threats that have never been cataloged, including fileless malware, living-off-the-land attacks, and ransomware variants that evade signature-based detection. In 2026, EDR is the minimum viable endpoint security.

But EDR alone is not enough. At-Bay’s 2026 InsurSec Report found that 60% of organizations hit by the Akira ransomware group had EDR deployed. The attacks still succeeded.

EDR watches individual machines, but it can’t correlate activity across your network, respond to alerts at 2 AM on a Saturday, or take containment action when nobody is watching the console. We covered this finding in detail in our analysis of VPN-based ransomware attacks and the At-Bay data.

EDR is the foundation. What we build on top of it depends on the client.

Managed SOC: The 3 AM Problem

The next layer for most clients is connecting their environment to our Security Operations Center (SOC) for 24/7 monitoring. SOC analysts receive alerts from EDR, firewalls, email security tools, and identity platforms, then investigate and respond in real time.

This is what the At-Bay data points to. Those Akira victims had EDR deployed. The attacks succeeded anyway because no one was acting on the alerts. EDR generates the alert. The SOC makes sure someone acts on it before the attacker has time to move laterally across the network, escalate privileges, and start encrypting systems.

Not every client needs the same level of SOC integration. A professional services firm with 40 employees, strong backups, and no regulatory compliance requirements might pair EDR with SOC monitoring and stop there. That combination provides solid detection and response capability without the cost and complexity of a full SIEM deployment.

For clients with mature backup and disaster recovery, including Veeam replication with immutable storage, the risk calculus is different. If a ransomware event occurs and the client can restore from clean backups within hours, the business impact of a successful attack is bounded in a way it isn’t for organizations without tested recovery capabilities.

The decision to add layers beyond EDR and SOC depends on what the assessment reveals about regulatory requirements, data sensitivity, and the client’s tolerance for residual risk.

SIEM and SOAR: When Compliance or Complexity Demands It

Security Information and Event Management (SIEM) platforms aggregate logs from firewalls, servers, cloud services, identity providers, and email systems, then correlate them to detect patterns that no single tool can see on its own. Security Orchestration, Automation, and Response (SOAR) adds automated playbooks that trigger containment actions when specific conditions are met.

We deploy SIEM for clients in two situations: when regulatory frameworks require centralized log retention and audit trails, or when the environment is complex enough that correlating events across multiple systems is the only way to detect sophisticated threats.

A healthcare practice subject to HIPAA needs to demonstrate that security events are logged, retained, and reviewed. A defense contractor pursuing CMMC certification has specific requirements around continuous monitoring and incident reporting. In both cases, SIEM isn’t optional. It’s a compliance control.

For clients outside regulated industries with straightforward environments, SIEM adds cost and complexity that doesn’t always translate to better protection.

A Real-World Example of Why This Matters

The consequences of getting the stack wrong aren’t theoretical. We took over IT for a CPA firm that had been hit by ransomware.

The previous provider had claimed the firm was running a SIEM. During incident response, it became clear that no functioning SIEM existed. Logs weren’t being collected. No one was monitoring alerts. The “SIEM” was a line item on an invoice, not an operational security control.

The ransomware encrypted client data, and the firm couldn’t determine definitively whether that data had been exfiltrated. A CPA firm holds tax records, Social Security numbers, and financial statements for hundreds of clients. The inability to answer “was client data stolen?” turned a bad situation into a catastrophic one.

When the firm filed a $250,000 cyber insurance claim, the insurer denied it. The policy required a functioning SIEM, and forensic evidence showed the firm didn’t have one despite claiming otherwise on their application. The firm was left with the full cost of recovery, client notification, legal liability, and reputational damage.

When we onboarded the firm, we deployed SentinelOne across all endpoints, connected the environment to our SOC for 24/7 monitoring, and implemented an actual SIEM with verified log collection and retention. Every tool was validated as operational, not just installed.

The distinction between “deployed” and “operational” is one most businesses never think to ask about until after a breach forces the question.

Two Patterns We See in Every Audit

Two patterns show up repeatedly when we assess environments built by previous providers.

The first is over-engineering. An SMB with 50 employees gets sold enterprise-grade tools designed for organizations ten times their size. The tools generate more alerts than anyone reviews and cost more than the client needs. The security posture isn’t better because the tools aren’t being used effectively.

The second is under-investing in detection. A client has a firewall and antivirus and assumes they’re covered. No EDR, no monitoring, no log collection. When something goes wrong, there’s no way to determine what happened or what data was affected.

Both mistakes come from the same root cause: building a security stack without first understanding the specific environment it needs to protect.

If you’re working with an IT provider today, these questions reveal whether your security stack was built from an assessment or a product catalog:

• Can your provider explain why you have each tool in your stack and what specific risk it addresses?
• Has anyone verified that every security tool is operational, not just installed?
• Do you know who monitors your security alerts outside business hours?
• If you’re in a regulated industry, can your provider map your current controls to specific compliance requirements?
• When was the last time your provider recommended removing a tool because you didn’t need it?

If you can’t answer these confidently, the stack may have been built for the provider’s margins rather than your risk profile.