Offensive security has become a deliberate program. Testing is no longer limited to traditional infrastructure, cloud, SaaS, APIs, and third-party integrations are in scope. Threat modeling is structured and formally tied to test planning. The organization is testing its real attack surface, not a compliance proxy of it. Remediation is governed by SLAs and security testing is integrated into how the organization manages change.
Outcomes
- ·A documented offensive security strategy exists, is reviewed annually, and is tied to organizational risk priorities
- ·Testing demonstrably covers on-premises infrastructure, cloud environments, SaaS platforms, APIs, and critical third-party integrations
- ·Threat modeling is formalized and used to drive scope and scenario selection before major initiatives
- ·Remediation is governed by formal SLAs defining timelines by severity, with compliance tracked
- ·Security testing is triggered not only by schedule but by significant business or technology changes
- ·Offensive security is formally embedded in change management and project approval workflows
Actions
- 01Develop and maintain a written offensive security strategy connecting testing activities to organizational risk objectives
- 02Formally expand testing scope to include cloud environments, SaaS platforms, APIs, and supply chain integrations
- 03Adopt a structured threat modeling methodology (STRIDE, PASTA, MITRE ATT&CK, or equivalent)
- 04Define remediation SLAs by severity tier and establish a formal escalation process for breaches
- 05Embed security testing requirements into change management, DevOps, and project approval processes
Sustainment Criteria
All criteria must be met to hold this level. If any criterion is unmet at reassessment, consider yourself at the previous level.
A documented and approved offensive security strategy is current and reviewed annually
Testing coverage demonstrably includes cloud, SaaS, and third-party environments with documented evidence
Remediation SLAs are defined, consistently applied, and tracked, SLA breaches are escalated
Security testing requirements are formally embedded in change management workflows
Threat modeling sessions occur before major initiatives and at least annually for core assets
Practitioner note
T3 is where scope expansion most commonly outpaces the organizational capacity to act on findings. Before expanding coverage further, confirm that SLA governance and remediation ownership are functioning. A broad testing program producing findings that sit unaddressed is not a T3 program, it is a T2 program with an overextended scope.
Moving to T4
Introduce red and purple team exercises, integrate threat intelligence into scenario design, begin collecting resilience metrics, and conduct structured tabletop exercises with cross-functional participants.
Corresponding Governance & Integration level
G3 Strategic
Organizations often develop these axes at different rates. Compare your position on both.