Cyber Threat Intelligence Requirements: Translating Business Risk into Collection Tasks

Most CTI programs collect first and ask questions later. They subscribe to feeds, stand up a TIP, hire analysts - and only afterwards try to work out what any of it is for. The result is a stream of indicators and reports that the business cannot use, because nobody ever asked the business what it needed to know.

Intelligence requirements close that gap. They are the contract between business risk and intelligence work. Done well, they turn vague worries ("ransomware is bad") into specific collection tasks an analyst can actually execute this week.

The translation problem

Executives talk in outcomes: protect revenue, protect customer trust, stay out of the headlines, satisfy the regulator. Analysts talk in artefacts: hashes, infrastructure, TTPs, victimology. Neither side is wrong — they are speaking different languages about the same threat.

The intelligence requirement is the translator. It takes a stated business risk and decomposes it into something collectable.

A worked example:

• Business risk (executive): "A ransomware incident at our largest manufacturing site would halt production for days and breach our contractual delivery SLAs."
• Intelligence requirement (CTI lead): "Identify ransomware operators that target European discrete manufacturers, prioritising those with observed activity against our peer companies in the last 12 months. Track their initial-access tradecraft, dwell time, and negotiation behaviour."
• Collection tasks (analyst): monitor named leak sites for peer-company posts; ingest IR vendor write-ups tagged manufacturing + ransomware; track CVEs for the perimeter products we run; subscribe to feeds covering the access brokers feeding these affiliates.

Every layer narrows scope and increases actionability. By the bottom layer, the analyst knows exactly what to fetch on Monday morning.

Where requirements come from

Good requirements are not invented in the CTI team. They are negotiated with the people who own the risk. In practice that means at least four input sources:

1. Crown-jewel analysis. What assets, processes, and data would hurt most if compromised? These anchor your strategic requirements.
2. Risk register. The board-level risks the business already tracks. CTI requirements should map directly onto the cyber-related entries.
3. Threat landscape for the sector. Which actors and campaigns plausibly come for an organisation like yours? This shapes your prioritisation, not your scope.
4. Stakeholder conversations. SOC, IR, vulnerability management, fraud, legal, third-party risk - each owns decisions that intelligence can support. Ask them what they wish they knew.

If a requirement cannot be traced back to one of these, it probably exists because someone found it interesting. Interesting is not a business case.

A simple structure that holds up under pressure

A workable intelligence requirement has five parts:

• ID and owner. Who signed off, who consumes the output.
• Decision supported. What action becomes possible (or unnecessary) once this is answered.
• Question. Written in plain language, answerable, time-bounded.
• Sources and methods. What collection is needed, and what is explicitly out of scope.
• Review cadence. When the requirement is re-validated or retired.

The "decision supported" field is the one most teams skip and the one that does the most work. If you cannot name a decision, you do not have a requirement — you have curiosity.

From requirement to collection task

The bridge from requirement to daily collection is where most programs collapse. The fix is to decompose every PIR into concrete, assignable tasks with explicit outputs:

Layer	Example
PIR	Ransomware risk to our manufacturing site
Sub-question	Which groups currently hit European manufacturers?
Collection task	Weekly review of leak-site posts for sector + region
Output	Updated actor watchlist; alert on peer-company appearance
Consumer	SOC tuning lead; site IT director

Once each task has a named consumer and a defined output, you can measure whether the requirement is being satisfied. Without that, "we collected a lot of intelligence this quarter" is the only metric available, and it tells you nothing.

Common failure modes

• Requirements written by the CTI team alone. No stakeholder sign-off means no stakeholder use.
• Open-ended questions. "Tell us about ransomware" is not a requirement. "Which ransomware operators have hit our top-10 suppliers in the last 6 months?" is.
• No retirement criteria. Requirements accumulate forever, collection bloats, analysts burn out.
• Confusing topics with requirements. "Initial access brokers" is a topic. "Identify IABs selling access to our sector and the prices they charge" is a requirement.
• Skipping the decision. If answering changes nothing, do not collect.

A 30-day starter plan

You do not need a perfect framework to begin. You need one cycle to prove the model.

• Week 1. Interview five stakeholders (SOC lead, IR lead, CISO, one business unit head, one risk/legal contact). Capture the decisions they make and what they wish they knew.
• Week 2. Draft 5–8 candidate PIRs in the structure above. Review with each stakeholder; cut ruthlessly.
• Week 3. Decompose surviving PIRs into collection tasks. Assign owners. Wire outputs into existing channels (SOC ticket queue, IR runbook, exec briefing pack) - do not create new ones yet.
• Week 4. Run one full cycle. Hold a 30-minute review. Retire what did not produce a decision; refine what did.

Repeat monthly. After two or three cycles the requirements stabilise and the rest of the program - feeds, tooling, hiring has a yardstick to be measured against.

The point

A CTI program organised around requirements is a small program that matters. A CTI program organised around feeds is a large program that does not. Requirements are how you choose the first option on purpose.