After a closed intrusion, what is a collection requirement and how does it differ from a detection request?

## Why closure produces artefacts at all An intrusion that has been contained and eradicated is not finished when the hosts are back. The organisation has just paid for a very expensive experiment about itself, and the only way to keep the return is to convert what the responders learned into things other teams can act on. In a security operations function those things are usually three, and they are genuinely different artefacts with different owners, different costs and different lead times. ## The collection requirement A **collection requirement** is a statement that a source of evidence exists which the detection and investigation platform does not receive. It is not a rule and it is not a ticket saying `improve logging`. To be actionable it names: - **the source** - which log, on which product, in which format (for example a host's local Windows Security log, a gateway service's own session log, an identity provider's sign-in log, a cloud control-plane audit trail); - **the host or tenant set** - every member of the gateway pool, not the one host you investigated; - **the events and fields that carry the meaning** - the smallest set that makes the behaviour visible, because volume is what the argument will be fought over; - **retention** - how far back an investigator must be able to look, which is a different question from how far back a rule needs; - **the owner** - the team that runs the platform and must fund and operate the ingest. A collection requirement almost never lands inside the SOC's own budget, which is exactly why it has to be written down rather than assumed. ## The detection request A **detection request** describes a behaviour that should raise an alert, and hands it to whoever authors and maintains rules. Its defining property is that it presumes its input: a rule executes over records that have already arrived at the platform. Raise a detection request against a source nobody collects and you get a rule that compiles, deploys, sits in the inventory, and can never fire. That is worse than nothing, because a deployed rule reads as coverage, and nothing on the surface distinguishes a rule that has never matched from a rule that has never had data. Sequencing matters for that reason alone: the detection request is a dependent obligation, written once the collection requirement is delivered. ## The intel record The **intel record** is what the incident contributes back so that the same activity is recognisable later. It holds two kinds of thing, and the distinction is the one interviewers actually probe. An **indicator** is an artefact you observed - an address, a domain, a file hash, a certificate, an account name. A **behaviour** is what the adversary did and how - which access path, which account type, in what order, at what hours, using which native tooling. Indicators are cheap for an adversary to replace and stop matching almost immediately; behaviours survive infrastructure changes and are what a later hunt or detection is written against. A record that is only a list of hashes and addresses has captured the disposable half of the incident. The record should also carry confidence: what you observed directly, what you inferred, and what you assumed. ## Why the difference is not pedantry The three artefacts fail differently. A collection requirement fails on money and on someone else's roadmap. A detection request fails on data quality and on false positives. An intel record fails on being too specific to this one case, or on nobody reading it. Filing the wrong one is a common and quiet failure: the closure says `new detection created for RDP abuse`, everyone relaxes, and the detection is running over a source the platform still does not receive. ## Who reads the closure The document carrying these obligations has an audience wider than the SOC. The platform or identity owner reads it to size the work. Detection engineers inherit the request. After a notified incident, an internal auditor, a customer assurance team, a regulator or an examiner may read it years later with no context at all. Write it so a reader outside the SOC can see what happened, what the investigation could **not** determine and why, and what was asked for as a result. Two habits follow from that audience: state limits explicitly rather than leaving them implied, and never let an obligation exist only in someone's memory of the review meeting.