All posts
Offensive Security

Penetration Testing Has a Strategy Problem

Most organizations treat penetration tests like oil changes: periodic, procedural, and disconnected from everything else. With regulators finally getting specific about what they expect, it's worth asking whether your testing program is delivering strategic value or just generating PDFs.

March 17, 20265 min readRobert Wood

Penetration Testing Has a Strategy Problem

Every year, thousands of organizations run a penetration test, file the report, fix whatever the auditor flags, and move on. The test happened. The box got checked. And almost nothing changed about the organization's actual security posture.

That's the problem. Not that pentests are bad. They're one of the most useful tools we have. The problem is that most organizations treat them like oil changes: periodic, procedural, and disconnected from everything else the security program is doing. In 2026, with a $3 billion global pentest market and regulators finally getting specific about what they expect, it's worth asking whether your testing program is delivering strategic value or just generating PDFs.

The Regulatory Floor Just Got Higher

For years, compliance frameworks gestured vaguely at "security testing" without saying much about what that meant in practice. That's changing fast.

CMMC 2.0 hits full enforcement in October 2026. Any defense contractor handling CUI needs certification pre-award, and Level 2 explicitly requires annual penetration testing mapped to NIST SP 800-171. PCI DSS 4.0 has tightened its requirements around testing cadence and post-change validation. You're not just testing annually anymore; you're testing after every significant infrastructure change. And the proposed HIPAA Security Rule updates, expected to finalize mid-2026, would mandate annual penetration testing for every covered entity and business associate handling ePHI. That's a first. HIPAA has required risk analyses for years but never specified the testing method.

Add NYDFS 23 NYCRR Part 500 for financial services, the EU Cyber Resilience Act for product manufacturers, and updated FISMA guidance for federal agencies, and the picture is clear: regulators are done being vague about penetration testing. They want it, they want it regularly, and they want evidence it actually tested something meaningful.

This is good news, if you use it right. The compliance requirement gives security leaders the mandate and budget justification to build a testing program that goes beyond checkbox exercises. The risk is treating the new requirements the same way we treated the old ones: doing the minimum and calling it done.

Five Shifts Worth Paying Attention To

AI Changed the Attacker's Timeline, and Testing Needs to Keep Up

A vulnerability introduced by a Tuesday deployment can be discovered and exploited by an AI-driven attack tool by Thursday. That's not hypothetical. It's the operational reality multi-agent AI frameworks have created. On the defensive side, tools like RapidPen are achieving shell access on targets in under seven minutes at less than a dollar per run.

The implication isn't that AI replaces human testers. Creative exploitation, business logic flaws, and chained attack paths still require people who understand context. But AI compresses the window between "vulnerability exists" and "vulnerability is exploited," which means annual testing cycles carry more residual risk than they used to. The organizations getting this right are using AI to handle volume and velocity (continuous scanning, pattern recognition across findings, exploitability-based prioritization) while focusing human testers on the problems that require judgment.

Cloud Environments Need Cloud-Native Testing

If your pentest partner's methodology still starts with "scan the network perimeter," you have a methodology problem. Modern environments are identity-driven, API-heavy, and ephemeral. Containers spin up and disappear. Serverless functions execute without a traditional host to scan. Multi-cloud architectures mean your attack surface spans AWS, Azure, GCP, and a dozen SaaS platforms, each with their own privilege models.

Effective cloud penetration testing evaluates misconfigurations and over-privileged service accounts across cloud providers, assesses container security from image vulnerabilities through orchestration weaknesses, and tests serverless functions and infrastructure-as-code deployments for security flaws. When selecting testing partners, look for demonstrable expertise in your specific cloud ecosystem. General IT security credentials don't cut it, and neither does a fixed, canned test scope. Effective strategy doesn't come in a box, and neither does an effective pentest.

The PTaaS Hype Curve Has Landed

Penetration Testing as a Service had its moment. The promise was compelling: on-demand testing, continuous visibility, real-time dashboards. The reality, for many organizations, hit the same ceiling that every bespoke security platform does. Nobody wants another dashboard to manage. Hundreds of conversations with CISOs over the past few years confirmed this dynamic over and over.

The delivery model that actually works in practice isn't the one wrapped in the slickest UI. It's the one that balances automation with human expertise and integrates findings into the workflows teams already use. The best programs use technology to scale routine testing while reserving experienced pentesters for complex scenarios, and critically, connecting findings to the broader security program rather than treating them as isolated reports.

Continuous Validation Is the New Baseline

The shift from point-in-time assessments to continuous security validation is the most consequential change in how testing programs operate. Automated scanners tuned for high-signal results, regression testing integrated into CI/CD pipelines, and breach-and-attack simulation tools that continuously validate security assumptions. These aren't aspirational anymore. They're table stakes for mature programs.

The strategic implication: when you do engage penetration testers, your scope should complement these automated layers. You're not paying humans to find what a scanner could have caught. You're paying them to find the risks that sit in the gaps between your automated tools. The business logic flaws. The chained attack paths. The assumptions your detection engineering hasn't tested yet.

Adversary Simulation Tests Your Program, Not Just Your Controls

Traditional vulnerability scanning identifies technical weaknesses. Adversary simulation tests whether your security program actually works: detection, response, containment, and recovery, not just whether a port is open or a patch is missing.

Red team operations emulating specific threat actors relevant to your industry. Social engineering assessments that test human vulnerabilities and the authentication flows people interact with. Purple team exercises that improve blue team detection capabilities in real time. Mapped to MITRE ATT&CK, these methodologies tell security leaders how their investments would perform against actual threats, not just theoretical ones.

From Compliance to Capability

The regulatory tailwinds are real. CMMC, PCI DSS 4.0, HIPAA, NYDFS. They all give security leaders the mandate to invest in testing that matters. The question is whether you use that mandate to build a compliance checkbox or a genuine security capability.

The organizations getting the most value from their testing programs in 2026 are the ones that plan with strategic intent, select partners and methodologies aligned to their actual threat landscape, and treat pentest findings as inputs to a broader security program rather than standalone deliverables. The goal isn't to pass the next audit. It's to build resilience against the threats that actually matter to your organization.

Ready to strengthen your security posture?

Let's discuss how Sidekick Security can help protect your organization.

Schedule a Consultation