Auditing Annex A 5.7 (Threat Intelligence) can be tricky because it is one of the new controls in the 2022 standard. Unlike checking a firewall rule or a locked door, auditing “intelligence” feels abstract. How do you audit a thought process?
As an auditor, or someone preparing to face one, you need to move past the buzzwords. You are not looking for evidence that the company is the CIA. You are looking for evidence that they are aware, analytical, and active regarding the threats facing their specific environment.
Here is a practical guide on how to audit this control effectively, what evidence to dig for, and how to spot a “paper shield” that offers no real protection.
Table of contents
The Core Requirement: What Are You Testing?
The standard requires that “Information relating to information security threats should be collected and analyzed to produce threat intelligence.”
When auditing this, you are testing a lifecycle. You need to see evidence of three distinct phases:
- Collection: Are they gathering data?
- Analysis: Are they thinking about how it applies to them?
- Dissemination/Action: Are they telling the right people?
If you find a folder full of unread PDF reports, they have failed the “Analysis” and “Action” phases. That is a non-conformity.
Step 1: Audit the Source List (The Input)
Start by asking: “Where do you get your security news?”
You want to see a defined list of sources. This list should be relevant to the organization’s technology stack and industry.
The Auditor’s Test:
- Relevance Check: If they are a cloud-native startup using AWS, but their only threat feed is a physical security newsletter for retail stores, challenge them. Why is this relevant?
- Variety Check: Do they have a mix of strategic (high-level trends) and operational (technical vulnerabilities) sources?
Red Flag: The “Data Dump.” If they subscribe to 50 automated feeds that pump thousands of alerts into a generic inbox that nobody checks, the control is ineffective.
Step 2: Audit the Analysis (The Process)
This is the hardest part to audit, but the most important. You need to verify that a human being (or a configured logic system) is filtering the noise.
Ask for Evidence of Review:
- Meeting Minutes: Look for a standing agenda item in the weekly Security or IT Operations meeting called “Threat Review.”
- Slack/Teams History: Ask to see their #security-intel channel. Are people discussing the alerts? (“Hey, does this Log4j vulnerability affect our legacy server?”)
- The “Discard” Pile: Ask them for an example of a threat they saw but decided didn’t apply to them. If they can’t answer, they aren’t analyzing; they are just hoarding data.
Step 3: Audit the Action (The Output)
Intelligence is useless without action. You need to trace the thread from an external alert to an internal change.
The “Traceability” Test:
- Pick a major recent vulnerability (e.g., a specific CVE in a common library).
- Ask: “When did you find out about this?” (Check the Source).
- Ask: “How did you assess it?” (Check the Analysis).
- Ask: “Show me the ticket.” (Check the Action).
You want to see a Jira ticket, a patch record, or a firewall change request that explicitly references the intelligence source. “We patched this because CISA Alert #1234 said so.”
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
Documentation and Tools
While ISO 27001 is less about documents and more about processes, you still need a framework. A compliant organization usually maintains a Threat Intelligence Register or log.
This register should track:
- Date of Intelligence.
- Source.
- Summary of Threat.
- Relevance (High/Medium/Low).
- Action Taken.
If the organization is struggling to produce this evidence structure, it often indicates they lack a formal process. For those preparing for an audit, using a structured template is a lifesaver. Hightable.io provides excellent ISO 27001 toolkits that include audit-ready Threat Intelligence registers, ensuring you can demonstrate this workflow clearly to an auditor.
Interview Questions to Ask
If you really want to test the maturity of this control, ask these questions during the interview:
- “How do you distinguish between a generic threat and a targeted threat?” (Tests analysis capability).
- “Who is responsible for reading these alerts when the primary owner is on holiday?” (Tests resilience and resource allocation).
- “Can you show me a time when threat intelligence changed a business decision?” (Tests strategic value).
Common Non-Conformities
1. Confusion with Annex A 5.6 (Special Interest Groups)
The organization lists the groups they joined but cannot show any data they received from them. Annex A 5.6 is the network; Annex A 5.7 is the news. You need to audit the news flow.
2. Informal “Head Knowledge”
The CISO says, “I read Twitter every morning.” While valid, it is hard to audit. If it’s not documented or shared, it’s a single point of failure. Require them to formalize how that “Twitter intel” enters the company workflow.
Conclusion
Auditing ISO 27001 Annex A 5.7 is about verifying the organization’s situational awareness. You are looking for a pulse. If the organization can show that they are actively listening to the outside world and changing their defences based on what they hear, they are compliant. If they are just sitting behind a firewall waiting for the alarm to go off, they have work to do.
About the author
Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management.
Holding an MSc in Software and Systems Security, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.
As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations – from high-growth technology startups to enterprise financial institutions – through the audit lifecycle.
His toolkits represents the distillation of that field experience into a standardised framework. They move beyond theoretical compliance, providing a pragmatic, auditor-verified methodology designed to satisfy ISO/IEC 27001:2022 while minimising operational friction.
