ISO 27001 A.5.7: Turn Threat Information into Decisions

What A.5.7 requires in practice

Annex A control A.5.7 asks the organisation to collect and analyse information about security threats so that it becomes threat intelligence. The two verbs together are important. Gathering feeds of alerts is not enough; the information must be examined and turned into something that supports decisions.

Useful intelligence relates to the organisation’s own circumstances. It answers questions about who might target the business, how, and what that implies for controls, monitoring and response. The sources can be internal, such as observed attempts and incident history, or external, such as advisories and sector bulletins. The organisation chooses what suits its size and risk.

The control does not require a dedicated intelligence team, a commercial feed or a specific format. A small business may rely on a few trusted sources and a regular review. What an assessor looks for is a working path from information received to action taken.

Begin with a decision that needs better information

Define who will use the intelligence and what they need to decide. A leadership team may need to understand a change in the threat environment affecting a planned service. Technical staff may need to prioritise a relevant exposure. Incident responders may need context for an unusual event. These audiences require different levels of detail.

A clear question helps control volume. Ask whether a reported threat affects a technology, process or supplier used by the organisation, and what information would change the response. Avoid collecting material solely because it is available. An extensive feed without an analysis owner can obscure a small but consequential signal.

Assess the source and the organisation’s exposure

Consider reliability, timeliness and the basis of a report. Distinguish confirmed observations from inference, repetition or promotional claims. Several outlets repeating the same original report do not necessarily provide independent corroboration. Preserve relevant uncertainty instead of converting an early allegation into a statement of fact.

Relate the information to the organisation’s actual assets, configurations and dependencies. A product name alone may be insufficient to establish exposure. Use the information and asset inventory and appropriate technical input to determine whether the reported conditions apply. If the inventory is incomplete, record that uncertainty and investigate it rather than concluding that no affected system exists.

Communicate an assessment people can act on

A useful intelligence output explains the issue, its relevance, confidence and the decision or further investigation needed. Technical detail should support the recipient’s role. Sending an indicator list to a business manager without its implications does not help them authorise resources or accept risk.

Assign action ownership and review what happened. Intelligence may lead to a risk reassessment, a change in monitoring, a test or a justified decision to keep existing arrangements. When technical mitigation is needed, connect with vulnerability management and authorised change procedures. An urgent external report does not remove the need to understand operational consequences.

Why threat intelligence matters to the business

Attackers change methods constantly, and defences designed once age quickly. Threat intelligence helps the organisation spend limited effort where it counts: patching what is actually being exploited, tuning monitoring and warning staff about current scams. It helps avoid both complacency and reacting to every headline.

For customers, evidence that the business learns from the wider threat picture supports trust, especially in sectors that handle valuable data. Unanalysed feeds, by contrast, create noise and a false sense of coverage. The business value comes from relevance and decision, not the volume of information collected.

How to implement A.5.7

Keep the process small enough to run reliably, and always end it with a decision. Start modestly; a small, consistent routine produces better decisions than an ambitious service that nobody sustains. Whatever you choose, keep a short record of what was judged relevant so the reasoning can be explained to others later.

1. Decide what you need intelligence for, such as prioritising fixes, informing staff or shaping monitoring.
2. Choose a handful of sources that match your technology and sector, including your own incident and monitoring history.
3. Name someone to review incoming information on a regular rhythm and to filter what is relevant.
4. Analyse relevance by asking which assets, suppliers or users could be affected and how likely that is.
5. Pass conclusions to the people who can act, and track what was done as a result.
6. Review whether the sources and routine remain useful, and feed lessons into risk assessment.
7. Share non-sensitive findings with colleagues in plain language, so awareness training reflects what is actually happening.

Evidence an auditor expects for A.5.7

Common nonconformities with A.5.7

Findings typically show information collected but never turned into decisions. Assessors usually look for evidence of judgement, not just evidence that information was received.

• Feeds are subscribed to, but nobody reviews them or records any conclusion.
• Sources do not match the organisation’s technology, so most items are irrelevant.
• Relevant warnings were received but did not reach the people who could act on them.
• The activity depends on one individual, with no cover during absence.
• Analysis does not consider the organisation’s own incident history, which is often the most relevant source.

Illustrative software example: a dependency advisory

Illustrative manufacturing example: changing disruption patterns

A hypothetical manufacturer receives sector information suggesting increased attacks on remote maintenance relationships. Its analysis considers the actual supplier connections used at its plants, the protection of those connections and the effect of service interruption. It does not assume that every reported campaign targets its own operations.

The assessment prompts a focused review of access arrangements and a continuity exercise involving one critical provider. Management receives a short explanation of the potential operational consequence and remaining uncertainty. Technical teams receive the detail needed for their checks, avoiding a single generic message sent to every audience.

Judge quality by decisions, not alert totals

Evidence can include source selection, assessments, communicated outputs, decisions and follow-up results. A.5.7 does not prescribe a report format or daily production quota. The ISMS should retain the information needed to support confidence in the process and explain consequential decisions.

Review a sample of outputs. Was the source understood? Was relevance assessed? Did the information reach someone with authority? Did subsequent findings support or challenge the original judgement? Useful performance information may concern delayed assessment or repeated uncertainty about asset ownership, rather than the number of indicators collected.

Common failures include forwarding unfiltered material, treating all alerts as equally credible, failing to revisit an assessment when facts change and using intelligence only after an incident. A provider can support analysis, but the organisation still needs a route for interpreting the result within its own business and risk context.