Intelligence Requirements Builder

Intelligence Requirements Builder

This skill helps a CTI analyst convert an informal stakeholder request into formally codified intelligence requirements. The output should be precise enough that a CTI team could begin collection against it immediately, structured enough to slot into an existing intelligence requirements list, and concise enough that a busy analyst can scan it in under a minute. Favor brevity throughout: short phrases over full sentences in structured fields, and no filler.

Before producing requirements, read references/ir-definitions.md to ensure correct terminology, and read references/requirement-quality.md to ensure every requirement is written to the quality standard. Intelligence requirements have specific meanings inherited from military and government intelligence practice, and using the wrong term (for example, conflating prioritized intelligence requirements with Priority Intelligence Requirements) undermines the credibility of the output. Equally, a requirement that asks two questions at once, or asks a question that collection cannot answer, undermines the credibility of the whole set.

Workflow

Follow these six stages in order. Do not skip the clarification stage unless the user's request already contains the answers.

Stage 1: Intake

Parse the stakeholder ask and extract what is already known:

• Stakeholder: Who is asking, and what is their role? (CISO, SOC lead, fraud team, executive leadership, product team, etc.)
• Decision: What decision or action will this intelligence support? Every requirement must link to a decision; intelligence without a decision attached is trivia.
• Timeframe: Is this a one-off, time-bound need or an ongoing concern?
• Scope: Which assets, business units, geographies, technologies, or threat types are implicated?

State your initial read back to the user in two or three sentences before asking anything. This shows the analyst what you have inferred and lets them correct you early.

Stage 2: Clarify

Ask only the questions you cannot answer from the request itself, and ask no more than five. Prioritize in this order:

1. What decision will this intelligence inform, and who makes it?
2. When is the decision being made (or is this an enduring concern)?
3. What does the stakeholder already know or believe about this topic?
4. What would a useful answer look like to them (a briefing, a report, an alert, a recommendation)?
5. Are there constraints on scope (specific regions, subsidiaries, technologies, or threat actors)?

If the user cannot answer a question, proceed with a documented assumption rather than blocking. Mark every assumption clearly in the final output so it can be validated with the stakeholder later.

Stage 3: Classify

Determine whether the need is enduring or priority, and say which explicitly:

• Enduring requirement (GIR or SIR): An ongoing intelligence support need with no fixed end date. Example: "What ransomware groups are targeting the financial services sector in North America?"
• Priority Intelligence Requirement (PIR): A time-bound need with a short shelf life, usually landing as an unscheduled RFI, that pulls the team's attention and resourcing toward a decision that has to be made soon. Example: "Is the vulnerability disclosed yesterday in our VPN appliance being actively exploited in the wild?"

Apply this test: if the requirement still matters in 90 days in roughly its current form, it is likely enduring. If it expires once a specific decision is made or event passes, it is likely a PIR.

Do not label an enduring requirement as a PIR simply because the stakeholder is senior or the topic feels urgent. A team that ranks its enduring requirements has prioritized intelligence requirements; that is a different concept from a PIR, and the distinction matters. See references/ir-definitions.md for the full explanation.

Stage 4: Decompose

Decompose the ask into candidate requirements, then keep the final set small. If the stakeholder asked a single question, fully enrich only the 2 to 4 requirements most load-bearing for the decision identified in Stage 1, and never more than 6. If the stakeholder asked more than one distinct question, keep all the resulting requirements in one combined set and fully enrich 1 to 3 requirements per question; this budget applies per question, so three questions may yield up to nine enriched requirements in the single set. The questions stay distinct inside that one set: each requirement records which stakeholder question and decision it traces to (via its linked-decision field and, in the CSV, its Stakeholder and Decision_Supported columns), so context is never lost even though everything lives in one place. List any remaining valid questions in a single "Candidate requirements" section at the end of the set so the team can promote them later if capacity allows. Candidates get the question and a one-line rationale only, with no EEIs, collection guidance, or criticality scores, and they never enter the CSV ledger. Before writing any requirement, read references/requirement-quality.md for the full standard and worked examples of bad questions rewritten into good ones.

Every requirement must pass all five tests below. If it fails any one, rewrite or split it before moving on. According to CTI best practices, a strong requirement is singular, atomic, decision-centric, and timely: it asks only one question, focuses on a specific fact, event, or activity, and supports a single decision. This skill adds a fifth test, answerability, which commercial CTI practice makes necessary.

1. Singular. One question per requirement, asking one thing. If the question contains "and" joining two distinct asks (actors and techniques, footprint and pipeline), split it into separate requirements. A parenthetical enumeration of categories within a single fact is acceptable; a second question clause is not.
2. Atomic. The requirement targets a specific fact, event, or activity. "What is happening with ransomware?" is a topic. "Which ransomware operations have claimed victims in our sector in the past 12 months?" is a fact to establish.
3. Decision-centric. Answering the requirement supports one decision identified in Stage 1. Note the linkage explicitly in the requirement's linked-decision field. If a requirement supports no decision, cut it. If the ask spanned several questions, the set may serve several decisions, but each individual requirement must still map to exactly one of them.
4. Time-bound. The question states its timeframe inside the requirement itself ("over the past 12 months", "before the Q3 board decision"). A requirement without a timeframe cannot be judged answered, current, or stale.
5. Answerable with CTI. The question must be answerable through collection and analysis of observable evidence, internal or external. Questions that ask the team to predict the organization's own future ("How likely are we to be breached?") are risk judgments, not intelligence requirements. Do not write them. Instead, decompose them into the observable questions that feed the judgment (incident frequency among comparable organizations, evidence of targeting, evidence of techniques defeating controls equivalent to ours) and state in the requirement set that the final risk call is the stakeholder's synthesis of that evidence.

In all cases, a requirement is phrased as a question. "Monitor ransomware" is an activity, not a requirement.

Under each requirement, list 2 to 4 Essential Elements of Information (EEIs): the individual facts an analyst must establish before the requirement can be considered answered. EEIs are what make a requirement collectible. Keep each EEI to a short noun phrase of roughly 5 to 10 words, not a full sentence. For example, for the requirement "Which threat actors have targeted our sector in LATAM in the past 12 months?", EEIs might be: "Actors with confirmed sector victims in LATAM"; "Their observed targeting of new market entrants"; "Attribution confidence per actor".

Where the user indicates a mature team, also suggest Collection Requirements (what data sources need to be tasked) and Production Requirements (what intelligence products will be created and on what cadence). Do not force these on users who only need the requirements themselves.

Stage 5: Enrich

For each requirement, provide four things:

Collection guidance. Name specific source types and, where possible, specific starting points. "Monitor the dark web" is not collection guidance. "Track affiliate recruitment posts on RAMP and Exploit forums, ransomware leak sites for victims in [sector], and vendor reporting on [actor] campaigns" is. Prefer free and open sources where they exist, and say which sources require paid access.

Success criteria. Define how the stakeholder will know the requirement has been answered. Phrase as observable outcomes: "The stakeholder can name the three most likely initial access techniques and has a prioritized mitigation list" rather than "stakeholder is informed."

Deliverable and cadence. Name the intelligence product or service that will answer the requirement (for example, a one-time briefing, a monthly threat landscape report, a quarterly stakeholder review, or an alerting service) and how often it will be delivered (One-time, Ad hoc, Weekly, Monthly, Quarterly, or Continuous). Base this on the Stage 2 answer about what a useful output looks like to the stakeholder. PIRs usually take a one-time or ad hoc deliverable; enduring requirements usually take a recurring one.

Criticality rating. Score the requirement using the matrix below and assign Critical, High, Medium, or Low. Show the component scores so the rating is defensible rather than asserted.

Criticality matrix

Score each dimension from 1 (low) to 5 (high), then average:

Mapping: average 4.0 or above = Critical; 3.0 to 3.9 = High; 2.0 to 2.9 = Medium; below 2.0 = Low.

Feasibility is included deliberately. Early in an intelligence program, demonstrating value quickly matters, so a moderately impactful requirement the team can answer this week may rank above a highly impactful one it cannot answer at all.

Stage 6: Output

Produce exactly three files in total: one markdown record, one Word document, and one CSV list. This holds no matter how many questions the stakeholder asked. Do not split the output into a separate file, set, or trio per question. Where the environment supports file creation, write all three as actual downloadable files; otherwise render the markdown in the conversation and say so.

When the stakeholder asked more than one distinct question, all of those questions and their requirements go into the same three files. Use one shared summary block at the top that covers the whole set, then list every enriched requirement together under a single Requirements section, and put every row in the one CSV. The distinct questions do not fragment the output; they are preserved inside it. Give the summary block a single row for the requesting stakeholder(s) and a "Questions addressed" row that lists each stakeholder question with the decision it supports, so a reader sees at a glance which decisions the set serves. Every requirement then carries its own context through its linked-decision field (naming which of those questions and decisions it answers), and every CSV row carries it through the Stakeholder and Decision_Supported columns. Keep IDs unique across the whole set and grouped in a contiguous run per originating question (see the ID rule below) so a reader can still tell which question a requirement came from without needing separate files.

Output 1: The intelligence requirements set (markdown). Use the template in assets/requirements-template.md. This is the analytical record and must include:

1. A single summary block (stakeholder, decision supported, classification, date, review date). When the ask covered more than one question, keep this one block and use its "Questions addressed" row to list each stakeholder question with the decision it supports; set classification to Mixed if the set spans enduring and priority requirements, and set the review date to the earliest date at which any part of the set needs revalidating.
2. The full requirements detail for every requirement across all questions, in one Requirements section (ID, requirement, type, EEIs, collection guidance, success criteria, deliverable and cadence, criticality with component scores). Each requirement's linked-decision field names which stakeholder question it answers.
3. An assumptions list, if any assumptions were made.
4. A single "Candidate requirements" section, if any valid questions were deprioritized in Stage 4: the question plus a one-line rationale each, nothing more.

Keep the prose tight. Collection guidance and success criteria should be one short bullet each per point; do not pad fields to fill the template.

Output 2: The intelligence requirements set (Word document). The same content as the markdown record, produced as a single .docx file covering the whole set, for analysts who need to circulate the requirements to stakeholders or attach them to an approval workflow. Mirror the markdown structure: one shared summary table, then one section per requirement across all questions, assumptions at the end. Where .docx creation is not available in the environment, say so and offer the markdown file as the alternative.

Output 3: The intelligence requirements list (CSV). Use the column structure in assets/requirements-list-template.csv. This is the working file the team appends to their existing intelligence requirements list, uses to guide operations, and imports into security tooling. Rules:

• One row per requirement, exactly these 14 columns, in this order: IR_ID, Type, Requirement, Stakeholder, Decision_Supported, Criticality, Status, EEIs, Intelligence_Deliverable, Delivery_Cadence, Success_Criteria, Owner, Date_Created, Review_Date.
• Keep cell contents condensed. The CSV is deliberately a simplified view; full collection guidance, matrix scores, and assumptions live in the markdown and Word records only.
• Separate multiple values within a cell using semicolons (notably EEIs), never commas.
• Use controlled vocabulary: Type is GIR, SIR, or PIR; Criticality is Critical, High, Medium, or Low; Status is Proposed, Active, or Retired; Delivery_Cadence is One-time, Ad hoc, Weekly, Monthly, Quarterly, or Continuous.
• Always set Status to Proposed and leave Owner blank. Approving requirements and assigning analysts are the team's decisions, not the skill's.
• Candidate requirements never enter the CSV; only fully enriched requirements get a row.
• Use ISO 8601 dates (YYYY-MM-DD). For enduring requirements, Review_Date is the revalidation date; for PIRs, it is the expiry date tied to the decision.

Use requirement IDs in the format IR-YYYY-NNN for enduring requirements and PIR-YYYY-NNN for priority requirements, and keep IDs identical across all three files so they stay traceable to each other. When one ask covers multiple questions, all IDs still belong to the same set and must be unique across it; group each question's IDs in a contiguous run (for example IR-2026-101 to 104 for the first question, IR-2026-111 to 113 for the second) so a reader can tell at a glance which question an ID came from without needing separate files.