A.5.7 Threat intelligence: requirements and evidence

What A.5.7 threat intelligence asks for in plain words

A.5.7 asks the organization to collect information about information security threats, analyze it, and turn it into threat intelligence it acts on, so that people understand the threat environment they operate in and can take mitigating action. It is one of the 11 controls that are new in the 2022 revision of Annex A, so a team that certified under the 2013 edition has no prior control to build on and must design the process from the requirement itself. The risk it addresses is simple to state: an organization that learns about a campaign, a vulnerability being exploited or an attacker's technique only after it has hit a peer is managing threats by luck. ISO/IEC 27002:2022 describes threat intelligence at strategic, tactical and operational levels, running from high-level information about how the threat landscape is changing, through the adversary behavior and techniques that tactical intelligence describes, down to technical indicators about specific attacks. A complete program usually needs all three, because each level informs a different decision: board risk appetite, control priorities, and detection rules.

The harder part for most teams is showing that intelligence changes decisions. Feeds get subscribed, reports get circulated, and a platform fills up with indicators, but an assessor will ask what happened as a result. Start by naming the people who must receive each level of intelligence, such as the risk owner for strategic items, the security engineering lead for tactical items and the SOC for operational indicators, and record the route for each. Then decide which decisions intelligence is allowed to trigger, for example a new detection rule, a patch priority change, a supplier review or an update to the risk assessment under clause 6.1.2. Each action should leave a record that links back to the intelligence item. Confirm with your own risk owners how often strategic reviews happen, since the standard requires the outcome to be usable rather than fixing a cadence for you.

The control also has to connect to the rest of the ISMS. Threat information feeds the information security risk assessment, the vulnerability process under A.8.8 and the monitoring activities under A.8.16, and it is one of the inputs that A.5.6 contact with special interest groups can supply. A practical test is to pick one recent threat report your organization received and trace it: where it was recorded, who assessed it, whether it changed a risk entry, a detection or a patch, and what evidence shows that. If that trace cannot be completed for a sample of items, the control is not yet demonstrated, whatever tools are in place.

Which sources, teams and systems fall under threat intelligence scope

Scope for A.5.7 comes down to four decisions: which threat sources feed the process, which teams act on the output, which systems the intelligence is matched against, and how the results connect to the clause 6.1.2 risk assessment. Document each decision, because an assessor will test whether the scope matches what the organization actually receives, reads and acts on.

Threat sources to include

List every source the organization relies on: commercial or open feeds, sector information sharing groups, vendor and software advisories, and internal detections from logs and alerts. For each source, record who owns it, how often it is reviewed and how its quality is judged. An assessor will ask whether sources were chosen because they are relevant to the organization's threat environment, so note why each one is in scope and which ones were deliberately excluded.

Vendor advisories and sector groups

Vendor advisories and sector sharing groups give early warning about vulnerabilities and campaigns that affect the products the organization runs. Decide which vendors and sector groups are covered, who subscribes to them and where their messages are logged. Check that the subscriptions match the technology inventory, since advisories for products the organization does not run add noise without changing risk.

Internal detections as sources

Alerts from security monitoring are a threat source in their own right, because they show what has already reached the environment. Define which detection platforms, log types and rule sets feed the intelligence process, and how confirmed detections are turned into indicators shared with other tools. Confirm the detection scope with the teams that operate those tools so that gaps are visible.

Teams that consume the output

Name the audiences who receive threat intelligence: the security operations team for detection content, risk owners for prioritizing treatment, engineering for patching and configuration, and management for decisions on resources. Each audience needs a different level of detail, so define the format and frequency for each. Auditors commonly sample whether the intelligence reached the people who needed it and whether they acted.

Systems matched against intelligence

Decide which assets indicators are matched against, such as endpoints, servers, network devices, cloud accounts and business applications. Use the asset inventory required by A.5.9 as the reference, so that every system in scope can be matched and every match can be traced to an owner. Systems that are outside the inventory or managed by suppliers should be listed explicitly with the arrangement that covers them.

Link to the clause 6.1.2 risk assessment

Threat intelligence should feed the information security risk assessment required by clause 6.1.2, so that new threats change likelihood ratings, risk treatment and the Statement of Applicability. Define how a relevant threat is recorded, who reviews it, and when the risk register is updated. Confirm with the risk owner how often this review happens, and keep a record showing that intelligence changed a decision.

How an assessor tests threat intelligence

The first question is whether the organization has a defined process for collecting and analyzing threat information, or whether intelligence arrives informally through newsletters, vendor emails and ad hoc searches. An assessor looks for a documented procedure that names the sources in use, the criteria for judging their relevance to the organization, who performs analysis, and how findings are recorded. The procedure should show how strategic, tactical and operational information are each handled, since ISO/IEC 27002:2022 describes threat intelligence at those three levels.

Named sources: a current list of feeds, information sharing communities, vendor advisories and internal telemetry, with the reason each source is relevant to the business.
Analysis steps: written criteria for turning raw indicators into an assessment, such as relevance, confidence and expected impact.
Ownership: a named role responsible for the process, with a backup for absences.
Typical finding: feeds connected to a platform for months with no recorded analysis, triage decisions or outputs.

Assessors usually ask to see the procedure alongside a sample of records produced under it. Confirm that the document matches what the team actually does.

Implementing A.5.7 in sequence, with the output of each step

This sequence turns threat collection into intelligence the organization acts on, with each step producing a record that an assessor can trace from risk assessment to detection and back. Each output feeds the next step, so the chain stays visible during an audit.

Define intelligence requirements from the risk assessment
Start from the risk assessment required by clause 6.1.2 and list the threats that could affect the assets, services and processes in scope, such as ransomware against backups, credential theft against remote access or attacks on a key supplier. Ask the risk owners which of these they most need to know about and which decisions the intelligence must support, such as patch priority, detection tuning or supplier review. The output is a short, approved intelligence requirements register that names each threat area, its business owner and the decision it informs. The step is done when every requirement traces to a risk entry and a named owner has signed it off.
Select and document intelligence sources
Choose sources that cover the threat areas in the requirements register, mixing strategic reporting, sector information sharing, vendor advisories, open-source feeds and internal telemetry. Record for each source what it covers, how often it is checked, who receives it, how it is authenticated and whether its terms allow internal use and sharing. Where a source comes from a special interest group or authority, link it to the related contact arrangements under A.5.5 and A.5.6. The output is a source register with an owner and review date for each entry. The step is done when every requirement is covered by at least one source, and gaps are recorded with a planned action.
Set the collection and triage routine
Define how information arrives, who checks it, how often, and how each item is triaged as relevant, irrelevant or needing escalation. Set criteria for urgent items, such as an advisory affecting software the organization runs, and state where raw items are stored so they can be found later. Automated ingestion, where used, should be documented with its configuration, including which feeds are pulled and how duplicates are handled. The output is a written collection procedure and a triage log showing each item, the decision and the reviewer. The step is done when a sample of items can be followed from source to triage decision without gaps.
Assign analysis roles and define outputs
Name the people who analyze the triaged items, state their authority and the tactical, operational and strategic outputs each one produces, reflecting the levels ISO/IEC 27002:2022 describes. Strategic outputs inform management and risk decisions, tactical outputs describe attacker methods relevant to the organization, and operational outputs contain indicators and specific alerts for detection teams. Confirm that analysts have access to the systems and asset inventory they need to judge relevance. The output is a role matrix and an output catalogue with templates for each product type. The step is done when each output type has an assigned author, reviewer and recipient group.
Define distribution lists and channels
Map each intelligence product to the audiences that need it, such as the security operations team, system owners, the risk committee, developers and key suppliers, and choose a channel for each: a ticketing queue, a restricted platform, a briefing or a formal report. Apply handling markings that match the information classification scheme under A.5.12, and check any sharing rules attached to external sources before passing items on. The output is a distribution matrix and a recipient list with the reason each person receives each product. The step is done when every product type has at least one defined audience and a restricted-sharing rule where the source requires it.
Connect outputs to detection and risk treatment
Turn operational intelligence into detection content, such as indicators loaded into a correlation tool or rules written for a log platform, and turn strategic or tactical findings into entries in the risk register and treatment plan. Each link should be explicit: an indicator set points to the detection rule that uses it, and a risk change points to the treatment decision and the control owner. Consider how this tie-in relates to vulnerability handling under A.8.8 and monitoring under A.8.16. The output is a traceability record linking intelligence items to rules, risk entries or treatment actions, with the date each link was made. The step is done when a sampled intelligence item can be shown to have influenced a detection, a risk decision or a documented decision not to act.
Set a review cycle for sources and outputs
Review the requirements register, source register, triage criteria and distribution lists at planned intervals and after significant changes to the business, the threat environment or the risk assessment. Measure whether intelligence changed decisions, which sources produced false positives, and which requirements no longer apply. Feed the findings into the management review and the internal audit of the ISMS, so that the cycle itself is reviewed. The output is a review record with decisions, source changes and updated registers, approved by the owner of the ISMS. The step is done when the review has been completed, its actions are tracked to closure, and the next review date is set.

Which evidence artifacts satisfy A.5.7 and how to keep them current

An auditor testing A.5.7 looks for proof that threat information is gathered, analyzed, shared and acted on over time, not a single threat report written before the audit. The six artifacts below link together: sources feed analysis, analysis feeds distribution, detection and risk decisions, and review checks the whole loop.

Threat source register

This is the list of every feed, community, vendor bulletin and government source the organization uses for threat information, with the owner, the reason it was chosen and the date it was last checked. Auditors use it to confirm the collection side of A.5.7 is deliberate and scoped to the organization's threat environment. Keep it current by reviewing each source at a set interval, recording additions and removals with a reason, and noting feeds that stopped delivering. A stale source list with dead feeds is one of the easiest gaps for an assessor to spot.

Threat analysis records

These are the written outputs where raw indicators and reports are turned into conclusions about relevance, such as which actors or techniques target the sector and which assets could be affected. ISO/IEC 27002 describes threat intelligence at strategic, tactical and operational levels, so records should show which level each item addresses. Keep them current by dating each analysis, linking it to the source records it used, and retiring conclusions when the threat picture changes. Platforms such as OpenCTI can hold these as linked entities and containers.

Intelligence distribution records

Distribution records show that relevant intelligence reached the people who act on it, such as security operations, system owners, development leads and management, and in what form. Keep a log of each distribution with the date, recipients, classification and the action requested. Auditors will test whether the right roles received the right level of detail, so the distribution list should match the roles defined in the organization's responsibility model. Sharing groups in tools like MISP can record who received each event and under what rules.

Detection rules and blocklists traced to intelligence

Here the auditor checks whether intelligence changed what the organization detects or blocks. Each rule, signature or blocklist entry should carry a reference to the intelligence item that prompted it, plus an owner and a review or expiry date. Maintain the trace by tagging rules with their source identifier and reviewing the set regularly to remove indicators that are out of date. Tools such as Wazuh and OpenSearch Security Analytics can hold custom rules, and MISP can export indicators in Suricata, Snort and Zeek formats, so the link between intelligence and detection stays visible.

Risk register updates citing intelligence

The risk assessment required by clause 6.1.2 is where threat intelligence affects priorities. When analysis shows a new threat to a business process or asset, the risk register should show the change, the intelligence that caused it and the treatment decision. Keep this current by reviewing relevant threat entries at each risk review and after significant intelligence events, and by recording when an item was assessed and found not relevant. This artifact connects A.5.7 to the rest of the ISMS, so an assessor who finds threat analysis with no risk effect will question both controls.

Threat intelligence review minutes

Review minutes show management or the responsible forum examining whether the threat intelligence process works. They should cover source performance, unanswered intelligence items, detection gaps found, and decisions taken, with actions assigned and tracked to closure. Hold reviews at planned intervals and after significant events, and keep the minutes with the actions list so an auditor can follow an item from source to decision. Minutes that repeat the same open actions for several cycles suggest the process is not being acted on.

What meeting A.5.7 costs in money and effort

This table breaks the cost of running A.5.7 threat intelligence into its components, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request. The main takeaway is that licence spend is only one part of the cost, and analyst time and detection integration usually drive the ongoing effort.

Cost component	Who is paid and for what	One-time or recurring	What drives it up or down
Commercial threat intelligence feeds or platform licences	The vendor, for access to curated indicators, reports or a hosted platform	Setup is one-time, subscription is recurring	Number of feeds, data volume, user seats and whether sharing groups are needed. Ask for pricing by tier and renewal terms.
Open-source platform licences	Nobody for the software itself, since MISP, OpenCTI, Wazuh and OpenSearch are open source	Licence cost is zero, but hosting and support remain	Removes licence spend. Hosting, storage, upgrades and staff time still apply, so ask any implementer to quote these separately.
Analyst time for collection and analysis	Internal staff or a contracted analyst, for triage, enrichment and writing assessments	Recurring	Number of sources, sector relevance, and whether intelligence is produced at strategic, tactical and operational levels. Reducing sources and automating ingestion lowers the load.
Integration engineering to link intelligence to detection	Internal engineers or an implementation partner, to map indicators into detection rules and SIEM content	One-time build, then recurring tuning	Number of log sources, rule complexity and format conversions to Suricata, Snort, Zeek or Sigma. Clear indicator formats and tested exports reduce rework.
Risk assessment linkage	Internal risk owners, with support if the clause 6.1.2 method needs revision	Recurring review cycle	How many threat scenarios feed the risk register and how often the register is reviewed. Ask how threat intelligence changes are recorded against risks.
External review or assessment support	An independent reviewer or a readiness partner, to test whether intelligence is acted on	One-time readiness review, then periodic	Scope of the ISMS, number of sites and whether the review covers the full intelligence cycle. Ask for the deliverables in writing before work starts.
Auditor sampling time	The certification body, for sampling evidence during audits	Recurring, within the three-year cycle	Evidence quality, consistency of records and number of sample points. Ask the certification body how it plans to sample A.5.7 evidence.

Who owns threat intelligence and what can be outsourced

The organization owns threat intelligence in full. It decides which sources matter for its sector, footprint and technology stack, who reviews what, and which changes follow from each finding. An auditor will ask the organization, not its partner, to show how intelligence turned into decisions.

Source selection: Choose feeds, sharing communities and vendor advisories based on the organization's asset inventory and risk assessment, and record why each source was accepted or dropped.
Analysis decisions: Set the triage rules that turn raw indicators into validated intelligence, including who may mark an indicator as actionable.
Distribution: Name the recipients for each type of intelligence, such as the security operations team, system owners and key suppliers, and state how quickly each group receives it.
Risk treatment: Feed findings into the risk assessment required by clause 6.1.2 and the treatment plan, and approve the resulting actions.
Ownership records: Keep the named owner, review cadence and decision log in the ISMS documentation.

Confirm that a named individual can walk an assessor through one recent threat, from the source that reported it to the control change it caused, using records only.

Common gaps in threat intelligence programs and how to close them

Most A.5.7 findings do not come from a missing feed. They come from intelligence that is collected but never analyzed, never reaches the people who manage risk or detection, and is never checked for effect. The cards below pair each common gap with a closing action you can show an assessor.

Feeds collected without analysis

Teams often subscribe to several feeds and store indicators without recording what they mean for the organization. A.5.7 asks for analysis that produces intelligence, so an assessor will look for a written triage step, a named owner and records showing which items were judged relevant and why. Close the gap by defining a short intake procedure: source, relevance to your technology and sectors, confidence rating and disposition. Check that a sample of feed items can be traced to a recorded decision.

Intelligence not linked to risk assessment

Threat information that never reaches the risk register leaves clause 6.1.2 and A.5.7 disconnected. Assessors commonly ask how a recent threat changed a risk rating, a treatment or a control priority. Close the gap by adding threat sources as a named input to the risk assessment review, and by recording which threats were considered for each risk. Ask your team to show one threat item that moved from intake to a documented risk decision.

No defined distribution

Intelligence that stays with one analyst does not help the people who patch systems, run cloud accounts or handle incidents. Define who receives which product, at what level (strategic briefings for management, tactical notes for architects, operational indicators for detection engineers), and through which channel. Keep a distribution list tied to roles, not individuals, and retain a record of each release.

No evidence that detection changed

An indicator list that never reaches a detection rule cannot show that intelligence is acted on. Auditors look for a link between an intelligence item and a change in monitoring, such as a new Sigma or custom rule, a blocked indicator or a hunt. Close the gap by tagging each detection change with the intelligence item that prompted it. Wazuh and OpenSearch Security Analytics both produce alerts that can be cross-referenced to these changes during review.

No review cycle

Feeds go stale, sources change and relevance drifts as the technology estate moves to new platforms. Without a scheduled review, the program cannot show it still fits the threat environment the organization faces. Set a review interval in the procedure, review source quality, relevance and outcomes, and record decisions to add or drop sources. Keep the review minutes so an assessor can see the program was maintained, not just launched.

No sharing agreements for sector groups

Sector information sharing can add context that commercial feeds miss, but informal sharing creates handling risk. Without agreed rules, staff may share sensitive details without authority or cannot use what they receive. Document which groups the organization participates in, the classification of material it may share, and the handling conditions for received intelligence. Confirm with your legal and compliance team how sharing interacts with A.5.6 and any reporting duties under A.5.5.

Questions buyers ask about A.5.7 cost, effort and outsourcing

Can a small team meet A.5.7 without a commercial threat intelligence feed?

Yes, the control does not require a paid feed. A.5.7 asks the organization to collect information about threats relevant to it, analyze it, and act on the result. A small team can start with free government and sector advisories, vendor bulletins it already receives, and open-source platforms such as MISP or OpenCTI, which can ingest feeds the team chooses. What an assessor looks for is a defined list of sources, a record of what was reviewed, evidence that findings reached the people who act on them, and proof that at least some findings changed a risk decision or a detection rule. A paid feed can help with volume and context, but its cost is a choice, not a requirement. Confirm the expected source set with your certification body before you budget for one.

How long does it take to put A.5.7 in place?

The duration depends on the drivers below, and no fixed timeline applies to every organization. The main factors are how many threat sources you intend to monitor, whether a threat intelligence platform must be installed and integrated with existing logging, how many people review and triage intelligence, and whether the output already feeds your risk assessment under clause 6.1.2 and your detection tooling. An organization that already runs a vulnerability process and a SIEM usually has less to build than one starting from nothing. Ask any partner for a written plan with milestones and the evidence each milestone produces, and check it against the internal audit schedule you will need to run before certification.

How much of the organization's own staff time does A.5.7 require?

Staff time is recurring, not a one-off task. Someone must own the threat intelligence process, review incoming sources on a set cadence, decide which items matter to the organization's assets and services, and pass them to the teams who act on them, such as security operations, system owners and the risk owner. The effort rises with the number of sources, the amount of noise each source produces and how many systems you must map against the findings. Automation in tools like OpenCTI or Wazuh reduces manual sorting but still needs tuning and periodic review by a person. Document the roles in your intelligence procedure so an auditor can see who does what.

Should we build threat intelligence in-house or hire a partner?

The organization must own the control, but it can buy help preparing the platform, sources, workflows and evidence. An implementation partner can deploy and configure open-source platforms inside your own cloud account or data center, connect them to logs and ticketing, and document the procedure. DeployOpen, for example, prepares systems and evidence for compliance assessments but does not issue audit reports or certificates. Internal staff must still analyze findings, make risk decisions and sign off the process. Ask any partner which tasks stay with your team, how the work is scoped in writing before it starts, and whether the handover includes runbooks your staff can operate after the engagement ends. Keep the implementer independent of the certification body that will audit you.

What will an auditor sample when testing A.5.7?

An auditor typically asks to see the sources you monitor, the process that collects and analyzes information, and examples that show the process working. Expect requests for a source register, the triage or analysis records for a sample of intelligence items, the distribution list or channel used to share findings, and the link from a finding to an action such as a risk treatment, a detection rule change, a patch request or a blocked indicator. Auditors also check whether intelligence feeds into the risk assessment required by clause 6.1.2. Keep records dated and attributable so the sample can be traced without reconstruction.

How does A.5.7 differ from A.5.6 and A.8.8?

A.5.7 is about producing threat intelligence that the organization analyzes and acts on. A.5.6 concerns keeping contact with special interest groups, security forums and professional associations, which is one possible source of that information. A.8.8 covers managing technical vulnerabilities: identifying, evaluating and treating known weaknesses in systems you run. Threat intelligence can tell you which vulnerabilities are being exploited, so it informs A.8.8 priorities, but it is broader than a vulnerability list because it also covers actors, campaigns and indicators. Your evidence for A.5.6 can be membership records and forum notes, while A.5.7 needs analysis records and actions taken. Mapping these controls together avoids duplicate work.

What should we ask for in a quote for A.5.7 help?

Ask for a written scope that lists the sources to be monitored, the platforms to be deployed or configured, the integrations with logging and ticketing, the procedures and records to be produced, and the tasks the client's staff must perform. Request the deliverables by name, the acceptance criteria, what happens if scope changes, and whether a support or retainer arrangement covers tuning after go-live. Confirm which items are one-time work and which recur, such as source subscriptions, hosting, staff review time and periodic review of the process. A quote without these components is hard to compare across suppliers.

How DeployOpen prepares A.5.7 systems and evidence

DeployOpen plans, implements and documents self-hosted open-source threat intelligence and detection platforms inside the client's own cloud accounts, data centers or air-gapped networks. The work is scoped in writing before it starts, so the organization knows which intelligence sources, platforms, log feeds and detection rules are in scope, who owns each one, and what will be delivered. Typical building blocks, as described in the open-source projects' own documentation, include MISP for indicator sharing and correlation, OpenCTI for structuring intelligence as STIX-based entities and feeding it through connectors, and detection components such as Wazuh or OpenSearch Security Analytics that run Sigma rules against collected logs. The exact combination depends on the client's sources, sharing agreements and existing tooling, and the scope document should name each platform and version.

The evidence side is where engagements succeed or fail. DeployOpen configures the platforms so that the records an assessor will ask for already exist: feed and connector configuration, sharing groups and distribution settings, the threat intelligence register linking each finding to a risk assessment entry under clause 6.1.2, and detection rules mapped to the threats they address. Each Statement of Applicability justification for A.5.7 should point to these artifacts. Ask the implementer to show how an analyst's decision on an indicator is recorded and how it reaches the people who act on it, because an assessor will sample that trail rather than accept a description of it.

DeployOpen does not issue audit reports or certificates. Only an independent auditor or accredited certification body can assess conformity and issue a certificate. The organization keeps ownership of its controls, decides which threats matter to its business, and signs off on its risk treatment and SoA. DeployOpen prepares the systems, documentation and evidence that an assessor will examine, and ongoing support, upgrades and continuous testing are available as retainers once the initial scope is delivered. Confirm in the written scope which tasks remain with the client's security team after handover.

A.5.7 Threat intelligence