Annex A Controls

A.5.7 Threat Intelligence — What Auditors Actually Expect

Alex Fuerst

05 Sep 2025 — 5 min read

The Three Layers That Matter

Control 5.7 requires organizations to collect and analyze information relating to information security threats to produce threat intelligence. The standard deliberately defines three distinct layers of threat intelligence that must be considered, and understanding these layers is crucial to meeting audit expectations:

Strategic threat intelligence: High-level information about the changing threat landscape (types of attackers, attack trends)
Tactical threat intelligence: Information about attacker methodologies, tools and technologies
Operational threat intelligence: Details about specific attacks, including technical indicators

During audits, I see organizations focus heavily on operational indicators—IOCs, file hashes, domain reputation—while completely ignoring strategic intelligence that could inform long-term security investments. This creates a dangerous blind spot. Your threat intelligence program needs to address all three layers proportionate to your organizational context.

The ISMS Integration Imperative

Here's what separates effective threat intelligence from expensive noise: integration with your broader ISMS. Control 5.7 isn't a standalone activity—it must feed directly into your risk management process under Clause 6.1.2. The standard explicitly states that threat intelligence should be used "by implementing processes to include information gathered from threat intelligence sources into the organization's information security risk management processes."

This means your threat intelligence needs to influence:

Risk identification and assessment activities
Control selection and implementation decisions
Security monitoring and detection capabilities (feeding into Controls 8.16 and 8.7)
Incident response planning under Control 5.24
Vulnerability assessment and testing processes under Controls 8.8 and 8.33

If your threat intelligence exists in isolation from these processes, you're missing the fundamental intent of the control.

What Auditors Actually Look For

Let me be specific about what evidence I examine during a 5.7 assessment:

Documentation and Process Evidence

I want to see a documented process that covers the six activities explicitly mentioned in ISO/IEC 27002:

Establishing objectives for threat intelligence production
Identifying, vetting and selecting internal and external sources
Collecting information from selected sources
Processing information for analysis
Analyzing information to understand organizational relevance
Communicating and sharing intelligence to relevant individuals

This doesn't need to be a 50-page procedure manual. A simple flowchart showing how threats are identified, assessed, and acted upon is often sufficient for smaller organizations.

Source Management

I examine your threat intelligence sources and their appropriateness to your risk profile. For a manufacturing company, this might include ICS-CERT advisories and sector-specific threat sharing groups. For a financial services firm, I'd expect to see engagement with FS-ISAC and monitoring of financially-motivated threat actor campaigns.

The key audit question: Can you demonstrate that your sources are relevant to your threat environment and business context?

Analysis and Contextualization

Raw threat feeds aren't threat intelligence—they're just data. I look for evidence of analysis that considers your specific environment. This might be as simple as a risk assessment that evaluates whether a new malware family affects your technology stack, or as sophisticated as a custom report analyzing threat actor targeting of your industry vertical.

Actionability Evidence

The most critical audit evidence is proof that your threat intelligence actually changes organizational behavior. I want to see:

Security control adjustments based on emerging threats
Detection rules or signatures updated because of threat intelligence
Risk register updates reflecting new threat information
Training or awareness activities triggered by threat intelligence
Incident response playbook modifications

The Proportionality Principle

ISO/IEC 27002 emphasizes that threat intelligence should be "relevant," "insightful," "contextual," and "actionable." This creates an implicit proportionality requirement that many organizations miss.

A 25-person accounting firm doesn't need a dedicated threat intelligence analyst parsing nation-state TTPs. They need someone monitoring relevant vendor security bulletins and ensuring critical patches get applied based on active threats. Conversely, a critical infrastructure operator that claims basic vendor advisories constitute adequate threat intelligence will face serious audit findings.

The standard's guidance on using threat intelligence as "additional input to technical preventive and detective controls" means your capability should match your technical sophistication. If you're operating a SOC with advanced detection capabilities, your threat intelligence should be sophisticated enough to enhance those capabilities.

Cross-Standard Considerations

Control 5.7 has important implications for organizations using other ISO 27000-series standards:

ISO/IEC 27017 (Cloud Security): Cloud-specific threat intelligence should include threats targeting your cloud services, shared responsibility model considerations, and cloud service provider threat notifications.

ISO/IEC 27018 (Privacy): Organizations processing personal data should incorporate privacy-specific threat intelligence, including threats targeting PII and regulatory enforcement trends.

ISO/IEC 27036 (Supplier Security): Your threat intelligence should extend to supply chain threats and include information sharing with critical suppliers.

Common Implementation Failures

Based on hundreds of audits, here are the most common 5.7 failures I encounter:

The "Set and Forget" Syndrome

Organizations subscribe to a threat feed, configure it to populate their SIEM, and consider the control implemented. Six months later, no one can explain how the intelligence influences security decisions. The threat feed generates alerts that get closed without investigation because they lack business context.

The Over-Engineering Trap

I've audited organizations spending six-figure sums on threat intelligence platforms that produce beautiful reports nobody reads. They've confused sophistication with effectiveness. Meanwhile, their patch management program ignores basic vulnerability intelligence because it comes from a "less sophisticated" source.

The Intelligence Island Problem

The security team has excellent threat intelligence capabilities, but this intelligence never reaches the people making business decisions. Risk assessments proceed without threat context, and business continuity planning ignores current threat trends.

Building Audit-Ready Threat Intelligence

Here's my practical framework for implementing Control 5.7 in an audit-ready manner:

Step 1: Define Your Intelligence Requirements

Start with your risk register and business context. What threats could significantly impact your organization? What intelligence would help you make better security decisions? Document these requirements clearly—they'll become your success criteria during audit.

Step 2: Map Sources to Requirements

Identify and document sources for each intelligence requirement. This creates the traceability auditors look for between your threat landscape and your intelligence collection activities.

Step 3: Establish Processing Workflows

Create simple, repeatable processes for analyzing and contextualizing threat information. This doesn't need to be complex—even a basic decision tree showing how threats are triaged and acted upon demonstrates systematic processing.

Step 4: Build Distribution Mechanisms

Ensure relevant personnel receive actionable intelligence in formats they can use. Your vulnerability management team needs different intelligence than your executive team, but both need timely, relevant information.

Step 5: Measure and Improve

Track metrics that demonstrate intelligence effectiveness: threats detected early, risks mitigated proactively, security investments informed by intelligence. These metrics provide objective evidence of program value during audit.

The Sharing Imperative

ISO/IEC 27002 specifically states that organizations "should share threat intelligence with other organizations on a mutual basis in order to improve overall threat intelligence." This sharing requirement is often overlooked but increasingly important as threats become more sophisticated.

Consider participating in industry threat sharing groups, ISACs, or informal peer networks. Document your participation and any intelligence shared or received. This demonstrates both community engagement and access to relevant threat information beyond commercial feeds.

Looking Forward

Threat intelligence capabilities will continue evolving, but the fundamental audit expectation remains constant: demonstrate that your organization systematically collects, analyzes, and acts upon threat information appropriate to your context. Whether that's a monthly review of vendor bulletins or a sophisticated threat hunting program backed by custom intelligence, the key is showing clear linkage between threats, intelligence, and organizational action.

The most successful organizations I audit treat threat intelligence as a risk management capability, not a technical tool. They understand that Control 5.7 is ultimately about making informed decisions in an uncertain threat environment.

Need help building an audit-ready threat intelligence program? Connect with experienced practitioners in our ISO 27001 Info Hub community or explore our comprehensive control implementation guides for additional insights.

Need personalized guidance? Reach our team at ix@isegrim-x.com.