Cyber attacks evolve faster than traditional security review cycles. So, to stay secure, organisations need a clearer understanding of the threats that are most relevant to their systems, data and business operations.
Threat intelligence is the process of collecting and analysing information about these threats so that security decisions are informed by real-world attack patterns rather than theoretical risk models. Done well, it enables organisations to both pre-empt attacks and respond more effectively when incidents happen.
This is the purpose of ISO 27001:2022 control 5.7.
As one of 11 new controls introduced by the 2022 iteration of the Standard, it requires organisations to collect information about security threats and analyse it to produce threat intelligence.
But what does that actually involve?
This blog post explains control 5.7 and how to implement it.
What does ISO 27002 say about threat intelligence?
According to ISO 27001’s supporting standard ISO 27002, there are three levels of threat intelligence that organisations should consider:
- Strategic threat intelligence: exchange of high-level information about the changing threat landscape (for example types of attacks or attackers).
- Tactical threat intelligence: information about attack methodologies, tools and technologies.
- Operational threat intelligence: details about specific attacks, including technical indicators.
Wherever you choose to focus, it’s important that the intelligence you gather is relevant, insightful, contextual and actionable.
What you do with that intelligence is, of course, also important. ISO 27002 states that threat intelligence activities should include:
- Establishing objectives.
- Identifying, vetting and selecting necessary and appropriate internal and external information sources.
- Collecting information from those sources.
- Processing that information, for example by translating, formatting or corroborating information).
- Analysing the information to understand how it affects your organisation.
- Communicating and sharing it to relevant individuals in an understandable format.
But what does that look like in real terms?
Roles and responsibilities
First, it’s essential to assign responsibilities clearly to ensure the right intelligence is gathered, analysed and acted upon.
Senior management should, naturally, be accountable for ensuring the ISMS uses intelligence to keep risk at acceptable levels, but other roles will be involved in the process. For instance, the:
- Information security manager sets requirements, approves sources, reports to management.
- SOC (security operations centre) or monitoring lead owns collection, triage and detection changes.
- Vulnerability manager aligns remediation with live exploitation and vendor alerts.
- Supplier manager routes relevant items to contract owners and records assurance responses.
- Communications lead issues staff advisories for current lures.
- Risk owner updates risk records when analysis changes exposure.
Information sources
Second, it’s important to consider the sources of information you rely on. As with anything, it’s worth using multiple sources – both internal and external – to ensure you have a balanced view and don’t miss anything important.
Internal examples include:
- SIEM (security information and event management) and log analytics, incident reviews and lessons learned.
- Vulnerability scans and penetration testing, and red/purple team assessments.
- Supplier findings and change records that indicate emerging exposure.
External examples include:
- Government advisories and alerts (for example, the NCSC (National Cyber Security Centre’s reports and advisories).
- Vendor bulletins and CVE (common vulnerabilities and exposures) notices (for example, Microsoft’s Patch Tuesday updates)
- Sector ISACs (information sharing and analysis centres) and trusted communities.
- Curated commercial reporting where budget allows. (Free and low-cost sources can help you meet the control’s intent if you analyse and act on them.)
A simple operating model
So, how does this translate to day-to-day operations? Let’s look at how threat intelligence works in practice.
Set intelligence requirements
First, write down what you need to know and why. Base this on threat-led risks to your assets, services and supply chain. For example, known vulnerability exploitation activity that changes your patching management programme, supplier compromise patterns in your sector and known phishing attacks targeting similar organisations.
Select and vet sources
Choose a small set of sources that serve those requirements, evaluate their credibility and coverage, and review the list at least quarterly. Record source ownership and access paths (emails, APIs, portals).
Collect and triage
Automate collection where possible, but keep triage human. Use a mailbox, ticket queue or TIP/SIEM integration so items are not missed. Tag by requirement, asset, threat actor or MITRE ATT&CK technique to aid routing.
Analyse
Ask four questions before you act:
- Relevance – does it touch our tech stack, suppliers or users?
- Timeliness – is it current enough to matter now?
- Confidence – do multiple credible sources align?
- Impact – what is the plausible worst case if we do nothing?
Document your analysis briefly. Your audit trail should show why you did or did not act.
Act and record
Actions should include:
- Prioritising remediation where exploitation is active rather than relying on severity alone.
- Updating detection logic and blocklists with verified IOCs and TTPs.
- Adjusting incident playbooks and escalation triggers.
- Tightening supplier controls or requesting evidence where a campaign targets your supply chain.
- Briefing users on live lures observed in your sector.
Maintain a traceable link from the item to the change ticket, playbook update, training note or supplier action.
Review effectiveness
At management review, assess whether threat intelligence affected any decisions or reduced your organisation’s exposure. Then retire sources that create work without outcomes.
Track whether intelligence has resulted in any measurable changes, such as faster remediation, fewer repeat incidents, improved detection coverage or more informed supplier oversight. If a source has produced no decisions over several review cycles, either retire it or redefine intelligence requirements to ensure alignment with actual risk.
Documentation and audit evidence
Auditors will look for evidence that you both collect and analyse threat information, and that it drives action. Examples of the sort of documentation you should maintain:
- Intelligence requirements register with owners and consumers.
- Vetted source list with review cadence.
- Triage and analysis notes linked to tickets or change records.
- Evidence that risks and SoA (statement of applicability) entries were updated when threats changed.
- Communication logs showing who received what intelligence and when.
Small organisations can document this within an incident or vulnerability procedure. Larger ones may require a short threat intelligence procedure and a monthly digest.
How control 5.7 integrates into the ISMS
Threat intelligence should feed into several other ISO 27001 activities:
- Risk assessment (Clause 6.1)
New or changing threats should trigger updates to risk likelihood, impact evaluations and treatment plans. - Supplier security (A.5.19–A.5.22)
If intelligence shows increased supply chain targeting, this should be reflected in supplier assurance checks or contract requirements. - Technical vulnerability management (A.8.8)
Prioritise patching based on active exploitation, not just CVSS scores. - Monitoring and detection (A.8.16)
Tactical intelligence should lead to updated detection rules and alerting thresholds. - Incident management (A.5.24–A.5.28)
Operational intelligence should inform playbooks, escalation triggers and communication plans.
Recording these linkages provides clear evidence that threat intelligence is used to inform decisions, which is what auditors expect to see.
Demonstrating effective threat intelligence in practice
Implementing control 5.7 is more than simply subscribing to threat feeds. In practice, auditors look for evidence that the intelligence you gather changes something – in your risk assessments, controls, monitoring or supplier oversight.
The most common nonconformities involve the absence of this link:
- Threat information is collected but not analysed or documented.
- No updates are made to risk records when threat likelihood or impact has changed.
- Source lists grow over time without review, leading to noise and missed priorities.
- Intelligence that relates to suppliers is not routed to contract owners, leaving supply-chain exposure unaddressed.
These issues usually indicate that threat intelligence is treated as an isolated activity rather than part of the ISMS.
Auditors are more likely to recognise effective implementation when your organisation can show:
- A short, periodic digest that highlights relevant threats and the decisions taken as a result.
- A change log showing how detection rules, firewall policies or hardening steps were updated in response to specific intelligence.
- Risk register entries that cite threat intelligence as the basis for re-rating likelihood or impact.
- Supplier assurance communications tied to threat activity affecting the supply chain.
These outputs demonstrate that threat intelligence is being used to inform risk treatment and control improvement, which is the core purpose of control 5.7.
How we can help
We’ve been implementing information security management systems for over 20 years. If you need support with any aspect of your ISO 27001 compliance programme – from an initial gap analysis to ongoing ISMS maintenance and everything in between – we have everything to help you.
The post Threat Intelligence – ISO 27001:2022 Control 5.7 Explained appeared first on IT Governance Blog.
