Topics in this domain
- The Security Program: Charter, Scope and Objectives
- Security Team Structure, Roles and Staffing
- Working with Legal, HR, IT, Audit and the Business
- Program Implementation: From Plan to Operating Controls
- Information Asset Identification and Valuation
- Data Classification: Owners, Custodians and Users
- Data Lifecycle: Retention, Archiving and Secure Disposal
- Enterprise Architecture for Security Managers
- Information Security Architecture: Principles and SABSA
- Defence in Depth and Zero Trust
- Cloud Security and Shared Responsibility
- Control Frameworks: NIST SP 800-53, CIS Controls and ISO 27002
- Security Policy Development and Lifecycle
- Security Standards and Baseline Requirements
- Procedures, Guidelines and Acceptable Use
- Policy Enforcement, Exceptions and Review
- Designing Security Metrics: KPIs, KRIs and KCIs
- Collecting, Analysing and Reporting Metrics
- Security Maturity Models and Program Assessment
- Control Types and Categories
- Control Design and Selection Based on Risk and Cost
- Control Testing: Design vs Operating Effectiveness
- Identity and Access Management
- Network and Endpoint Security Controls
- Application Security and the Secure SDLC
- Configuration, Change and Patch Management
- Cryptography for Security Managers
- Security Testing: Scanning, Pen Testing and Tracking Remediation
- Security Awareness Program Design
- Role-Based Security Training
- Phishing Simulations and Social Engineering Defences
- Third-Party Risk Management and Due Diligence
- Vendor Contracts, SLAs and Right to Audit
- Fourth-Party and Supply Chain Risk
- Outsourcing and Managed Security Services
- Security Stakeholder Communication
- Executive Dashboards and Board Reporting
- Continuous Improvement of the Security Program
Security Maturity Models and Program Assessment
How well run is the program?
Two organisations can both “have” incident response. In one, it depends on whoever is on shift. In the other, it’s documented, practised, measured and improved. Maturity models put a number on that difference, giving a common language for the current state, the target and progress between them.
The levels
| Level | Name | What it means |
|---|---|---|
| 1 | Initial | Ad hoc; depends on individuals |
| 2 | Managed | Planned and tracked, team by team |
| 3 | Defined | One standard process across the organisation |
| 4 | Quantitatively managed | Measured and controlled with data |
| 5 | Optimising | Continuously improved |
COBIT 2019 rates process capability from 0 (incomplete) to 5 on a similar scale. NIST CSF uses implementation tiers 1 to 4 (partial, risk informed, repeatable, adaptive).
Current vs target, area by area
Targets are set per capability area, by business need and risk. A bank may need level 4 identity management but only level 2 for some low-risk processes. Recommending level 5 everywhere ignores cost and need. The gaps between current and target become roadmap initiatives, which ties maturity directly to the security strategy in Domain 1.
Running an assessment
- Choose the model and capability areas (COBIT, CMMI, NIST CSF tiers, or a sector model such as C2M2).
- Gather evidence: documents, interviews, records, tests.
- Rate each area consistently, with evidence for every rating.
- Agree targets with the business, based on risk.
- Turn gaps into roadmap initiatives and reassess yearly.
Example. A self-assessment rates incident response at level 4. An external review finds no metrics and an untested plan: level 2. The roadmap is reset, and the board gets a more honest view of readiness.
Other program assessments
- NIST CSF profiles: current against target outcomes.
- ISO 27001 audits: internal and certification audits of the ISMS.
- Benchmarks: comparison with peers and industry surveys.
- Independent review: internal audit or consultants validating self-assessments.
Maturity shows process discipline. It doesn’t prove that every individual control works; that needs control testing.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Level with standard organisation-wide processes | Level 3: defined |
| How to set target maturity | By business need and risk, area by area |
| Main use of a maturity assessment | Define the current state and gaps for the strategy |
| Self-assessed maturity seems too high | Validate with evidence or independent review |
| Does maturity prove controls work? | No; it shows process discipline |
In short
- Maturity models rate how well defined, managed and improved processes are, usually on a 0 or 1 to 5 scale.
- CMMI-style levels: initial, managed, defined, quantitatively managed, optimising; COBIT 2019 uses capability levels 0 to 5.
- Targets are set per capability area by business need and risk; not everything needs level 5.
- Maturity assessments define the current and desired state for the strategy, and the gaps become roadmap items.
- Other program assessments include NIST CSF profiles, ISO 27001 internal audits, and external benchmarks.
- Maturity shows process discipline; it doesn't prove that every individual control works.
Exam traps
- Recommending the highest maturity everywhere ignores cost and need.
- Level 3 means one standard process across the organisation, not just good practice in some teams.
- Maturity scores self-assessed without evidence tend to be inflated.
- A mature process can still contain a badly designed control.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The levels
Current vs target, area by area