ISO 27001 Annex A 5.7: Implementing Threat Intelligence Beyond Compliance.
- Evo-user
- 11 minutes ago
- 11 min read
Since the famous Information Security Management System standard, ISO/IEC 27001, was upgraded from the 2013 version to ISO/IEC 27001:2022, several positive and relevant changes were introduced.
From “real” and measurable information security objectives to new controls that better reflect today’s security landscape, the 2022 edition brought many improvements. One of the controls that immediately caught my attention was Annex A 5.7: Threat Intelligence.
At the same time, I was already finding the world of Security Operations Centres (SOCs) very interesting. In my previous role, I learned how much valuable information we can obtain from system logs. When logs are correlated over time and across different devices, they can reveal a great deal about what is happening in an environment—and sometimes even point us towards the probable root cause of an incident.
While security teams are often busy treating symptoms, careful monitoring and correlation of logs can help uncover the actual cause of a problem.
Now scale this concept across your entire infrastructure, extend it beyond your organization, and map it against an adversary’s tactics, techniques, and procedures (TTPs) using the MITRE ATT&CK framework. You begin to develop a much clearer picture of your current security posture and the concrete actions required to detect and respond to threats.
That, in my view, is where threat intelligence becomes extremely valuable.
My Experience with Annex A 5.7 Threat Intelligence.
As a penetration tester, I am naturally curious about how systems work and how they can be attacked. As a compliance consultant and auditor, I also spend considerable time examining whether security processes are actually working as intended.
Because of this, I have often found the connection between penetration testing, security monitoring, risk assessment, and compliance both interesting and, at times, slightly odd.
Whenever I audit an organization and ask about ISO/IEC 27001:2022 Annex A 5.7: Threat Intelligence, I have been disappointed on several occasions. Not necessarily because the control was completely absent. The disappointment was more often because the control had been misunderstood.
An organization may have a threat intelligence policy, a subscribed threat feed, or a security tool. But that alone does not demonstrate that the organization understands the threats relevant to its business or uses intelligence to improve its security decisions.
What does ISO 27001 Annex A 5.7 Threat Intelligence control requires?
The control states: "Information relating to information security threats shall be collected and analysed to produce threat intelligence."
To understand the control properly, it is useful to refer to the implementation guidance in ISO/IEC 27002:2022.
In simple terms, the objective of Annex A 5.7 is to help an organization understand the types of threats it faces and take appropriate action. Threat intelligence should provide useful input into the organization’s risk assessment and risk treatment processes.
It should also help create a more realistic picture of the threats affecting the organization’s particular:
Industry sector.
Geographic footprint.
Technology environment.
Business model.
Supply chain.
Critical services.
Crown-jewel assets.
This is important because a generic threat landscape report does not automatically represent the threat landscape of your organization.
The real purpose of threat intelligence is not to collect information and store it in a folder. It is to analyse that information, understand its relevance, and use it to make better security decisions.
What do i commonly see During Audits?
While auditing against standard ISO/IEC 27001:2022 for annex A control A 5.7 Threat Intelligence, the most common observation I see is copy-paste threat intelligence theory.
The organization has a document called Threat Intelligence Policy. It contains definitions of tactical, operational, and strategic threat intelligence. It may also include statements such as:
“XYZ is committed to protecting its information assets from cyber threats.”
There is nothing wrong with such a statement. The problem begins when the document has no connection with the organization’s actual ISMS implementation.
The policy exists, but:
No one can explain which threats are relevant to the organization.
There are no documented intelligence requirements.
No one can show how intelligence is collected and analysed.
The risk register does not reflect the identified threats.
Management reviews do not discuss relevant threat activity.
Security controls have not changed based on the intelligence received.
Employee awareness training does not address the relevant threat actors or TTPs.
This is how a document becomes a compliance artifact rather than a useful security process.
The SOC trap and the illusion of Compliance
Threat intelligence is often mistakenly treated as an incident response activity or a form of perimeter defense. An organization subscribes to a feed, connects it to a firewall or SIEM, blocks a few indicators, and assumes the control has been implemented.
This is where the SOC trap begins.
A SOC may receive thousands of indicators every day. IP addresses, domains, URLs, file hashes, malware signatures, and other indicators can be useful, but they are only one part of threat intelligence.
If the organization does not understand who is targeting it, why it is being targeted, what techniques are being used, and which assets are at risk, then it is working with data—not intelligence.
Threat intelligence should not create the illusion that the organization is secure simply because a dashboard is full of alerts.
The 3 Tiers of Threat Intelligence - The current scenario
Tactical Threat Intelligence - This is where most organizations stop.
Tactical intelligence generally includes automated Indicators of Compromise (IoCs), such as:
IP addresses.
File hashes.
Malicious domains.
URLs.
Malware signatures.
Email indicators.
These indicators can be fed into security technologies such as:
Firewalls.
SIEM platforms.
EDR and XDR solutions.
Intrusion detection systems.
Secure email gateways.
Threat-hunting platforms.
Tactical intelligence is useful for immediate detection and blocking. However, it often has a short lifespan and provides limited context about the attacker, campaign, or business impact. Blocking one malicious IP address does not necessarily mean the organization understands the threat.
Operational Threat Intelligence - This is the level I find missing most often during audits.
Operational intelligence focuses on the way threat actors operate. It examines their tactics, techniques, and procedures and helps security teams understand how an attack may develop.
This may include information about:
Initial access techniques.
Phishing and social engineering methods.
Exploitation of public-facing applications.
Credential theft.
Lateral movement.
Command-and-control activity.
Data exfiltration.
Ransomware deployment.
Persistence mechanisms.
Operational intelligence can be mapped to the MITRE ATT&CK framework to improve detection engineering, threat hunting, incident response, and defensive planning.
This is where an organization can move from asking: “Which malicious IP addresses should we block?”
to asking: "How is this threat actor likely to enter our environment, move through it, and reach our critical assets?"
That is a much more useful question which can address the compliance as per ISO 27001 for control A 5.7 threat intelligence.
Strategic Threat Intelligence - Strategic intelligence is where organizations often create an executive blind spot.
Senior management needs to understand the broader threat environment and its possible business consequences. Strategic intelligence addresses questions such as:
Which threat actors target our industry?
Why would they target us?
Which business services are most attractive to them?
What is the likely impact of a successful attack?
Are our current security investments aligned with the threat?
Which risks require executive attention?
If an organization has no understanding of the operational tactics of threat actors targeting its sector, security teams may simply be “punching in the dark.” Eventually, this creates fatigue, wasted effort, and poor prioritization.
Strategic intelligence helps leadership make informed decisions about risk acceptance, security investment, resilience, and business continuity.
Understand your "Context".
Many of us have seen reports with titles such as: “Global Threat Report 2026”
These reports may contain valuable data, graphs, statistics, and observations. Sometimes they are useful. Sometimes we download them, save them, and never read them again.
The problem is not that global reports are useless. The problem is that organizations often consume them without considering their own context.
A threat report focused on telecommunications may not be directly relevant to a pharmaceutical organization. A report about attacks in North America may not accurately represent the risk faced by an organization operating primarily in India. A report about cloud-native environments may not be useful to an organization with a mostly on-premises infrastructure.
Always consider your context before operationalizing threat intelligence.
Define your Area of Operation
Defining your Area of Operation (AoO) is extremely important.
Your AoO should consider:
Where your organization operates.
Which sectors and markets it serves.
Which regulations apply to it.
Which technologies support its business.
Which third parties and suppliers are connected to it.
Which assets are critical to its operations.
This concept can be linked to Clause 4.1: Understanding the Organization and Its Context.
Your geographic footprint, industry sector, business model, and technology stack all matter.
You should also define your organization’s crown jewels. These are the systems, information assets, processes, and services that must be protected because their compromise could seriously affect the organization.
Without defining these assets, it becomes difficult to determine whether a piece of threat intelligence is genuinely important.
A Practical example
Consider a targeted executive-impersonation campaign attempting to collect employee WhatsApp numbers.
For an organization that regularly communicates with customers, vendors, or field employees through WhatsApp, this could be highly relevant intelligence. It may require immediate administrative action, employee awareness training, stronger verification procedures, and monitoring for impersonation attempts.
Now compare that with a generic global malware report that has no direct connection with the organization’s sector, technology, geography, or assets.
The global report may still be useful as background information, but it may not require immediate action.
This is the missing link in many threat intelligence programmes: organizations collect information without deciding whether that information matters to them.
The missing Link - Risk Assessment
Let me put this plainly: threat intelligence is almost useless if it does not change organizational behaviour or decision-making.
Once you understand your context and Area of Operation, your risk assessment should be influenced by relevant intelligence—not by every external feed that happens to arrive in your inbox. If intelligence reveals a rising threat in your sector, the organization should review whether the likelihood and impact scores in the risk register remain accurate.
For example, intelligence about increasing ransomware activity against your sector may require you to reassess risks related to:
Backup and recovery.
Privileged accounts.
Remote access.
Endpoint security.
Network segmentation.
Vulnerability management.
Business continuity.
Third-party access.
This may trigger:
A revised risk rating.
A new risk treatment action.
A review of existing controls.
A new monitoring requirement.
An updated incident response scenario.
Targeted security awareness training.
When this linkage is present, threat intelligence becomes a meaningful input into the ISMS.
When it is absent, the organization may have a threat intelligence policy—but not a threat intelligence capability.
What should an Organization actually do?
Organizations need to move beyond paper-pushing exercises and create a practical, repeatable workflow. The process does not need to begin with an expensive platform. It should begin with clear requirements and ownership.
Define Intelligence Requirements
First, decide what the organization needs to know.
Examples include:
Which threat actors target our industry?
Which vulnerabilities affect our technology stack?
Which threats target our geographical region?
Are our critical suppliers being targeted?
Are executives or employees being impersonated?
Which attack techniques could affect our crown-jewel assets?
What emerging threats could disrupt our business services?
Without clear requirements, threat intelligence quickly becomes a collection exercise.
Identify Relevant Sources
Depending on the organization’s size and risk profile, sources may include:
Government and national cybersecurity advisories.
CERT notifications.
Industry information-sharing groups.
Vendor security advisories.
Internal SOC alerts.
Vulnerability management records.
Incident reports.
Open-source intelligence.
Commercial threat intelligence providers.
Regulatory or law enforcement notifications.
The organization should know why each source is being used and who is responsible for reviewing it.
Collect and Analyse Information
Raw data is not threat intelligence. The information should be reviewed for:
Relevance.
Reliability.
Timeliness.
Confidence.
Potential impact.
Applicability to organizational assets.
Relationship to known threat actors or campaigns.
The same piece of information may be highly important to one organization and completely irrelevant to another.
Communicate the Intelligence
The right information must reach the right people.
Security teams may need indicators, detection logic, and attacker TTPs. IT teams may need patching and configuration recommendations. Business owners may need information about service disruption and operational impact. Senior management may need a concise view of business risk and required investment.
A technical alert sent to the wrong audience is not effective communication.
Record the Decision and Action
Every meaningful intelligence item should result in a decision. That decision could be:
Block an indicator.
Create a SIEM detection rule.
Patch a vulnerable system.
Review privileged access.
Perform threat hunting.
Update an incident response playbook.
Modify a risk rating.
Conduct targeted security awareness training.
Accept the risk temporarily.
Continue monitoring without immediate action.
Even when the decision is to take no immediate action, the reasoning should be recorded.
Red Flags in Threat Intelligence Implementation
Here are some red flags that most experienced security and audit professionals will recognize while auditing against ISO 27001 for control A 5.7 threat intelligence:
A static threat intelligence policy containing only definitions and commitments.
No connection between the policy and actual security activities.
No defined sources or review frequency.
No analysis records.
No intelligence requirements.
No risk identification related to the organization’s sector.
No connection between threat intelligence and the risk register.
Risk ratings changed through unexplained red, orange, yellow, and green formulas.
Management review minutes that do not mention relevant threats.
Security awareness training that ignores identified threat actors and their TTPs.
A commercial threat feed with no evidence of review or action.
A security tool being treated as proof that the control is effective.
A threat intelligence process should leave behind evidence of thinking, analysis, decisions, and action—not just a subscription invoice or an exported dashboard.
The Ecosystem Check: Advisories and Audit Reality
Some organizations genuinely invest significant effort in implementing their ISMS. They may implement it through their own teams or with the support of an external consultant. I am comfortable with both approaches.
My strongest objection is to the templated approach used for a crucial control such as threat intelligence. Threat intelligence requires a real-world operational workflow. It cannot be implemented effectively by copying a policy, subscribing to a feed, and purchasing a tool simply because someone said it was necessary.
Sometimes organizations are advised to “just subscribe to a threat feed” or purchase a tool that supposedly solves the problem. This can give leadership a false sense of security while leaving significant strategic blind spots.
A tool can help collect, enrich, correlate, and distribute information. But it cannot define the organization’s context, understand business priorities, or make risk decisions on behalf of management. The technology may be useful, but the process must come first.
Threat Intelligence from an Auditor’s Perspective
If you are auditing a client against ISO/IEC 27001 Annex A 5.7 Threat Intelligence, shift your focus away from the boilerplate template—especially if you notice that the organization has one.
Start asking for evidence of actual activities, including:
How the organization identifies relevant threats.?
How intelligence requirements are defined.?
Which sources are used.?
How information is analysed.?
How findings are communicated.?
How risks are identified or reassessed.?
How controls are selected or modified.?
How awareness activities are tailored to relevant threats.?
How management reviews threat intelligence.?
How actions are assigned and tracked.?
Try tracing the evidence from a specific threat to a specific risk or control. for example, "A threat actor targets the organization’s industry using credential phishing. The organization identifies the threat, updates the risk assessment, improves email controls, modifies monitoring rules, and delivers targeted awareness training."
The important point is not whether the organization has collected information. The important point is whether it has converted that information into a meaningful understanding of risk and action. Identify how the controls interlink with one another and how the mitigation is justified in that context. You are smart enough to get the answer.
Apply the “So What?” Test
Every time an organization receives a piece of intelligence—whether it is a daily automated brief, a vendor advisory, or a quarterly executive report—it should ask: So, What?
How does this affect us?
What should we do differently?
Who needs to know?
Does this change our risk assessment?
Does this require a control review?
If the intelligence does not result in a new alert, a modified risk rating, a system update, a threat-hunting activity, an incident response improvement, or targeted security awareness training, then the organization should question whether the intelligence was properly analysed. Of course, not every intelligence item will require immediate action. Sometimes the correct response is to document that the item is not relevant or that the organization will continue monitoring it. But that decision should be deliberate and evidence-based.
Conclusion: Is Your Threat Intelligence Producing Action?
For ISO/IEC 27001 Annex A 5.7 Threat Intelligence is not about maintaining another policy document or subscribing to another security feed. It is about understanding the threats relevant to your organization and using that understanding to make better security decisions.
Threat intelligence should connect the external threat landscape with your internal environment, critical assets, risk assessment, security controls, SOC operations, incident response, and employee awareness.
So the next time someone shows you a threat intelligence dashboard, a feed subscription, or a beautifully formatted policy, ask the most important question: “So what changed because of this intelligence?”
If the answer is “nothing,” then the organization may have collected threat data—but it has not yet produced threat intelligence.
True compliance is not about generating paperwork. It is about achieving measurable risk reduction.
Comments