Key Takeaways:
Spending ≠ security: Growing cybersecurity budgets and impressive tool stacks don’t automatically reduce breach risk; without adversary-focused validation, you’re mainly buying optics and compliance comfort, not real protection.
Breaches follow contextual attack paths: Real intrusions usually succeed through credential abuse, trusted remote access, cloud/SaaS misconfigurations and business-process abuse—chains that generic controls and checkbox testing rarely capture.
Adversary-driven testing makes spend count: Human-led, realistic attack emulation is what turns security investments into measurable risk reduction by revealing paths to critical data and showing exactly where to focus future budget.
As cybersecurity budgets rise, many organizations assume that more tools, more licenses and more “best practices” will naturally lead to fewer breaches. Our CEO, Adriel Desautels recently published an article for Forbes Technology Council that challenges this assumption and explains why so much cybersecurity spending fails to deliver real protection. Read the full Forbes article to see why you can be fully “compliant,” heavily invested in security products, and still be one credential theft away from a serious data breach.
Organizations are spending more on cybersecurity than ever and still getting compromised. Budgets grow, new platforms are deployed and audit reports look clean, yet attackers keep finding reliable paths to sensitive data. If spend alone solved the problem, we wouldn’t keep seeing the same kinds of incidents year after year.
The core issue is misalignment. Most security investments are optimized for what is easy to justify and measure – controls, tools and compliance – rather than for how real adversaries actually operate in your environment. On the surface, the program looks mature. Underneath, it can still be dangerously fragile.
The Illusion Of Security
From an executive or board perspective, a typical security program often looks solid:
-
A substantial annual security budget
-
Leading EDR/XDR, SIEM and cloud security tools
-
Compliance certifications and clean audit findings
On paper, that signals seriousness. In practice, it often signals that the organization knows how to buy security, not that it has verified those investments against realistic attack paths.
Spend is frequently treated as a proxy for safety. But security is not linear, and not all spend is equal. Some projects measurably reduce breach likelihood or impact; others mostly improve optics and comfort.
Where The Money Really Goes
Most organizations don’t design their security programs from a blank slate. They inherit an existing stack, regulatory obligations and a list of “must-have” projects. Over time, money flows into a few predictable areas:
-
Controls required by auditors and regulators
-
Platforms that promise broad, generic coverage
-
Projects with simple metrics like patch rates or MFA adoption
These are not bad investments, but they are generic. They’re driven by best practices and compliance, not by the specific attack paths that matter most in your environment.
That’s why it’s possible to have leading tools deployed everywhere and still be compromised through stolen credentials, misused legitimate access or a misconfigured cloud service no one considered “critical.”
How Breaches Happen In Reality
If you look at real intrusions, the patterns are often:
-
Credential theft and abuse: phishing, token theft, password reuse and service principal abuse
-
Trusted remote access: VPNs, remote management tools and cloud consoles used as initial entry points
-
“Low-importance” internet-facing systems: dev or test assets used as footholds before pivoting inward
-
Cloud and SaaS misconfigurations: over-permissioned roles, weak conditional access, unmonitored admins
-
Business-process and integration abuse: exploiting how systems and workflows fit together, not just CVEs
These chains are highly contextual. They depend on the way your systems, identities and processes interact. A checklist or generic tool deployment rarely captures that nuance.
The Checkbox Problem
Compliance frameworks and industry standards are valuable, but many organizations end up optimizing for passing audits rather than blocking intrusions.
That creates predictable problems:
-
Success is defined as “we have control X” instead of “control X stops technique Y when we test it.”
-
Requirements evolve slowly, while attackers adapt quickly.
-
Certifications create a false sense of security that isn’t backed by deep adversarial testing.
Compliance should be a floor, not the ceiling. It proves you meet a baseline; it doesn’t prove a motivated attacker can’t reach your data.
When Testing Isn’t Truly Adversarial
On paper, regular security testing should surface the real risks. In practice, the way testing is scoped and executed often leaves major gaps:
-
“Pen tests” that are mostly automated scanning plus a report
-
Narrow scopes that exclude cloud control planes, identity, third parties or production SaaS
-
No clear attacker objective tied to real business impact
-
Time-boxed work that stops where a real adversary would keep going
You end up with plenty of findings, but limited insight into whether a realistic attacker can still reach your crown jewels.
Refocusing On The Attacker Mindset
To close the gap between spend and security, shift the core question from “Do we have the right tools?” to “Can a realistic attacker still get to what matters and how?”
That means:
-
Starting with the attack scenarios that are most plausible for your organization, rather than around a checklist of security controls
-
Using human-led adversary emulation to see how real attackers would target you
-
Following full attack chains from initial access to material business impact
-
Measuring security by outcomes (which attacks fail or succeed in testing), not by inventory (which tools you own)
Once you see how intrusions actually unfold in your environment, your budget decisions change. You can invest surgically in the controls, architecture changes and process improvements that directly cut off those paths, rather than spreading money evenly across every category.
Making Your Spend Count
Most organizations aren’t simply underfunded they’re under-validated. They buy the right-sounding tools and achieve the right certifications without enough evidence that those investments stand up to real adversarial behavior.
The fix is straightforward, if uncomfortable:
-
Be honest about how breaches are most likely to occur in your environment
-
Continuously test those scenarios with realistic, human-driven adversary emulation
-
Align future spending with the specific gaps these exercises reveal
When you do this, every dollar you spend stops being just another line item and becomes a targeted move against a known attack path. That’s the difference between a program that looks secure and one that is built to withstand how modern intrusions really work.
If you want to understand how an attacker would break into your organization – not just how your environment looks on paper – Netragard’s Real Time Dynamic Testing (RTDT) was built for exactly that. Our human-led, penetration testing and red teaming focuses on realistic attack chains, the same way real operators think and move, so you can see which paths to your critical data still work and which investments close them.
FAQ
If we already have leading security tools, why do we still need adversary-driven testing?
Tools show you what should happen; adversary-driven testing shows you what does happen under real attack conditions. Even the best tools can be misconfigured, bypassed or scoped too narrowly, and only realistic attack emulation reveals those gaps.
How often should we run realistic, human-led penetration tests or red team exercises?
For most organizations, at least annually is a minimum, with additional focused exercises after major architectural changes (like cloud migrations, M&A, or new remote access models). High-risk or highly targeted organizations often benefit from more frequent, scoped engagements throughout the year.
What’s the first step to making our security spend more effective?
Start by mapping out your most plausible breach scenarios – how attackers would actually try to reach your critical data – then test those scenarios directly. Use the results to reprioritize budget toward closing real attack paths instead of adding more generic tools or controls.
