Every year, organizations spend more money on cybersecurity than the year before. In 2025, global cybersecurity spending surpassed $215 billion, yet breaches continue to rise. Having watched this pattern repeat itself for more than two decades, Greg Anderson, CISSP, asks whether that spending, especially on activities such as penetration testing, is being used effectively?
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
Early in my career, I believed more testing meant more security. Now, I see I was wrong.
While working in governance, engineering, offensive security and advisory roles, I’ve seen penetration testing succeed technically, but fail strategically. Reports were thorough, findings were valid and vulnerabilities were patched. But, months later, similar structural weaknesses would surface again in different forms.
In one case, leadership felt confident after a strong annual test with minimal findings. Not long after, a real-world incidents exposed gaps the test hadn’t exercised. The issue wasn’t the absence of testing, but that the organization had never measured whether it could detect and contain activity outside the narrow scope of the engagement.
In another case, my well-resourced enterprise had invested heavily in tools and formal red team exercises. On paper, the program was mature. But, during a simulated incident, coordination broke down. The technical controls were capable, but the operational integration was not: offensive testing had never been fully connected to crisis management or decision-making processes.
Experiences like these led me to a difficult conclusion: penetration testing itself wasn’t broken, but our expectations of it were.
From Event to Capability
For most organizations, penetration testing is an event: scheduled annually, scoped narrowly and treated as validation for compliance. When the report is delivered, teams remediate the findings and move on.
But attackers don’t operate this way. They probe continuously, adapt and exploit process weaknesses as often as technical ones. I spent years seeing the same pattern play out again and again: organizations increasing the frequency of testing without increasing their maturity. More activity did not equal more resilience.
So, in my work, I started to reframe the purpose of offensive security. I believed that the question shouldn’t be “Did we pass the test?”, but “What did this test reveal about our ability to detect, respond and recover?”. My shift in thinking led me to develop my own model, which I call ARMOR; my own personal attempt to provide structure to that evolution.
Developing ARMOR
My model defines progressive levels of offensive maturity, from ad hoc validation to integrated resilience.
Initially, the focus is on establishing repeatability. At the earliest level, organizations often lack a clear picture of what they own and what has been tested. ARMOR starts there: I define asset inventory, establish consistent testing scope and build the discipline to track findings through to verified remediation. This sounds foundational because it is; without it, more frequent or sophisticated testing produces more findings without producing more security. The reports stack up but the structural weaknesses remain. Repeatability is not a low bar; it’s the prerequisite for everything that follows.
At the mid-levels of my model, ARMOR helps me introduce threat-informed planning and governance. My testing cadence is no longer driven by the calendar or the compliance schedule; it’s aligned with business change, new deployments and emerging threat patterns relevant to the organization's actual risk profile. Findings are analyzed not just for remediation, but for what they reveal about systemic weakness: where detection failed, where response was slow, where the same class of vulnerability keeps surfacing in different forms.
My metrics shift from counting vulnerabilities to measuring detection and response capability. This is where most organizations discover the gap between their technical controls and their operational readiness, and where governance structures, ownership of findings and executive visibility begin to matter as much as the testing itself.
At the highest levels, my red and purple teaming, crisis simulations and continuous validation are no longer separate programs. They are integrated directly into how the organization operates. My offensive exercises stress-test not just technical controls but decision-making processes, cross-functional coordination and incident response readiness under realistic conditions. Findings from these exercises inform executive decision-making: where we need to invest, what do we need to prioritize and can the organization absorb a real adversary operating at speed. The goal at this level is not to find vulnerabilities, but to validate that the organization has built the operational muscle to detect, respond and recover, and to continuously improve that capability based on evidence rather than assumption.
Since I didn’t know where I’d be applying it, my approach is designed intentionally to be vendor-agnostic; it works regardless of size, technology stack or service provider. What I’ve found matters most is disciplined practice.
It Really Matters
Resilience cannot be purchased. Many organizations invest heavily in tools but fail to practice coordinated response. Others with fewer resources outperform expectations because they build muscle memory through deliberate repetition. And security maturity is not about conducting more tests, it’s about integrating offensive insights into how our organizations operate every day.
If testing only produces a report, it has limited value. If testing changes how leaders make decisions, how teams detect anomalies and how the business prepares for disruption, it becomes transformative. The difference between being secure and being resilient is operational: one validates controls, the other validates capability.
After two decades in this field, I believe offensive security must evolve from periodic validation to continuous, measurable readiness. That belief is what shaped the ARMOR model that continues to guide my work today.
Greg Anderson, CISSP, has over 20 years of experience in cybersecurity spanning governance, offensive testing and advisory roles. He has held leadership positions across consulting, product and operational security functions, with responsibility for building offensive security programs and resilience strategy. His cybersecurity work spans enterprise risk management, red and purple teaming integration and maturity model development.
