Security Capability Model
What an organisation must be able to do — independent of technologies, products, or controls.
The OSA Security Capability Model organises everything an organisation must be able to do in cybersecurity into three phases: Foundation (governance, people, supply chain), Protect (the seven asset classes to secure), and Operate (detection, response, continuity). Each capability area breaks down into strategic capabilities (L1) and architectural sub-capabilities (L2), grounded in the OSA pattern catalogue.
Click any pattern badge to explore its details
Download SVG
Foundation
What must exist before anything else can work — governance, people, and supply chain
CA-01 Governance, Risk & Compliance
Define, govern, measure and continuously improve the organisation's security posture in alignment with business strategy and regulatory obligations.
L1 Clear Security Rules That Everyone Knows How to Follow
- • Security Policy Hierarchy
- • Standards & Procedures Lifecycle
- • Exception & Waiver Management
- • Regulatory Requirements Translation
L1 Risk Decisions Grounded in Evidence, Not Gut Feel
- • Enterprise Risk Taxonomy & Register
- • Risk Treatment & Acceptance
- • Risk Appetite & Tolerance Definition
- • Control Effectiveness Assessment
L1 Audit Readiness Built In, Not Bolted On
CA-02 Human & Organisational Security
Reduce the human-layer attack surface through awareness, cultural embedding, and insider threat management — recognising that people are simultaneously the greatest risk and the most important security asset.
L1 Staff Who Know How to Spot and Respond to Threats
L1 Security as a Shared Habit, Not Just a Team's Responsibility
- • Security Champion Network
- • Security Culture Maturity Measurement
- • Developer Security Enablement
- • Security Feedback & Recognition
L1 Detecting When Trusted People Become a Risk
- • Insider Threat Policy & Programme
- • Behavioural Analytics (UEBA)
- • DLP-UEBA Correlation
- • Investigation & Response Procedures
L1 Collaboration Tools That Don't Become a Leakage Channel
- • Secure Collaboration Platform Controls SP-021
- • External Sharing Governance
- • Information Barrier Enforcement
- • Meeting & Channel Security
CA-03 Supply Chain & Third-Party Risk
Identify, assess, and continuously monitor the security posture of third parties, vendors, and software dependencies — preventing the extended enterprise from becoming an uncontrolled attack surface.
L1 Suppliers Assessed for Security Before and After Onboarding
- • Vendor Risk Tiering & Assessment SP-042
- • Continuous Vendor Security Monitoring
- • Contractual Security Requirements & Baseline
- • Right-to-Audit & Evidence Collection
L1 Every Software Component Tracked and Checked for Known Weaknesses
- • Software Bill of Materials (SBOM)
- • Open-Source Dependency Governance
- • Dependency Vulnerability Tracking (SCA)
- • Artefact Signing & Approved Registry
L1 External Access That Expires and Leaves a Full Record
- • Vendor Access Provisioning & Governance
- • Time-Limited & JIT Third-Party Access
- • Third-Party Session Recording
- • Segregated Network Access for Vendors
L1 Understanding Which Suppliers You Cannot Afford to Lose
- • Critical Supplier Identification & Mapping
- • Concentration Risk Assessment
- • Alternative Supplier Planning
- • Supply Chain Incident Response
Protect
The seven asset classes to secure, ordered by ZTA pillar and extended with AI-specific governance
CA-04 Identity & Access Management
Establish, govern, and continuously verify the identity of every user, service, and machine — enforcing least-privilege access across all resources.
L1 Secure Sign-In That Needs No IT Support
L1 The Right Access for the Right Job
L1 Admin Access That Expires When the Task Is Done
L1 Every System Has Its Own Secure Identity
- • Service Account Governance
- • PKI & Certificate Lifecycle Management
- • Workload Identity Federation (SPIFFE/SPIRE)
- • Secrets & Dynamic Credential Management
CA-05 Device & Endpoint Trust
Assess, enforce, and continuously verify the security posture of every endpoint — managed and unmanaged — as a prerequisite for resource access.
L1 Every Device Configured Correctly and Kept Up to Date
L1 Active Defences on Every Device That Catch What Antivirus Misses
- • Endpoint Detection & Response (EDR/XDR)
- • Anti-Malware & Behavioural Detection
- • Application Allowlisting
- • Full-Disk Encryption & Hardware Security (TPM/Secure Boot)
L1 Personal Devices That Can Safely Access Company Tools
L1 Only Healthy Devices Are Allowed to Connect
- • Device Posture Evaluation
- • Compliance-Gated Access (ZTNA Integration)
- • Hardware Root of Trust
- • Continuous Compliance Monitoring
CA-06 Network & Infrastructure Security
Segment, protect, and monitor network infrastructure — replacing perimeter-centric models with dynamic, policy-driven access based on identity and context.
L1 Access That Checks Who You Are, Not Where You Are
L1 Walls Inside the Network That Contain a Breach
L1 Filters and Guards That Block Harmful Traffic
- • Next-Generation Firewall & IPS
- • Network Detection & Response (NDR)
- • DNS Security (Protective DNS, DNSSEC)
- • DDoS Protection
L1 Industrial Systems Kept Separate From Office Networks
- • OT Network Isolation SP-023
- • Purdue Model Segmentation
- • Unidirectional Gateway Architecture
- • OT Asset Visibility & Inventory
CA-07 Application & API Security
Design, build, and operate applications and APIs with security embedded throughout the software delivery lifecycle — treating code, dependencies, and runtime as the attack surface.
L1 Security Built Into Software Before It Ships
- • Secure SDLC Policy & Phase Gates SP-012
- • Threat Modelling
- • Security Architecture Review
- • Developer Security Enablement
L1 Applications Tested for Weaknesses Before They Reach Customers
L1 APIs That Only Do What They Are Supposed To Do
CA-08 Data & Information Protection
Classify, protect, and govern data throughout its entire lifecycle — at rest, in transit, in use, and in shared contexts — including future-proof cryptographic resilience.
L1 Knowing What Data You Hold and How Sensitive It Is
- • Data Classification Framework SP-013
- • Data Discovery & Inventory
- • Retention, Backup Classification & Disposal Policy
- • Privacy by Design
L1 Sensitive Data Cannot Leave Without Authorisation
- • Endpoint DLP
- • Network DLP
- • Cloud DLP
- • Information Rights Management (IRM/DRM)
L1 Data Protected by Encryption Throughout Its Lifecycle
CA-09 Cloud & Platform Security
Secure cloud infrastructure, workloads, and platform services across multi-cloud and hybrid environments — enforcing the shared responsibility model and preventing cloud-native misconfiguration.
L1 Cloud Settings Checked Continuously for Dangerous Misconfigurations
- • Cloud Security Posture Management (CSPM)
- • Infrastructure-as-Code Security Scanning SP-028
- • Compliance Benchmark Enforcement (CIS, NIST)
- • Cloud Drift Detection & Automated Remediation
L1 Servers and Containers Protected While They Run
L1 Cloud Access Rights That Don't Accumulate Unchecked
- • Cloud IAM Governance
- • Cloud Infrastructure Entitlement Management (CIEM)
- • SaaS Security Posture Management (SSPM)
- • Cross-Cloud Identity Federation
L1 Cloud Infrastructure Designed to Be Secure by Default
- • VPC Design & Private Endpoints
- • Cloud-Native Firewall & Security Groups
- • Cloud Key Management & Encryption
- • Cloud Storage Security & Cross-Region Backup Replication
CA-10 AI & Agentic Security
Govern, secure, and assure AI systems and autonomous agents — addressing AI-specific attack surfaces, model integrity, and the novel trust and control challenges introduced by agentic architectures.
L1 Every AI System Assessed and Approved Before It Goes Live
- • AI Model Inventory & Risk Classification SP-045
- • AI Use Case Assessment & Approval
- • Responsible AI — Bias, Fairness, Explainability
- • AI Regulatory Compliance (EU AI Act, NIST AI RMF)
L1 Protecting AI Systems From Being Manipulated or Misused
- • Prompt Injection Detection & Filtering SP-027
- • AI Input/Output Monitoring
- • Model Access Controls & Authorisation
- • AI Audit Logging & Traceability
L1 Keeping Autonomous AI Within Strict Boundaries
L1 AI Models From Trusted Sources, Tested Before Deployment
- • Model Provenance & Signing
- • Approved Model Registry
- • Training Data Governance
- • AI Red Teaming & Adversarial Testing
Operate
Continuous detection, response, continuity, and resilience
CA-11 Threat Detection & Security Operations
Continuously monitor the entire attack surface, detect adversarial activity early, and operate a coordinated security operations function — intelligence-led and MITRE ATT&CK-aligned.
L1 Suspicious Activity Spotted Early Across Every System
L1 Knowing Which Threats Are Headed Your Way and How They Work
- • Threat Intelligence Platform (TIP)
- • Strategic & Tactical Intelligence Consumption
- • Indicator of Compromise (IOC) Management
- • ATT&CK-Aligned TTP Tracking
L1 Continuously Testing Whether Defences Actually Detect Attacks
- • Detection-as-Code & Rule Development
- • MITRE ATT&CK Coverage Mapping
- • Threat Hunting
- • Breach & Attack Simulation (BAS)
CA-12 Incident Response & Business Continuity
Prepare for, detect, contain, eradicate, and recover from security incidents — maintaining business continuity under adversarial conditions and enabling organisational learning.
L1 A Practised Plan for When Things Go Wrong
- • IR Plan & Playbook Library SP-036
- • Incident Detection, Triage & Classification
- • Containment & Eradication Procedures
- • Digital Forensics & Evidence Preservation (DFIR)
L1 The Right Message Reaches the Right People During a Crisis
- • Crisis Management & War-Room Coordination
- • Regulatory Notification & Reporting
- • Internal Stakeholder Communication
- • External & Media Management
L1 Critical Operations Keep Running When Systems Are Disrupted
- • Business Impact Analysis (BIA)
- • Business Continuity Planning & Failover
- • RTO/RPO Definition & Testing
- • Tabletop Exercises & Simulations SP-034
L1 Every Incident Leaves the Organisation Stronger
- • Post-Incident Review (PIR) & Root Cause Analysis
- • Lessons-Learned Integration & Control Improvement
- • Resilience Metrics & Recovery Assurance
- • Continuous Improvement Feedback Loop
CA-13 IT Service Continuity & Recovery
Ensure critical IT services can continue or be restored within agreed timeframes after disruption — from planned failover through to recovery under destructive adversarial conditions — with architecturally enforced backup protections that prevent data loss.
L1 Defined HA Architecture Tiers Matched to Service Level Classes
- • Service Criticality Tiering & Classification Framework
- • Reference HA Architecture per Tier (active-active, active-passive, warm standby, backup-only)
- • Service-to-Tier Assignment, Gap Analysis & Compliance Monitoring
L1 IT Services Mapped, Prioritised and Designed to Fail Over
- • IT Service Dependency Mapping & Critical Service Identification
- • Failover Architecture Design per Assigned Tier
- • Service Recovery Prioritisation & Sequencing
L1 Backup Architecture That Attackers Cannot Reach or Destroy
- • Immutable Backup Storage (WORM / append-only)
- • Air-Gapped & Offline Vault
- • Backup Encryption & Key Segregation
L1 Recovery Tested, Proven and Executable Under Adversarial Conditions
- • Backup Coverage & Gap Analysis
- • Automated Integrity Verification & Monitoring
- • Clean-Room / Isolated Restore Environment
- • Tiered Recovery Prioritisation (crown jewels first)
- • Recovery Drill, DR Orchestration & Automation
- • Ransomware Recovery Runbook & Decision Tree
Cross-Cutting Analysis
NIST ZTA Pillar Coverage
| ZTA Pillar | Capability Areas |
|---|---|
| Identity | CA-04 Identity & Access Management |
| Devices | CA-05 Device & Endpoint Trust |
| Networks | CA-06 Network & Infrastructure Security |
| Applications | CA-07 Application & API Security |
| Data | CA-08 Data & Information Protection |
| Infrastructure | CA-09 Cloud & Platform Security , CA-13 IT Service Continuity & Recovery |
| Visibility & Analytics | CA-11 Threat Detection & Security Operations |
| Automation & Orchestration | CA-12 Incident Response & Business Continuity |
| Cross-cutting | CA-01 Governance, Risk & Compliance , CA-02 Human & Organisational Security , CA-03 Supply Chain & Third-Party Risk |
| Cross-cutting (emerging) | CA-10 AI & Agentic Security |
OSA Pattern Density
46 unique patterns referenced across 49 mappings. Capability areas sorted by pattern count.
| CA | Capability Area | Patterns | # |
|---|---|---|---|
| CA-07 | Application & API Security | SP-004 , SP-005 , SP-008 , SP-012 , SP-028 , SP-030 , SP-041 | 7 |
| CA-04 | Identity & Access Management | SP-010 , SP-032 , SP-033 , SP-037 , SP-044 | 5 |
| CA-05 | Device & Endpoint Trust | SP-001 , SP-003 , SP-006 , SP-007 , SP-024 | 5 |
| CA-06 | Network & Infrastructure Security | SP-015 , SP-016 , SP-017 , SP-023 , SP-029 | 5 |
| CA-08 | Data & Information Protection | SP-013 , SP-019 , SP-020 , SP-039 , SP-040 | 5 |
| CA-11 | Threat Detection & Security Operations | SP-025 , SP-031 , SP-035 , SP-038 , SP-046 | 5 |
| CA-01 | Governance, Risk & Compliance | SP-018 , SP-022 , SP-026 , SP-043 | 4 |
| CA-02 | Human & Organisational Security | SP-014 , SP-021 , SP-022 | 3 |
| CA-09 | Cloud & Platform Security | SP-002 , SP-011 , SP-028 | 3 |
| CA-10 | AI & Agentic Security | SP-027 , SP-045 , SP-047 | 3 |
| CA-12 | Incident Response & Business Continuity | SP-034 , SP-036 | 2 |
| CA-03 | Supply Chain & Third-Party Risk | SP-042 | 1 |
| CA-13 | IT Service Continuity & Recovery | SP-034 | 1 |
Coverage Notes
- • Physical security (facilities, access control, environmental) is not modelled as a standalone capability area. Physical controls appear as implementation details within CA-06 (OT isolation) and CA-05 (hardware root of trust).
- • Privacy is embedded across CA-01 (regulatory compliance), CA-08 (data protection), and CA-10 (responsible AI) rather than isolated as a separate domain. A dedicated privacy capability area may be warranted as regulations expand.
- • Blockchain and DLT security (SP-051 to SP-054) is not yet mapped into the capability model. These patterns post-date the current model version and will be integrated in a future revision.
What is a Capability Model?
A capability model describes what an organisation must be able to do — independent of the technologies, products, or controls used to do it. Each named capability is an organisational ability: a persistent competence that can be built, measured, and matured over time.
Capabilities are intentionally business-readable. They do not prescribe tooling or implementation choices; they describe outcomes. This makes them stable across technology generations and useful at every level of the organisation — from board-level risk conversations to architectural procurement decisions.
How It Relates to a Control Framework
The two are complementary but distinct. A capability model defines the functional abilities the organisation must possess — what must we be able to do? A control framework defines the specific safeguards — what must we put in place?
| Step | Question | Example |
|---|---|---|
| The capability | What must the organisation be able to do? | Identity Lifecycle Management |
| The control | What safeguard is required within it? | NIST AC-2: Manage accounts |
| The technology | What category of tool delivers it? | Identity Governance platform |
| The product | What do you buy or build? | Okta, SailPoint, Azure AD |
Design Alignments
| Input | Contribution |
|---|---|
| NIST SP 800-207 / CISA ZTA pillars | Defines what must be secured — six ZTA pillars plus Visibility & Analytics and Automation & Orchestration |
| NIST CSF 2.0 | Defines how security operates as a lifecycle — Govern, Identify, Protect, Detect, Respond, Recover |
| OSA pattern catalogue | Grounds each capability in proven, implementable patterns — the implementation evidence base |
Layer Definitions
Each capability area contains two levels of named capability, mirroring SABSA's top two conceptual tiers. A third layer (L3 — logical services and tools) is deferred to the OSA pattern catalogue.
| Layer | SABSA Equivalent | Role | Count |
|---|---|---|---|
| L1 — Strategic | Contextual (Business) | Named business capability — what the organisation must be able to do | 3–4 per CA |
| L2 — Architectural | Conceptual (Architect) | Named sub-capability — the logical domain through which L1 is realised | 2–6 per L1 |