Many threat intelligence programmes are judged by how many feeds they ingest and reports they publish, while the people who should act on the intelligence cannot name one decision it changed. Maturity in cyber threat intelligence (CTI) is about stakeholder outcomes: whether intelligence answers agreed requirements and reaches detection, incident response, vulnerability management, identity and risk owners in time to matter. This model scores a CTI programme on the five-level Ad hoc to Optimised scale used across NHI Mgmt Group maturity models, and aligns it with the community Cyber Threat Intelligence Capability Maturity Model (CTI-CMM), the FIRST CTI SIG programme stages, NIST SP 800-150, MITRE ATT&CK and the OASIS STIX and TAXII standards. It is for CTI leads, SOC managers and CISOs who need an honest baseline and a roadmap that fits their size. For the fundamentals of the discipline itself, see the Threat Intelligence Guide.
Key takeaways
- Use CTI-CMM as the primary reference: it is a free, community-built model launched in 2024, aligned with the C2M2 format, that scores CTI practices in 11 stakeholder domains on four maturity indicator levels, CTI0 Pre-Foundational to CTI3 Leading.
- Requirements are the first maturity test. A programme without written priority intelligence requirements (PIRs) agreed with stakeholders is Ad hoc, however many feeds it buys.
- Maturity means moving up the Pyramid of Pain: from collecting IP addresses, domains and hashes to tracking adversary behaviour mapped to ATT&CK, which is what detection engineering, hunting and vulnerability prioritisation can actually use.
- Not every organisation needs the top level. FIRST's CTI SIG notes that "In some cases, it may be best to stay in stage 1 and outsource more advanced activities"; set a target per domain based on what stakeholders need.
- Measure value, not volume. Count decisions, detections and mitigations that intelligence drove, and stakeholder feedback, alongside throughput.
The five levels
| Level | Name | Description |
|---|---|---|
| 1 | Ad hoc | CTI is a part-time task for an incident responder or SOC analyst. Indicator feeds are imported into security tools with little tuning, vendor and government advisories are read when someone has time, and there are no written requirements, no defined consumers and no feedback. |
| 2 | Developing | Someone is named as responsible for CTI. A first set of intelligence requirements exists, often written by the CTI team alone. Indicators are enriched and used for alerting, advisories are triaged for relevance to the estate, and the SOC and incident response receive regular briefings. Output is mostly tactical and reactive. |
| 3 | Defined | PIRs are agreed with stakeholders and reviewed on a schedule. A documented intelligence lifecycle runs from planning and direction to feedback, supported by a threat intelligence platform. Analysis focuses on adversary behaviour mapped to ATT&CK, feeds detection engineering, hunting and vulnerability prioritisation, and produces a regular threat landscape report. Sources are graded and confidence is stated. |
| 4 | Managed | Intelligence is part of the risk management process and serves most stakeholder domains: identity, third parties, architecture and fraud as well as security operations. Enrichment and sharing are automated through STIX and TAXII, metrics combine throughput with stakeholder feedback and outcomes, and the team shares with sector peers. |
| 5 | Optimised | Intelligence drives strategic decisions: investment, architecture, acquisitions and geopolitical risk. Internally generated intelligence from investigations and hunting is the main source, repeatable tasks are automated so analysts work on behaviour and strategy, and metrics are reviewed routinely and tied to future improvements. |
How the levels relate to CTI-CMM and the FIRST stages
The CTI-CMM is published at cti-cmm.org as "a community-driven framework designed to provide CTI programs with a roadmap to improve stakeholder support", developed by a volunteer group of practitioners. Version 1.3 dates from January 2026. Its authors stress that "The model was developed to provide descriptive, not prescriptive, guidance" and that "The future maturity of your program is dependent on the appetite and ambition of your organization." It defines four maturity indicator levels: CTI0 Pre-Foundational ("No practices are performed at this level."), CTI1 Foundational ("Basic practices are performed but are mostly undocumented, ad hoc, unplanned, and response-driven."), CTI2 Advanced and CTI3 Leading. CTI1 work is reactive and serves a subset of stakeholders; CTI2 is proactive and predictive, mostly documented and standardised, with automation at scale; CTI3 is prescriptive, cross-functional and tied to business outcomes.
The FIRST CTI SIG describes three programme stages. In Stage 1 CTI is "a secondary duty, not an official position" within incident response, consuming automated observable feeds for flagging and alerting. Stage 2 moves up the Pyramid of Pain to attacker behaviour, adds a threat intelligence platform, documented analytical processes, formal input into risk management and threat landscape reporting. Stage 3 runs the full intelligence cycle on internally generated data, tracks relevant adversaries, adds geopolitical awareness and gives the team "some input into corporate decisions".
| NHI Mgmt Group level | CTI-CMM level | FIRST CTI SIG stage | NIST CSF 2.0 Tier |
|---|---|---|---|
| 1 Ad hoc | CTI0 to early CTI1 | Before Stage 1 | Tier 1 Partial |
| 2 Developing | CTI1 Foundational | Stage 1 | Tier 2 Risk Informed |
| 3 Defined | CTI2 Advanced in core security domains | Stage 2 | Tier 3 Repeatable |
| 4 Managed | CTI2 across most domains, CTI3 in some | Stage 2 to Stage 3 | Tier 3 to Tier 4 |
| 5 Optimised | CTI3 Leading in the domains that matter most | Stage 3 | Tier 4 Adaptive |
This alignment is NHI Mgmt Group's judgement, not an official crosswalk. Where the two disagree, score yourself with the CTI-CMM practices, because they are specific and testable.
The CTI-CMM domains
CTI-CMM is organised around the people CTI serves. Each domain states its purpose (taken from the US Department of Energy's C2M2), a CTI mission, use cases, data sources and practices at each level, with IDs such as THREAT-1.a. Version 1.0 had ten domains; version 1.1 added Fraud and Abuse Management, which is not in C2M2. The table summarises each domain with examples: some paraphrase CTI-CMM practices (THREAT, ACCESS, SITUATION, RESPONSE, RISK), the rest are our illustrations. Use the model itself for the full practice list.
| Domain (ID) | What CTI delivers | Foundational looks like | Advanced or Leading looks like |
|---|---|---|---|
| Asset, Change, and Configuration Management (ASSET) | Threat context for what you own | Advisories matched to products in use | Threat-informed priorities for critical assets and changes |
| Threat and Vulnerability Management (THREAT) | Knowledge of the relevant threat landscape | Indicators collected from external reports; alerts on active adversaries | Hunts and patching prioritised by PIRs and exploitation against critical assets |
| Risk Management (RISK) | Threat input to risk decisions | Ad hoc threat input to risk reviews | CTI aligned to the risk strategy and giving proactive mitigation guidance |
| Identity and Access Management (ACCESS) | Intelligence that informs IAM | Alerts on leaked or compromised credentials | Early warning on malware and techniques targeting identities |
| Situational Awareness (SITUATION) | Threat-informed decisions for all stakeholders | Alerts collected from open and trusted sources | Routine threat landscape reports; dissemination driven by PIRs |
| Event and Incident Response, Continuity of Operations (RESPONSE) | Enriched, prioritised intrusion activity | Incidents mapped to a kill chain or framework | Detected events enriched automatically with CTI |
| Third-Party Risk Management (THIRD-PARTIES) | Threats to and through suppliers | Breach news about key suppliers tracked | Supplier threat exposure feeding onboarding and review |
| Fraud and Abuse Management (FRAUD) | Intelligence on fraud and abuse of services | Reactive support to fraud cases | Shared indicators and actor tracking with fraud teams |
| Workforce Management (WORKFORCE) | Skilled CTI staff and threat-aware staff | CTI as a secondary duty | Defined roles, training paths and analytic standards |
| Cybersecurity Architecture (ARCHITECTURE) | Threat-informed design | Occasional input to design reviews | Architecture decisions tested against adversary behaviour |
| Cybersecurity Program Management (PROGRAM) | A managed CTI programme | No charter or metrics | Charter, budget, metrics and stakeholder feedback reviewed routinely |
Where identity fits: the ACCESS domain is where intelligence most often prevents a breach. Stolen session cookies, infostealer logs and leaked API keys are intelligence about your identities, and acting on them means resetting credentials and revoking tokens, not just blocking an IP address. The Snowflake breach showed infostealer-harvested credentials unlocking customer accounts that lacked MFA. See the Infostealer Threat Guide.
Programme capabilities by level
Domains tell you whom you serve; these capabilities tell you how well the programme runs. Score both.
| Capability | Level 1 Ad hoc | Level 3 Defined | Level 5 Optimised |
|---|---|---|---|
| Requirements | None written | PIRs agreed with a stakeholder group and reviewed at least quarterly; request process for ad hoc questions | PIRs revised on business change and drive collection, hunting and dissemination |
| Collection and sources | Whatever free feeds are available | Sources chosen against PIRs, graded for reliability and reviewed for value; trusted sharing communities joined | Internal investigations and hunting are the main source; external feeds used to pivot and validate |
| Analysis | Indicator lookups | Behaviour mapped to ATT&CK techniques, Groups and Campaigns; confidence and source grading stated | Strategic and geopolitical assessment alongside technical analysis |
| Dissemination | Forwarded emails | Products by audience: tactical for the SOC, operational for responders, strategic for leadership; TLP labels applied | Products tailored to each stakeholder domain, with feedback on every product |
| Integration and automation | Indicators pasted into tools by hand | Threat intelligence platform; automatic enrichment of alerts; STIX 2.1 objects exchanged over TAXII | Repeatable tasks automated; intelligence-to-detection pipeline measured end to end |
| Sharing | Consume only | Rules that control what is shared and with whom, as NIST SP 800-150 recommends; member of a sector community | Regular contributor of sightings and analysis to peers |
| Measurement | Feed and report counts | Throughput plus stakeholder feedback and detections created | Outcome metrics tied to business decisions and reviewed routinely |
On standards: STIX 2.1 is "a language and serialization format used to exchange cyber threat intelligence" with 18 domain objects such as Threat Actor, Intrusion Set, Campaign, Attack Pattern and Indicator, plus Relationship and Sighting objects. TAXII 2.1 is "an application protocol for exchanging CTI over HTTPS", using Collections for request and response and Channels for publish and subscribe. Requiring both in tooling is a Level 3 decision; see the Threat Intelligence Platform Buyer's Guide.
Framework mapping
| Capability | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 | Other |
|---|---|---|---|---|
| Receiving intelligence | ID.RA-02 | PM-16, SI-5 | A.5.7 | NIST SP 800-150 |
| Threat identification | ID.RA-03 | RA-3, RA-3(3) | A.5.7 | ATT&CK Groups and Campaigns |
| Intelligence in detection and analysis | DE.AE-07 | SI-4, RA-10 | A.8.16 | ATT&CK techniques; CTI-CMM RESPONSE |
| Automated sharing | ID.RA-02 | PM-16(1) | A.5.7 | STIX 2.1, TAXII 2.1 |
| Improvement | ID.IM-01, ID.IM-03 | PM-16 | Clause 10.1 | CTI-CMM Measure step |
Self-assessment questions
CTI-CMM scores each practice on a four-point scale (Fully, Largely, Partially or Not Implemented) and advises using the lower score when in doubt. Its free assessment tool does the arithmetic. Before you start, answer these questions with evidence:
- Requirements: can you show the current PIRs, who outside security agreed them and when they were last revised?
- Stakeholders: which of the 11 CTI-CMM domains received an intelligence product in the last quarter, and which have never asked for one?
- Outcomes: how many detection rules, hunts, emergency patches or credential resets in the last 90 days started from an intelligence product?
- Analysis depth: what share of your products describe adversary behaviour as ATT&CK techniques rather than lists of indicators?
- Sources: which feed would you cancel tomorrow, and what data tells you so?
- Timeliness: when a new exploited vulnerability or campaign hits your sector, how many hours pass before affected owners have assessed relevance and actions?
- Feedback: what did stakeholders say about the last three products, and what changed as a result?
- Sharing: what did you contribute to a trusted community this year, under which TLP label?
Moving up a level
CTI-CMM's own cycle is Prepare, Assess, Plan, Deploy and Measure, and its Plan step asks what can improve within about 90 days. A small organisation should aim for Level 2 or 3 in the THREAT, RESPONSE and ACCESS domains, built on government advisories, a sector sharing community and a managed service for deeper analysis. A large or highly targeted organisation (finance, critical infrastructure, government suppliers) needs a dedicated team, a platform and Level 4 across most domains.
From Ad hoc to Developing
- Name a CTI owner and write a one-page charter: purpose, consumers and what is out of scope.
- Draft five to ten intelligence requirements tied to your crown jewels, technology stack and sector.
- Subscribe to national advisories and your vendors' security bulletins, and triage each against the asset inventory.
- Pilot one indicator feed in alert-only mode, measuring false positives before allowing any blocking, with a documented way to remove a bad indicator quickly.
From Developing to Defined
- Rebuild the requirements as PIRs with a working group from leadership, legal, HR, finance and product security, as the FIRST CTI SIG recommends, and review them quarterly; FIRST notes "PIRs are fluid and not static".
- Document the intelligence lifecycle and a request process for ad hoc questions.
- Map adversary behaviour to ATT&CK and hand prioritised techniques to detection engineering and hunting. See the Detection Engineering Guide and Threat Hunting Guide.
- Grade sources and state confidence in every product; apply TLP labels.
- Deploy a threat intelligence platform that imports and exports STIX 2.1 over TAXII, and automate alert enrichment.
- Publish a quarterly threat landscape report for leadership in plain language.
From Defined to Managed
- Formalise CTI input into the risk register and risk reviews.
- Extend products to identity, third-party, architecture and fraud stakeholders, starting with leaked credential and supplier breach alerts.
- Feed exploitation intelligence into vulnerability prioritisation. See the Vulnerability Management Guide.
- Agree sharing rules and contribute sightings to a sector community.
- Collect structured feedback on every product and report outcomes, not just volumes.
From Managed to Optimised
- Make investigations and hunts the primary source, with external feeds used to pivot and validate.
- Add strategic and geopolitical analysis that informs investment, market entry and supplier decisions.
- Automate repeatable collection, enrichment and dissemination so analysts focus on behaviour and strategy.
- Reassess with CTI-CMM annually and tie each metric to a planned improvement.
Metrics that show maturity
- Requirement coverage: percentage of PIRs answered by at least one product in the period.
- Stakeholder reach: number of CTI-CMM domains receiving products, against the target set.
- Actioned intelligence: detections, hunts, patches, blocks and credential resets that started from CTI.
- Time to relevance: hours from a public report of a campaign or exploited flaw to an owner-ready assessment.
- Stakeholder satisfaction: feedback score on timeliness, relevance and actionability.
- Source value: share of actioned intelligence attributable to each source, used at renewal.
CTI-CMM publishes a metrics spreadsheet alongside the model. See the Security Operations Metrics Guide for reporting.
Common failure patterns
- Feed hoarding: buying more indicator feeds than anyone can tune, producing alert noise and blocking errors without moving up the Pyramid of Pain.
- Requirements written by the CTI team alone: the products answer analysts' curiosity rather than stakeholders' decisions, so nobody reads them.
- Intelligence that never reaches controls: the help desk social engineering used against the MGM Resorts breach was the kind of technique-level intelligence that is only useful if it changes help desk verification and detections.
- Security operations as the only customer: identity, third-party and fraud owners never receive anything, so the ACCESS, THIRD-PARTIES and FRAUD domains stay at CTI0.
- Reports without confidence: assessments with no stated source grading or confidence get over-trusted or ignored.
- Measuring output: counting reports and indicators hides whether any decision changed.
Practitioner checklist
- Run a CTI-CMM self-assessment and record a current and target level for each of the 11 domains.
- Agree PIRs with stakeholders outside security and review them at least quarterly.
- Map products to ATT&CK and hand prioritised techniques to detection and hunting teams. See the MITRE ATT&CK Guide for Defenders.
- Require STIX 2.1 and TAXII 2.1 support in any platform you buy.
- Apply TLP labels and written sharing rules, and join one sector community.
- Deliver at least one product a quarter to the identity, third-party and risk owners.
- Report actioned intelligence and stakeholder feedback, not feed counts.
- Reassess annually and after major changes in business, sector or threat.
Standards and references
- CTI-CMM: Cyber Threat Intelligence Capability Maturity Model
- CTI-CMM: Cyber Threat Intelligence Capability Maturity Model, Version 1.3
- FIRST: CTI SIG Curriculum
- FIRST: CTI SIG, Building a CTI Program, Program Maturity Stages
- NIST: SP 800-150, Guide to Cyber Threat Information Sharing
- NIST: The NIST Cybersecurity Framework (CSF) 2.0
- MITRE: ATT&CK Resources
- OASIS: Introduction to STIX
Related NHI Mgmt Group resources: Threat Intelligence Guide · Threat Hunting Guide · Detection Engineering Guide · Threat Intelligence Platform Buyer's Guide · SOC Maturity Model