Emerging Cyber Risk Horizon Scanning Guide

Most cyber risk registers describe the threats of the last three years well and the threats of the next three years barely at all. Emerging risks, such as AI-enabled intrusion, quantum-vulnerable cryptography, concentration on a handful of cloud and SaaS providers, or a new class of integration token, rarely arrive as a single event. They show up first as weak signals in advisories, research, supplier changes and your own telemetry, long before they are scoreable. Horizon scanning is the discipline that catches those signals, tests them and decides when one is mature enough to become a register entry. This guide sets out a working method: sources and scan records, a watchlist with promotion criteria, a review cadence, and the hand-off into the risk register and enterprise risk management. It is written for risk managers, CISOs, threat intelligence leads and GRC teams. Regulatory horizon scanning is covered separately in the Regulatory Change Management Guide.

Key takeaways

Scan, watch, then register. Keep a three-stage pipeline: individual scan records, a watchlist of emerging risks under review, and only then a scored entry in the risk register. Skipping the watchlist either floods the register or hides the signal.
Write every signal down the same way. A short scan record with date, author, source link, category, timescale and importance is what makes scanning repeatable and auditable, and it mirrors the metadata the UK Government Office for Science recommends in its Futures Toolkit.
Balance the sources deliberately. Technology signals dominate cyber scanning. Count scans by PESTLE category and actively look for political, economic, legal and social drivers, which are often where the real change starts.
Promotion needs explicit criteria. A watchlist item moves to the register when you can name an asset, a plausible scenario and an owner, and when the expected time to impact falls inside your planning horizon.
Measure the scan, not just the risks. Track lead time (signal logged to register entry), the share of incidents that were already on the watchlist, and source balance. Those numbers show whether scanning is detecting anything early.

What horizon scanning is, and what it is not

The Government Office for Science Futures Toolkit (2024 edition) defines horizon scanning as the systematic collection of insights on emerging trends and weak signals of change, used to identify potential threats, risks and opportunities. In cyber terms it sits upstream of three activities that teams often confuse with it.

Activity	Time horizon	Question it answers	Main output
Operational threat intelligence	Days to weeks	Who is attacking organisations like ours now, and how?	Detections, blocks, hunt leads
Vulnerability management	Days to months	Which known weaknesses in our estate need fixing first?	Prioritised remediation queue
Risk assessment	Months to a few years	How likely and how damaging are identified risks, and what do we do about them?	Scored register entries and treatment plans
Emerging risk horizon scanning	One to ten years	What could change our risk picture that we cannot yet score with confidence?	Watchlist, promoted register entries, early decisions

The point of separating them is ownership. Threat intelligence teams are excellent at the first row and often weak at the last, because their incentives reward speed and specificity. Horizon scanning needs patience and breadth, and it needs a home in the risk function so that its output lands in decisions. See the M1019 Threat Intelligence Program for the operational side.

Sources: building a balanced scan

A scan is only as good as its inputs. The Futures Toolkit lists published scans and trend collections, directed web and academic research, expert interviews, professional journals, news, blogs and social media, and non-English sources. For cyber, translate that into named sources with named owners.

Source type	Examples	What it is good for	Suggested owner
Government foresight and assessments	ENISA Foresight Cybersecurity Threats for 2030; NCSC assessment "Impact of AI on cyber threat from now to 2027"	Structured, multi-year judgements with stated confidence	Risk lead
Standards and migration timelines	NIST FIPS 203 (ML-KEM, final August 2024); NCSC PQC migration timelines	Dated deadlines that turn a vague risk into a planning item	Security architecture
Annual surveys and outlooks	World Economic Forum Global Cybersecurity Outlook; ENISA Threat Landscape	Peer sentiment, emerging concerns, cross-sector comparison	CISO office
Threat intelligence reporting	Government advisories, vendor research blogs, ISAC bulletins	Early evidence that a theoretical technique is being used	Threat intelligence
Supplier and platform signals	Product deprecation notices, roadmap changes, new integration models, concentration changes in your supply chain	Risks introduced by others' decisions	Third-party risk and procurement
Internal signals	Near misses, incident post-mortems, architecture review boards, shadow IT and shadow AI discovery	Change that is already happening inside your estate	Security operations and architecture
Expert interviews	Structured conversations with engineering, legal, product and business leaders	Context and drivers nobody has published	Risk lead

Read the assessment language carefully. The NCSC AI assessment, for example, uses the Professional Head of Intelligence Assessment probability yardstick: it judges that AI will almost certainly make elements of cyber intrusion more effective and efficient, and that there is a realistic possibility critical systems become more vulnerable to advanced actors by 2027 if mitigations lag. Carry that calibrated wording into your scan record rather than flattening it to "AI is a big threat".

Balance by category. The Futures Toolkit recommends tagging every scan with a PESTLE category (Political, Economic, Social, Technological, Legal, Environmental) and counting how many fall in each, so the exercise does not over-focus on technology. ENISA's 2030 foresight work used the same PESTLE lens alongside workshops, scenario planning and threatcasting, and its ranked list shows why: skills shortage, disinformation and cross-border ICT providers as single points of failure sit alongside supply chain compromise and AI abuse. See the ENISA Threat Landscape Guide for the annual counterpart.

The scan record

Every signal becomes one short record. The Futures Toolkit suggests each scan carries date, author, source link, PESTLE category, timescale and importance, and that each scanner writes about one scan a week. Extend that with the fields a cyber risk team needs later.

Signal: one or two sentences on what was observed, in the source's own terms.
Source and date: link, publisher, publication date and the date read.
Category: PESTLE tag plus an internal theme (for example AI, cryptography, identity, supply chain, regulation, geopolitics).
So what for us: which business services, asset classes or identities could be affected.
Timescale: expected time to material impact, in bands (under 1 year, 1 to 3 years, 3 to 5 years, over 5 years).
Importance and confidence: scanner's view of potential impact, and how confident the source is, kept separate.
Related records: links to earlier scans on the same theme, so clusters become visible.

Keep the record in the same tool as the risk register if you can. A scan that lives in a slide deck cannot be traced when the risk is later promoted, and the audit trail from first signal to decision is one of the most useful things the process produces.

The emerging risk watchlist

Scans are raw material. The watchlist is where related scans are clustered into a named emerging risk that someone is actively watching. It is deliberately lighter than a register entry: no residual score, no treatment plan, but a clear statement of what would make it real.

Watchlist field	Purpose	Example
Emerging risk statement	Cause, event and possible effect in one sentence	Because quantum-vulnerable key exchange protects long-lived data, data recorded today could be decrypted later, exposing regulated records
Supporting scans	Evidence trail	FIPS 203 final; NCSC timelines; supplier PQC roadmaps
Drivers	What is pushing the change	Standards, government migration targets, supplier roadmaps
Trigger indicators	Observable events that would raise urgency	A key supplier announces end of support for classical-only TLS; a regulator sets a date
Time to impact	Banded estimate	3 to 5 years for migration deadlines; now for data with long confidentiality needs
Watcher	Named person who reviews it each cycle	Head of security architecture
Status	Watch, assess, promote, retire	Assess
Next review	Date	Next quarterly scan review

Trigger indicators are the most valuable field. They turn an open-ended worry into something the scanning team can actually watch for, and they let you agree in advance what will cause escalation. For an AI-related watchlist item, a trigger might be your first confirmed phishing campaign using convincing synthetic voice against your help desk; for a supply chain item, a dominant supplier changing its integration or token model.

Promotion criteria: from watchlist to register

The Risk Register Template sets out the register's columns, scales and escalation rules. The horizon scanning process needs its own rule for when a watchlist item is ready to enter it. Use explicit criteria and record which ones were met.

Specific scenario: you can write a plausible scenario naming a threat source, an event and an affected business service. The Cyber Risk Scenario Library Guide shows how to phrase them.
Exposure exists: the organisation has the technology, data, supplier or process that the risk depends on, confirmed by inventory rather than assumption.
Inside the planning horizon: expected time to impact falls within the strategy or budget cycle, typically three years.
Estimable: likelihood and impact can be estimated, even as a wide range. If you cannot estimate it at all, keep watching and gather more scans.
Owner accepts: a business or control owner agrees to own it. An emerging risk nobody will own is a governance finding in its own right.

Two to three criteria met keeps an item in "assess"; all five promotes it. Record the promotion as a decision with date and approver. Items that fail repeatedly, or whose triggers never fire, should be retired with a reason, which keeps the watchlist short enough to be read.

Choosing the right promotion path

Situation	Recommended path	Why
New risk, clear exposure, deadline known	Promote straight to the register with a treatment plan	Example: PQC migration once a dated target applies to your sector
Existing register risk, new cause or method	Update the existing entry's cause and likelihood; do not create a duplicate	Example: AI-assisted phishing raises the likelihood of an existing credential compromise risk
High impact, very uncertain likelihood	Keep on watchlist; run a scenario or tabletop to test assumptions	Scenario work is cheaper than premature controls
Strategic opportunity	Record as a positive risk for the strategy discussion	NIST CSF 2.0 GV.RM-07 expects positive risks to be characterised
Risk only to a supplier, no current dependency	Note in third-party risk records; retire from watchlist	Avoids register noise

Running the process: cadence and roles

Horizon scanning fails when it is an annual workshop with nothing in between. Use a small standing group and a steady rhythm.

Set scope and horizon (month 0). Agree the planning horizon, the themes in scope and the business services that matter most. Link scope to the organisation's risk appetite; see the Cyber Risk Appetite Statement Template.
Name the scanners (month 0). Start small: the Futures Toolkit advises no more than ten scanners in a project, each writing roughly one scan a week. In most security teams four to eight people across threat intelligence, architecture, third-party risk, legal and the business is plenty.
Pilot for one quarter. Collect scans, cluster them monthly, and build a first watchlist. Do not promote anything yet: use the quarter to calibrate importance and timescale bands.
Quarterly review. The risk lead chairs a review of the watchlist: new clusters, trigger indicators that fired, promotions and retirements. Output goes to the risk committee as a one-page summary.
Annual deep dive. Once a year, run a structured foresight session using scenarios or driver mapping (both tools in the Futures Toolkit) against your top themes, and test strategy against them.
Event-driven review. Any trigger indicator firing, a major incident in your sector, or a significant supplier change prompts an out-of-cycle look at the affected watchlist items.
Roll back if it becomes theatre. If promotions are rare and reviews are skipped, shrink scope to two or three themes rather than abandoning the process.

Small versus large organisations

Small organisations: one owner, a shared spreadsheet or the register tool, a monthly half hour, and reliance on government assessments and sector body outputs. Focus on suppliers and platforms, because most emerging risk arrives through them.
Mid-sized organisations: a named scanning group, quarterly reviews reported to the risk committee, and links to the threat intelligence function.
Large and regulated organisations: integrate with enterprise risk management so that emerging cyber risks appear in the enterprise risk profile. NIST IR 8286 Rev. 1 and IR 8286C Rev. 1 (both final, December 2025) describe how cybersecurity risk register information rolls up into an enterprise risk register and profile.

Feeding the register and the board

Promoted risks need the same treatment as any other entry: risk statement, owner, likelihood and impact, treatment and review date. Two additions help with emerging risks.

Keep the provenance. Link the register entry to its watchlist record and scans. When the board asks why a risk appeared, the trail shows when it was first noticed and what changed.
Use ranges, then refine. Early estimates are wide. Quantified methods can express that honestly; see the Cyber Risk Quantification Guide.
Attach a leading indicator. Convert the watchlist trigger into a key risk indicator for the register entry. See Key Risk Indicators for Cyber Risk Guide.
Report emerging risks as a separate view. A board summary with "new on watchlist", "promoted this quarter" and "retired" alongside the top register risks shows that the organisation is looking ahead, without inflating the main heat map.

Where identity fits

A large share of recent emerging cyber risk has arrived through identities that are not people: OAuth tokens for SaaS integrations, API keys used by AI assistants, workload credentials in new cloud services, and agent identities. These tend to appear first as product features, not threats, so scanning should include product and integration changes. The Salesloft Drift breach in August 2025, where stolen OAuth tokens from a chatbot integration were used against many customers' Salesforce instances, is the kind of event a watchlist item on third-party integration tokens would have flagged as a trigger. See the Threat Intelligence for Identity and NHI Guide for identity-specific sources.

Detection and measurement

Horizon scanning is a detection control for future risk, so measure it like one.

Metric	How to calculate	What good looks like
Lead time	Median months from first scan on a theme to its register entry	Rising over time, meaning earlier detection
Anticipation rate	Share of material incidents and new register risks that were on the watchlist beforehand	A majority of new register risks
Source balance	Scans per PESTLE category per quarter	No single category above about half of scans
Scan throughput	Scans logged per scanner per month	Close to the agreed rhythm, for example about four a month
Watchlist hygiene	Items past their next review date	Near zero
Decision rate	Promotions plus retirements per quarter	At least one decision a quarter; a watchlist that only grows is not being reviewed

Common failure patterns

Technology-only scanning: the scan fills with new attack techniques while legal, economic and supplier drivers go unnoticed. Use PESTLE counts to correct it.
Straight to the heat map: speculative risks are scored next to well understood ones, the scores are guesses, and the board learns to ignore both. Keep the watchlist separate until promotion criteria are met.
Forecasts without triggers: items say "AI will change phishing" and never move, because nobody agreed what evidence would cause action.
Annual workshop only: a single session produces a list that is stale by the next quarter. Small weekly scans and quarterly reviews are what keep it alive.
Ignoring concentration: dependence on a few widely deployed providers grows quietly through procurement; when one is compromised, as in the SolarWinds Supply Chain Compromise where up to 18,000 customers received a trojanised update, the impact is shared. ENISA ranked cross-border ICT service providers as a single point of failure among its top threats for 2030.
No owner after promotion: the scanning team promotes a risk, but no business owner accepts it, so it sits unmanaged. Make owner acceptance a promotion criterion.

Framework mapping

Framework	Reference	How horizon scanning supports it
NIST CSF 2.0	ID.RA-02	Cyber threat intelligence is received from information sharing forums and sources
NIST CSF 2.0	ID.RA-03	Internal and external threats are identified and recorded, including emerging ones
NIST CSF 2.0	ID.RA-05	Threat, likelihood and impact information informs risk response prioritisation
NIST CSF 2.0	GV.RM-03	Cybersecurity risk activities and outcomes are included in enterprise risk management
NIST CSF 2.0	GV.RM-07	Strategic opportunities (positive risks) are characterised and included in risk discussions
NIST CSF 2.0	ID.IM-01	Improvements are identified from evaluations, including scan reviews
NIST SP 800-53 Rev. 5	PM-16 Threat Awareness Program	Organisation-wide threat awareness and information sharing
NIST SP 800-53 Rev. 5	PM-28 Risk Framing	Assumptions, constraints, risk tolerance and priorities that set the scanning horizon
NIST SP 800-53 Rev. 5	RA-3 Risk Assessment	Promoted risks enter the formal assessment
ISO/IEC 27001:2022	Annex A 5.7 Threat intelligence	Collection and analysis of information about threats
NIST IR 8286 series	IR 8286 Rev. 1, IR 8286C Rev. 1	Rolling cybersecurity risk register information into the enterprise risk register and profile

Practitioner checklist

Agree the scanning horizon, themes and business services in scope, linked to risk appetite.
Name four to eight scanners across security, architecture, third-party risk, legal and the business.
Adopt a standard scan record with source, date, PESTLE category, timescale, importance and confidence.
Build a watchlist with risk statement, drivers, trigger indicators, time to impact, watcher and status.
Write and approve five promotion criteria, and record which were met for every promotion.
Hold a quarterly watchlist review and an annual scenario session; allow event-driven reviews.
Link every promoted register entry back to its watchlist record and scans.
Turn trigger indicators into key risk indicators once a risk is in the register.
Report lead time, anticipation rate and source balance to the risk committee.
Include product, integration and supplier changes, especially new non-human identity types, as scan sources.

Emerging Cyber Risk Horizon Scanning: Building a Watchlist That Feeds the Register