ISO 27001 A.5.7 threat intelligence without a platform

The auditor asks to see one change you made because a threat feed told you something. You have a browser bookmark, a few vendor emails and a good memory. That is the gap A.5.7 threat intelligence exposes in firms of 25–250 people: plenty of awareness, no trace of it.

This guide shows how to build the process with free authoritative feeds, a weekly triage and light automation, so the evidence accrues as you run it. It is written for the security manager, CTO or head of operations who holds this control alongside three other jobs.

What does ISO 27001 Annex A 5.7 require?

ISO 27001:2022 Annex A 5.7 requires you to gather information about threats from inside and outside the business, analyse it in your own context, and act on what is relevant. It is new to the 2022 edition, and it treats threat awareness as a repeatable process rather than something absorbed from the news.

Many firms have never run it formally, but most half-run it already: someone skims NCSC emails, someone watches vendor bulletins, and patching reacts to whatever looks urgent. What the control adds is the discipline of choosing sources, judging relevance and recording what changed.

The standard expects the output to be genuinely usable. Three properties define that:

• Specific to you: a ransomware pattern hitting your sector matters more than a headline about a vendor you do not use.
• Contextualised: each item is read against your stack, your suppliers and your risk register.
• Quick to act on: a person can turn it into a ticket, a rule or a risk entry without further research.

External awareness is not optional polish. The UK Cyber Security Breaches Survey 2025 found that just over four in ten businesses (43%) reported a cyber security breach or attack in the last 12 months, with phishing the most prevalent threat. A threat picture built from whatever made the news is a thin basis for patching decisions in that environment.

Without a deliberate intake, patching order follows whoever shouts loudest. A critical vulnerability in your actual stack can wait for weeks while the team patches something trending but irrelevant. Regulated firms have a further reason, because boards and supervisors increasingly expect management to articulate the current threat picture, and DORA makes threat-led thinking explicit for financial entities.

How do strategic, tactical and operational A.5.7 threat intelligence differ?

Strategic intelligence describes the threat landscape for leadership decisions, tactical intelligence describes attacker methods for whoever designs your defences, and operational intelligence supplies technical indicators for detection tooling. A.5.7 expects you to think about all three, scaled to your size, rather than staffing three separate functions.

At a 50-person firm, one person often wears all three hats. The altitudes describe audiences for the output, not job titles, and each audience needs a different format:

• Strategic: landscape trends, such as a new ransomware pattern in your sector or a credential-stuffing wave against platforms like yours. The consumer is leadership, and the format is a short quarterly paragraph for the management review.
• Tactical: attacker methods and tradecraft. The consumer is whoever owns architecture and security design, and the format is brief notes that change how you build and configure.
• Operational: technical indicators such as malicious domains and addresses. The consumer is your detection tooling, so indicators go straight into it rather than into a report.

The split prevents a common pitfall: one undifferentiated bulletin sent to board, builders and operators alike. Each audience ignores the two-thirds not meant for them, and the one paragraph that mattered goes unread. Splitting the output by audience costs almost nothing once the triage queue exists, because the same dispositions feed all three.

Which free sources replace a threat intelligence platform at A.5.7?

A firm of 25–250 people needs no platform. A curated set of free feeds does the job: NCSC advisories and Early Warning, the CISA Known Exploited Vulnerabilities catalogue, cloud and SaaS vendor bulletins, your sector sharing group, and your own incident records and logs.

Here is what each source gives you:

• NCSC advisories and the NCSC Early Warning service****: a free service, open to any UK organisation, that alerts you as soon as possible to potential cyber attacks on your network.
• The CISA Known Exploited Vulnerabilities Catalog****: CISA describes it as the authoritative source of vulnerabilities exploited in the wild and says organisations should use it as an input to vulnerability management prioritisation.
• Cloud and SaaS vendor security bulletins: only for the products you actually run, which keeps the volume low.
• A sector sharing group: an industry information-sharing group or trade body. The memberships you hold under A.5.6, contact with special interest groups, are among the cheapest inputs you have.
• Your own signal: incident records, identity provider and firewall logs, and phishing reports from staff.

Sector groups run on reciprocity. Share back where you can do so safely, because contributing sharpens your own access to what others see.

Start with these five and resist adding a sixth until the first five are triaged every week. The common failure is looking inward only. Internal telemetry is the cheapest source, so it belongs on the list, but it cannot be the whole list, because the control expects outside sources too.

Your own logs only tell you about the attacks that have already reached you.

What are the 5 stages of threat intelligence in a weekly triage?

The usual five stages are direction, collection, processing, analysis and dissemination. For A.5.7 at small-firm scale, they compress into one weekly habit: feeds arrive in one place, you filter them against your stack, sector and suppliers, record an act, watch or discard decision, and report what changed.

This is how each stage maps onto the habit:

1. Direction: decide once what you need to know, who triages and how often. The standing question is simple: does this touch our stack, our sector or our suppliers?
2. Collection: the feeds from the previous section land in a single queue rather than ten inboxes.
3. Processing: remove duplicates and tag each item against your software, supplier list and sector.
4. Analysis: judge relevance and urgency, then give each item a disposition of act, watch or discard.
5. Dissemination: report what changed. Tickets go to the owners, tradecraft notes to architecture, and a landscape paragraph to the management review.

The stage names are conventional practice, so an auditor will look for the work rather than the labels. Relevance filtering is the whole game. Discard the rest without guilt, because a logged discard is still a decision and shows the analysis happened.

Feed hoarding is the failure this habit prevents: subscribing to everything and triaging nothing.

A threat feed nobody triages is a subscription, not a control.

Do you need a standalone threat intelligence procedure?

No. At 25–250 staff, half a page inside your incident management procedure is proportionate: what you collect, from where, who triages it, how often, and where actions land. Standalone policies suit firms with dedicated intelligence teams, and an unread one adds nothing an auditor can trace to action.

The half page needs four items:

• Sources, with a line on why each was chosen, including internal telemetry.
• Owner, as a named role with a deputy.
• Cadence, such as weekly triage and a quarterly landscape summary.
• Action paths, meaning the ticket queue, the risk register and the management review.

Folding the intake into incident management keeps response and awareness in one place. An auditor who opens that procedure finds the intake where the response lives. The document is not the evidence, though. The triage records and the tickets are, and they are what the auditor will ask to see next.

How does threat intelligence feed the risk register, A.8.16 and A.8.8?

Relevant intelligence must change something. Landscape shifts update the Clause 6.1.2 risk assessment, tradecraft and indicators tune monitoring under A.8.16, and exploited vulnerabilities pull patches forward under A.8.8. Each advisory that matters becomes a ticket, so the link from intelligence to change stays traceable.

Three routes carry the output into the ISMS:

• Risk register: when the landscape shifts, reflect it in the risk assessment instead of leaving the register frozen at certification day.
• Monitoring (A.8.16): attacker tradecraft and published indicators sharpen detections for what gets through.
• Vulnerability management (A.8.8): a known-exploited entry that matches your software moves that patch to the front of the queue.

Incident playbooks and security testing also take their cues from the same triage.

Collection without consequence isn't intelligence.

Make the action traceable at the moment it is created. A patch pulled forward, a block rule added, a detection tuned or a supplier queried should each carry the advisory as its origin. A ticket that cites its source is the cheapest evidence you will ever produce for this control.

What will an auditor ask about A.5.7, and what counts as a nonconformity?

Auditors ask where your threat information comes from, who triages it, and which change it caused. They sample a recent vulnerability relevant to your stack and trace source, triage, action and speed. Claiming A.5.7 with no process grades major; a dormant feed with no analysis or action grades minor, aggregating to major as a pattern.

That grading reflects audit practice as we see it, not wording in the standard. Expect questions like these:

• Where does your threat information come from, and why did you choose those sources?
• Who reviews what arrives, how often, and how do they decide what is relevant?
• Show me a change you made because of something a feed told you.
• How does a new threat find its way into your risk assessment?
• When did leadership last see a view of your threat landscape?

The sampling follows the chain. The auditor picks a recent high-profile vulnerability that affects your stack and asks whether a source surfaced it, who triaged it, what happened and how fast. Then comes a risk register entry, to see whether threat inputs actually move it.

The evidence set that answers all of this is short:

• The documented intake naming sources, owner, cadence and output paths.
• The source list, with internal telemetry alongside external feeds and the reasoning for each.
• Triage records showing a disposition for each item.
• Tickets and change records that cite an advisory or indicator as their origin.
• Risk register entries updated after landscape shifts.
• The threat summary presented at management review.

Losing the paper trail sinks otherwise sound practice. Dispositions and reports scattered across direct messages and inboxes are unfindable at audit, so keep them in the one queue. As a final check, ask whether you could show, from records alone, a source, a disposition, a ticket and a register change from the last quarter. Feed hoarding, inward-only collection, intelligence that never becomes change and one-size bulletins each break one of those links.

How can you automate A.5.7 threat intelligence with webhooks and KEV tickets?

At small-firm scale, A.5.7 is one of the most automatable Annex A controls. Feeds land in one queue, workflows tag items against your asset inventory, a matching CISA KEV entry raises a prioritised patch ticket, and each act, watch or discard decision is logged, so the audit trail and the management summary build themselves.

Aggregation is plumbing. NCSC items, KEV updates, vendor bulletins and sector digests flow into one queue through webhooks, RSS or email parsing. An n8n-style workflow then matches product and supplier names against your asset inventory, so only stack-relevant advisories reach a human.

Disposition becomes data. Each surfaced item gets its act, watch or discard decision recorded in the queue itself, so the triage log the auditor wants simply accrues. A known-exploited entry that matches your software raises a ticket without waiting for the weekly review, and where an EDR or SIEM exists, published indicators flow in through its API rather than by copy-paste.

The quarterly management-review summary is generated, not written. It assembles from the quarter's dispositions and actions, which puts evidence and briefing in one artefact. The human layer stays small and concentrated on judgement:

• Decide which watch items deserve action.
• Confirm that automated KEV tickets reflect real exposure.
• Add context to the quarterly summary before it reaches leadership.

The result is an hour or two a week, and an audit trail that is a by-product of running the control.

Frequently asked questions