ISO 27001 A.5.7: Threat Intelligence

ISO 27001 A.5.7 requires an organization to collect and analyze information about information security threats, turn it into threat intelligence, and act on what that intelligence says. It is a new control in the 2022 revision, and the action teams most often get flagged on is the acting. Reading vendor advisories and CISA alerts is consumption on its own; the control is what that reading changes. The single most common A.5.7 gap is threat information that arrives but never changes a patch priority, a detection rule, or an incident playbook.

What is ISO 27001 A.5.7?

ISO 27001 A.5.7 Threat intelligence is the organizational control that requires an organization to collect and analyze information relating to information security threats and produce threat intelligence from it. Paraphrasing the intent attributed to ISO/IEC 27001:2022, Annex A: the organization gathers information about existing and emerging threats from relevant sources, analyzes it for relevance to its own environment, and uses the result to inform its protective actions. A.5.7 is a governance and process control rather than a technical tool. It asks for a repeatable loop from threat information to action rather than the purchase of a threat feed.

A.5.7 is one of the controls introduced in the 2022 revision. It did not exist as a standalone control in the 2013 standard, where threat awareness was implied inside risk assessment and the supplier and monitoring controls rather than named on its own. The 2022 revision named threat intelligence as its own control to make the collect-analyze-act loop an explicit, auditable expectation. ISO 27002 describes threat intelligence across three levels: strategic (high-level trends and attacker motivations that inform risk decisions), tactical (attacker methods, tools, and technologies), and operational (specific indicators and details of active attacks). A right-sized program touches all three without needing a dedicated team for any of them.

How do you implement A.5.7?

Implementing A.5.7 is a repeatable loop a team runs on a defined cadence rather than a one-time setup. The control is environment-agnostic: the same loop applies whether the stack is cloud, on-prem, or hybrid, because A.5.7 governs the process rather than the infrastructure. Each step produces an artifact an auditor can later sample.

1. Identify relevant threat sources. Pick the sources that match the actual stack and sector rather than subscribing to everything. Practical inputs include vendor and software security advisories for the technologies in use, CISA and CCCS (Canadian Centre for Cyber Security) alerts, an industry ISAC or special interest group where one fits the sector, national vulnerability feeds such as the NVD and CISA Known Exploited Vulnerabilities catalog, and the threat findings the organization's own detection and vulnerability-scanning tooling (for example, Nessus or Qualys) already produces. Write the source list down: an undocumented source list is one an auditor cannot confirm.
2. Assign ownership. Name who reviews the threat sources, on what cadence, and who decides what happens next. On a small team this is a named person with a recurring calendar slot rather than a security operations center. Ownership is what separates a control that operates from a mailing list nobody reads. Without a named owner, threat intelligence defaults to whoever happened to see the news that week.
3. Analyze for relevance to your stack. Filter incoming threat information against the asset inventory and technology in use, and discard what does not apply. A critical advisory for a database engine the organization does not run is noise; the same advisory for a component in production is a priority. Relevance analysis is the step that turns a firehose into a short list a small team can act on, and it is where the operational and tactical levels of intelligence get connected to real assets.
4. Feed the output into action. Route the analyzed intelligence into the controls that act on it. An actively exploited vulnerability in a component you run raises its patch priority under A.8.8 management of technical vulnerabilities. A new attacker technique or indicator becomes a detection rule or alert in the SIEM (such as Wazuh or Microsoft Sentinel) under A.8.16 monitoring activities. A credible campaign against your sector informs a runbook or tabletop scenario under A.5.24 incident management planning. This routing is the control. Steps 1 through 3 produce nothing an auditor can credit unless step 4 leaves a trail.
5. Record the loop. Keep a short running record of what was reviewed, what was judged relevant, and what action it drove, even when the action is documented no-action-needed. The record is what demonstrates the loop operates over time rather than existing as a subscription list. A monthly cadence with a one-line disposition per relevant item is enough for most SMB and SaaS teams.

What evidence demonstrates A.5.7?

A.5.7 evidence is the set of artifacts that prove the collect-analyze-act loop operates rather than simply that a feed was purchased. Auditors sample across the definition (sources and ownership exist) and the operation (intelligence was analyzed and drove action).

How does A.5.7 map to SOC 2?

A.5.7 maps to SOC 2 CC7.1 as a Partial overlap. SOC 2 has no dedicated threat-intelligence criterion, so A.5.7 is not a one-for-one match with any single criterion. It supports CC7.1, the criterion for detecting and monitoring new vulnerabilities and threats, by supplying the external threat input that vulnerability detection and monitoring act on.

The overlap is Partial rather than Full because CC7.1 is satisfied largely by vulnerability scanning, penetration testing, and detection tooling, while A.5.7 adds the explicit expectation of a documented threat-intelligence loop with sources, ownership, and analysis. A SOC 2 program produces the detection and vulnerability evidence that feeds A.5.7, but the source list, ownership, and intelligence-to-action records usually need to be documented as net-new for the ISO 27001 certification audit. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across every criterion.

Related controls

A.5.7 is the input that several other controls act on. A.8.8 management of technical vulnerabilities is where threat intelligence changes patch priority, since knowing a vulnerability is actively exploited raises it in the queue. A.8.16 monitoring activities is where new attacker techniques and indicators become detection rules and alerts. A.5.24 incident management planning and preparation is where a credible threat to the sector informs runbooks and tabletop scenarios. A.5.6 contact with special interest groups is the adjacent organizational control that establishes the ISAC and community relationships many threat sources come through. All belong under the ISO 27001 certification guide.

Frequently Asked Questions

What is ISO 27001 A.5.7?

ISO 27001 A.5.7 Threat intelligence is an organizational control in Annex A of ISO/IEC 27001:2022. It requires an organization to collect and analyze information about information security threats and produce threat intelligence, then use that intelligence to inform its protective actions. It covers identifying relevant threat sources, assigning ownership, analyzing incoming information for relevance to the organization's own environment, and feeding the result into vulnerability prioritization, detection, and incident preparation. It was introduced in the 2022 revision.

Is A.5.7 new in ISO 27001:2022?

Yes. A.5.7 Threat intelligence is one of the controls introduced in the 2022 revision of ISO 27001. It did not exist as a standalone control in the 2013 version, where threat awareness was implied inside risk assessment and the supplier and monitoring controls. The 2022 revision named threat intelligence as its own organizational control to make the collect-analyze-act loop an explicit and auditable expectation.

What evidence satisfies A.5.7?

A.5.7 evidence proves the collect-analyze-act loop operates. Auditors look for a documented list of relevant threat sources, a record of who owns threat-intelligence review and on what cadence, analysis or triage records showing incoming information was assessed for relevance to the stack, and intelligence-to-action records showing that analyzed intelligence changed a patch priority, a detection rule, or an incident playbook. A subscription list with no analysis and no action trail does not satisfy the control.

Does a small company need a threat intelligence program?

Yes, but a right-sized one. A.5.7 does not require a dedicated threat-intelligence team, a paid platform, or a full-time analyst. For an SMB or SaaS organization, a named owner spending a defined block of time each month on a curated source list of vendor advisories, CISA or CCCS alerts, and relevant vulnerability feeds, and feeding the conclusions into patching and detection, satisfies the control. The requirement is a documented, operating loop at any scale.

What are the three levels of threat intelligence in A.5.7?

ISO 27002 describes threat intelligence at three levels. Strategic intelligence covers high-level trends and attacker motivations that inform risk decisions and program priorities. Tactical intelligence covers attacker methods, tools, and technologies. Operational intelligence covers specific technical details and indicators of active attacks. A right-sized A.5.7 program touches all three: strategic input shapes risk decisions, while tactical and operational input drives detection rules and patch priorities.

How does A.5.7 map to SOC 2?

A.5.7 maps to SOC 2 CC7.1 as a Partial overlap. SOC 2 has no dedicated threat-intelligence criterion, so A.5.7 supports CC7.1, the criterion for detecting and monitoring new vulnerabilities and threats, rather than matching a criterion one-for-one. The vulnerability and detection evidence produced for CC7.1 feeds A.5.7, but the documented threat-source list, ownership, and intelligence-to-action records usually need to be added as net-new work for the ISO 27001 certification audit.

Part of Truvo's control-by-control ISO 27001 Annex A reference series. Start from the ISO 27001 certification guide for the full picture. If you are building A.5.7 as part of an effective security program and want a second set of eyes on the design, Truvo runs scoping calls.