The penetration testing landscape is changing fast. AI-assisted testing is compressing timelines. Continuous testing models are replacing annual point-in-time assessments. The volume and frequency of findings organizations receive are going up.
That's progress. But it's also pressure — on the teams receiving those findings, on the executives being asked to fund and support security programs, and on the operational infrastructure that has to absorb and act on what testing surfaces.
At Cobalt, we watched this challenge play out across our customer base for years. And earlier this year, we launched a formal response to it: the Security Program Manager — a senior practitioner embedded in customer accounts on retainer, sitting at the intersection of testing output and organizational response.
Not to run the tests. To make sure the program around the tests actually works.
Here's the problem we were solving.
The bottleneck was never the test
Organizations that struggle to get value from their pentesting programs aren't usually struggling because the testing is poor. They're struggling because the underlying program layer isn't built to handle what the testing produces.
Findings arrive. Ownership is unclear. Remediation stalls. Leadership sees metrics that don't tell a coherent story. And the security team — often small, often stretched — doesn't have the bandwidth to bridge the gap between what the test surfaced and what the organization needs to do about it.
That gap exists whether you're running a traditional human-led program, an AI-augmented model, or a hybrid of both. Testing methodology affects the volume and velocity of findings. It doesn't resolve the operational and governance questions that determine whether those findings actually reduce risk.
The metric problem that undermines good programs
There's a specific dynamic worth naming because it's easy to miss until you've seen it play out repeatedly.
When an organization improves its testing coverage — more frequent assessments, broader scope, better tooling — finding counts go up. That's the point. Better visibility surfaces more of what was already there.
But without executive context on why that's a sign of progress, leadership sees a dashboard that looks worse than before. More open findings. Higher severity counts. A backlog that didn't exist six months ago.
Programs get scrutinized at exactly the moment they're starting to work. Budgets get questioned. Security teams spend time defending the program instead of running it.
This is one of the core problems the Security Program Manager (SPM) role was designed to solve. Not by manipulating the metrics — by building the reporting framework and executive narrative before the numbers shift, so that when they do, leadership understands what they're looking at.
What good looks like with the right program support
A security program with dedicated program management looks different from one where the security team is managing everything themselves. Specifically:
Frictionless setup and execution is the baseline. As test volumes increase, the administrative weight of scheduling, scoping, and credentialing doesn't disappear — it compounds. Most security teams absorb that burden silently until it starts crowding out the work that actually matters. An SPM takes that operational load off the internal team entirely, so engineers are focused on managing risk and remediation rather than coordinating test logistics.
Executive alignment is established before it's needed. The hardest executive conversation isn't explaining a breach — it's explaining why your vulnerability count went up after you invested in better testing. An SPM owns that narrative proactively, translating complex technical findings into business risk language before the dashboard shifts and leadership starts asking the wrong questions.
Remediation governance is documented, not assumed. Most security teams know roughly who should own what. Roughly isn't good enough when findings are arriving faster, and the stakes of a missed SLA are higher. An SPM makes ownership explicit — who gets notified, by when, what the escalation path looks like — and the SPM follows up to ensure findings don't stall because accountability was fuzzy.
Reporting answers the question that actually matters. A list of open vulnerabilities isn't a risk story. Executives and boards need to know whether material risk is going down — not how many tickets are open. An SPM builds and maintains the reporting layer that answers that question consistently, across every level of the organization.
Why this matters more as AI enters the picture
The shift toward AI-assisted and continuous testing is a genuine improvement in how organizations can understand their security posture. More coverage. Faster feedback loops. The ability to pair automated discovery with human expertise on complex findings. These are meaningful advances.
But they increase the velocity of everything — including the operational and governance challenges that were already present. More findings, arriving faster, requiring faster triage, faster remediation decisions, and more frequent executive communication.
The organizations that will get real value from that capability are the ones with the program infrastructure to absorb it. The ones that have answered the governance questions. The ones whose leadership understands the metrics. The ones with someone accountable for making sure testing outcomes translate into risk reduction, not just report generation.
That's exactly why we launched the Security Program Manager function at Cobalt. And it's why I believe the demand for that kind of embedded, ongoing program support is only going to grow as the testing landscape continues to evolve.
The technology is moving fast. The program layer has to move with it.
