What is a threat intelligence program runbook?

A threat intelligence (CTI) program runbook is the durable, end-to-end operating procedure that converts external and internal threat signal into decisions the rest of the security programme uses. It is not the same as a threat intelligence feed list, a vendor TIP tool, or a one-time CTI strategy slide. It is the named, versioned, role-anchored procedure that codifies how the programme sets priority intelligence requirements (PIRs), runs the six-phase intelligence cycle from direction through collection, processing, analysis, dissemination, and feedback, and how each stage lands on a workspace record that the audit, the leadership, the SOC, the AppSec team, and the vulnerability management team all read against. Without a runbook the CTI function devolves into ad-hoc article forwarding and the firm cannot answer the regulator question of how the threat picture moved decisions on a named date.

How is a CTI program runbook different from a threat intel feed list or a TIP tool?

A feed list names the sources (CISA KEV, FIRST EPSS, ISACs, vendor PSIRTs, CERT alerts, dark-web monitoring, internal red team outputs). A TIP tool is the technology that ingests and stores indicators of compromise. The runbook is the operating procedure that sits above both: it names which PIRs the programme is trying to answer, which sources are authorised against each PIR, what processing rules turn raw signal into analyst-rendered intelligence, which products the programme dispatches per consumer (strategic for the CISO and board, operational for the SOC and detection engineering, tactical for the SOC analyst and incident responder, technical for the AppSec engineer and VM team), what dissemination cadence applies to each product class, and how the feedback record from each consumer closes the loop back to the next direction-setting cycle. A feed list answers what sources exist; a TIP answers where indicators live; the runbook answers how the programme actually operates.

Why do priority intelligence requirements (PIRs) matter, and how should a programme set them?

PIRs are the named questions the CTI programme is funded to answer, set by the consumer (typically the CISO or the security operations leader) and refreshed at a documented cadence. Without explicit PIRs the programme drifts into article forwarding and chases whichever advisory landed on the analyst desk that morning. A pragmatic PIR set spans four classes: adversary PIRs (which named threat actor groups are likely to target this estate, what TTPs are they currently using, what is their current targeting and tooling), capability PIRs (which TTPs against the deployed estate are most likely to succeed given current control posture, which exposed services are being targeted in the wild), exposure PIRs (which deployed components have active exploitation in the wild, which supply-chain dependencies are at risk, which vendor advisories affect the estate), and programme PIRs (where does the detection and prevention stack have visible gaps the CTI programme should surface for control validation, what intel does the audit committee and the board need to read against the firm risk appetite). Each PIR should be a specific question with a named consumer, a refresh cadence, a relevance horizon, and a documented owner who reviews PIR fitness at the quarterly governance review.

How does the runbook ingest, process, and analyse threat intelligence safely?

The runbook codifies the chain from raw signal to analyst-rendered intelligence so the consumer reads vetted product rather than unverified chatter. Collection captures the source identifier, the TLP marking (TLP:CLEAR, TLP:GREEN, TLP:AMBER, TLP:AMBER+STRICT, TLP:RED) per the FIRST TLP 2.0 standard, the relevance assessment against the active PIRs, and the date observed. Processing applies four rules: deduplication against prior records, indicator normalisation against a controlled schema, source-credibility tagging against the Admiralty System or an equivalent six-level scale, and PIR linkage so every processed item is tied to a named requirement. Analysis applies analyst tradecraft to convert processed signal into intelligence: structured analytic techniques (analysis of competing hypotheses, key assumptions check, devils advocate, red team analysis), explicit confidence levels (high, moderate, low) per ICD 203 conventions, named author and named reviewer for the analytic product. Intelligence is then packaged per the product catalogue in Section 7 and dispatched to the named consumer with the relevant TLP marking preserved through the chain.

What intelligence products should the programme dispatch, and to which consumers?

Five product classes cover the durable consumer set. Strategic intelligence products (quarterly or on event) cover the threat-actor and capability picture the CISO, the audit committee, the board risk committee, and enterprise procurement read. Operational intelligence products (weekly or on event) cover the named campaigns, the active TTPs, and the prioritised hunting hypotheses the SOC manager, detection engineering, and security operations leaders read against. Tactical intelligence products (daily or on event) cover the SOC analyst-facing hunting prompts, the indicator-of-compromise watchlists, and the active incident enrichment the SOC analyst and incident responder consume. Technical intelligence products (on event) cover the vendor advisories, the in-scope CVE picture, the supply-chain advisories, and the deployed-estate exposure intelligence the AppSec team, the vulnerability management team, the product security team, and the security engineering team consume. Programme intelligence products (monthly or on event) cover the CTI portfolio read against PIR fitness, the consumer feedback summary, and the source-credibility evolution the runbook owner, the security architects, and the GRC operator read for portfolio governance.

How often should the CTI program runbook run, and what are the event-driven triggers?

The runbook operates on a dual cadence: calendar cadence per product class plus event-driven cadence for named triggers regardless of calendar position. Calendar cadence: daily tactical intelligence products and indicator watchlist refresh; weekly operational intelligence and active-campaign briefing; monthly programme intelligence and PIR fitness review at the operational governance forum; quarterly strategic intelligence and full PIR refresh at the CISO governance forum; annual runbook revision pass and consumer survey. Event-driven triggers force out-of-band intelligence production regardless of calendar: a CISA KEV addition affecting deployed components, a vendor PSIRT advisory with confirmed in-the-wild exploitation, an ISAC TLP:AMBER or TLP:RED bulletin against the sector, an internal red team or pentest finding naming an upstream TTP, a regulator advisory or CERT alert against the sector, a confirmed incident in scope, a supply-chain compromise affecting a named dependency, a credible dark-web indicator surfacing against the brand, a peer-firm public incident disclosure with shared exposure shape, an emerging-CVE pattern with shared exploit framework signature. Each trigger has a documented response time budget so the operational cadence does not absorb event-driven work into the next scheduled briefing.

How does the runbook handle indicator lifecycle, false positives, and source credibility?

Indicators are first-class records with an explicit lifecycle: ingested (raw, unrendered), candidate (under analyst review), confirmed (passed processing and analysis), active (currently in the watchlist), aged-out (timestamp exceeded the relevance window), suppressed (analyst-rejected as false positive or non-relevant). Each state has a named transition rule and a documented authority. False-positive handling routes through a structured rejection workflow that captures the rejection rationale, the rejecting analyst, the date, and the source-credibility impact so recurring rejections from the same source produce a credibility downgrade rather than silently degrading the watchlist. Source credibility is tracked on a six-level scale (Admiralty System or equivalent) and reviewed at the monthly programme intelligence cycle: a source that has produced repeated false-positive indicators is downgraded; a source that has produced confirmed early warnings is upgraded; new sources start at moderate credibility and earn their position. Indicator aging is automated by setting a per-class relevance window at ingest (90 days for opportunistic-campaign indicators, 365 days for state-aligned-actor TTPs, indefinite for confirmed-tool signatures). Without lifecycle discipline the watchlist becomes a graveyard of stale indicators that produces alert fatigue and degrades the SOC read.

How does the runbook close the feedback loop with consumers and refresh PIRs?

The feedback loop is the structural mechanism that prevents the CTI programme from becoming a one-way broadcast operation. Each intelligence product carries a feedback reference (a thread, a record, a ticket) the consumer uses to mark whether the product was actionable, partially actionable, or non-actionable, and to record the action taken (hunt executed, detection deployed, finding raised, control adjusted, no action). The runbook owner reads the feedback record at the monthly programme intelligence cycle and produces three outputs: an updated PIR fitness assessment naming which PIRs are producing consumer-actionable intelligence and which are not, a source-credibility update reflecting which sources contributed to actionable versus non-actionable products, and a product-catalogue tuning record naming which product classes are landing with which consumers and where format or cadence adjustments are warranted. The quarterly strategic cycle reads the three monthly outputs and produces a full PIR refresh with the CISO, the security operations leader, the audit committee, and the heads of AppSec, vulnerability management, and security engineering, so the next quarter operates against current requirements rather than stale ones.

How does the runbook align with ISO 27001, SOC 2, PCI DSS, NIST, NIS2, DORA, and the CTI framework canon?

The runbook produces the per-decision evidence the framework controls and the CTI canon expect. ISO/IEC 27001 Annex A 5.7 (threat intelligence) reads the runbook charter, the PIR set, the collection plan, and the dissemination cadence as the operating instance of the threat intelligence control. ISO/IEC 27001 Clause 9.1 (monitoring, measurement, analysis, evaluation) reads the quarterly governance review and the programme metrics. SOC 2 CC3.2 (specifies objectives sufficient to identify and assess risks) and CC7.2 (monitors system components for anomalies and indications of system events) read the PIR-to-product chain and the indicator lifecycle. PCI DSS Requirement 12.10.1 (incident response plan addresses external alerts) and Requirement 6.3.1 (identifies new vulnerabilities through external sources) read the source authorisation and the operational cadence. NIST SP 800-150 (guide to cyber threat information sharing) reads the runbook as the operating model the sharing programme runs against. NIST SP 800-53 RA-3 (risk assessment), RA-10 (threat hunting), SI-5 (security alerts and advisories), and PM-16 (threat awareness program) read the requirement, source, dissemination, and feedback chain. NIST CSF 2.0 ID.RA-2 (cyber threat intelligence is received from information sharing forums and sources), ID.RA-3 (threats, vulnerabilities, and risks are identified, recorded, prioritized, assessed, and responded to), DE.AE-7 (cyber threat intelligence and other contextual information are integrated into analysis), and GV.RR (roles, responsibilities, authorities) read the chain end-to-end. NIS2 Article 21(2)(g) (cybersecurity training) and Article 23 (incident reporting) read the runbook as the procedural anchor for threat-aware operations. DORA Article 6 (ICT risk management framework) and Article 13 (learning and evolving) read the feedback loop and the runbook revision cadence. MITRE ATT&CK provides the structured tradecraft vocabulary the analyst products read against; the FIRST Traffic Light Protocol 2.0 standard governs sharing classification; the Admiralty System or equivalent governs source credibility; ICD 203 (Analytic Standards) governs analytic tradecraft and confidence-level conventions.

What metrics does the quarterly governance review read?

The quarterly governance review reads twelve durable indicators against trend. PIR coverage: percentage of PIRs that produced at least one consumer-actionable intelligence product in the quarter. Source health: count of authorised sources by credibility band, with movement across bands. Indicator lifecycle: ingested, confirmed, aged-out, and suppressed indicator volumes. Product volume by class: strategic, operational, tactical, technical, and programme product counts against the published cadence. Dissemination cadence adherence: percentage of products dispatched within the cadence window. Consumer actionability: percentage of products marked actionable in the feedback record by named consumer class. Event-driven trigger volume: count of triggers by class and the median time from trigger to first product. Cross-source corroboration rate: percentage of intelligence products with corroborating signal from two or more authorised sources. False-positive rate by source: rate of analyst-rejected items by source over the quarter. Detection contribution: count of detections deployed or tuned in the quarter attributed to CTI products. Hunting contribution: count of hunts executed or scoped against CTI-supplied hypotheses. Programme PIR refresh: count of PIRs added, retired, or reworded against last quarter. The review reads these against the prior quarter and against the annual baseline so the runbook owner, the CISO, the audit committee, and the board risk committee can answer whether the programme is improving over time.

Who owns the runbook, who runs the cycle, and how does the workspace help?

The runbook is owned by the CTI programme lead (sometimes titled Head of Threat Intelligence, Senior CTI Analyst, or Threat Intelligence Manager) reporting to the security operations leader or the CISO. The intelligence cycle is run by the named CTI analyst pool, with the runbook owner accountable for cadence adherence, product quality, PIR fitness, and the runbook itself. Independent review of analytic products comes from a peer analyst (where the programme has two or more analysts) or from a rotated reviewer drawn from detection engineering or AppSec leadership. Strategic products carry CISO sign-off; operational products carry SOC manager and detection engineering lead acknowledgement; tactical products land with the SOC analyst rota; technical products land with named AppSec, VM, and product-security owners; programme products land with the runbook owner and the governance forum. SecPortal pairs every intelligence product to a versioned engagement record through engagement-management; the source artefacts, the analyst-rendered products, the PIR set, and the runbook itself live on document-management with the audit evidence retention classification applied; the named consumers and the analyst pool are gated by team-management role-based access and protected by multi-factor authentication; the activity-log captures the timestamped chain of state changes across the intelligence cycle; findings-management carries the corrective actions, the AppSec and VM follow-ups, and the in-estate exposure findings raised by technical intelligence products with a CVSS-aligned severity, a named owner, a target close date, and an evidence-of-closure requirement; bulk-finding-import supports CSV-based ingestion of vendor PSIRT advisories, KEV updates, and ISAC bulletins; notifications-and-alerts dispatches the cadence reminders and the event-driven trigger pages; compliance-tracking pairs the intelligence records to ISO 27001 Annex A 5.7, SOC 2 CC3.2 and CC7.2, PCI DSS 6.3.1 and 12.10.1, NIST SP 800-53 RA-3 and RA-10 and SI-5 and PM-16, NIST CSF 2.0 ID.RA-2 and ID.RA-3 and DE.AE-7, NIS2 Article 21 and 23, DORA Article 6 and 13; ai-reports drafts the strategic briefing, the operational summary, and the quarterly governance review pack from the same engagement data so the audit committee read of CTI performance and the operational read are the same record.

How does the CTI programme integrate with BAS, detection engineering, vulnerability management, and incident response?

The CTI programme is the upstream signal layer; the four disciplines are the downstream consumers. Breach and attack simulation reads the CTI operational and technical products to scope which library-supplied attacker behaviours are most relevant to validate this cycle, and the BAS coverage gaps feed back into CTI PIRs through the feedback loop. Detection engineering reads the CTI operational products to scope new detection rules and to tune existing ones; the detection telemetry produces back-pressure on CTI through the feedback record naming which products produced detection improvements and which did not. Vulnerability management reads the CTI technical products to enrich the prioritisation queue with current exploitation signal beyond the static CVSS score, and the VM closure record feeds back into CTI to tag which technical intelligence resulted in finding closure within SLA. Incident response reads the CTI tactical products during active investigations for adversary attribution and TTP context, and the post-incident review produces a structured request back to CTI for new PIRs or refreshed source authorisation. The pair-wise interfaces are captured in the runbook product catalogue (Section 7) and the feedback loop (Section 9) so each integration carries a named handoff record rather than ad-hoc messaging across chat channels.

Free Tool

Threat Intelligence Program Runbook Template
twelve sections that turn ad hoc threat intel forwarding into a defensible operating record

A free, copy-ready CTI programme runbook template. Twelve structured sections covering runbook header and version control, programme charter and authority, priority intelligence requirements (PIRs) and standing intelligence requests, collection plan with authorised sources and TLP 2.0 handling, processing rules and analyst-rendering discipline, analysis tradecraft and confidence levels per ICD 203, intelligence product catalogue with named consumers and dissemination cadence across five product classes, indicator lifecycle and false-positive handling, feedback loop and intelligence requirement refresh, programme metrics and quarterly governance review, operating cadence with calendar and event-driven triggers, and programme governance and review and runbook revision. Aligned with ISO/IEC 27001 Annex A 5.7 and Clause 9.1, SOC 2 CC3.2 and CC7.2, PCI DSS Requirement 6.3.1 and 12.10.1, NIST SP 800-150, NIST SP 800-53 RA-3 and RA-10 and SI-5 and PM-16, NIST CSF 2.0 ID.RA-2 and ID.RA-3 and DE.AE-7 and GV.RR, NIS2 Article 21 and 23, DORA Article 6 and 13. Built for enterprise CTI programme leads, SOC managers, detection engineering teams, AppSec teams, vulnerability management teams, product security teams, security engineering teams, security operations leaders, GRC and compliance teams, CISOs, security architects, audit committees, and board risk committees that need a defensible alternative to ad hoc article forwarding and vendor TIP screenshots as evidence the CTI programme actually moves decisions.

Get Started Free

No credit card required. Free plan available forever.

Twelve sections that turn ad hoc threat intel forwarding into a defensible operating record

A cyber threat intelligence (CTI) programme is the security function that converts external and internal threat signal into decisions the rest of the security organisation uses. The programme runbook is the named, versioned, role-anchored operating procedure that codifies how the programme runs the six-phase intelligence cycle (direction, collection, processing, analysis, dissemination, feedback) on a workspace record the SOC, the detection engineering team, the AppSec team, the vulnerability management team, the CISO, the audit committee, and the board can all read against. It is not the same as a list of threat intelligence feeds, a vendor TIP tool, or a one-time CTI strategy slide. Run alongside a continuous threat exposure management programme for cycle-level exposure decisions and a threat-intelligence-driven prioritisation workflow for the per-finding queue, the CTI programme runbook becomes the operating record the audit and the regulator read against.

The twelve sections below cover the durable shape of one programme runbook against ISO/IEC 27001 Annex A 5.7 (threat intelligence) and Clause 9.1, SOC 2 CC3.2 and CC7.2, PCI DSS Requirement 6.3.1 and 12.10.1, NIST SP 800-150 (guide to cyber threat information sharing), NIST SP 800-53 RA-3 and RA-10 and SI-5 and PM-16, NIST CSF 2.0 ID.RA-2 and ID.RA-3 and DE.AE-7 and GV.RR, NIS2 Article 21 and 23, and DORA Article 6 and 13. The package is not a substitute for a TIP tool, a SIEM, a SOAR platform, or the engineering teams that own the detection and prevention stack. Pair it with the security program charter template that names the upstream chartered authority the CTI programme operates under, the security control validation runbook template that converts the operational and technical CTI products into per-control validation scenarios, the incident response runbook template that the tactical product class supports during active investigations, the vulnerability remediation runbook template that the technical product class feeds, the quarterly review template that reads the strategic product class into management review, the security KPI dashboard template for the indicator layer that surfaces programme contribution into leadership reporting, and the audit evidence retention policy template that classifies the programme records. Copy the section that fits your stage and paste the rest as you go.

Copy the full runbook package (all twelve sections) as one block.

1. Runbook header and version control

Open the runbook with the programme name, the version, the owner, the authority, and the next review date. A reviewer should be able to read in the first lines who owns the CTI programme, who runs the intelligence cycle, when the runbook was last revised, and which framework expectations the programme evidences. ISO/IEC 27001 Clause 7.5 expects documented information for the management system with controlled identification, format, and review; the version control block is what makes the CTI evidence traceable across audit cycles rather than a loose folder of analyst notes.

Runbook title: {{RUNBOOK_TITLE}}
Runbook identifier (cross-referenced from the programme charter and the governance forum minute book): {{RUNBOOK_IDENTIFIER}}

Programme name: {{PROGRAMME_NAME}}
Programme tier (one of: dedicated CTI programme with named analyst pool, distributed CTI function with named lead and matrixed analysts, founding-stage CTI programme with single lead):
- {{PROGRAMME_TIER}}

Version: {{RUNBOOK_VERSION}}
Effective date: {{EFFECTIVE_DATE}}
Next scheduled review date: {{NEXT_REVIEW_DATE}}
Revision trigger that produced this version (one of: scheduled annual review, post-incident lesson, post-engagement lesson, vendor or feed change, regulatory change, audit observation, PIR refresh, consumer feedback pattern, source-credibility shift):
- {{REVISION_TRIGGER}}

Programme owner (the role accountable for the CTI programme and the runbook):
- Role: {{PROGRAMME_OWNER_ROLE}}
- Named person at time of publication: {{PROGRAMME_OWNER_NAME}}
- Reporting line: {{PROGRAMME_OWNER_REPORTING_LINE}}

Runbook author (the role responsible for keeping the procedure current):
- Role: {{RUNBOOK_AUTHOR_ROLE}}
- Named person at time of publication: {{RUNBOOK_AUTHOR_NAME}}
- Signature: {{RUNBOOK_AUTHOR_SIGNATURE}}
- Signature date: {{RUNBOOK_AUTHOR_SIGNATURE_DATE}}

Sponsor (the executive who chartered the programme and reads its outputs at the strategic cadence):
- Role: {{PROGRAMME_SPONSOR_ROLE}}
- Named person at time of publication: {{PROGRAMME_SPONSOR_NAME}}
- Sign-off date: {{PROGRAMME_SPONSOR_SIGNOFF_DATE}}

Analyst pool (the named roles authorised to render intelligence under this runbook):
- Senior CTI analyst (analytic tradecraft authority, final reviewer for strategic and operational products): {{SENIOR_CTI_ANALYST_ROLE}}
- CTI analyst (rendering authority for tactical and technical products, contributing author for higher-tier products): {{CTI_ANALYST_ROLE}}
- Rotated reviewer (independent analytic review for higher-confidence products; rotated through detection engineering and AppSec leadership):
  - {{ROTATED_REVIEWER_ROLE}}

Framework expectations evidenced by this runbook (ISO/IEC 27001 Annex A 5.7 threat intelligence; Clause 9.1 monitoring; SOC 2 CC3.2 risk identification; CC7.2 anomaly monitoring; PCI DSS Requirement 6.3.1 new vulnerability identification; Requirement 12.10.1 external alerts in incident response; NIST SP 800-150 cyber threat information sharing; NIST SP 800-53 RA-3 risk assessment, RA-10 threat hunting, SI-5 security alerts and advisories, PM-16 threat awareness program; NIST CSF 2.0 ID.RA-2, ID.RA-3, DE.AE-7, GV.RR; NIS2 Article 21 and 23; DORA Article 6 and 13; sector overlays; internal policy):
- {{FRAMEWORK_EXPECTATIONS_LIST}}

Cross-references:
- Parent security programme charter: {{SECURITY_PROGRAMME_CHARTER_REFERENCE}}
- Parent risk management framework: {{RISK_MANAGEMENT_FRAMEWORK_REFERENCE}}
- Linked CTEM cycle reference (where the CTI programme feeds a continuous threat exposure management cadence): {{CTEM_REFERENCE}}
- Linked detection engineering programme reference: {{DETECTION_ENGINEERING_PROGRAMME_REFERENCE}}
- Linked vulnerability management policy reference: {{VULNERABILITY_MANAGEMENT_POLICY_REFERENCE}}
- Linked incident response plan reference: {{INCIDENT_RESPONSE_PLAN_REFERENCE}}
- Compliance tracking record identifier: {{COMPLIANCE_RECORD_IDENTIFIER}}

Revision history (each entry: version, effective date, trigger, author, signed-off-by):
- v{{PRIOR_VERSION_1}} effective {{PRIOR_DATE_1}}, trigger {{PRIOR_TRIGGER_1}}, author {{PRIOR_AUTHOR_1}}, signed {{PRIOR_SIGNATORY_1}}
- v{{PRIOR_VERSION_2}} effective {{PRIOR_DATE_2}}, trigger {{PRIOR_TRIGGER_2}}, author {{PRIOR_AUTHOR_2}}, signed {{PRIOR_SIGNATORY_2}}

2. Programme charter, mandate, and authority

Name what the CTI programme is funded to produce, who it serves, and what authority it operates under. A CTI programme without a chartered mandate drifts into article forwarding because the operating priorities reset every time the inbox refreshes. The charter block converts the unstated assumptions about scope, audience, and authority into a named contract between the programme and the rest of the security organisation that the audit, the regulator, and the board read against.

Programme mandate (one paragraph describing what the CTI programme is funded to produce):
{{PROGRAMME_MANDATE}}

Programme scope (which estates, business units, geographies, and technology footprints the programme covers):
- In-scope estates: {{IN_SCOPE_ESTATES}}
- In-scope business units: {{IN_SCOPE_BUSINESS_UNITS}}
- In-scope geographies: {{IN_SCOPE_GEOGRAPHIES}}
- Out-of-scope estates and the rationale (prevents scope drift into adjacent programme space): {{OUT_OF_SCOPE_ESTATES}}

Programme authority (what the programme is empowered to do without external sign-off):
- Direct dissemination authority across the authorised consumer set: granted
- Direct source authorisation within published policy: granted
- Direct PIR setting in collaboration with named sponsor: granted
- Direct event-driven trigger activation: granted
- Direct finding raising on findings-management for technical intelligence products: granted
- Sign-off authority for strategic intelligence products: requires sponsor or CISO sign-off
- Sign-off authority for board-facing intelligence products: requires sponsor sign-off and audit committee acknowledgement

Programme dependencies (the upstream and downstream programmes the CTI programme is contractually paired with):
- Upstream dependency: detection engineering programme for telemetry context and detection-rule consumer feedback
- Upstream dependency: vulnerability management programme for in-estate exposure context and finding-side enrichment closing the loop on technical intelligence
- Upstream dependency: incident response programme for the post-incident lessons and PIR adjustments
- Upstream dependency: security testing programme for the red team and pentest finding intake that feeds the source plan
- Downstream consumer: SOC analyst pool for tactical intelligence
- Downstream consumer: detection engineering team for operational intelligence
- Downstream consumer: AppSec, product security, and vulnerability management teams for technical intelligence
- Downstream consumer: CISO, audit committee, board risk committee, and enterprise procurement for strategic intelligence
- Downstream consumer: runbook owner, governance forum, and security architects for programme intelligence

Programme consumer registry (named role, named consumer class, named cadence, named feedback record):
- Consumer 1: {{CONSUMER_1_ROLE}} | {{CONSUMER_1_PRODUCT_CLASS}} | {{CONSUMER_1_CADENCE}} | {{CONSUMER_1_FEEDBACK_RECORD}}
- Consumer 2: {{CONSUMER_2_ROLE}} | {{CONSUMER_2_PRODUCT_CLASS}} | {{CONSUMER_2_CADENCE}} | {{CONSUMER_2_FEEDBACK_RECORD}}
- Consumer 3: {{CONSUMER_3_ROLE}} | {{CONSUMER_3_PRODUCT_CLASS}} | {{CONSUMER_3_CADENCE}} | {{CONSUMER_3_FEEDBACK_RECORD}}

Programme commitments (the named deliverables the programme commits to per cadence):
- Daily tactical hunting prompt set: {{DAILY_TACTICAL_PROMPT_COMMITMENT}}
- Weekly operational briefing: {{WEEKLY_OPERATIONAL_BRIEFING_COMMITMENT}}
- Monthly programme intelligence review: {{MONTHLY_PROGRAMME_REVIEW_COMMITMENT}}
- Quarterly strategic intelligence brief: {{QUARTERLY_STRATEGIC_BRIEF_COMMITMENT}}
- Event-driven trigger response budget: {{EVENT_DRIVEN_RESPONSE_BUDGET}}

Programme exclusions (what the CTI programme explicitly does not do):
- The programme does not run live detection operations; detection engineering and the SOC own that workstream.
- The programme does not run live incident response; the IR team owns that workstream and the CTI programme provides tactical context.
- The programme does not run vulnerability remediation; the VM and AppSec teams own that workstream and the CTI programme provides exploitation context.
- The programme does not represent the firm externally to law enforcement, regulators, or media; legal, comms, and the executive team own those workstreams.

Sponsor acknowledgement (signed at the point this charter is published or after material scope change):
- Sponsor: {{PROGRAMME_SPONSOR_NAME}}
- Acknowledgement statement: "The mandate, scope, authority, dependencies, and commitments above accurately represent the chartered CTI programme as of {{ACKNOWLEDGEMENT_DATE}}."
- Signature: {{SPONSOR_ACKNOWLEDGEMENT_SIGNATURE}}

3. Priority intelligence requirements and standing intelligence requests

Name the priority intelligence requirements (PIRs) the programme is funded to answer this cycle, and the standing intelligence requests (SIRs) the programme runs continuously. Without explicit PIRs the programme chases the inbox and the consumer cannot answer whether the programme is producing relevant intelligence. PIRs are not generic statements; they are specific consumer questions with a named consumer, a refresh cadence, a relevance horizon, and a documented owner.

Priority intelligence requirements (PIRs) for the current cycle (named question, named consumer, refresh cadence, relevance horizon, documented owner):

PIR 1 - Adversary class:
- Question: {{PIR_1_QUESTION}}
- Named consumer: {{PIR_1_CONSUMER}}
- Refresh cadence: {{PIR_1_REFRESH_CADENCE}}
- Relevance horizon (how long an answer remains current): {{PIR_1_HORIZON}}
- Owner: {{PIR_1_OWNER}}
- Last refreshed: {{PIR_1_LAST_REFRESHED}}

PIR 2 - Capability class (what TTPs against the deployed estate are most likely to succeed given current control posture):
- Question: {{PIR_2_QUESTION}}
- Named consumer: {{PIR_2_CONSUMER}}
- Refresh cadence: {{PIR_2_REFRESH_CADENCE}}
- Relevance horizon: {{PIR_2_HORIZON}}
- Owner: {{PIR_2_OWNER}}
- Last refreshed: {{PIR_2_LAST_REFRESHED}}

PIR 3 - Exposure class (which deployed components have active exploitation in the wild, which supply-chain dependencies are at risk):
- Question: {{PIR_3_QUESTION}}
- Named consumer: {{PIR_3_CONSUMER}}
- Refresh cadence: {{PIR_3_REFRESH_CADENCE}}
- Relevance horizon: {{PIR_3_HORIZON}}
- Owner: {{PIR_3_OWNER}}
- Last refreshed: {{PIR_3_LAST_REFRESHED}}

PIR 4 - Programme class (where does the detection and prevention stack have visible gaps the CTI programme should surface for control validation):
- Question: {{PIR_4_QUESTION}}
- Named consumer: {{PIR_4_CONSUMER}}
- Refresh cadence: {{PIR_4_REFRESH_CADENCE}}
- Relevance horizon: {{PIR_4_HORIZON}}
- Owner: {{PIR_4_OWNER}}
- Last refreshed: {{PIR_4_LAST_REFRESHED}}

PIR 5 - Regulatory and reporting class (what intelligence does the audit committee, the board risk committee, and the regulator-facing reporting line need to read against the firm risk appetite):
- Question: {{PIR_5_QUESTION}}
- Named consumer: {{PIR_5_CONSUMER}}
- Refresh cadence: {{PIR_5_REFRESH_CADENCE}}
- Relevance horizon: {{PIR_5_HORIZON}}
- Owner: {{PIR_5_OWNER}}
- Last refreshed: {{PIR_5_LAST_REFRESHED}}

Standing intelligence requests (SIRs) the programme runs continuously without per-cycle refresh:
- SIR A: Continuous monitoring of CISA KEV catalog additions against the deployed estate
- SIR B: Continuous monitoring of FIRST EPSS feed for in-estate CVEs entering high-probability bands
- SIR C: Continuous monitoring of sector ISAC bulletins under the authorised sharing classification
- SIR D: Continuous monitoring of vendor PSIRT advisories for deployed products
- SIR E: Continuous monitoring of regional CERT alerts under the named geographies
- SIR F: Continuous monitoring of named contracted dark-web and brand-monitoring services
- SIR G: Continuous tracking of internal red team and pentest finding outputs that name upstream TTPs
- SIR H: Continuous tracking of named threat-actor public reporting from authorised research vendors

PIR governance:
- PIR refresh cadence: full PIR refresh at the quarterly strategic cycle; partial PIR refresh at the monthly programme cycle if consumer feedback or threat picture warrants
- PIR retirement criteria: a PIR is retired when the named consumer no longer reads the produced intelligence into a decision, when the relevance horizon has expired with no renewal, or when a successor PIR supersedes the question
- PIR addition criteria: a new PIR is added when a consumer raises a named question that current PIRs do not cover, when a regulator or audit observation requires new evidence, when an incident or red team finding surfaces a gap in the current question set

Standing intelligence request review:
- SIR fitness reviewed at the monthly programme cycle: which SIRs are producing high-actionability intelligence and which are not
- SIR addition criteria: a new SIR is added when a confirmed early-warning channel emerges or an existing channel splits into a more granular source
- SIR retirement criteria: a SIR is retired when the channel produces no actionable intelligence over two consecutive quarters, when the channel folds or merges into another, or when the source-credibility downgrade puts the channel below the floor

4. Collection plan with authorised sources and TLP handling

Name the authorised sources the programme draws from against each PIR and the handling rules that apply under the FIRST Traffic Light Protocol 2.0 standard. Without an explicit collection plan the analyst pool collects whatever the analyst chooses to subscribe to, and the source-credibility record is invisible until something goes wrong. The collection plan converts ad-hoc subscription into a named contract that the audit and the regulator read against.

Authorised source catalogue (per source: identifier, channel type, sharing classification, primary PIRs served, credibility band, contractual basis):

Source class A - Open public catalogs:
- CISA Known Exploited Vulnerabilities (KEV) catalog: PIR 3 and SIR A; TLP:CLEAR; high credibility; no contract required
- FIRST EPSS feed: PIR 3 and SIR B; TLP:CLEAR; high credibility; no contract required
- CWE catalogue: technical-product enrichment; TLP:CLEAR; high credibility; no contract required
- MITRE ATT&CK technique catalogue: PIR 1 and PIR 4 tradecraft anchor; TLP:CLEAR; high credibility; no contract required
- NIST National Vulnerability Database (NVD): CVE enrichment baseline; TLP:CLEAR; high credibility; no contract required

Source class B - Government and regional CERT advisories:
- CISA alerts and emergency directives: TLP:CLEAR; high credibility; no contract
- NCSC UK alerts: TLP:CLEAR; high credibility; no contract
- BSI advisories (Germany): TLP:CLEAR; high credibility; no contract
- ENISA advisories: TLP:CLEAR; high credibility; no contract
- ACSC alerts (Australia): TLP:CLEAR; high credibility; no contract
- CCCS bulletins (Canada): TLP:CLEAR; high credibility; no contract
- CERT-EU advisories: TLP:CLEAR; high credibility; no contract
- JPCERT/CC bulletins: TLP:CLEAR; high credibility; no contract
- Regional CSIRT bulletins for in-scope geographies: TLP:CLEAR; high credibility; no contract

Source class C - Sector ISACs and ISAOs (TLP-restricted sharing):
- FS-ISAC, H-ISAC, Auto-ISAC, Aviation ISAC, IT-ISAC, Energy ISAC, Retail and Hospitality ISAC, MS-ISAC, others applicable to the sector
- Membership status: {{ISAC_MEMBERSHIP_STATUS}}
- Sharing classification range observed: TLP:CLEAR through TLP:AMBER+STRICT (rarely TLP:RED)
- Credibility band: high for confirmed-incident reporting; moderate for emerging-threat chatter
- Handling rule: TLP:AMBER and TLP:AMBER+STRICT bulletins carry an explicit handling note on the engagement record; onward sharing respects the originating constraints

Source class D - Vendor PSIRT advisories:
- Authorised vendor PSIRT subscription list: {{VENDOR_PSIRT_SUBSCRIPTION_LIST}}
- Sharing classification: TLP:CLEAR; high credibility (vendor authoritative on own products)
- Handling rule: PSIRT advisories are linked to the deployed-estate inventory at intake; vendor TLP markings observed where present

Source class E - Commercial threat intelligence subscriptions (contracted):
- Authorised commercial subscriptions: {{COMMERCIAL_SUBSCRIPTION_LIST}}
- Contract reference and scope: {{COMMERCIAL_CONTRACT_REFERENCE}}
- Sharing classification range: TLP:AMBER and TLP:AMBER+STRICT typical; TLP:GREEN where the vendor publishes broadly
- Credibility band: per-vendor track record; commercial sources start at moderate and adjust on observed credibility

Source class F - Dark-web, brand-monitoring, and chatter services (contracted):
- Authorised contracted services: {{DARK_WEB_SERVICE_LIST}}
- Contract reference: {{DARK_WEB_CONTRACT_REFERENCE}}
- Sharing classification: TLP:AMBER+STRICT typical
- Credibility band: low to moderate; outputs require analyst rendering before downstream dispatch
- Handling rule: raw chatter is never disseminated; analyst-rendered intelligence carries the source identifier but not the raw extract

Source class G - Internal sources (first-class intelligence):
- Internal red team operations: high credibility; TLP:RED unless explicitly downgraded; PIR 1 and PIR 4 contributor
- Contracted penetration test findings: high credibility; TLP:AMBER+STRICT until report finalisation
- Bug bounty submissions: variable credibility; PIR 3 and PIR 4 contributor
- Incident-response post-incident analysis: high credibility; PIR 1 and PIR 4 contributor
- Application security finding patterns from AppSec triage: high credibility; PIR 3 and PIR 4 contributor

Collection rules:
- Every collected item is captured on the engagement record with source identifier, channel type, timestamp observed, sharing classification, PIR linkage, and initial credibility tag.
- TLP:CLEAR through TLP:GREEN items can be dispatched per the product catalogue without restriction; TLP:AMBER and TLP:AMBER+STRICT items carry an explicit handling note; TLP:RED items remain internal unless explicit downgrade is authorised by the source.
- Sources that consistently produce non-actionable items are routed for credibility review at the next monthly cycle.
- New sources are added through the SIR addition path and reviewed for credibility at the first monthly cycle after addition.
- Retired sources are recorded on the source register with the retirement date and the reason; the historical intelligence record retains the source attribution for traceability.

5. Processing rules and analyst-rendering discipline

Convert raw signal into processed intelligence with a named, repeatable procedure so the consumer reads vetted product rather than raw chatter. Processing without explicit rules produces inconsistent intelligence quality across analysts and across cycles, and the audit cannot reconstruct what the programme actually delivered. The processing block applies four named rules between collection and analysis.

Rule 1 - Deduplication against prior intelligence record:
- Each new item is checked against the prior 90 days of intelligence on the engagement record by indicator hash, by named-actor reference, by CVE identifier, and by source-original identifier.
- Duplicates from the same source are folded with a count increment rather than added as a separate record.
- Duplicates from different sources are added as separate records but linked to a single intelligence item so the corroboration count is observable.

Rule 2 - Indicator normalisation against a controlled schema:
- Indicators of compromise (IoCs) are normalised to the named indicator type (IPv4, IPv6, FQDN, URL, file hash by hash family, JA3 fingerprint, certificate SHA-1, certificate SHA-256, registry path, mutex name, process name, mailbox header, user agent string, named adversary tradecraft signature).
- The controlled schema is held in document-management and versioned alongside the runbook.
- Indicators that cannot be normalised onto the schema are routed for schema review at the monthly programme cycle.

Rule 3 - Source-credibility tagging:
- Each processed item carries a six-band source-credibility tag derived from the Admiralty System or equivalent: completely reliable (A), usually reliable (B), fairly reliable (C), not usually reliable (D), unreliable (E), reliability cannot be judged (F).
- Item credibility is paired with information credibility (1 confirmed by other sources, 2 probably true, 3 possibly true, 4 doubtful, 5 improbable, 6 truth cannot be judged) for the standard two-character rating (A1, B2, C3, etc.).
- The rating is captured at processing and re-read at analysis so the analyst tradecraft applies the right confidence treatment.

Rule 4 - PIR linkage and product-class routing:
- Every processed item is tied to one or more named PIRs from Section 3.
- Items that do not map onto a PIR are routed for SIR or PIR review rather than dispatched.
- Each processed item carries an initial product-class routing recommendation (strategic, operational, tactical, technical, programme) read off the PIR-to-consumer matrix in Section 7.

Processing audit trail:
- Every processed item produces an activity-log entry naming the processing analyst, the timestamp, the four-rule pass status, and the disposition (kept for analysis, rejected with reason, routed for review).
- Rejected items are captured with the named rejection reason against six standard categories: confirmed false positive, non-relevant to scope, duplicate of higher-credibility item, source classification prohibits onward routing, schema unsupported (pending review), corroboration failure threshold.
- The activity log carries the full chain so the audit can read why an item did or did not enter the analysis stage.

Processing capacity safeguards:
- Processing backlog age threshold: items aged more than {{PROCESSING_BACKLOG_AGE}} hours since collection trigger a backlog review.
- Processing throughput target per analyst per cycle: {{PROCESSING_THROUGHPUT_TARGET}}.
- Backlog overrun handling: routed to programme owner for source-volume rebalance or capacity request.

6. Analysis tradecraft and confidence levels

Convert processed intelligence into analyst-rendered intelligence with structured analytic techniques and explicit confidence levels per ICD 203 conventions. Analysis without tradecraft produces unjudged assertions that the consumer cannot weight, and the audit cannot reconstruct how the analyst reached the assessment. The analysis block names the techniques, the confidence vocabulary, and the named author plus reviewer chain.

Structured analytic techniques applied per intelligence product:

Technique A - Analysis of competing hypotheses (ACH):
- Apply to attribution claims, capability assessments, and intent assessments where multiple explanations are plausible.
- Capture the hypothesis set, the evidence matrix, and the inconsistency mapping on the engagement record.
- The analytic product carries the surviving hypothesis with the explicit alternative hypotheses considered and rejected, with the rationale for rejection.

Technique B - Key assumptions check:
- Apply to every strategic and operational product before sign-off.
- Capture the named assumptions the analytic product relies on, the evidence basis for each, and the failure mode if the assumption proves wrong.
- The analytic product carries the assumptions list with the failure-mode note so the consumer can read the analytic durability.

Technique C - Devils advocate or red team analysis:
- Apply to high-impact strategic products, executive-facing assessments, and assessments that would drive material control investment.
- The rotated reviewer or a named peer analyst challenges the assessment with an alternative reading and the resulting tension is captured on the product.

Technique D - Indicators and signposts:
- Apply to forward-looking assessments (capability shifts, campaign maturation, actor pivot signals).
- Capture the named indicators that would confirm the assessment versus the named indicators that would refute it.
- The collection plan is updated to flag the indicators for monitoring.

Confidence levels per ICD 203 Analytic Standards:
- High confidence: the assessment rests on high-quality, well-corroborated information from multiple credible sources, and analytic judgement is well-supported. Confidence band typically applies when source-credibility ratings cluster at A and information credibility at 1 or 2.
- Moderate confidence: the assessment rests on credible information but with gaps in corroboration, source-credibility mix, or analytic certainty. Confidence band typically applies when source-credibility ratings cluster at B and information credibility at 2 or 3.
- Low confidence: the assessment rests on plausible but uncorroborated information, on contested information, or on analytic judgement that depends on assumptions the analyst cannot fully evidence. Confidence band typically applies when source-credibility ratings include C or below and information credibility at 3 or worse.

Confidence-level discipline:
- Every analytic product carries an explicit confidence level on the assessment as a whole and per major sub-finding where the confidence varies across the product.
- Confidence is set by the analyst and confirmed by the reviewer; disagreement on confidence is captured on the product as a noted tension.
- Confidence is paired with the source-credibility and information-credibility ratings so the consumer can read the rating chain end-to-end.

Author and reviewer chain:
- Author: the named analyst who renders the product. Capture the analyst role, the analyst name, the date of authoring.
- Reviewer (peer or rotated, depending on product class): the named role that reviews the analytic tradecraft and the confidence assignment. Capture the reviewer role, the reviewer name, the date of review.
- Sponsor or sign-off (strategic products only): the named sponsor or CISO who signs the product for dissemination. Capture the role, the name, the date.
- The chain is held on the engagement record with the activity log capturing each handoff.

Analytic product structure (every product carries a consistent structure so consumers can read across products):
- Bottom line up front (BLUF): the assessment in one paragraph with confidence level.
- Key findings: three to seven specific findings supporting the BLUF, each carrying its own confidence level where it varies.
- Evidence summary: the source-credibility-rated evidence base.
- Key assumptions and indicators: the assumptions the assessment rests on and the indicators that would confirm or refute.
- Implications and consumer recommendations: the named action set for the consumer (hunt to run, detection to deploy, finding to raise, control to validate, decision to escalate, no action).
- Sources: the source register references used.
- Attribution: the named author, the named reviewer, the sponsor sign-off where applicable, the date, the version.

Sensitivity and TLP marking on the product:
- Each product is marked at the lowest TLP value that any source contributed; if any source is TLP:AMBER, the product is TLP:AMBER unless the analyst explicitly downgrades with source authorisation.
- TLP:RED products carry the additional handling note: read-only access to the named consumer, no onward forwarding without explicit re-authorisation.

7. Intelligence product catalogue with named consumers and dissemination cadence

Define the product catalogue the programme commits to producing, who consumes each product class, and the dissemination cadence per product. Without an explicit product catalogue the programme produces whichever shape is easiest that week and the consumer cannot rely on a stable read. Five durable product classes cover the consumer landscape; cadence is set per class.

Product class 1 - Strategic intelligence (quarterly cadence; event-driven on material threat-actor shift or material capability shift):
- Named consumers: CISO, audit committee, board risk committee, enterprise procurement, executive risk forum
- Format: written brief plus presentation pack
- Length: 4 to 12 pages
- Cadence: quarterly published by end of week 2 of the quarter; event-driven dispatched within 5 business days of trigger
- Content: threat-actor and capability picture against the firm, named campaigns active in the sector, programme outcome read against the prior quarter PIR set, recommended sponsor decisions
- Sign-off: programme owner authors; sponsor or CISO signs

Product class 2 - Operational intelligence (weekly cadence; event-driven on confirmed in-sector incident or KEV addition affecting deployed components):
- Named consumers: security operations leaders, SOC manager, detection engineering lead, AppSec leadership, vulnerability management leadership, security architects, incident response leads
- Format: written briefing
- Length: 2 to 6 pages
- Cadence: weekly published by end of day Monday; event-driven dispatched within 24 hours of trigger
- Content: active campaigns affecting the sector, recently observed TTPs against in-sector firms, recommended hunts, recommended detection rule changes, recommended control validation scenarios, recommended VM prioritisation tilts
- Sign-off: senior CTI analyst authors; programme owner reviews

Product class 3 - Tactical intelligence (daily cadence for hunting prompt set; event-driven on emerging confirmed exploitation):
- Named consumers: SOC analyst rota, threat hunter rota, incident response analyst rota
- Format: structured hunting prompt set plus indicator watchlist update
- Length: 1 page per item; multiple items per day
- Cadence: daily published by 09:00 local time; event-driven dispatched within 2 hours of trigger
- Content: per-prompt hunt hypothesis with named indicator set, named telemetry channels to query, named expected output, named follow-up if positive
- Sign-off: CTI analyst authors; senior CTI analyst reviews

Product class 4 - Technical intelligence (event-driven on confirmed vulnerability disclosure, vendor advisory, supply-chain disclosure, or KEV addition):
- Named consumers: AppSec teams, product security teams, vulnerability management teams, security engineering teams
- Format: technical brief with in-estate impact assessment and recommended response
- Length: 1 to 3 pages
- Cadence: event-driven dispatched within 4 hours of trigger for in-scope critical-band advisories; within 24 hours for high-band; within 72 hours for medium and below
- Content: named CVE or advisory reference, named affected products and versions in-estate, named exploitation status (KEV, EPSS percentile, public proof-of-concept, confirmed exploitation in sector), recommended remediation pathway, recommended SLA tier
- Sign-off: CTI analyst authors; technical-product reviewer (rotated AppSec or VM engineer) reviews

Product class 5 - Programme intelligence (monthly cadence; event-driven on consumer escalation):
- Named consumers: runbook owner, governance forum, security architects, audit committee
- Format: written programme review pack
- Length: 4 to 10 pages
- Cadence: monthly published by end of week 1 of the month
- Content: PIR fitness assessment, source-credibility movement, consumer feedback summary, product-volume and cadence-adherence metrics, indicator lifecycle metrics, programme cost and contribution metrics
- Sign-off: programme owner authors and signs

Dissemination mechanics:
- Strategic and programme products dispatched to named consumer via document-management workspace with named-actor activity log on dispatch.
- Operational and tactical products dispatched via notifications-and-alerts to the named consumer rota with cadence and event-driven trigger reference.
- Technical products dispatched as findings on findings-management with the affected products, the severity band, the SLA tier, and the named owner; the technical product also dispatches a notification to the named consumer rota.
- TLP markings are preserved on every dispatch with the handling note attached.
- Dispatch produces an activity-log entry naming the product, the consumer, the timestamp, and the dispatch channel.

Product retention:
- Strategic and programme products retained per the audit evidence retention policy classification.
- Operational and tactical products retained for the relevance window plus one quarter for trend analysis.
- Technical products retained as findings on the workspace per the findings retention policy; the underlying advisory is retained in document-management against later traceability.

8. Indicator lifecycle and false-positive handling

Run the indicator watchlist as a lifecycle rather than as an ever-growing list. Watchlists that only accept additions degrade into noise because stale indicators produce false-positive alerts that consume SOC attention and erode trust in the source plan. The indicator lifecycle block defines the named states, the transition rules, and the false-positive feedback into source credibility.

Indicator lifecycle states:
- Ingested: raw indicator captured at collection, not yet rendered
- Candidate: indicator under analyst review for inclusion in the watchlist
- Confirmed: indicator passed processing and analysis; eligible for watchlist inclusion
- Active: indicator currently on the watchlist, under monitoring
- Aged-out: indicator timestamp exceeded the relevance window; removed from the active watchlist
- Suppressed: indicator analyst-rejected as false positive or non-relevant; held on the suppression list for re-suppression on recurrence

Per-class relevance windows (applied at confirmation):
- Opportunistic-campaign indicators (commodity malware C2, generic phishing infrastructure): {{OPPORTUNISTIC_WINDOW}} days, default 90
- Targeted-campaign indicators (named-actor infrastructure, named-actor tooling signatures): {{TARGETED_WINDOW}} days, default 365
- State-aligned-actor TTPs (procedure-level indicators, tradecraft signatures): indefinite with quarterly re-confirmation
- Confirmed-tool signatures (named loader, named RAT, named ransomware family signatures): indefinite with annual re-confirmation
- Sector-campaign indicators (named sector-targeting campaigns active in the wild): {{SECTOR_CAMPAIGN_WINDOW}} days, default 180

Transition rules:
- Ingested to Candidate: analyst review per the processing rules in Section 5.
- Candidate to Confirmed: analysis pass per the tradecraft rules in Section 6.
- Confirmed to Active: watchlist inclusion at the next watchlist refresh.
- Active to Aged-out: relevance window expiry without renewal; analyst can renew if continued activity is observed.
- Active to Suppressed: confirmed false positive in production telemetry; capture the rejection rationale, the rejecting analyst, the date, and the source-credibility impact.
- Suppressed to Confirmed: analyst review on recurrence with new evidence; suppression is not permanent.

False-positive feedback loop:
- Each suppression carries the named source contribution; sources that produce repeated false positives are flagged for credibility review.
- Per-source false-positive rate is read at the monthly programme cycle (Section 10 metrics).
- Sources crossing the false-positive rate threshold ({{FALSE_POSITIVE_RATE_THRESHOLD}}) are downgraded one credibility band; sources sustaining the rate over two quarters are routed to retirement review.

Indicator delivery and watchlist refresh:
- The active watchlist is refreshed at the cadence of the consuming detection layer (typically daily for SOC watchlists, weekly for AppSec dependency checks).
- Watchlist deltas (additions, aging-outs, suppressions, renewals) are captured on the engagement record at every refresh.
- The watchlist is delivered to the consumer detection layer via the agreed mechanism (export, manual transfer, named integration) with the activity log capturing the delivery.

Indicator quality safeguards:
- Confidence band on every indicator carried through to the watchlist so the detection layer can read the indicator weight.
- Source attribution preserved across the lifecycle so a positive hit can be traced to the originating source.
- Aging trend reviewed at the monthly programme cycle; if a class is aging out faster than indicators are being confirmed, the source plan is reviewed.

Indicator volume safeguards:
- Active watchlist size target by indicator class: {{ACTIVE_WATCHLIST_SIZE_TARGET}}
- Active watchlist overrun handling: triage to remove low-confidence or low-relevance items before adding new ones.

9. Feedback loop and intelligence requirement refresh

Close the loop from the consumer back to the programme so the next cycle operates against current requirements rather than stale ones. Programmes that only broadcast outputs without capturing consumer feedback drift away from consumer relevance, and the consumer reads the programme as a forwarding service rather than as decision support. The feedback block names the mechanism per product class, the read cadence, and the refresh outputs.

Per-product-class feedback mechanism:

Strategic product feedback:
- Sponsor and CISO record the strategic product reading at the quarterly review forum.
- The forum captures the actionability rating (high, moderate, low), the named decisions taken or deferred, and any requirement adjustments.
- The forum record is held on the engagement record and read into the runbook revision pass.

Operational product feedback:
- Each operational product carries a feedback thread on the engagement record.
- Consumers mark the product actionability (actionable, partially actionable, non-actionable) and the action taken (hunt executed, detection deployed, control validated, no action) within 5 business days of dispatch.
- The CTI programme reads the feedback record at the monthly programme cycle.

Tactical product feedback:
- Hunting prompt feedback is captured on the per-prompt thread on the engagement record.
- The SOC analyst rota marks the prompt outcome (hunt executed: positive, hunt executed: negative, hunt not executed: capacity, hunt not executed: deferred for review) within 2 business days of dispatch.
- The feedback is read at the weekly programme review.

Technical product feedback:
- Technical intelligence dispatches a finding on findings-management.
- The finding lifecycle (open, in remediation, closed, exception accepted) produces structural feedback at the per-finding level.
- Per-product corrective-action latency, closure-within-SLA rate, and exception rate are read at the monthly programme cycle.

Programme product feedback:
- The runbook owner and the governance forum read the monthly programme product directly.
- Programme feedback captures whether the metrics are improving, stable, or regressing against the prior cycle, and which corrective actions the forum is taking.

Feedback-driven outputs:

Output A - PIR fitness assessment (monthly):
- For each PIR: count of products produced, count rated actionable, named consumer feedback summary, refresh recommendation (retain, reword, retire).
- The assessment is captured on the programme intelligence product for the month and fed forward to the quarterly strategic cycle for the full PIR refresh.

Output B - Source-credibility update (monthly):
- For each authorised source: count of items contributed, count contributing to actionable products, count contributing to suppressed indicators, named credibility-band movement.
- Credibility movement is captured on the source register and published on the next collection plan revision.

Output C - Product-catalogue tuning record (monthly):
- For each product class: count published, on-cadence rate, consumer actionability rate, recommended format or cadence adjustments.
- Catalogue tuning is captured on the programme product and fed into the next runbook revision when the change is material.

Output D - Programme PIR refresh (quarterly):
- Read the three monthly outputs cumulatively, plus the strategic-product feedback from the quarterly review forum, plus the sponsor and CISO direction.
- Produce a refreshed PIR set: additions, retirements, rewordings, owner changes.
- Capture the refresh decision and the sponsor sign-off on the engagement record.

Feedback discipline safeguards:
- Consumer non-response on operational and tactical feedback within the named window triggers a consumer-engagement reminder; sustained non-response triggers a consumer-fitness review (is the product class still relevant for this consumer).
- Disagreement between the analyst rendering and the consumer reading is captured on the product as a noted tension rather than silently resolved one way; the tension is read into the runbook revision pass.

10. Programme metrics and quarterly governance review

Read the programme on durable indicators that move quarter over quarter so the audit committee, the board, and the sponsor can answer whether the CTI investment is producing increasing decision support. Metrics without trend produce point-in-time pictures that the next cycle reads from zero. The metrics block names twelve durable indicators and the governance forum that reads them.

Quarterly governance metrics:

Metric 1 - PIR coverage:
- Percentage of PIRs that produced at least one consumer-actionable intelligence product in the quarter.
- Target: 90% or higher; movement against prior quarter captured.

Metric 2 - Source health:
- Count of authorised sources by credibility band (A, B, C, D, E, F).
- Movement: count promoted, count demoted, count retired, count added.

Metric 3 - Indicator lifecycle:
- Volumes per state: ingested, confirmed, active, aged-out, suppressed.
- Suppression rate per source class as a trend indicator on source-plan quality.

Metric 4 - Product volume by class:
- Strategic, operational, tactical, technical, programme product counts against published cadence commitments.
- Variance from the commitment captured per class.

Metric 5 - Dissemination cadence adherence:
- Percentage of products dispatched within the cadence window (on time, within 24 hours, within 72 hours, late).
- Cadence overrun explanations captured per overrun.

Metric 6 - Consumer actionability:
- Percentage of products marked actionable in the feedback record by named consumer class.
- Movement against prior quarter; non-actionable rate trend by consumer class.

Metric 7 - Event-driven trigger volume:
- Count of triggers by class (KEV addition, PSIRT advisory, ISAC bulletin, CERT alert, incident, supply-chain disclosure, red team finding, dark-web indicator).
- Median time from trigger to first product dispatched.

Metric 8 - Cross-source corroboration rate:
- Percentage of intelligence products with corroborating signal from two or more authorised sources.
- Single-source-only product rate (a risk indicator for source diversification).

Metric 9 - False-positive rate by source:
- Rate of analyst-rejected items by source over the quarter.
- Sources crossing the threshold flagged for credibility review.

Metric 10 - Detection contribution:
- Count of detections deployed or tuned in the quarter attributed to CTI products.
- Detection-engineering feedback record read into this metric.

Metric 11 - Hunting contribution:
- Count of hunts executed or scoped against CTI-supplied hypotheses.
- Hunt outcome breakdown: positive (confirmed activity), negative (no activity found), capacity-deferred.

Metric 12 - Programme PIR refresh:
- Count of PIRs added, retired, or reworded against the prior quarter.
- Indicates programme responsiveness to the threat picture and consumer set.

Quarterly governance review forum:
- Forum membership: programme sponsor, CISO, security operations leader, runbook owner, senior CTI analyst, named consumer representatives (SOC manager, detection engineering lead, AppSec lead, VM lead, GRC lead).
- Cadence: end of week 2 of the new quarter.
- Inputs: prior quarter programme intelligence product, the twelve metrics above, the sponsor and CISO direction.
- Outputs: PIR refresh decision (Output D from Section 9), source-plan adjustments, product-catalogue adjustments, runbook revision triggers, sponsor sign-off on the new quarter operating plan.
- Forum minutes are captured on the engagement record with named-actor activity log.

Annual programme review:
- Annual metric trend across the four quarters: coverage trend, actionability trend, source-credibility trend, cadence-adherence trend, contribution trend.
- Annual PIR refresh evaluating long-running PIRs against changing programme priorities.
- Annual runbook revision pass incorporating the four quarters of lessons.
- Annual sponsor sign-off renewal.
- The annual review is captured on a dedicated engagement record and published to the audit committee.

Audit-readable artefacts per cycle:
- Runbook version with effective date and revision trigger record.
- Sign-off chain (sponsor, CISO, programme owner, runbook author).
- PIR set with refresh history.
- Source register with credibility-band history.
- Per-quarter programme intelligence product.
- Per-quarter governance forum minute book.
- Activity log entries for the full intelligence cycle per product.
- Findings raised by technical intelligence products with closure or exception record.

11. Operating cadence with calendar and event-driven triggers

Run the programme on a dual cadence: named calendar bands per product class plus named event-driven triggers that force out-of-band production regardless of calendar position. Calendar-only programmes are always one cadence interval behind the threat picture; event-only programmes burn out the analyst pool and lose the durable trend reading. The cadence block names both tracks with named time budgets.

Calendar cadence per product class:

Daily cadence (tactical):
- 09:00 local time: tactical hunting prompt set published; indicator watchlist refreshed
- End of day: SOC analyst rota feedback on prior-day prompts captured
- Time budget per cycle: 2 to 3 analyst-hours

Weekly cadence (operational):
- Monday 09:00 local time: operational briefing published
- Wednesday 14:00 local time: cross-team operational sync (CTI, SOC manager, detection engineering lead)
- Friday end of day: operational feedback captured on prior-week briefing
- Time budget per cycle: 8 to 12 analyst-hours

Monthly cadence (programme):
- Week 1 of the month: programme intelligence product published
- Week 1 governance forum: programme owner, senior CTI analyst, named consumer leads
- Week 2: PIR fitness, source-credibility, product-catalogue tuning outputs captured
- Time budget per cycle: 16 to 24 analyst-hours

Quarterly cadence (strategic):
- Week 2 of the new quarter: strategic intelligence product published
- Week 2 quarterly governance review forum
- Week 3: PIR refresh, source-plan adjustments, runbook revision triggers captured
- Sponsor sign-off on the new quarter operating plan by end of week 4
- Time budget per cycle: 40 to 60 analyst-hours

Annual cadence:
- End of Q4: annual programme review pack
- Sponsor and audit committee read of the annual pack
- Annual runbook revision pass and PIR refresh
- Sponsor sign-off renewal
- Time budget per cycle: 60 to 100 analyst-hours

Event-driven triggers (force out-of-band production regardless of calendar):

Trigger A - CISA KEV addition affecting deployed components:
- Response time budget: 4 hours from KEV addition to in-estate impact assessment
- Output: technical intelligence product to AppSec, VM, product security; tactical hunting prompt to SOC

Trigger B - Vendor PSIRT advisory with confirmed in-the-wild exploitation against deployed components:
- Response time budget: 4 hours
- Output: technical intelligence product; finding raised on findings-management

Trigger C - ISAC TLP:AMBER or TLP:RED bulletin against the sector:
- Response time budget: 24 hours (TLP:AMBER), 6 hours (TLP:RED)
- Output: operational intelligence product to authorised consumer set with TLP marking preserved

Trigger D - Internal red team or pentest finding naming an upstream TTP:
- Response time budget: 5 business days
- Output: programme intelligence product noting the TTP for PIR consideration

Trigger E - Regulator advisory or CERT alert against the sector:
- Response time budget: 24 hours
- Output: operational intelligence product; strategic intelligence product update if the advisory has board implication

Trigger F - Confirmed incident in scope:
- Response time budget: continuous IR support during the incident; post-incident programme intelligence product within 2 weeks of incident closure
- Output: tactical intelligence support during incident; PIR refresh consideration post-closure

Trigger G - Supply-chain compromise affecting a named dependency:
- Response time budget: 6 hours
- Output: technical intelligence product; operational intelligence update; programme owner briefing for CISO

Trigger H - Credible dark-web indicator surfacing against the brand:
- Response time budget: 24 hours
- Output: operational intelligence product; finding raised where the indicator suggests in-estate compromise

Trigger I - Peer-firm public incident disclosure with shared exposure shape:
- Response time budget: 5 business days
- Output: operational intelligence product reading the disclosure against in-estate exposure

Trigger J - Emerging-CVE pattern with shared exploit framework signature:
- Response time budget: 24 hours from CVE confirmation
- Output: technical intelligence product; tactical hunting prompt set

Capacity-vs-cadence safeguards:
- Event-driven trigger volume is monitored at the monthly programme cycle; sustained overrun triggers a capacity request or a trigger-threshold review.
- Calendar cadence has priority over event-driven backlog only when the event-driven response budget has been honoured; otherwise the calendar cycle is rescheduled with a documented note rather than skipped.

12. Programme governance, review, and runbook revision

Keep the runbook in sync with the programme by running explicit governance and explicit revision triggers. Runbooks that never revise read as procedure-on-paper rather than as the operating record; runbooks that revise without governance read as the analyst pool drifting away from the chartered mandate. The governance block names the forum, the cadence, and the revision triggers.

Programme governance forum (parallel to the quarterly review forum in Section 10):

Cadence: quarterly (paired with the strategic cycle) and annually (paired with the annual review).

Membership:
- Programme sponsor
- CISO
- Security operations leader
- Runbook owner
- Senior CTI analyst
- Named consumer representatives (SOC manager, detection engineering lead, AppSec lead, VM lead, GRC lead, IR lead)
- Rotated audit observer (where the firm has an internal audit function)

Standing agenda:
- Read the monthly programme intelligence products for the quarter
- Read the twelve metrics from Section 10
- Read the PIR fitness, source-credibility, product-catalogue tuning outputs
- Read the consumer feedback summary across the four product classes
- Read the event-driven trigger volume and the response-budget adherence
- Decide on PIR refresh, source-plan adjustments, product-catalogue adjustments, runbook revision triggers
- Capture sponsor sign-off on the new quarter operating plan

Runbook revision triggers (each triggers a runbook revision pass; the pass produces a versioned new runbook):
- Scheduled annual revision pass
- PIR set refresh that materially shifts the consumer mix
- Source-plan addition or retirement that materially shifts the collection plan
- Consumer feedback pattern indicating recurring product-class fitness issues
- Event-driven trigger volume sustained increase or decrease materially shifting the response-budget assumption
- Regulator change altering programme expectations
- Audit observation against the programme
- Incident post-mortem item naming the runbook as a contributor
- Sponsor or CISO direction request

Runbook revision discipline:
- The runbook author drafts the revision against the named trigger.
- The senior CTI analyst reviews the revision for analytic-tradecraft fidelity.
- The programme owner reviews the revision for operational fidelity.
- The sponsor or CISO signs the revision for governance fidelity.
- The new version is published with the effective date; the prior version is retained on document-management per the audit evidence retention classification.
- The activity log captures the revision event with the named actor, the timestamp, and the revision trigger.
- The next scheduled monthly cycle runs against the new version.

Programme metrics the audit committee receives quarterly:
- The twelve metrics from Section 10 with quarter-over-quarter trend.
- Programme cost per quarter (analyst-time plus contracted services) against the prior quarter.
- Programme contribution to detection (Metric 10), to hunting (Metric 11), to corrective action chains (count of findings raised by technical intelligence and closed within SLA), to leadership decisions (count of named decisions referenced in the strategic-product feedback record).

Annual programme metrics:
- Annual trend on the twelve durable indicators.
- Year-over-year programme cost vs. programme contribution ratio for the budget cycle.
- Notable lessons learned that landed in runbook revisions, PIR adjustments, source-plan adjustments, or wider programme adjustments.
- Year-over-year framework alignment evidence for ISO 27001 Annex A 5.7, SOC 2 CC3.2 and CC7.2, PCI DSS Requirement 6.3.1 and 12.10.1, NIST SP 800-53 RA-3 and RA-10 and SI-5 and PM-16, NIST CSF 2.0 ID.RA-2 and ID.RA-3 and DE.AE-7, NIS2 Article 21 and 23, DORA Article 6 and 13.

Programme acknowledgement:
- The runbook is the live operating procedure of the chartered CTI programme.
- The charter defines what the programme is funded to produce, the PIRs codify what the programme answers, the collection plan codifies which sources are authorised, the processing rules codify how raw signal becomes processed intelligence, the analysis tradecraft codifies how processed intelligence becomes analyst-rendered intelligence, the product catalogue codifies what gets delivered to whom on what cadence, the feedback loop codifies how consumer use refreshes the next cycle, the metrics codify how the programme reads at governance, the cadence codifies when the programme operates, and the revision discipline codifies how the runbook itself stays current.
- The ten artefacts are kept in sync on one workspace so the audit read of CTI performance, the consumer read of CTI relevance, the sponsor read of CTI value, and the operational read of CTI workload are the same record rather than ten independently edited summaries that diverge between reporting cycles.

Eight failure modes the runbook has to design against

The CTI programme fails the audit read and the consumer read in recognisable patterns. Each failure has a structural fix that the template above is designed to enforce. Read this list before you customise the runbook so the customisation does not weaken the discipline that makes the CTI evidence chain defensible.

No priority intelligence requirements at all

The CTI programme produces whichever shape is easiest that week and the consumer cannot answer what question the programme is funded to address. The inbox refresh rate sets the operating priority and analyst attention scatters across whatever advisory landed that morning. The audit reading asks how the firm knows the threat-intel investment moved decisions on a named date, and the answer collapses to a forwarded link. The fix is Section 3 instantiated against the named consumer set in Section 2, with named PIRs that name the question, the consumer, the cadence, the horizon, and the owner.

Source plan that grows without ever shrinking

New sources are added on enthusiasm and never reviewed for credibility; the analyst pool drowns in low-credibility signal that produces false-positive indicators downstream. The watchlist becomes a graveyard of stale items that erode SOC trust. The fix is Section 4 with named authorised sources per class, Section 8 with explicit suppression and aging rules, and the monthly credibility review that produces explicit promote-and-demote decisions on the source register.

Indicators that never age out

The watchlist accumulates monotonically because the programme adds confirmed indicators without ever retiring them. Stale infrastructure signatures produce false-positive alerts months after the campaign moved, and SOC analysts learn to ignore CTI-supplied indicators. The fix is per-class relevance windows in Section 8, the active-watchlist size target, and the aged-out transition rule with renewal evidence required for high-confidence indicators.

Analyst tradecraft without explicit confidence levels

Strategic and operational products assert claims without explicit confidence weighting, and the consumer cannot read the analytic durability. Two analysts produce inconsistent confidence treatments for similar evidence sets and the audit reading reads the programme as inconsistent. The fix is Section 6 with structured analytic techniques, ICD 203 confidence levels, the named author plus reviewer chain, and the source-credibility plus information-credibility rating pairing carried through to the analytic product.

Products without named consumers or named cadence

The programme dispatches whatever the analyst pool finds interesting to whichever channel feels right that week, and the consumer reads the programme as a forwarding service rather than as decision support. Strategic intelligence lands on operational consumers and tactical hunting prompts land in board packs. The fix is Section 7 with five named product classes, named consumer registries, named formats, named lengths, named cadences, and named sign-off chains.

Feedback loop that broadcasts but never listens

Products go out and the programme never reads consumer use back into the next cycle. The PIR set hardens into permanence and the programme drifts away from consumer relevance over four to eight quarters. The fix is Section 9 with per-product-class feedback mechanisms, the four feedback-driven outputs (PIR fitness, source-credibility update, product-catalogue tuning, programme PIR refresh), and the monthly-plus-quarterly read cadence.

TLP markings ignored on dispatch

Restricted intelligence (TLP:AMBER, TLP:AMBER+STRICT, TLP:RED) gets forwarded to consumers outside the authorised set, and the firm breaches the sharing contract with the originating source. ISAC membership becomes contractually contested and the source plan loses credibility. The fix is Section 4 with named TLP marking per source class, Section 6 with TLP carried onto the product at the lowest contributing source value, and Section 7 with TLP preservation through the dispatch chain.

Runbook that never revises

The runbook publishes at programme launch and freezes; the threat picture, the consumer set, the source plan, the regulatory expectation, and the programme cost all move underneath while the runbook reads against year-one assumptions. The audit reads the programme as procedure-on-paper. The fix is Section 12 with named revision triggers (PIR refresh, source-plan change, consumer feedback pattern, regulator change, audit observation, sponsor direction) and the versioned revision pass with named author, reviewer, and signatory.

Ten questions the quarterly governance review has to answer

Operational review keeps the runbook current at the cycle level. Governance review answers whether the programme is delivering durable decision support or accumulating volume without consumer relevance. Run these ten questions at every quarterly review and capture the answers in the governance record on the workspace.

1.How many PIRs did the programme answer with consumer-actionable intelligence in the quarter, and how does the count compare to the prior quarter.
2.Which PIRs produced zero consumer-actionable products in the quarter, and what is the runbook owner plan (retain, reword, retire).
3.Which authorised sources moved between credibility bands in the quarter, and what is the source-plan adjustment.
4.What is the active-watchlist size by indicator class against the target, and how is aging-out tracking against confirmation.
5.What is the dissemination cadence adherence rate per product class, and which cadences sustained overrun for two or more cycles.
6.What is the consumer-actionability rate by named consumer class, and which consumer-class trend warrants a product-catalogue tuning.
7.What is the event-driven trigger volume by class, and what was the median time from trigger to first product against the response-time budget.
8.How many detections were deployed or tuned in the quarter attributable to CTI products, and what is the trend.
9.How many hunts were executed against CTI-supplied hypotheses in the quarter, and what was the positive-outcome rate.
10.How many findings did the technical intelligence product class raise in the quarter, and what is the closure-within-SLA rate against the VM closure record.

How the package pairs with SecPortal

The template above is copy-ready as a standalone artefact. If your team already runs engagement records, document custody, and finding tracking on a workspace, the CTI programme record becomes a byproduct of the work rather than a separate evidence project. SecPortal pairs every intelligence product to a versioned engagement record through engagement management, so the runbook identifier, the PIR set, the source authorisation, the analyst-rendered product, the dispatch cadence, the consumer feedback, and the framework anchor live alongside the rest of the security record rather than scattered across a chat channel, a wiki page, and a shared inbox.

The document management feature holds the runbook itself, the strategic and programme product packs, the source register, the indicator schema, the analytic-product evidence base from Section 6, and every prior runbook version retained per the audit evidence retention policy. Access to each document is gated by role-based access control through team management and protected by multi-factor authentication. The activity log captures the timestamped chain of state changes by user with 30, 90, or 365-day retention windows depending on the plan, so the collection event, the processing pass, the analytic-product authoring, the reviewer sign-off, the dispatch, and the consumer feedback are all observable rather than asserted. The notifications and alerts feature dispatches the daily tactical prompts, the weekly operational briefing, the event-driven trigger pages, and the cadence reminders to the analyst pool and the named consumer rota with the same audit trail.

Technical intelligence products land as findings on findings management alongside vulnerability findings from external, authenticated, and code scanning, each carrying a CVSS-aligned severity, a named owner, a target close date, and an evidence-of-closure requirement so the consumer can read the technical product into the corrective action chain directly. Bulk finding import supports CSV-based ingestion of vendor PSIRT advisories, KEV catalog updates, and ISAC bulletin findings so the technical product class lands on the workspace at the cadence the source publishes rather than at the analyst rota cadence. The continuous monitoring feature operates the recurring scan cadence the in-estate exposure picture reads against, so the technical product can name the affected components from the same record the VM and AppSec teams are operating against. The compliance tracking feature maps the CTI programme records to ISO 27001 Annex A 5.7, SOC 2 CC3.2 and CC7.2, PCI DSS Requirement 6.3.1 and 12.10.1, NIST SP 800-53 RA-3 and RA-10 and SI-5 and PM-16, NIST CSF 2.0 ID.RA-2 and ID.RA-3 and DE.AE-7, NIS2 Article 21 and 23, and DORA Article 6 and 13 with CSV export, so when an auditor asks how the firm operates a chartered threat intelligence function, the runbook version, the PIR set, the source register, the governance forum minute book, the per-quarter programme intelligence product, and the corrective action chain are one query against the same data. The AI report generation workflow produces a draft strategic intelligence brief, a draft operational briefing, and a draft quarterly governance review pack from the same engagement data so the audit committee read of CTI performance, the sponsor read of CTI value, and the operational read of CTI workload are the same record rather than three independently edited summaries.

SecPortal is not a threat intelligence platform (TIP), is not a SIEM, is not a SOAR, is not a managed detection and response service, does not ingest STIX or TAXII feeds, does not run analyst-grade dark-web crawlers, does not federate to MISP, does not ship native connectors into Jira or ServiceNow or Slack or PagerDuty or Splunk or Microsoft Sentinel or Google Chronicle or IBM QRadar or CrowdStrike Falcon Intelligence or Mandiant Advantage or Recorded Future or ZeroFox or Flashpoint or Anomali ThreatStream or ThreatConnect, does not auto-enrich indicators against public reputation APIs, and does not run live ATT&CK heatmaps. The analysts run the intelligence cycle; the runbook codifies the procedure; SecPortal carries the durable workspace record the intelligence cycle produces and the audit reads after. For the operational workflow that consumes the tactical and technical product classes, pair with the threat-intelligence-driven prioritisation workflow and the zero-day and emergency response workflow. For the parallel detection-engineering reading the operational product class supplies, see the breach and attack simulation explainer and the extended detection and response explainer. For the cycle-level exposure-decision discipline the strategic product class supports, see the continuous threat exposure management explainer. For the live VM consumer of the technical product class, see the CISA KEV catalog vulnerability management guide and the EPSS score explained guide. For the compliance anchors the programme records feed, see the framework pages for ISO 27001, SOC 2, PCI DSS, NIST SP 800-53, NIST CSF 2.0, NIS2, DORA, and MITRE ATT&CK.

Buyer and operator pairing

The CTI programme runbook is the operating procedure internal security teams, security operations leaders, SOC analysts, detection engineering teams, AppSec teams, product security teams, vulnerability management teams, security engineering teams, GRC and compliance teams, security architects, incident response leads, and CISOs and security leaders run when a CTI function has to survive an audit, a regulator inquiry, a board read, and a consumer-relevance read at the same time. External providers (MSSPs, virtual CISOs, security consultants) use the same package to give clients a chartered CTI procedure that meets framework expectations rather than a one-page checklist fragment per client.

Loading tool...

Related features

Orchestrate every security engagement from start to finish

Document management for every security engagement

Every action recorded across the workspace

Vulnerability management software that tracks every finding

Bulk finding import bring your scanner data with you

Collaborate across your entire team

Multi-factor authentication on every workspace

Compliance tracking without a full GRC platform

Notifications and alerts for the people who carry the work

AI-powered reports in seconds, not days

Monitor continuously catch regressions early

Threat intelligence driven vulnerability prioritisation

Continuous Threat Exposure Management

Security leadership reporting

Security testing program management

Zero-day and emergency vulnerability response

Vulnerability prioritisation

Incident response

Security debt portfolio management

Run the CTI programme on the live workspace, not on chat forwards and slide decks

SecPortal pairs every intelligence product to a versioned engagement record so the runbook, the PIR set, the source authorisation, the analyst-rendered products, the dispatch cadence, the consumer feedback, and the corrective action chain all live on one workspace with named-actor activity log. Free plan available.

Get Started Free

No credit card required. Free plan available forever.

Threat Intelligence Program Runbook Templatetwelve sections that turn ad hoc threat intel forwarding into a defensible operating record

Twelve sections that turn ad hoc threat intel forwarding into a defensible operating record

1. Runbook header and version control

2. Programme charter, mandate, and authority

3. Priority intelligence requirements and standing intelligence requests

4. Collection plan with authorised sources and TLP handling

5. Processing rules and analyst-rendering discipline

6. Analysis tradecraft and confidence levels

7. Intelligence product catalogue with named consumers and dissemination cadence

8. Indicator lifecycle and false-positive handling

9. Feedback loop and intelligence requirement refresh

10. Programme metrics and quarterly governance review

11. Operating cadence with calendar and event-driven triggers

12. Programme governance, review, and runbook revision

Eight failure modes the runbook has to design against

No priority intelligence requirements at all

Source plan that grows without ever shrinking

Indicators that never age out

Analyst tradecraft without explicit confidence levels

Products without named consumers or named cadence

Feedback loop that broadcasts but never listens

TLP markings ignored on dispatch

Runbook that never revises

Ten questions the quarterly governance review has to answer

How the package pairs with SecPortal

Buyer and operator pairing

Related features

Orchestrate every security engagement from start to finish

Document management for every security engagement

Every action recorded across the workspace

Vulnerability management software that tracks every finding

Bulk finding import bring your scanner data with you

Collaborate across your entire team

Multi-factor authentication on every workspace

Compliance tracking without a full GRC platform

Notifications and alerts for the people who carry the work

AI-powered reports in seconds, not days

Monitor continuously catch regressions early

Threat intelligence driven vulnerability prioritisation

Continuous Threat Exposure Management

Security leadership reporting

Security testing program management

Zero-day and emergency vulnerability response

Vulnerability prioritisation

Incident response

Security debt portfolio management

Run the CTI programme on the live workspace, not on chat forwards and slide decks

Twelve sections that turn ad hoc threat intel forwarding into a defensible operating record

1. Runbook header and version control

2. Programme charter, mandate, and authority

3. Priority intelligence requirements and standing intelligence requests

4. Collection plan with authorised sources and TLP handling

5. Processing rules and analyst-rendering discipline

6. Analysis tradecraft and confidence levels

7. Intelligence product catalogue with named consumers and dissemination cadence

8. Indicator lifecycle and false-positive handling

9. Feedback loop and intelligence requirement refresh

10. Programme metrics and quarterly governance review

11. Operating cadence with calendar and event-driven triggers

12. Programme governance, review, and runbook revision

Eight failure modes the runbook has to design against

No priority intelligence requirements at all

Source plan that grows without ever shrinking

Indicators that never age out

Analyst tradecraft without explicit confidence levels

Products without named consumers or named cadence

Feedback loop that broadcasts but never listens

TLP markings ignored on dispatch

Runbook that never revises

Ten questions the quarterly governance review has to answer

How the package pairs with SecPortal

Buyer and operator pairing

Threat Intelligence Program Runbook Template
twelve sections that turn ad hoc threat intel forwarding into a defensible operating record