Use Case

Threat intelligence driven vulnerability prioritisation
CTI signals operationalised into the queue, not into a spreadsheet

Most vulnerability programmes consume threat intelligence by reading the CISA KEV catalog every morning and forwarding interesting CERT advisories into Slack. The intel arrives, but the prioritisation queue does not change. Run threat intelligence driven vulnerability prioritisation as a structured workflow on the engagement record so every CTI signal (KEV listing, EPSS percentile shift, CERT or vendor advisory, ISAC bulletin, internal red team finding, sector-specific exploit chatter) is ingested as an explicit input, fitness-assessed against the in-scope estate, converted into a recorded prioritisation action with a named decider, routed to the named owner, and fed back into the next ingest cycle on the same trail the auditor and the audit committee read.

Get Started Free

No credit card required. Free plan available forever.

Operationalise threat intelligence into the prioritisation queue, not into a chat channel

Most vulnerability programmes consume threat intelligence by reading the CISA KEV catalog every morning and forwarding interesting CERT advisories into Slack. The intel arrives, but the prioritisation queue does not change. The KEV addition is noted; the queue keeps running on its CVSS-base ordering. The vendor PSIRT advisory is forwarded; the affected components in the deployed estate are not catalogued. The ISAC bulletin lands with counsel under TLP:AMBER and never reaches the vulnerability management team. Six months later an audit asks how the programme operationalised a specific advisory, and the answer is a multi-week reconstruction across email and chat that produces a thinner story than the team actually lived. Run threat intelligence driven vulnerability prioritisation as a structured workflow on the engagement record so every signal is ingested as an explicit input, fitness-assessed against the in-scope estate, converted into a recorded prioritisation determination, routed to the named owner, and fed back into the next ingest cycle on the same trail the auditor and the audit committee read.

This workflow composes with the rest of the security operating model. The broader prioritisation policy that combines CVSS, EPSS, KEV, asset criticality, exposure, and compensating controls runs on the vulnerability prioritisation workflow. The single-CVE emergency response loop that opens when a new critical advisory drops on a Friday afternoon runs on the zero-day and emergency vulnerability response workflow. The asset criticality classification the fitness assessment reads against rides on the asset criticality scoring workflow. The owner mapping the routing layer reads against runs on the asset ownership mapping workflow. The product-security-side coordination for downstream-affected customers rides on the PSIRT workflow.

Eight intelligence sources the workflow ingests as structured signals

A modern vulnerability programme reads against multiple intelligence sources concurrently. Each source carries different latency, different reliability, and different handling constraints. The engagement holds every applicable source as an explicit object so the prioritisation determination can cite the originating signal cleanly when the audit, the insurer, or the regulator reads back the chain.

Source	Signal class	Operational use
CISA Known Exploited Vulnerabilities (KEV) catalog	Public catalog of CVEs with confirmed in-the-wild exploitation. The single strongest exploitation signal a prioritisation queue can carry. KEV additions, due-date assignments, and the periodic updates the catalog publishes are the operational triggers.	Each KEV addition is logged on the engagement with the CVE, the addition date, the CISA-assigned remediation due date for federal civilian executive branch agencies (a useful enterprise benchmark), and the affected component and version range. The fitness assessment converts the listing into a per-asset exposure picture so the engagement can track whether the affected component is present in the connected repositories or on running systems behind verified domains.
EPSS exploit prediction (FIRST)	A daily-updated probability estimate that a CVE will be exploited within thirty days based on real-world exploitation data. EPSS separates the small set of CVEs that are likely to be exploited from the much larger set that are theoretically severe but rarely targeted.	EPSS is queried per CVE rather than ingested as a feed. When a finding is logged, the platform-side workflow stamps the EPSS percentile against the underlying CVE so the prioritisation determination uses the live estimate. Programmes that snapshot EPSS at intake and never refresh end up running on six-month-old probability estimates that no longer reflect current exploitation patterns.
Vendor PSIRT advisories and security bulletins	Vendor-issued advisories for products in the deployed estate (operating system vendors, application vendors, runtime vendors, library maintainers, cloud platform PSIRTs). Often the earliest signal because the vendor is fixing the issue before public disclosure.	Each vendor advisory the programme tracks lands on the engagement as a signal with the vendor identifier, the advisory ID, the date observed, and the affected products list. Document management retains the advisory text against later source-link rot. The fitness assessment uses repository connections and the deployed estate map to convert the advisory into the in-scope asset picture.
Sector ISAC and ISAO bulletins	Sector-specific intelligence sharing from FS-ISAC (financial services), H-ISAC (healthcare), Auto-ISAC (automotive), Aviation ISAC, IT-ISAC, MS-ISAC (state and local government), and equivalent regional bodies. Sector intel often references attacker tradecraft and exploit chatter that does not surface in public catalogs for weeks.	Each bulletin is logged with the issuing ISAC, the bulletin reference, the sharing classification (TLP:CLEAR, TLP:GREEN, TLP:AMBER, TLP:RED), and the relevance assessment. Privileged bulletins (TLP:AMBER and TLP:RED) carry an explicit handling note on the engagement so onward sharing respects the originating constraints.
Regional CERT and CSIRT alerts	CISA alerts, NCSC UK alerts, BSI advisories, ENISA advisories, JPCERT/CC bulletins, ACSC alerts, CCCS bulletins, CERT-EU advisories, and equivalent regional bodies. CERT alerts often pair the technical detail with attribution context and sector-specific advisories that public catalogs lack.	Each CERT or CSIRT alert is logged with the issuing body, the alert reference, the date observed, and the analyst-rendered relevance assessment. The fitness assessment converts the alert into the in-scope picture with the same scanner and asset workflow as the other sources.
Internal red team and penetration test findings	Findings from internal red team operations, contracted penetration tests, and bug bounty submissions on assets the programme operates. Internal findings often surface chained vulnerabilities and tradecraft that external feeds miss.	Internal findings already live on the engagement workspace through the engagement record. The CTI workflow treats them as first-class intelligence inputs alongside external feeds: the prioritisation determination cites the originating engagement and reads the same SLA tier logic against the finding identifier.
Supplier and third-party security advisories	Advisories from third-party suppliers in the supply chain (managed service providers, cloud providers, SaaS vendors, hardware vendors, library maintainers). Often the earliest signal of a supply-chain compromise affecting the deployed estate.	Each supplier advisory is logged on the engagement with the supplier identifier, the advisory reference, the date observed, and the contractual notification path. Document management holds the advisory artefact and the supplier correspondence so the chain of custody is reconstructable when a regulator or insurer asks how the programme learned about a supplier-side incident.
Contracted dark-web and chatter monitoring outputs	Outputs from contracted services that monitor dark-web forums, ransomware leak sites, exploit marketplaces, and threat actor chatter. The signal class is noisy and requires analyst rendering, but it is often the earliest indicator of an active exploitation campaign.	Outputs are filtered through analyst rendering before they land on the engagement so the prioritisation queue does not chase unverified chatter. When the rendering produces a credible signal, it is logged with the contracted service identifier, the analyst rendering note, and the relevance assessment. The original raw chatter excerpt is held in document management for later traceability without being treated as authoritative on its own.

Six failure modes that quietly break threat intelligence programmes

Most CTI failures do not look like failures while they are happening. They look like sensible defaults: read the catalog, forward the alert, post in chat. The cost arrives months later as an unmodified queue, an unanswered audit ask, or an exposure that the programme had the intel to prioritise but did not.

Intel arrives but the queue does not change

The team reads CISA KEV every morning and forwards interesting CERT advisories into Slack. The prioritisation queue keeps running on its CVSS-base ordering. The fix is making CTI ingest a structured action that produces a recorded prioritisation determination on the engagement, not an informational post in a chat channel that nobody is required to act on.

EPSS is snapshotted at intake and never refreshed

A team integrates EPSS scoring at first import and treats the value as static. Six months later the queue is using a six-month-old probability estimate that no longer reflects current exploitation patterns. EPSS is updated daily and the prioritisation logic has to read the live estimate, not the snapshot taken at the moment of import.

KEV listings get checked at the end of triage rather than at the start

Findings that should have been escalated to the tightest SLA tier sit in the standard queue for weeks before someone notices the underlying CVE landed in KEV. The fix is making KEV a queue-entry signal so KEV-listed findings carry the tightest SLA from the moment they land, with the listing date and the CISA due date stamped against the finding for the determination trail.

CTI provenance is lost the moment the signal is acted on

A CERT alert prompts an emergency prioritisation; the team patches the affected systems and closes the loop. Six months later an audit asks what evidence the prioritisation read against; the team cannot reconstruct which alert, on which date, with which content. The fix is recording the source identifier, the source link, the ingest date, and the original content excerpt in document management so the determination chain stays defensible.

Sector ISAC bulletins sit in a counsel inbox and never reach prioritisation

TLP:AMBER and TLP:RED bulletins land with general counsel or with the chief privacy officer because of contractual handling restrictions. The vulnerability management team never sees them and the prioritisation queue is blind to the sector-specific intel. The fix is naming the privileged-intel handler on the engagement, capturing the TLP classification at ingest, and routing the rendering through a permissioned engagement view so the operational signal reaches the queue without violating the sharing constraints.

Threat-intelligence requirements are written once and never reviewed

The PIR/TIR list was written when the programme stood up. Eighteen months later the business has shifted to a new product line, a new compliance regime, a new geographic market, and a new supplier panel. The PIRs still talk about the old estate. The fix is reviewing the PIR/TIR list on a documented cadence (often quarterly with a board read-out, plus trigger-driven reviews when business context shifts) so the intel programme keeps reading against the current programme rather than the legacy programme.

Six fields every prioritisation determination has to record

A defensible prioritisation determination is six concrete fields on the engagement, not a narrative line in a Slack message. The fields make the determination chronology reconstructable when an auditor, an insurer, or a regulator asks how the programme reached the SLA tier it operated against.

Source identifier and provenance

The source the determination read against (KEV addition, EPSS shift, CERT alert reference, vendor PSIRT advisory, ISAC bulletin reference, internal finding identifier, supplier advisory reference, contracted-service rendering note), the date observed, the analyst who logged the signal, the source link, and the document management reference for the upstream artefact. Provenance is the root of every later defensibility check.

Fitness assessment scope and result

The scanner runs the fitness assessment commissioned (code scans across connected repositories, authenticated DAST against verified domains, external scans against the asset estate), the date and time of each scan, the in-scope asset count examined, and the affected asset list the assessment produced. The fitness assessment is what converts a generic CTI signal into a programme-specific exposure picture; without it the determination is operating on broadcast information.

SLA tier and criteria applied

The SLA tier the determination moves the affected findings into (immediate, accelerated, standard, monitoring, no-change), and the explicit criteria the decision read against (KEV listing on internet-facing crown jewel, EPSS percentile crossing the programme threshold, CERT advisory aligned with active sector-specific exploitation, vendor advisory with concrete patch availability, internal finding with chained exploitation path). Criteria are recorded as enumerable rules from the prioritisation policy rather than as narrative text so the audit can read the rule against the determination.

Named decider, dissent, and timestamp

The named decider for the determination (typically the vulnerability management lead, the on-call CTI analyst, or the security operations leader depending on the signal class), any dissenting views captured during the deliberation, the deliberation duration, and the determination timestamp. Dissent is captured rather than suppressed because the artefact is what shows the deliberation was substantive when a regulator, auditor, or insurer asks how the determination was reached.

Affected finding identifiers and routing

The list of affected finding identifiers the determination cites explicitly so the routing layer does not have to guess scope, the named owners the routing assigns each finding to, and the response decision the routing expects (patch upstream, deploy mitigation, apply workaround, accept with exception register, decommission). Routing is the bridge between the prioritisation determination and the remediation work; without explicit citation the queue drift is undetectable.

Re-evaluation triggers and chronology

The named re-evaluation triggers that would reopen the determination (new EPSS percentile shift, new KEV addition, scope expansion from the next fitness scan, vendor advisory amendment, sector ISAC bulletin update), the cadence on which the determination is re-read, and the chronology of subsequent determinations stitched against the original. Each re-evaluation produces a fresh determination; nothing is edited in place so the chronology is reconstructable as the chain of decisions actually rendered.

Eight queues the engagement runs in parallel during the active programme cycle

During an active programme cycle the engagement runs eight queues concurrently. Each queue has a named owner, a documented cadence, and an unresolved-item escalation rule so signals do not fall behind the cadence between weekly reads.

Open KEV signals queue, with the ingest date, the affected component, the CISA-assigned due date for FCEB benchmarking, the in-scope asset count from the fitness assessment, and the routed work status.
Open EPSS-shift signals queue, with the percentile crossing event, the underlying CVE, the affected finding count from the fitness assessment, and the determination trail.
Open CERT and CSIRT advisory queue, with the issuing body, the alert reference, the relevance assessment, and the routed work status.
Open vendor PSIRT advisory queue, with the vendor identifier, the advisory ID, the affected products list, the patch availability status, and the routed work status.
Open ISAC and ISAO bulletin queue, with the issuing body, the bulletin reference, the TLP classification, the privileged-handler assignment, and the rendered relevance assessment.
Open supplier and third-party advisory queue, with the supplier identifier, the advisory reference, the contractual notification path, and the routed work status.
Internal red team and penetration test feeder queue, with the originating engagement reference, the intel-class finding identifiers, and the cross-engagement routing assignments.
Determination chronology queue, with every prioritisation determination across the active week, the named decider, the deliberation note, and the routed-work outcome ready for the weekly programme read.

How threat intelligence driven prioritisation runs in SecPortal

The CTI workflow rides on the same feature surfaces the rest of the vulnerability programme already uses. The programme cycle opens as an engagement on the workspace, every ingested signal lands as an explicit object, document management holds the upstream advisory artefacts, scanner runs produce the fitness assessment, findings management holds the affected scope, the activity log captures every state change, and AI report generation composes the operational read for the security operations leader, the CISO, and the audit evidence pack from the live record.

Programme cycle as an engagement

The CTI programme opens on the engagement record with the named programme owner, the cycle scope, the PIR/TIR list, and the source allowlist. Every ingested signal lands as an object on the engagement so the chain of decisions stays queryable.

Signal ingest with provenance

Each KEV addition, EPSS shift, CERT advisory, vendor PSIRT bulletin, ISAC alert, internal finding, supplier advisory, or contracted-service rendering is logged with source identifier, ingest date, analyst attribution, and the original source link. The artefact lives in document management for traceability against later source-link rot.

Fitness assessment via scanners

Code scans against connected GitHub, GitLab, and Bitbucket repositories, authenticated DAST against verified domains, and external scans on continuous monitoring schedules convert the broadcast signal into the in-scope asset picture.

Determination decision register

Each determination logs as a structured row with source identifier, fitness scope, SLA tier, criteria applied, named decider, dissent, timestamp, affected finding identifiers, routing assignments, and re-evaluation triggers. Re-evaluations produce fresh rows so the chronology is reconstructable.

Findings cited explicitly

Findings management holds every affected finding with CVSS 3.1 vector and the SLA tier the determination assigned. The determination cites finding identifiers explicitly so the routing layer does not have to guess scope.

RBAC across the CTI handlers

Team management scopes engagement access to the named CTI analyst, the vulnerability management lead, the security operations leader, and the privileged-intel handler. TLP:AMBER and TLP:RED material is isolated by access scoping so the handling note stays defensible.

Notifications surface accelerated work

Notifications push the routed accelerated findings to the named owners on a documented cadence so shortened SLAs do not drift back into the standard backlog by accident.

AI operational and audit reads

AI report generation composes the weekly programme read for the security operations leader, the CISO briefing, the board read-out, and the audit evidence pack from the live engagement record. Reports regenerate so the operational and the audit views never disagree on the underlying chronology.

Activity log evidence chain

The activity log captures every ingest, fitness assessment, determination, routing, verification, and re-evaluation event with timestamp and user attribution. The CSV export is the inquiry-response evidence chain for ISO 27001, SOC 2, NIST 800-53, PCI DSS, NIS2, and DORA assessor reads.

Five reads the CTI engagement actually drives

The reads that drive CTI work are not the static glossy threat report and the static annual risk assessment deck. They are the live views the security operations leader, the CTI analyst, the vulnerability management lead, and the audit-committee secretary use between meetings. The five below are the ones every meaningful CTI engagement settles on, and they all derive from the live engagement record rather than a parallel spreadsheet extract.

Open accelerated work by SLA tier

Every accelerated finding with the originating CTI signal, the SLA deadline, the named owner, and the response decision. The view the vulnerability management lead reads against the calendar.

Determination chronology

Every determination row with source, fitness scope, SLA tier, criteria, decider, dissent, conclusion, and timestamp. The view the audit committee reads to understand how prioritisation evolved as new intel matured.

Source-by-source ingest read

Every source on the allowlist with ingest counts, fitness-assessment latency, accelerated determinations produced, and time-to-verification for routed work. The view the programme owner reads to assess source value at the quarterly review.

PIR/TIR coverage matrix

Every PIR with the TIRs it decomposes into, the sources bound to each TIR, the signals ingested in the cycle, and the prioritisation actions taken. The view the CISO reads to verify the intelligence programme is reading against the current business context, not the legacy one.

Activity log export

Every state change across ingest, fitness assessment, determination, routing, verification, and re-evaluation with timestamp and user attribution. The CSV export is the evidence trail the audit and the inquiry response read against.

What auditors and supervisory authorities expect

Threat intelligence work shows up in audit reads whenever an external assessor reviews vulnerability management, threat-awareness programme operation, or risk-monitoring capability. The frameworks below all expect evidence that covers the source allowlist, the ingest log, the fitness assessment chain, the determination chronology, and the routed-work verification.

Framework	What the audit expects
ISO 27001:2022	Annex A 5.7 (threat intelligence) is the explicit control the workflow produces evidence against. Annex A 5.5 (contact with authorities), 5.6 (contact with special interest groups), 5.23 (information security for use of cloud services), 5.30 (ICT readiness for business continuity), 8.8 (management of technical vulnerabilities), 8.16 (monitoring activities), and 5.24-5.28 (incident management) all read against the same engagement record. The PIR/TIR list, the source allowlist, the ingest log, the fitness assessments, and the determination chronology are the surveillance-audit evidence chain.
SOC 2 Trust Services Criteria	Common Criteria CC2.x (communication and information), CC3.x (risk assessment, particularly CC3.2 risk identification and CC3.4 risk monitoring), CC7.1 (the entity uses detection and monitoring procedures to identify changes that could result in introduction of new vulnerabilities), CC7.2 (the entity monitors system components and the operation of those components for anomalies), and CC7.3 (the entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives) all read against the CTI ingest, the determination register, and the routed-work evidence.
NIST CSF 2.0	The IDENTIFY function (ID.RA, risk assessment, particularly ID.RA-02 cyber threat intelligence is received from information sharing forums and sources; ID.RA-03 internal and external threats to the organization are identified and recorded) and the DETECT function (DE.AE, anomalies and events analysis; DE.CM, security continuous monitoring) are the framework backbone the workflow produces evidence against. The GOVERN function (GV.OC, organisational context; GV.RM, risk management strategy) is what the PIR/TIR list and the source allowlist sit inside.
NIST SP 800-53 Rev. 5	PM-15 (security and privacy groups and associations), PM-16 (threat awareness program), RA-3 (risk assessment), RA-5 (vulnerability monitoring and scanning), RA-10 (threat hunting), SI-5 (security alerts, advisories, and directives), and AU-6 (audit record review and analysis) are the controls the assessor reads against. The engagement record holds the threat awareness programme evidence, the alert ingest log, the determination chronology, and the routed-work evidence the controls all expect.
PCI DSS v4.0	Requirement 6.3.1 (security vulnerabilities are identified using industry-recognised sources for security vulnerability information), 6.3.3 (all system components are protected from known vulnerabilities by installing applicable security patches), 11.3 (external and internal vulnerabilities are regularly identified, prioritised, and addressed), 12.10.5 (alerting from security monitoring systems is responded to), and 12.5.2 (PCI DSS scope is documented and confirmed annually) all expect the threat intelligence ingest evidence the workflow produces.
CIS Controls v8.1	Safeguard 7.1 (establish and maintain a vulnerability management process), 7.2 (establish and maintain a remediation process), 17.1 (designate personnel to manage incident handling), 17.2 (establish and maintain contact information for reporting security incidents), and 17.4 (establish and maintain an incident response process) are the operating reads. The PIR/TIR list, the source allowlist, the ingest log, and the determination chronology are the implementation evidence the auditor reads against.
NIS2 Directive and DORA	NIS2 Article 21 (cybersecurity risk-management measures, particularly the use of cryptography, the human resources security, and the supply chain security obligations) and DORA Article 13 (learning and evolving, including the threat intelligence-sharing posture under Articles 45-49) read against the CTI workflow. The engagement record holds the ingest log per source, the analyst-rendered determinations, the routed-work evidence, and the post-event learning loop the supervisory authority reads when assessing the operational maturity.

Where threat intelligence sits in the rest of the security operating model

Threat intelligence driven prioritisation is a structured workflow that composes with the rest of the security programme. The intel feeds the prioritisation policy; the policy re-orders the queue; the queue drives the routed remediation; the verification feeds the next cycle. None of the pieces work as well alone as they do together.

Upstream and adjacent

The asset criticality classification rides on the asset criticality scoring workflow, the named-owner mapping rides on the asset ownership mapping workflow, and the broader prioritisation policy lives on the vulnerability prioritisation workflow.

Downstream and reporting

The single-event emergency response triggered by a critical advisory rides on the zero-day and emergency response workflow, the SLA enforcement runs on the vulnerability SLA management workflow, and the leadership read-out lands on the security leadership reporting workflow.

Pair the workflow with the long-form guides and the framework references

Threat intelligence driven prioritisation is operational. The surrounding long-form guides explain the underlying signals and the broader operating model the workflow has to satisfy. Pair this workflow with the CISA KEV catalog vulnerability management guide for the catalog operating model, the EPSS score explained guide for the percentile semantics, the SSVC stakeholder-specific vulnerability categorisation guide for the decision-tree framing, the reachability analysis prioritisation guide for the code-level reachability layer, the vulnerability prioritisation framework for the broader policy structure, and the risk-based vulnerability management buyer guide for the platform evaluation criteria. The framework references that mandate threat intelligence evidence include the ISO 27001 framework page, the SOC 2 framework page, the NIST CSF 2.0 framework page, the NIST SP 800-53 framework page, the CISA CPGs framework page, the PCI DSS framework page, the NIS2 framework page, and the DORA framework page.

Buyer and operator pairing

Threat intelligence driven prioritisation is the workflow vulnerability management teams run as the operational pipeline, security operations leaders read as the source-by-source value assessment, internal security teams run as the determination chronology backbone, CISOs read as the PIR/TIR coverage matrix at the quarterly review, and GRC and compliance teams read as the audit evidence chain when the next ISO 27001 surveillance, SOC 2 examination, NIST 800-53 review, or PCI DSS assessment lands.

What good threat intelligence driven prioritisation feels like

Every signal lands as a record

No signal lives only in chat. The KEV addition, the EPSS shift, the CERT advisory, the ISAC bulletin, and the vendor PSIRT alert all land on the engagement with provenance, ingest date, and analyst attribution.

Fitness scopes are programme-specific

A KEV addition is not treated as urgent for the entire backlog by default. The fitness assessment converts the signal into the in-scope picture so the prioritisation determination is rendered against the deployed estate rather than against the broadcast advisory text.

Determinations evolve as a chain

Prioritisation is not decided once. New EPSS shifts, KEV additions, scope expansions, and vendor advisory amendments produce fresh determinations on the engagement; the chronology is reconstructable as the chain of decisions actually rendered.

Audit reads from one record

The PIR/TIR list, the source allowlist, the ingest log, the fitness assessments, the determination chronology, and the routed-work evidence all read from the same engagement. ISO 27001, SOC 2, NIST, PCI DSS, NIS2, and DORA assessors get the evidence as a query rather than a multi-week reconciliation sprint.

Threat intelligence driven vulnerability prioritisation is the structured workflow the vulnerability management lead, the CTI analyst, the security operations leader, and the GRC team all read against. Run it on one engagement record so every ingested signal, every fitness assessment, every determination, every routed work item, and every verification lives on a single trail rather than scattered across catalog reads, forwarded advisories, and chat-channel posts. For the programme cycle that sequences this CTI ingest alongside Scoping, Discovery, Validation, and Mobilisation as one continuous exposure-reduction operating model, pair this workflow with the CTEM cycle workflow.

Frequently asked questions about threat intelligence driven prioritisation

What is threat intelligence driven vulnerability prioritisation as a workflow?

Threat intelligence driven vulnerability prioritisation is the structured operating discipline that ingests external and internal threat intelligence signals (CISA KEV listings, EPSS percentile shifts, CERT and CSIRT advisories, vendor PSIRT bulletins, sector ISAC alerts, internal red team findings, supplier advisories, contracted dark-web monitoring outputs) into the vulnerability management programme as explicit inputs, fitness-assesses them against the in-scope estate, renders prioritisation determinations with named deciders and explicit criteria, routes accelerated findings to named owners, and feeds verification evidence back into the next ingest cycle. The workflow exists because most programmes consume CTI passively (read the catalog, forward the alert, post in chat) without changing the prioritisation queue. The platform-side discipline is what turns intel into action with a defensible audit trail.

How does this differ from the broader vulnerability prioritisation workflow?

The broader vulnerability prioritisation workflow covers the full prioritisation policy: how CVSS, EPSS, KEV, asset criticality, exposure, and compensating controls combine into a defensible queue ordering. This workflow zooms into the threat intelligence ingest layer specifically: the source allowlist, the PIR/TIR list, the ingest cadence, the fitness assessment commissioned per signal, the determination chronology, and the post-closure feedback loop. Run them together: the prioritisation policy is the rubric every determination reads against; the CTI workflow is the operational pipeline that feeds the policy with current intelligence.

What are PIRs and TIRs and why do they matter for vulnerability management?

Priority intelligence requirements (PIRs) are the named questions the security programme reads threat intelligence against (which vulnerabilities affecting our deployed estate are being actively exploited, which sector-specific exploitation patterns are emerging, which supplier-side incidents have downstream exposure for us, which regional regulator-issued advisories require rendered response). Threat intelligence requirements (TIRs) are the operational translations of PIRs into specific signal classes, source bindings, and ingest cadences. The PIR/TIR list is the rubric that prevents the programme from chasing whatever intel arrived last regardless of fit; without it the queue drifts toward whichever source produces the loudest output rather than the highest-fitness output.

How do you avoid the EPSS-snapshot failure mode?

EPSS percentiles are queried per CVE rather than ingested as a one-time feed. When a finding is logged on the engagement, the platform-side workflow stamps the EPSS percentile against the underlying CVE and records the query date. The prioritisation determination reads the live EPSS rather than the snapshot. EPSS thresholds in the prioritisation policy (typically a percentile crossing into the top decile or top quintile) become trigger conditions that re-prioritise existing findings on the engagement when the underlying CVE moves. The activity log captures every re-prioritisation event with the trigger source and timestamp so the chain is reconstructable.

How does the workflow handle TLP-classified intelligence from ISACs?

Sector ISAC and ISAO bulletins arrive with TLP classifications (TLP:CLEAR, TLP:GREEN, TLP:AMBER, TLP:RED) that govern onward sharing. The workflow captures the TLP classification at ingest, routes privileged bulletins (TLP:AMBER and TLP:RED) through a permissioned engagement view scoped to named privileged-intel handlers via team management role-based access, and produces a rendered relevance assessment that can be shared at a less-restrictive TLP without exposing the originating bulletin content. The handling note lives on the engagement so the audit and the inquiry-response chain can show that the operational use respected the originating sharing constraints.

How do you prove to an auditor that the programme operationalised a specific advisory?

The engagement record holds the ingest event with timestamp and analyst attribution, the document management artefact for the upstream advisory text, the fitness assessment with the scanner runs commissioned and the in-scope asset list, the prioritisation determination with named decider and explicit criteria applied, the routed work with named owner and response decision, and the verification scan that confirmed the affected component was no longer present. The activity log CSV export stitches the entire chain. When an ISO 27001 surveillance auditor or a SOC 2 examiner asks how the programme operationalised a specific CERT advisory or KEV addition, the answer is one query against the engagement rather than a multi-week reconstruction across email and chat.

Does SecPortal subscribe to threat intelligence feeds for me?

No. SecPortal is the engagement record where ingested threat intelligence signals are captured, fitness-assessed, prioritised, routed, and verified against. The platform does not operate as a threat intelligence subscription service, does not sign ISAC membership agreements on behalf of customers, does not integrate directly into commercial CTI vendor APIs, and does not produce intelligence collection itself. The named programme owner subscribes to the relevant sources (CISA KEV is freely available, FIRST EPSS API is freely available, ISAC memberships are sector-specific contractual relationships, CERT advisories are publicly published, vendor PSIRT subscriptions are vendor-side, contracted dark-web monitoring is a separate vendor relationship); SecPortal holds the operational record of how each ingested signal was rendered into prioritisation action.

How does the workflow handle internal red team findings as intelligence inputs?

Internal red team operations, contracted penetration tests, and bug bounty submissions already produce findings that live on engagement records. The CTI workflow treats those internal findings as first-class intelligence inputs alongside external feeds. When a red team operation surfaces a chained exploitation path that touches the broader deployed estate, the engagement renders the chain as a CTI signal that prioritises the underlying findings against the same determination logic the external KEV listing or vendor advisory would. The cross-engagement reference keeps the originating engagement and the prioritisation engagement linked so the chain of reasoning stays reconstructable.

How does this workflow help close the feedback loop into the next ingest cycle?

The closure step measures time-from-CTI-signal to time-of-verification per signal and per source. The engagement holds the measurements so the programme can later answer which intelligence sources reduced exposure fastest, which fitness-assessment paths lagged, which routing layers dropped accelerated findings back into the standard queue, and which PIRs produced no in-scope exposure (review for relevance) versus repeated exposure (review for upstream investment). The quarterly PIR/TIR review reads against these measurements rather than against an analyst impression. The next intel cycle inherits a sharper rubric because the prior cycle closed on evidence.

How long does a CTI engagement stay open in SecPortal?

The engagement is typically structured as an evergreen programme record per quarter or per programme cycle rather than a per-signal ticket. Every ingested signal lands as an object on the running engagement; every determination is a row; every routed work item links to the affected findings on whichever engagement holds them. The activity log captures the chronology across the entire programme cycle. At the cycle close (often quarterly with a board read-out), the engagement produces the operational threat intelligence read, the audit evidence pack, and the PIR/TIR review inputs. A new programme cycle opens immediately so the chronology never breaks.

How it works in SecPortal

A streamlined workflow from start to finish.

Define the threat-intelligence requirements that drive prioritisation

Operational threat intelligence starts with named requirements. Capture the priority intelligence requirements (PIRs) the security programme reads against, the threat intelligence requirements (TIRs) that translate PIRs into specific signal classes, the source allowlist (CISA KEV, EPSS, FIRST EPSS API, vendor PSIRT advisories, sector ISAC bulletins, regional CERT alerts, internal red team and pentest findings, supplier security advisories, dark-web monitoring outputs from contracted services), the ingest cadence per source, and the named programme owner. Recording the requirements on the engagement is what separates an intel-aware programme from an intel-ingesting one. The PIR/TIR list is the rubric every later prioritisation decision reads against so the queue cannot drift into chasing whatever Twitter posted last night.

Ingest signals into the engagement with full provenance

Each new CTI signal lands on the engagement record as an explicit object: the source (KEV addition, EPSS shift, vendor advisory, CERT bulletin, ISAC alert, internal finding), the source identifier (CVE, vendor advisory ID, bulletin reference), the date observed, the analyst who logged the signal, the original source link, and the raw content excerpt the determination will read against. Document management holds the upstream advisory PDF or excerpt so the artefact is preserved against later source-link rot. The activity log captures the ingest event with timestamp and user attribution. The provenance chain is what makes a later determination defensible when the signal is challenged or when the audit asks how the team learned about a particular CVE.

Run a fitness assessment to convert the signal into an in-scope picture

A KEV addition or a vendor advisory is a generic signal. The fitness assessment converts it into a programme-specific exposure picture. Use code scans across connected GitHub, GitLab, and Bitbucket repositories to find every occurrence of the affected component in application source. Use authenticated DAST against verified domains to find the affected component in running systems where the fingerprint is observable. Use external scans on continuous monitoring schedules to surface internet-facing exposure. Pair the scanner output with the asset criticality on the engagement scope so the assessment answers four concrete questions: is the affected component present, on which assets, with what exposure, and against which business criticality. The fitness assessment is what turns the intel from broadcast information into an actionable internal picture.

Render the prioritisation determination with named decider and rationale

Each fitness-assessed signal produces a prioritisation determination on the engagement: the SLA tier the signal moves the affected findings into (immediate, accelerated, standard, monitoring, or no-change), the criteria the decision read against (KEV listing on internet-facing crown jewel, EPSS percentile crossing the programme threshold, CERT advisory aligned with active sector-specific exploitation, vendor advisory with concrete patch availability), the named decider, the timestamp, the dissenting views captured during deliberation, and the residual-risk note. The determination cites the affected finding identifiers explicitly so the routing step does not have to guess scope. Each determination is a fresh row when re-evaluated; nothing is edited in place so the chronology of how the prioritisation evolved as the signal matured is reconstructable.

Route accelerated findings to named owners and capture the response decision

The prioritisation determination feeds the routing layer. Accelerated findings move into the affected owners queue through team management with role-based access; the response decision lands on each finding as a structured field (patch the upstream library, deploy the vendor mitigation, apply the documented workaround, accept the residual risk through the exception register with a hard expiry and compensating controls cited, or decommission the asset where the cost exceeds the benefit). Notifications surface the routed work to the named owners on a documented cadence so accelerated SLAs do not drift into the standard backlog by accident. The branded client portal mirrors the priority shift for tenant audiences where applicable so the upstream and downstream picture stays synchronised.

Verify remediation and feed the closure back into the intelligence cycle

When the patch lands, a follow-up code scan, authenticated scan, or external scan re-runs against the affected asset and confirms the vulnerable component is no longer present. The verification scan attaches to the same finding as a state event so the closure becomes evidence rather than assertion. The engagement records the time-from-CTI-signal to time-of-verification per signal and per source so the programme can later answer which intelligence sources reduced exposure fastest, which fitness-assessment paths lagged, and where the routing layer dropped accelerated findings back into the standard queue. The closed signal feeds the next cycle: PIRs that produced no in-scope exposure are reviewed for relevance; PIRs that produced repeated exposure are reviewed for upstream investment.

Produce the audit and leadership evidence from the live record

The engagement holds the entire CTI-to-prioritisation trail: the PIR and TIR list, the source allowlist, the ingest log per signal with full provenance, the fitness assessments, the prioritisation determinations, the routed responses, the verification scans, and the time-to-closure measurements per source. AI-generated reports compose the operational threat intelligence read for the security operations leader, the executive briefing for the CISO, the board read-out, and the audit evidence pack for the next ISO 27001 surveillance, SOC 2 examination, NIST 800-53 review, or PCI DSS assessment. The activity log CSV export becomes the inquiry-response evidence chain when a regulator, auditor, or insurer asks how the programme operationalised a specific advisory.

Features that power this workflow

Vulnerability management software that tracks every finding

Orchestrate every security engagement from start to finish

Find vulnerabilities before they ship

Test web apps behind the login

Vulnerability scanning tools that map your attack surface

Monitor continuously catch regressions early

Document management for every security engagement

Every action recorded across the workspace

AI-powered reports in seconds, not days

Collaborate across your entire team

Compliance tracking without a full GRC platform

Notifications and alerts for the people who carry the work

Operationalise threat intelligence into the prioritisation queue

Ingest KEV, EPSS, CERT advisories, vendor PSIRT, and ISAC bulletins as structured signals on the engagement. Fitness-assess every signal, render a defensible determination, route to named owners, and close on verified evidence. Start free.