4 Types of Cyber Threat Intelligence for Incident Response

Written by: Nimesh Chakravarthi, Co-founder & CTO, Struct

Key Takeaways for CTI-Driven Incident Response

• CTI is divided into four types: Technical, Tactical, Operational, and Strategic. Each type aligns to a distinct NIST SP 800-61r2 incident response phase.
• Technical CTI delivers raw IOCs for automated Detection and alert enrichment across observability stacks like Datadog and CloudWatch.
• Tactical CTI maps adversary behaviors to MITRE ATT&CK techniques, which supports precise Containment playbooks and lateral-movement hunting.
• Operational and Strategic CTI provide actor context, blast-radius prioritization, and board-level investment guidance during and after incidents.
• Struct converts raw CTI feeds into zero-click root-cause dashboards inside Slack, so on-call engineers receive a pre-assembled investigation instead of a raw alert. See the complete CTI-to-resolution workflow.

What Are the Four Types of Cyber Threat Intelligence?

Each CTI type maps to a specific NIST incident response phase and produces a distinct output format, so teams can apply the right intelligence layer at the right moment in their response workflow.

CTI Type	NIST Phase	Primary Input	Expected Output
Technical	Detection & Analysis	IOCs: IPs, hashes, domains, CVE IDs	Automated alert enrichment, IOC-matched log hits in Datadog / CloudWatch
Tactical	Containment & Eradication	ATT&CK TTP mappings, adversary behavior patterns	Prioritized containment playbook, isolation and revocation steps
Operational	Containment & Post-Incident Activity	Threat-actor profiles, campaign timelines, blast-radius data	System prioritization decision tree, attribution summary, stakeholder brief
Strategic	Preparation & Post-Incident Activity	Industry trend reports, dwell-time benchmarks, regulatory context	Board-level narrative, security investment roadmap, SLA risk model

Technical CTI for Fast, Automated Detection

Technical CTI is the most time-sensitive layer and must plug directly into your logs and alerts. It consists of machine-readable indicators such as IP addresses, file hashes, malicious domains, and CVE identifiers that map to observable events in your stack. Exploits remained the top initial infection vector for the sixth consecutive year at 32% of intrusions in 2025, and the mean time to exploit vulnerabilities reached an estimated −7 days, with exploitation often occurring before patches are released. That timeline leaves no room for manual IOC lookups.

1. Ingest feeds. Pull STIX/TAXII or vendor IOC feeds into your SIEM (Datadog Security Signals, AWS Security Hub, Sumo Logic). Map each IOC to a log field such as source IP, user-agent hash, or CVE tag, because this mapping enables automated correlation later.
2. Enrich alerts automatically. With IOCs mapped to log fields, configure correlation rules so any log hit against a known IOC fires a high-priority alert with IOC context already attached. This enrichment removes the manual lookup step that would otherwise slow down triage.
3. Validate blast radius. Use the enriched alert to query CloudWatch or GCP Logs for the IOC across all services at once. A single compromised IP touching three production microservices requires a different response than one touching a dev sandbox.
4. Expire stale indicators. IOCs older than 30 days without reconfirmation degrade signal quality and inflate false positives. Apply TTL tags automatically at ingestion and remove or downgrade indicators after expiry.
5. Hand off to containment. After confirming the IOC and blast radius, pass the enriched alert, including matched services and timestamp range, directly into the Tactical CTI playbook so containment actions start from a complete picture.

Struct auto-ingests IOC context from connected observability tools as soon as an alert fires, then correlates log hits across Datadog, Sentry, and AWS CloudWatch into a single timeline before the on-call engineer is paged. This workflow removes the manual enrichment step entirely.

See how Struct auto-enriches IOC alerts

Tactical CTI via MITRE ATT&CK Playbooks

Tactical CTI translates adversary behavior into concrete containment actions that engineers can execute quickly. The January 2026 APT28 campaign weaponized CVE-2026-21509 within 24 hours of disclosure and mapped to multiple ATT&CK techniques. ShinyHunters’ 2026 Canvas breach exploited initial access techniques, exfiltrated 275 million records across 8,809 institutions, and then escalated to T1491 defacement. These campaigns show that ATT&CK-mapped playbooks form the operational difference between a contained incident and a full breach.

1. Map the alert to ATT&CK. When an alert fires, identify the technique ID from the enriched IOC or behavioral signature. T1566.001 means spearphishing attachment, while T1078 means valid account abuse. Each technique maps to a specific containment action set that drives the next step.
2. Execute technique-specific containment. Use the technique ID to choose actions. For T1528 and T1550.001 credential and token abuse, containment includes account resets, session revocation, and API key rotation, not generic host isolation. These actions must start before you search for persistence.
3. Hunt for lateral movement indicators. After immediate containment is in motion, use ATT&CK mapping to guide hunting for related techniques such as COM hijacks or macro abuse. This approach prevents responders from closing an incident while persistence mechanisms remain active.
4. Update detection rules. Once you confirm TTPs, push new Sigma or Datadog monitor rules for those techniques. A Sigma rule that detects T1562.001, such as disabling Windows Defender through PowerShell, can come directly from tactical intelligence reports.
5. Document technique coverage gaps. Record which ATT&CK techniques lacked detection rules before the incident and pass this list to the Strategic CTI layer. These gaps become concrete items for future investment.

Struct surfaces ATT&CK-aligned event timelines inside Slack alert threads, so on-call engineers see the technique context and the next containment step without leaving their primary incident channel.

Operational CTI for Attribution and Prioritization

Operational CTI helps teams decide which systems matter most during an incident, based on who is attacking and why. The median time between initial access and hand-off to a secondary threat group fell from more than 8 hours in 2022 to 22 seconds in 2025. At that speed, prioritization decisions made without actor context become guesswork.

1. Build threat-actor profiles. Maintain lightweight profiles for the top five actors that target your industry, including sector focus, preferred initial vectors, and known infrastructure. Manufacturing teams should note that manufacturing accounted for 27.7% of X-Force incidents in 2025 for the fifth consecutive year.
2. Apply a prioritization decision tree. During an active campaign, rank systems by data sensitivity, external exposure, and known actor affinity for that system type. SaaS OAuth integrations often rank high because a single compromised API can cascade into hundreds of customer environments.
3. Assess blast radius before containment. Use operational CTI to define campaign scope before you isolate services. Isolating one service while an actor holds OAuth tokens across five others closes one door while leaving several open.
4. Brief stakeholders with actor context. Replace generic statements with specific ones such as “APT28-affiliated activity targeting credential stores was detected and contained; no customer data was exfiltrated.” This context turns a panic call into a structured update.

Struct generates blast-radius summaries automatically, mapping which services, users, and integrations an alert touched, so the on-call engineer arrives at prioritization decisions with evidence already assembled.

Strategic CTI for Post-Incident Decisions

Strategic CTI converts incident data and industry trends into board-level narrative and future investment direction. Global median dwell time rose to 14 days in 2025 from 11 days the prior year, while espionage incidents showed a median dwell time of 122 days. A 14-day dwell time in a Series B fintech with 60-minute SLAs represents an existential business risk, not a minor technical detail.

1. Benchmark your MTTR against industry dwell time. Compare your median investigation time to industry dwell time. If your median investigation takes 45 minutes and the industry median dwell is 14 days, the primary gap lies in detection rather than response.
2. Translate ATT&CK coverage gaps into budget asks. Convert uncovered techniques from the Tactical CTI phase into specific line items such as detection rule development, new tooling, or additional headcount.
3. Frame the board narrative around business impact. Report MTTD, MTTR, and business impacts across data, systems, customers, and employees, along with containment measures. Avoid focusing on raw log counts or tool metrics alone.
4. Incorporate regulatory timelines. Include the U.S. SEC four-business-day disclosure rule for material cybersecurity incidents when you design post-incident reporting workflows.
5. Feed findings back into Preparation. Turn lessons learned into concrete deliverables with owners and deadlines, rather than vague recommendations such as “improve monitoring,” so the NIST lifecycle closes cleanly.

Integrating CTI Feeds into SIEM and SOAR Workflows

Vendor-neutral integration patterns help common engineering stacks turn CTI feeds into practical signals.

• Datadog: Use the Datadog Security Signals API to ingest STIX IOC feeds as custom threat lists. Correlate against APM traces to surface IOC hits with service-level context.
• AWS CloudWatch: Push IOC lists to CloudWatch Contributor Insights rules. Trigger Lambda functions on matches to auto-tag affected log groups and notify PagerDuty.
• Sentry: Tag error events with CVE IDs when stack traces reference known vulnerable library versions. Route tagged issues to a dedicated security project in Linear or Jira.
• GitHub: Use GitHub Advanced Security secret scanning and Dependabot alerts as a Technical CTI feed. Pipe critical alerts into the same Slack channel that your incident response workflow monitors.
• PagerDuty and Linear: Configure PagerDuty event rules to attach ATT&CK technique IDs to incidents based on alert source. Auto-create Linear tickets with technique-specific runbook links for Tactical CTI playbooks.

When threats move at machine speed, human-centric defense alone cannot keep pace. Struct connects to these tools quickly, then turns the combined feed into zero-click root-cause dashboards delivered directly in Slack, so responders do not need to craft prompts during an active incident.

Get zero-click root-cause dashboards in Slack

Common Pitfalls When Using CTI in Incident Response

• Stale IOCs generating false positives. IOCs without TTL tags accumulate and trigger alerts on benign traffic months after a campaign ends. Struct’s automated first-pass investigation checks whether a matched IOC aligns with active anomalous behavior before paging an engineer.
• Tactical intelligence without blast-radius context. Knowing an actor uses T1078 has limited value without an inventory of service accounts in your environment. Struct maps affected services at alert time so containment decisions reflect real exposure.
• Alert fatigue from unfiltered feeds. Ninety-four percent of login attempts now originate from bots and 41% of successful logins involve compromised passwords (Cloudflare data from Sept–Nov 2024). Raw feed volume overwhelms teams without automated triage, so Struct separates transient noise from high-severity incidents automatically.
• Strategic CTI siloed from engineering teams. Board-level threat reports often never reach the SRE who writes detection rules. Struct’s runbook encoding lets engineering leaders translate strategic findings into automated investigation logic within the same workflow.
• Tribal knowledge gaps during escalation. Junior engineers often lack the systemic context to apply CTI correctly during overnight incidents. Struct acts like an automated senior engineer by applying encoded runbooks to every alert, regardless of who is on call.

Measuring CTI-Driven Incident Response Success

Three metrics show whether CTI operationalization is working in practice.

• MTTR reduction. Baseline your current median investigation time and aim for under 5 minutes for first-pass root-cause identification. Struct customers working at large scale report an 80% reduction in triage time, compressing a 30–45-minute manual investigation to under 5 minutes.
• False-positive rate. Track the ratio of paged alerts that require no human action. A high false-positive rate usually indicates stale IOCs or misconfigured correlation rules, which you can address through the Technical CTI playbook described earlier.
• SLA compliance rate. For teams with contractual resolution windows, measure the percentage of incidents resolved within SLA before and after CTI integration. The Series A fintech case study referenced in the metrics above shows how this triage reduction protects SLAs that would otherwise be at risk.

Frequently Asked Questions

What minimum tooling maturity does a team need before CTI integration adds value?

A team needs three elements in place: a structured alerting channel such as Slack or PagerDuty, at least one observability source with queryable logs such as Datadog, AWS CloudWatch, or GCP Logs, and a code repository such as GitHub. Without basic logging and trace IDs, no CTI layer, automated or manual, can reliably correlate events. Teams already using Sentry for exceptions and a cloud log platform for infrastructure are well positioned to operationalize all four CTI types immediately.

Is a 10-minute setup for CTI-driven automation actually feasible?

This setup time is realistic for teams with existing observability tooling already configured. Struct requires authentication for three connection types: an issue source such as Slack or Linear, a code repository such as GitHub, and an observability context source such as Datadog or a cloud log platform. After these three connections are authenticated, auto-investigations activate immediately, so the 10-minute figure reflects configuration rather than a long deployment or indexing project.

How does automated CTI investigation handle SOC 2 and HIPAA compliance requirements?

Struct is fully SOC 2 and HIPAA compliant. Log data is accessed and processed ephemerally, and Struct does not store or retain this data beyond the investigation window. For most Seed-to-Series-C companies, this posture satisfies contractual and regulatory obligations. Teams with strict enterprise requirements that forbid log data from leaving an internal VPC should evaluate whether a full on-premises deployment is necessary before adopting any cloud-connected investigation tooling.

Can junior engineers safely use ATT&CK-mapped CTI playbooks without deep security expertise?

Junior engineers can use these playbooks safely when they are encoded into the investigation layer instead of stored only in a wiki. Wiki-based runbooks require a tired engineer to find, interpret, and apply instructions to an unfamiliar system. Struct encodes custom runbooks directly into the automated investigation, so the output already reflects the correct ATT&CK-mapped containment steps for that specific environment. The engineer reviews a pre-assembled, contextualized starting point instead of building one from scratch.

Conclusion

Mapping Technical, Tactical, Operational, and Strategic CTI to NIST phases turns a reactive, manual process into a structured, repeatable workflow. Attackers are accelerating their playbooks with AI, and defenders who still rely on manual log hunting to apply intelligence will consistently lose the time race. The four-layer framework in this guide gives engineering and SRE teams a vendor-neutral structure for using CTI across every NIST phase, from IOC ingestion at Detection through board-level reporting at Post-Incident Activity.

Struct provides a fast path from raw CTI feed to actionable root-cause dashboard. It integrates into Slack, Datadog, Sentry, AWS CloudWatch, GitHub, PagerDuty, and Linear, automatically applies your encoded runbooks when an alert fires, and delivers a complete investigation that includes blast radius, timeline, root cause, and suggested fix. This automation frees senior engineers from repetitive context gathering that a purpose-built AI can complete in minutes.

See the complete CTI-to-resolution workflow