How to set up regulatory horizon scanning — an operational, step-by-step guide

This post assumes the “what” and “why” of horizon scanning and moves straight to the “how”: the concrete, operational steps by which an EU financial institution stands up an auditable horizon-scanning function — from scoping the regulatory universe to the build-versus-buy decision. The methodology is not a financial-sector invention: it is codified in the UK Government Office for Science Futures Toolkit ^[1], which combines a structured PESTLE grid with an impact/likelihood matrix, and adapted for the commercial context by the Institute of Risk Management in “Horizon Scanning: A Practitioner's Guide” ^[2].

Treat the seven steps below as an ordered sequence. Each step produces an artefact — a scope matrix, a source list, a taxonomy, a workflow, a KPI set — that the next step depends on. A programme that begins at step four (the workflow tooling) before step one (the scope) is defined will predictably produce noise: much activity, little defensible signal.

Do not start with sources; start with your licence. An institution's regulatory universe is defined by three axes: the frameworks applicable to its activity (for a credit institution, typically CRR/CRD, DORA ^[6] and the AML package; for an insurer, Solvency II, IDD and DORA; for a CASP, MiCA, the Travel Rule regulation and DORA); the supervisory authorities that supervise it; and EU primary law itself via the Official Journal and EUR-Lex. Only once these three axes are written down does it become visible what actually has to be monitored — and, equally important, what does not.

On the authority axis the observable space is broader than most teams first assume. Beyond the three European Supervisory Authorities (EBA, EIOPA, ESMA) and the ECB, every EU/EEA member state operates at least one national competent authority — some 45 supervisory bodies in total, whose pronouncements become relevant the moment an institution operates cross-border or serves foreign customers. The practical output of this step is a framework × jurisdiction matrix in which each cell is marked “in scope” or “out of scope”, with a one-line rationale. That matrix is the first auditable artefact of your programme.

The Futures Toolkit calls for explicit source diversity and recommends a small core group of two to three people to organise the scan, supported by any number of additional scanners ^[1]. Translated to regulation, this means: assign each in-scope cell of your matrix a named primary source — the authority's publications page, its RSS feed or register, the framework's EUR-Lex dossier, the Official Journal of the EU. Primary sources are authoritative, carry a precise timestamp and reproduce the binding text.

Secondary sources — law-firm newsletters, trade press, consultancy alerts — have a genuine place as an interpretation layer, but not as the detection layer. Three reasons argue against using them as your detection signal. First, latency: a newsletter appears days to weeks after the primary publication, and that delay flows straight into your time-to-action. Second, selectivity: secondary sources curate, and their curation does not map to your licence scope. Third, evidence: in an inspection, the defensible proof of when you became aware is the primary-source timestamp — not the date a third party told you. Use primary sources for detection and secondary sources for enrichment, never the reverse.

Raw detections are not yet signal. The Futures Toolkit plots emerging drivers on a two-dimensional matrix of impact and likelihood and reads priority off it — “high impact / high likelihood” is planning-critical, “high impact / low likelihood” warrants a watching brief ^[1]. For regulation, teams typically extend this to a three-dimensional score: regulatory impact, implementation probability or resource intensity, and deadline criticality — each on a disciplined scale, say 1 to 4. Layer the PESTLE-style categories over the top (for financial institutions usually recast as prudential, conduct, financial crime, ICT/operational resilience and sustainability), so that every detection carries both a domain and a score.

The decisive design choice is the materiality threshold: the point at which a finding moves out of routine handling and into a formal four-eyes review. Set an explicit rule — for instance, any item whose impact or deadline-criticality score reaches the maximum triggers a second review by an independent person before it is routed. The four-eyes principle is not decoration but an established governance control: the EBA Guidelines on internal governance treat segregation of duties and the management of conflicts of interest as core governance controls ^[3]. A documented threshold turns subjective judgement into a repeatable, auditable rule.

Fold steps one to three into a running pipeline with four stations. Detect: the assigned primary sources are polled on a fixed cadence, and each new pronouncement is captured with a detection timestamp. Classify: each item receives its domain and its impact/probability/deadline scores; items above the materiality threshold pass through four-eyes review. Route: the classified finding goes to the team that owns the content — DORA items to the ICT/operational-resilience function, AML items to financial crime, prudential items to treasury or regulatory reporting. Evidence: every transition — detection, classification, review, routing, acknowledgement — is written to an immutable, timestamped audit trail.

Two rules make the difference between a workflow that survives an inspection and one that does not. First: route by content, not by org chart. If a DORA finding lands by default with the legal team because “regulation belongs to legal”, rather than with ICT security, time-to-action grows measurably. Second: write the audit trail continuously, not on request. Evidence reconstructed only when the supervisor asks is precisely the evidence that is missing in the supervisory test — when did the institution become aware? The EBA's RegTech analysis records that institutions using such solutions report “enhanced risk management, better monitoring and sampling capabilities, and reduced human error” as the main benefits ^[4] — outcomes that flow precisely from this automation of classification and audit trail.

A scanning function that cannot be measured can be neither improved nor defended to the board. Three KPIs cover most of it. Coverage: the proportion of your in-scope cells (from step 1) with an active, verified-reachable source — the target is full coverage, and every gap is consciously and documentably accepted. Time-to-route: the elapsed time from primary publication to acknowledgement by the owning team. False-positive rate: the share of routed items the receiving team rejects as not relevant — a high value points to a taxonomy that is too coarse or sources that are too broad.

Audit-readiness is not a separate project but a by-product of steps one to four, provided they were executed cleanly. The practical test in an inspection recurs: can the institution evidence when it became aware of a given requirement, who assessed the finding and to whom it went? If the scope matrix, the source mapping, the classification logic and the continuous audit trail all exist as artefacts, the answer is a record export, not a fire drill. That is precisely what separates an operational programme from a merely aspirational one.

Four failure patterns recur where programmes underperform; they are observed in vendor and consultancy practice and are qualitative, not peer-reviewed. First, boilerplate scenarios: generic impact write-ups that read the same for every finding and give the receiving team nothing to act on. Second, newsletter lag: building detection on secondary sources, which structurally inflates time-to-route by the third party's latency — see step 2. A vivid illustration of the value of scanning is the EU AI Act: obligations for high-risk AI systems under Annex III were originally set to apply from 2 August 2026, but the Digital Omnibus package agreed in June 2026 deferred that date to 2 December 2027 (and, for AI embedded in regulated products under Annex I, to 2 August 2028) ^[5] — exactly the kind of moving deadline a manual, newsletter-driven setup captures too late.

Third, no board line-of-sight: if the scanning function routes findings but reports no aggregated, prioritised view to the leadership level, the supervisory-expected line of sight is absent, and the function will be judged ineffective at the first inspection. Fourth, broad-but-shallow: monitoring 200 sources at low resolution typically yields less actionable output than 40 sources at high resolution. The IRM Practitioner's Guide makes the same point from the risk perspective — horizon scanning is a technique for structuring complexity and challenging assumptions, not an exercise in accumulating volume ^[2].

Once steps one to six are specified, the build-versus-buy question becomes concrete, because you now hold a precise requirements list: the number of in-scope sources, the required detection cadence, the taxonomy schema, the routing logic and the audit-trail retention. Build is attractive where your scope is narrow and stable and you already hold engineering capacity to operate and maintain the source adapters — every authority eventually changes its page layout, feed or register, and a broken adapter silently creates a coverage gap. Maintenance effort, not initial construction, dominates the total cost of a home-built solution.

Buy is attractive where your scope spans many jurisdictions, the supervisory landscape moves fast, and you want the audit trail standardised from day one rather than specifying it yourself. Test any vendor against exactly the artefacts of this guide: does it fully cover your scope matrix? Does it detect from primary sources? Is its classification transparent and mappable to your taxonomy? Does it write an immutable audit trail? As one reference implementation: Horizon Scanner monitors some 45 EU/EEA supervisory authorities from primary sources, applies a three-dimensional 1–4 classification to every finding, routes to the owning team and writes an immutable audit trail by default — the seven steps above, built as a product.