The intelligence cycle and F3EAD
Every intelligence failure in a CTI team traces back to the first step. If nobody can state the requirement, everything downstream is expensive noise.
The intelligence cycle is the process model behind the whole discipline. In CTI it is often taught as a diagram and then ignored, which is precisely why interviewers ask about it — being able to talk about requirements management credibly is a strong signal.
The cycle
- Direction / planning — establishing what decisions need supporting, and turning them into intelligence requirements.
- Collection — gathering against those requirements from internal telemetry, commercial feeds, OSINT, sharing communities and human sources.
- Processing — normalising, deduplicating, translating, enriching. The unglamorous step where most analyst hours actually go.
- Analysis and production — turning processed data into an assessment with judgements and confidence attached.
- Dissemination — getting it to the right person in the right format at a time they can still act on it.
- Feedback — finding out whether it was used, and refining requirements accordingly.
Real work is not a clean loop. Collection reveals that the requirement was wrong; analysis surfaces a gap that sends you back to collection. Saying this out loud in an interview is a plus, not a criticism of the model.
Requirements: where it actually goes wrong
"Tell us about ransomware" is not a requirement. It cannot be collected against, and no product will ever satisfy it. A usable intelligence requirement names a decision, an audience, and a decision point.
| Weak | Usable |
|---|---|
| Monitor threats to our sector | Which intrusion sets have targeted mid-size European logistics firms via edge appliances in the last 12 months, and which of their initial-access techniques would our current telemetry miss? |
| Track APT groups | Is there evidence of pre-positioning against our OT network that would change the sequencing of the segmentation programme this quarter? |
| Give us IOCs | What infrastructure and behavioural patterns should detection engineering build against for the two families most often deployed against our sector? |
Requirements are usually tiered: PIRs (priority intelligence requirements) set by leadership, decomposed into specific information requirements, then into collection tasks. Being able to walk that decomposition is a senior-level signal.
F3EAD
Adapted from a military targeting cycle, F3EAD is popular in CTI because it fixes the traditional cycle's weakest point: the handoff between intelligence and operations.
- Find — identify the target: an intrusion set, a campaign, an exposure.
- Fix — pin it down in your environment. Where is it, what does it touch?
- Finish — the operational action. Contain, remediate, block, disrupt.
- Exploit — mine what the operation produced. Forensic artefacts, samples, infrastructure, credentials used.
- Analyse — turn that material into intelligence.
- Disseminate — feed it back so it drives the next Find.
Find–Fix–Finish is operations; Exploit–Analyse–Disseminate is intelligence. Naming both halves in one cycle forces the handoff to be explicit. The classic failure it prevents: an incident is remediated, everyone moves on, and nothing durable is learned because nobody owned the Exploit step.
Measuring whether any of it worked
A question that separates leads from analysts. Report volume is not a metric. Better ones:
- Requirements satisfied, and how many were retired as answered.
- Decisions demonstrably changed — a control funded, a project resequenced, a hunt launched.
- Detections built from intelligence, and their true-positive rate.
- Time from external disclosure to internal assessment of exposure.
- Stakeholder feedback that is specific rather than polite.
See also writing intelligence reports for the dissemination end, and from intelligence to detection for the operational handoff.
Run a mock interview on this material. You get the question, a graded response against a vetted rubric, and the probing follow-up an interviewer would ask next.
Related reading
- MITRE ATT&CK for CTI analysts ATT&CK is a knowledge base of adversary behaviour organised by tactic and technique. Most candidates can recite that. Fewer can map an ambiguous artefact correctly, or explain what a heat map does not tell you.
- The Diamond Model of intrusion analysis The Diamond Model exists to make pivoting explicit. Its four vertices are not a taxonomy to recite — they are the four places you can be standing when you ask "what else touches this?"
- The Cyber Kill Chain A 2011 model that is still the clearest way to talk about intrusion sequence and defensive coverage — provided you can also say where its linear assumption fails.
- STIX, TAXII and TLP STIX is the data model, TAXII is the transport, TLP is the handling rule. Mixing these up is a common and very visible interview error.