What must a priority intelligence requirement name that 'keep an eye on infostealer activity' does not?
answer
- starts from a decision, not a topic
- who acts on the answer
- what would count as answered
- the so-what clause
- when does it expire
basics
~20 sA priority intelligence requirement names a consumer, the decision they owe by a date, and what would count as an answer. 'Keep an eye on infostealer activity' names none of those, so nobody acts on it and it never closes.
solid answer
~40 sA priority intelligence requirement (PIR) is a question a named person needs answered to make a decision they already owe. It has four parts: the consumer, the decision and its date, the question itself, and the criteria that say it is answered. 'Keep an eye on infostealer activity' is a topic, not a question - no owner, no decision, no finish line, so collection against it runs forever and produces reports nobody reads. Rewritten it becomes: 'Do our contractor accounts appear in the stealer-log listings our broker sells, and are any of the matching sessions still valid in our identity provider? - for the head of plant operations, who decides by 30 June whether to force re-enrolment across the contractor population.' That version can be tasked, answered, argued with and retired.
go deeper
Be ready to state the parts out loud: a named consumer, the decision and its date, the question, and what counts as an answer. Practise rewriting a vague topic into that shape in one sentence.
An interviewer expects you to explain the decomposition into specific information requirements and why the answer criteria are written before collection starts, not after the reporting arrives.
Show judgement about what a source can actually prove - a market listing proves a seller's claim, a sign-in record proves a credential was accepted - and write answer criteria that do not overstate it.
Own the inversion risk: a requirements list that mirrors your vendor's coverage map means the vendor is setting your priorities. Be able to describe how you keep the list short and consumer-owned.
## The idea Intelligence work starts from a decision somebody owes, not from a feed somebody bought. A **priority intelligence requirement (PIR)** is the written form of that: a question whose answer will change what a named consumer does. If the answer cannot change anything, collecting it is a hobby. ## The four parts 1. **A named consumer.** A role and a person - 'the head of plant operations', not 'the business'. If you cannot name who reads the answer, nobody will. 2. **The decision, with a date.** 'Whether to force re-enrolment for the contractor population this quarter.' The date is what makes the requirement finishable; without a decision point, collection is open-ended. 3. **The question.** Written so that a specific finding would push the decision one way and its absence the other. This is the *so what* clause: if the answer is yes, we do X; if no, we do Y. 4. **Answer criteria.** What evidence, from which kind of source, at what confidence, would let you say the requirement is satisfied. Without this, 'answered' silently means 'a report was delivered'. ## Why 'keep an eye on X' fails It fails on all four. It has no consumer, so no one is accountable for acting. It has no decision, so nothing is at stake in the answer. It cannot be finished, so it accumulates: three years later the requirements list has thirty topic headings, no ranking, and the analyst's attention goes wherever the vendor's reporting happens to point. And it invites the worst inversion in this field - writing requirements to match what your subscription covers, rather than buying collection to match what your consumers must decide. ## Requirement, then collection A PIR is decomposed into **specific information requirements** - the answerable sub-questions - and those are what get tasked to sources. For the contractor example: do our domains appear in listings a particular broker sells; do the matching accounts exist in the identity provider; when did each last authenticate successfully; do they carry remote-access entitlement. Each sub-question gets a source, a collector and a due date. The PIR stays at the decision level; the sub-questions do the work. ## Getting the direction of each claim right Requirements are written badly when the analyst overstates what a source can prove. - A market **listing** of stolen credentials proves that a seller *claims* to hold them, and nothing about whether they are current or ever worked. - A **successful sign-in record** in the identity provider proves that a credential was accepted, not that the legitimate person was present. Session cookies stolen off a laptop produce exactly that record. - The **absence** of any reporting against a requirement proves nothing on its own - it may mean nothing happened, or that nobody ever tasked a source. Writing the answer criteria forces you to confront this at requirement-writing time rather than in the briefing. ## What a PIR is not - **Not a detection rule.** A rule runs continuously over records and fires; a requirement is a question with an owner and an end date. They can be related - answering a PIR may argue for building a detection - but a requirement is satisfied by a judgement, not by a query returning rows. - **Not a risk rating.** Requirements are not scored likelihood-times-impact; they are ranked by whose decision is more consequential and sooner. - **Not a report subscription.** 'Send me the weekly criminal-ecosystem roundup' is a delivery arrangement. It answers no one's question. - **Not the analyst's curiosity.** Interesting is not the bar. Actionable-by-a-named-person is the bar. ## In practice A small manufacturer's SOC, co-managed with an MSSP, might carry five to eight live PIRs at a time, each with a consumer, a decision date and a one-page collection plan. Each quarter the set is reviewed with the consumers: which were answered, which decisions were actually taken, which requirements are now dead because the decision passed. A requirement that survives three reviews without anybody acting on it was never a requirement - it was a topic in disguise.
- Who writes the requirement - the analyst or the consumer?The analyst drafts it, because consumers rarely phrase questions in collectable terms, but the consumer has to accept it in their own words. The test is whether they can say out loud what they will do differently depending on the answer. If they cannot, the draft is wrong and no amount of collection will fix it.
- What is the difference between a priority intelligence requirement and a specific information requirement?The PIR sits at the decision level and is owned by the consumer. Specific information requirements decompose it into answerable sub-questions that can be tasked to a particular source, each with a collector and a due date. Consumers read PIRs; collection plans are built from the sub-questions.
- Should a priority intelligence requirement have an expiry date?Yes - it expires with the decision it supports. When the decision is taken or lapses, the requirement closes and either dies or is rewritten against the next decision. Requirements with no expiry are how a list grows to thirty items that nobody can rank.
It is the difference between a client asking a lawyer 'tell me about employment law' and asking 'can I dismiss this contractor before Friday'. Only the second has an answer and a deadline.
saying these in an interview costs you the question
- Treats a purchased feed as the requirement itself
- Writes a topic heading instead of a question
- Names no consumer, so nobody acts on the answer
- Calls a requirement answered when a report was delivered
- Confuses a requirement with a detection rule or a risk score