Turn threat intelligence into action
Connect an intelligence finding to a local check, named owner and validation record, with a worked defensive example.
Finish an intelligence assessment with a decision and a way to check its result. “Shared with the team” records distribution. It does not establish that a relevant system was reviewed, that a detection works or that an outstanding question has an owner.
The NCSC distinguishes intelligence, analytics development, engineering and other SOC functions. In a small organisation the same person may perform several of these jobs, but the handovers still matter: somebody interprets the report, somebody checks local conditions, and somebody accepts the operational change.
Choose the kind of action
| Finding | Appropriate next step | Evidence of completion |
|---|---|---|
| A credible report depends on a configuration you have not checked | Ask the authorised owner to establish whether the condition exists | Dated check, systems covered and limitations |
| Relevant behaviour is not visible in your records | Review logging requirements and the available service features | A verified example record and documented coverage |
| A useful signal exists but its meaning is unclear | Review representative records and define an investigation question | An analyst procedure with examples and false-positive considerations |
| A known weakness is confirmed locally | Open a remediation task through the normal change process | Change record and retest evidence |
| Local observations suggest a current incident | Escalate through the incident process | Assigned responder and triage record |
Actions should fit your authority. An analyst's report can recommend a configuration change; the service owner still needs to approve and manage it.
Worked example: checking mailbox-rule visibility
Fictional scenario. A training exercise at Merefield Supply describes misuse of a compromised mailbox and an unauthorised forwarding rule. The team wants to know whether it could investigate such a report. No attack or product-specific capability is asserted here.
The team's question is: “Could our responder identify a newly created external-forwarding rule, establish who created it and contact the mailbox owner?” That is narrower and testable compared with “improve email security”.
| Step | Recorded work in the fictional example |
|---|---|
| Establish applicability | The service owner confirms that the organisation permits a small set of approved forwarding rules |
| Identify evidence | The administrator checks which audit records are available, their retention and who can retrieve them |
| Find the gap | The team has not documented how to distinguish an approved rule from an unexpected one |
| Assign an action | The messaging owner creates an approval register and a responder lookup procedure |
| Validate safely | With permission, the team creates and removes a benign test rule on a designated test mailbox, then checks whether the expected record is available |
| Review the result | The record is present, but the responder initially lacks access; access arrangements are corrected and the lookup is repeated |
This sequence separates a collection gap from an interpretation gap and an access gap. Buying another feed would not have answered those local questions.
Define success before changing anything
Write the expected result in observable terms. In this example: “An authorised responder can retrieve the test event, identify the relevant mailbox and locate its approval record using the documented procedure.” State what the check cannot establish. It does not test every route to account misuse or prove that all malicious rules will be detected.
Use a designated environment or test account, agree the change with the owner, avoid real customer data and record how to reverse it. If the proposed validation would affect live users or breach an agreed boundary, stop and redesign the test. The scope guide provides a structure for those boundaries.
Use ATT&CK as a vocabulary, with evidence
MITRE ATT&CK® organises documented adversary behaviours. MITRE distinguishes a tactic's purpose from a technique's method and a procedure's particular implementation. Those distinctions can help teams describe what a report actually establishes.
Map only what the evidence supports, and link the relevant primary technique record when you make a mapping. A coloured matrix cell does not demonstrate that your logs contain the required evidence or that your detection has been validated. Write “mapped for discussion; local validation outstanding” when that is the actual state.
Keep a decision and outcome register
Our suggested record contains: requirement; source and version; local applicability; chosen action; owner; approval; due date; expected evidence; observed result; limits; and next review trigger. Keep the distinction between planned and completed work visible.
For the fictional mailbox example, a sensible close-out reads: “Lookup procedure verified on the designated test mailbox. Access issue corrected. Coverage outside the configured audit period was not evaluated. Messaging owner to review the procedure after the next service change.”
Feed the result back into research
Tell the person who requested the analysis what changed and what did not. If a source repeatedly leads to irrelevant checks, revisit the requirement or source choice. If a small number of well-supported reports expose useful gaps, record that benefit.
Review actions that remain open because of missing access, missing ownership or incomplete records. Those obstacles may be the most valuable result of the intelligence work. They belong in the improvement queue, with a named owner, rather than disappearing when the report is archived.
Sources and further reading
- MITRE ATT&CK: Frequently Asked Questions — checked 2 November 2026
- NCSC: Building a Security Operations Centre — Designing an Operating Model — checked 2 November 2026