How to operationalize threat intelligence: the intake-to-evidence workflow

The workflow, not the feed

Receiving threat intelligence is easy. Doing something traceable with it is not. The gap between a feed arriving and a control changing — or a justified decision not to change one — is where programs quietly fail. Most CTI programs can demonstrate volume of intelligence consumed; fewer can demonstrate that any given indicator triggered a documented decision, reached the right team, and produced a verifiable outcome.

THREAT-FOUND-001 argues why the conversion from raw intelligence to changed security posture is the measure that matters. This guide covers the operational mechanics of making that conversion happen and leaving evidence that it did. The workflow has seven stages: intake, relevance assessment, disposition, routing, acknowledgment, confirmation, and evidence. Each produces a distinct record. None of those records is interchangeable with the stage after it.

A structural note on intelligence types: Not all intelligence moves through this workflow at the same pace or with the same human touchpoints. In mature environments, a hard distinction exists between automated technical IOC pipelines and advisory or campaign intelligence. High-volume machine-generated indicators — raw IP addresses, domain names, file hashes ingested via STIX/TAXII feeds — are typically enriched, deduplicated, and pushed directly to SIEM or EDR platforms via SOAR automation.

Forcing those items through a full seven-stage manual workflow produces alert fatigue and analysis paralysis, not better outcomes. The seven-stage workflow described here is principally designed for advisory and campaign intelligence: TTP advisories, ISAC bulletins, vendor reports, and credential-based threat intelligence where human disposition and documented control-change decisions are what the audit chain requires. Where automated IOC pipelines intersect with this workflow — primarily at intake normalization and routing — those intersection points are called out explicitly.

Stage 1: intake and normalization

Intelligence arrives in formats that no downstream system can consume directly — STIX bundles, PDF advisories, email alerts, ISAC bulletins, vendor reports, raw IOC lists. The intake stage transforms that raw material into a structured record with a consistent schema before any human judgment is applied.

For automated technical IOC feeds, normalization is the point at which the pipeline diverges from the manual workflow. Deduplication, confidence scoring, and enrichment happen programmatically, and the output routes directly to enforcement platforms. The normalized record still exists and still carries a source identifier, ingestion timestamp, and confidence tier — but human disposition stages are bypassed by design, and that bypass should itself be a documented pipeline configuration, not an undocumented shortcut.

For advisory and campaign intelligence, the minimum fields a normalized record needs are: source identifier, ingestion timestamp, confidence tier from the originating source, indicator type, and an initial scope tag that associates the item with an asset class or environment segment. Teams that skip normalization and route raw feeds directly to detection engineering often create a different failure mode — analysts triaging the same indicator from three sources without realizing it, or applying a rule to an environment segment the indicator never applied to.

Failure mode: Source confidence is not carried through normalization. An indicator tagged "low confidence" by the originating ISAC arrives at detection engineering stripped of that context. The team writes a high-fidelity alert on a low-confidence indicator and generates weeks of false positives. Fix: enforce confidence as a required schema field with no default value — a null confidence forces manual review before the record advances.

Test question: Can your intake schema reject a record that is missing a source confidence field, or does it pass with a default value?

Stage 2: relevance and applicability assessment

Not every indicator is relevant to every environment. An ICS-targeting TTPs advisory is not relevant to an organization with no OT footprint. A credential-stuffing campaign targeting a SaaS platform the organization does not use does not need a detection rule. Relevance assessment filters intelligence against the organization's asset inventory, technology stack, and threat model before it consumes analyst time.

The two questions that drive this stage: Does this indicator or TTP apply to a technology or asset class we operate? Does the attack path described require a condition that exists in our environment?

For IAM-specific intelligence — compromised credential sets, identity provider abuse, OAuth token misuse — relevance assessment should include a check against the organization's deployed IdP, federation configuration, and token issuance policies. An advisory about a specific OAuth flow attack pattern may be irrelevant if the organization's IdP does not implement that flow, though that determination requires explicit verification, not assumption.

Failure mode: Relevance is assessed by the person who received the intelligence rather than against a maintained asset register. Result: the assessment reflects the analyst's knowledge of the environment, which is often incomplete. Remediation path is to route relevance checks through a configuration management database or asset inventory query, not analyst recall.

Stage 3: disposition decision

Every intelligence item that clears relevance assessment needs a disposition: act, monitor, defer, or close with documented rationale. THREAT-FOUND-010 owns the taxonomy of legitimate no-change decisions and the criteria for each — this stage routes and records those decisions; it does not redefine them. The disposition record must capture who made the call, what evidence supported it, and what condition would trigger re-evaluation.

Teams that treat "no change required" as a non-event — something that needs no record — create an audit gap. When the same indicator surfaces six months later after an incident, there is no way to demonstrate whether it was assessed and rejected for documented reasons or simply missed.

Decision criterion: If the disposition is "defer," the record should include a named trigger condition for re-evaluation, not just a calendar date. Calendar-based deferral without a trigger condition often results in the item being re-reviewed without new information and deferred again indefinitely.

Stage 4: routing to receiving functions

A disposition decision to act produces a routing record — an explicit assignment to a receiving function: detection engineering, vulnerability management, identity operations, network controls, or incident response. The routing record captures the receiving team, the expected action type, and a due date.

For automated technical IOC pipelines, routing is a pipeline configuration decision rather than a per-item human assignment. The SOAR playbook that pushes a blocklist update to a firewall or an indicator to an EDR platform is the functional equivalent of a routing record — and it should be logged and retrievable as such. The failure mode of untraceable automated routing is the same as untraceable manual routing: no signal returns when something goes wrong, and there is no record to audit.

For advisory intelligence, routing to "security operations" as a generic destination — rather than a named function with a defined owner — often produces a handoff that no one acknowledges. For IAM practitioners receiving routed intelligence, the expected action type should be specific: review federation configuration, rotate credential class, validate token lifetime policy, audit privileged role membership. Generic action types make confirmation impossible at Stage 6.

Failure mode: Intelligence routed to a team with no acknowledgment requirement. The routing record exists; the team never received it or deprioritized it. No signal returns. Three weeks later, the indicator is active in the environment. The fix is structural: routing without a mandatory acknowledgment timeout — after which the item escalates — is a one-way door.

Stage 5: acknowledgment and acceptance

Acknowledgment is a receiving function confirming it has received the routed item, reviewed the expected action type, and accepted or contested the assignment. Acceptance does not mean the action is complete. It means the team has taken ownership and confirmed the scope is within their operational authority.

Acknowledgment records and action completion records are distinct. A common failure in audit reviews is treating an acknowledgment timestamp as evidence that a control was changed. It is not. It proves the item was received, not acted upon.

Verification step: Pull ten routed items from the past quarter. For each, confirm that an acknowledgment record exists separately from the completion record. If your workflow system uses a single status field that moves from "routed" to "complete," you have no acknowledgment stage — you have a two-state system with a gap.

Stage 6: confirmation of action

The receiving function produces a confirmation record when the expected action is complete: the rule was deployed, the credential was rotated, the policy was updated. Confirmation records should reference the specific system changed, the change identifier or ticket number, and the operator who made the change.

Confirmation is not the same as validated effectiveness. A detection rule deployed to a SIEM confirms that the rule exists. It does not confirm that the rule fires correctly against real traffic, that it covers the relevant log sources, or that alerts route to an active queue. For environments that feed this workflow into the assurance model described in SECOPS-ASSUR-006, confirmation triggers a validation step — not a closure step.

Failure mode: Confirmation records reference a change ticket that was closed without deployment — the ticket was marked complete when the rule was written, not when it was promoted to production. Remediation: require confirmation records to include the production deployment timestamp, not the development or staging timestamp.

Stage 7: evidence records and audit

The evidence record is the aggregate of all preceding stage records for a single intelligence item: the normalized intake record, the relevance assessment, the disposition with rationale, the routing assignment, the acknowledgment, and the confirmation. Together they constitute the chain of custody for a single piece of intelligence from arrival to outcome.

Evidence records serve two distinct functions: internal operational review and external audit response. For IAM practitioners, the most frequent audit trigger is a compliance review asking whether a specific control was updated in response to a known threat. A complete evidence chain answers that question without reconstruction. A gap at any stage — missing acknowledgment, undated confirmation — typically forces the team to reconstruct from memory or change logs, which is slower and less credible.

For automated IOC pipelines, the evidence chain looks different but must still exist: pipeline configuration records, deduplication logs, enforcement platform push confirmations, and SOAR execution records collectively substitute for the manual stage records. The audit requirement is the same — demonstrate that a known indicator was received, processed, and acted upon — even if no human touched the item between intake and enforcement.

Checklist for evidence record completeness (advisory and campaign intelligence):
- [ ] Intake record with ingestion timestamp and source confidence
- [ ] Relevance assessment with asset register or technology stack reference
- [ ] Disposition record with named decision-maker and rationale
- [ ] Routing record with receiving function and due date
- [ ] Acknowledgment record distinct from routing
- [ ] Confirmation record with production deployment reference
- [ ] Aggregate record linked by a common intelligence item identifier

Checklist for evidence record completeness (automated technical IOC pipelines):
- [ ] Normalized intake record with ingestion timestamp, source confidence, and deduplication log
- [ ] Pipeline configuration record documenting automated routing logic
- [ ] SOAR or automation execution log confirming enforcement platform push
- [ ] Confirmation record or platform acknowledgment with deployment timestamp

Workflow state table