ISO/IEC 27001:2022 Control 5.7 Threat Intelligence — A Practical Implementation Guide

Threat intelligence is one of the controls introduced with the 2022 revision of ISO/IEC 27001. Yet the practical meaning of threat intelligence is not always obvious.

In my work as an ISO/IEC 27001 Lead Auditor, I regularly encounter questions around what organisations are actually expected to do with threat information.

Is subscribing to CERT notifications enough?

Does a vulnerability feed constitute threat intelligence?

Does an organisation need a dedicated threat-intelligence platform?

And how does information about a threat ultimately influence risk and security decisions?

The key distinction is simple:

Threat information is not automatically threat intelligence.

Threat intelligence emerges when relevant information is collected, analysed, placed into organisational context and used to support decisions.

What is ISO/IEC 27001 Control 5.7?

ISO/IEC 27001:2022 includes A.5.7 Threat Intelligence among its organisational controls.

At a high level, the objective is to ensure that organisations collect and analyse information concerning information-security threats so that the resulting knowledge can inform security decisions.

The important words are therefore not merely collect, but also analyse.

An organisation can subscribe to dozens of feeds and still have a weak threat-intelligence process.

Conversely, a smaller organisation may have comparatively few sources but a mature process for determining which threats are relevant and what should be done about them.

The common misunderstanding: feeds are not the outcome

A typical starting point might include:

• national CERT advisories
• vendor security advisories
• CVE and vulnerability information
• ISAC or industry intelligence
• security research
• threat feeds
• information from security providers
• incident and practitioner intelligence

These are sources of information.

They are not, by themselves, evidence that an organisation has transformed those inputs into actionable intelligence.

Consider a simple example.

A security team receives the following information:

A vulnerability affecting a particular VPN appliance is being actively exploited.

Receiving the notification is only the first step.

A useful intelligence process asks:

The result may then be:

The original advisory was threat information.

The contextualised result is much closer to threat intelligence.

A practical threat-intelligence lifecycle

A useful implementation of Control 5.7 can be understood as a cycle.

1. Define intelligence requirements

Start with the organisation, not with the feeds.

Ask questions such as:

• Which business services are critical?
• Which technologies support them?
• Which threat actors or attack types are particularly relevant?
• Which geographies or industries affect our threat profile?
• Which suppliers or cloud services create concentration or supply-chain risk?
• What does management actually need to know?

A financial institution, manufacturing company and small software provider will not necessarily have the same intelligence requirements.

This is why collecting everything is rarely the objective.

The objective is collecting what can meaningfully affect the organisation.

2. Select appropriate sources

Sources should reflect those requirements.

They can include strategic, operational and technical information.

For example:

The important question is not:

How many feeds do we have?

It is:

Why do we use this source and which intelligence requirement does it support?

3. Collect and correlate

Modern security teams face a different problem from lack of information:

Too much information.

The same vulnerability may appear simultaneously in:

• a vendor advisory
• a CERT bulletin
• a security research article
• social-media reporting
• commercial intelligence
• practitioner discussions

A useful process should therefore deduplicate and correlate information rather than simply forwarding everything to security personnel.

This is also an area where AI-assisted workflows can provide significant value.

AI can help:

• collect information
• identify duplicates
• cluster related reports
• extract affected products
• identify referenced vulnerabilities
• classify attack techniques
• summarise developments
• prioritise material for human review

Human judgement remains particularly important when confidence, context or consequential decisions are involved.

4. Analyse relevance

This is where threat information becomes organisationally useful.

A critical CVE affecting technology that the organisation does not use may have very little operational relevance.

A less spectacular vulnerability affecting a critical externally exposed system may deserve immediate attention.

Context therefore matters.

Relevant context can include:

• Asset inventory
• Technology stack
• Software versions
• External exposure
• Business criticality
• Identity architecture
• Existing controls
• Vulnerability status
• Recovery capability

Threat intelligence should help answer:

Does this matter to us?

rather than merely:

Is this important somewhere in the world?

5. Turn intelligence into decisions

Intelligence that never reaches someone who can act on it has limited value.

Depending on the intelligence, an organisation might:

• investigate systems
• patch a vulnerability
• change monitoring
• conduct a threat hunt
• update detection logic
• review privileged accounts
• contact a supplier
• modify a risk assessment
• test recovery capability
• brief management

One useful principle is:

Every high-relevance intelligence item should have a clear disposition.

For example:

• Not relevant
• Monitoring only
• Further investigation required
• Action required
• Risk accepted
• Remediation completed

This creates traceability between information and decision.

6. Record evidence

From an ISMS perspective, the process should also be demonstrable.

Useful evidence could include:

• documented intelligence requirements
• source registers
• received advisories
• analysis records
• relevance assessments
• security tickets
• vulnerability-management records
• threat-hunting activities
• resulting risk assessments
• management briefings
• lessons learned

A mature process should be able to demonstrate more than:

We receive security newsletters.

It should be possible to show:

We receive relevant threat information, assess it and can demonstrate what happened as a consequence.

What might an auditor look for?

There is no single technology or mandatory threat-intelligence platform required simply because Control 5.7 exists.

The relevant questions depend on organisational context.

From a practical perspective, useful questions include:

Those questions reveal much more than the number of threat feeds an organisation subscribes to.

What does good audit evidence look like?

From a practical audit perspective, I am less interested in the number of threat feeds an organisation subscribes to than in whether the organisation can demonstrate a traceable process from information to decision.

A particularly useful form of evidence is a complete example showing how a relevant threat was identified, assessed and handled.

For example, an organisation might demonstrate an advisory concerning an actively exploited vulnerability, the assessment that the affected technology is present, the resulting security ticket, evidence of the action taken and the recorded closure of that action.

Other useful evidence may include:

• documented intelligence requirements
• defined responsibilities
• source registers
• relevance assessments
• analysis records
• security or remediation tickets
• threat-hunting records
• changes to monitoring or detection
• updates to risk assessments
• management briefings
• lessons learned from incidents or investigations

Evidence that may be insufficient on its own

In practice, evidence may show that an organisation receives threat data without demonstrating what happens next.

The following may demonstrate that threat information is available, but do not necessarily demonstrate that it is analysed, contextualised and acted upon:

• a list of subscribed security newsletters
• screenshots of a threat feed
• a mailbox containing CERT notifications
• vulnerability-scanner output without evidence of further assessment
• a policy stating that threat intelligence is performed without evidence of the operational process

The objective is not to produce a particular document or use a particular tool. What matters is whether the organisation can demonstrate that relevant threat information is systematically evaluated and used to support security decisions.

How might Control 5.7 findings be classified?

The examples below are illustrative only. Audit findings are based on objective evidence, organisational context and the applicable certification body's grading procedures. A particular weakness does not automatically result in a predefined classification.

Opportunity for Improvement

An Opportunity for Improvement may be considered where the organisation has a functioning process and the applicable requirements are fulfilled, but there is potential to improve effectiveness, consistency, traceability or documentation.

For example, intelligence requirements might be understood in practice but could be documented more clearly, or an effective review process might benefit from stronger evidence of follow-up.

An opportunity for improvement should not be used to disguise a nonconformity where objective evidence shows that a requirement is not fulfilled.

Nonconformity

A nonconformity may be indicated where objective evidence shows that an applicable requirement is not fulfilled.

In the context of Control 5.7, an example could be an organisation that routinely receives relevant threat information but cannot demonstrate meaningful analysis, contextualisation or a process for determining whether that information requires action.

The key test is whether the organisation can demonstrate that threat information is analysed and contextualised, rather than simply collected, and that it leads to informed decisions where action is required.

The existence of feeds, tools or policies alone does not necessarily demonstrate effective implementation.

Major Nonconformity

A major nonconformity should not be inferred simply because a particular document, template or technology is missing.

The significance of a finding depends on the extent and systemic nature of the failure, its effect on the management system and the grading rules applied by the relevant certification body.

Where there is effectively no functioning process for addressing an applicable requirement, or where a broader systemic failure calls into question the management system's ability to achieve its intended outcomes, the significance may be substantially greater.

An auditor should not be looking for a particular tool or template. The question is whether the organisation can demonstrate that relevant threat information is systematically transformed into intelligence and used to support security decisions.

Threat intelligence does not have to be complicated

A smaller organisation might have a perfectly reasonable process consisting of:

A larger organisation might operate:

The tooling changes.

The underlying logic does not.

The next step: threat intelligence for defensive AI

There is another reason why getting this process right is becoming increasingly important.

Cyber defence is becoming more automated.

Future defensive systems will increasingly need to answer the same questions humans currently ask:

That requires threat intelligence to become more structured.

Instead of sending only a PDF describing a vulnerability, intelligence may eventually look more like:

• Threat
• Affected technology
• Known exploitation
• Confidence
• Provenance
• TTPs
• Recommended investigation
• Recommended mitigation

A locally operated defensive AI could then correlate that external intelligence against the organisation's own environment without necessarily exporting sensitive internal telemetry.

This is one of the research areas we are investigating at ShadowThreats Intelligence:

How can trusted external threat intelligence be made useful both to security professionals and to locally operated defensive AI?

The governance principles behind Control 5.7 remain relevant even when AI becomes part of the process.

The technology may become faster.

The fundamental questions remain:

Conclusion

ISO/IEC 27001 Control 5.7 should not be reduced to subscribing to threat feeds.

A practical implementation establishes a process that transforms external information into organisational knowledge:

The objective is not to know everything happening in cybersecurity.

It is to understand which threats matter to your organisation and what should happen next.