The Regulatory Horizon Scanning Process: 7 Steps From Sources to Board Report

The regulatory horizon scanning process is a seven-step loop: define the scanning universe, build a tiered source map, monitor on a defined cadence, triage what comes back, assess impact, convert accepted changes into owned obligations, and report to the board with KPIs. The sources are the easy part, and three of the best are free and published by regulators themselves: the UK's Regulatory Initiatives Grid (10th edition, 19 May 2026: 135 live initiatives over a 24-month pipeline), the US Unified Agenda (78 federal agencies in the 2026 edition), and the European Commission Work Programme 2026 (adopted 21 October 2025).

Horizon scanning programs fail at the three handoffs between steps (from source to triage, from triage to owner, and from owner to board), and guides most often skip that part. CUBE's Cost of Compliance Report 2025, surveying 2,000+ senior compliance, risk and legal leaders across 11 markets, found that 74% of firms take more than a year to implement new regulations. Most of that year passes between "someone saw it" and "someone owns it." That gap is why the process flow below comes with a RACI table. The pillar guide to regulatory horizon scanning covers what and why; this one covers how, step by step, as part of our horizon-scanning hub. Where scanning ends and monitoring and change management begin is untangled in regulatory intelligence vs horizon scanning.

The seven-step framework at a glance: two feedback loops do most of the work

This is how to do regulatory horizon scanning end to end: seven stages, wired together by two feedback loops. Every functioning program converges on the same seven stages. What separates the ones that survive an audit from the ones that decay into a forwarded-newsletter habit is the two feedback loops, described below, that most teams never wire up. The methodology is tool-agnostic: it runs the same whether you execute it in a spreadsheet or on a platform.

The two feedback loops are the difference between a process and a pipeline. Loop one (step 4 back to step 2): every suppressed item carries a reason, and sources whose findings are consistently suppressed get demoted or dropped. Otherwise your source map only ever grows, and so does your noise. Loop two (step 7 back to step 1): the KPI review interrogates the scope itself. A jurisdiction that produced zero relevant findings in two quarters is either quiet or mis-scoped, and the review decides which.

When scanning belongs to everyone, it belongs to no one: the RACI

Most guides say horizon scanning is a team effort and stop there, without ever saying who does what. That vagueness is the failure mode: when scanning belongs to everyone, the consultation that lands during the analyst's holiday belongs to no one, and you find out about it a year too late.

The anchor for the ownership model is older than most compliance teams: the Basel Committee's Compliance and the compliance function in banks (April 2005) puts the proactive identification, documentation and assessment of compliance risk with the compliance function, and says that function should keep senior management informed of developments. The compliance function owns the process; it does not do all the work. In the UK, the corresponding hooks are FCA Handbook SYSC 6.1.1R, which requires firms to maintain adequate policies and procedures sufficient to ensure compliance with their obligations under the regulatory system, and SYSC 4, which asks for well-defined, transparent and consistent lines of responsibility and effective processes to identify, manage, monitor and report risks (both as of 30 September 2026). What FCA supervisors expect UK firms to show for this is its own topic.

Here is the full RACI. R = does the work, A = accountable (one per step, always), C = consulted, I = informed, and n/a means not involved. Copy the table into a sheet and replace the role names with yours.

Three deliberate choices in this table, each of which someone will want to argue about:

• The Head of Compliance holds the A on every row. Accountability that moves between functions is accountability that evaporates at the handoff points where the process breaks. The R moves; the A never does.
• The R on step 5 sits with legal, not compliance. The objection I hear is that routing impact assessment through legal slows the queue down. It does, by days, and it is worth it: deciding whether a draft rule changes your obligations is legal analysis, and compliance teams that keep this R in-house produce impact notes that say only "monitor developments."
• The R on step 6 sits with the business. First-line ownership of remediation is the difference between a compliance-run to-do list and an operating control: compliance tracks the obligation, and the business closes it.

Two more decision rights belong in the same document: who can close a development, and who can accept residual risk. Set response-time expectations for triage, assessment and escalation by urgency, and name which matters need senior management review. If tooling runs your monitoring, the R on step 3 shifts to the platform and the analyst's job becomes reviewing the run output; the accountability row does not change. What agents take over, and what they cannot, is a question we treat at length in our guide to AI agents for regulatory compliance.

Step 1: The scanning universe is a written artifact, not a shared understanding

Scope is where most programs silently fail, because most programs never write it down. Start from the decisions the process must support, because "monitor global regulation" is not a scope. Should this proposed rule join the regulatory change portfolio? Which entities or products could it touch? Do we need to answer the consultation? When should implementation planning begin? Which developments need board visibility?

The scanning universe that answers those questions is a matrix: jurisdictions you operate or sell into × business lines and products × regulatory topics (prudential, conduct, privacy, AI, ESG, sector-specific). Write it as a table, date it, and put it in your compliance monitoring plan, because the only way to know a scan is complete is to know what complete means. Beyond the matrix, a usable scope statement names the regulators, legislatures and standard-setters in play, the stages you watch (from agenda through enforcement), the time horizon, the materiality and escalation criteria, and the explicit exclusions. For multi-entity organizations, map each regulator to the entities, products and topic owners it can affect, and revisit the map when you enter a market, launch a product or acquire a business.

Two rules for the artifact. First, every cell gets an explicit in-or-out decision: "Singapore: out, no entities, no customers, reviewed 30 September 2026" is a defensible record; silence is not. Second, scope changes only through step 7's review loop, with a dated entry in the scope changelog. A scanning universe that anyone can quietly extend is how source lists fill up with secondary commentary while primary regulators go unwatched.

If you are starting from zero, begin with one regulated business line, a defined set of jurisdictions and the sources most likely to create material obligations. Set up the workflow and the decision rights first, then expand coverage after measuring where relevant developments are missed or where you need more lead time. Our horizon scanning template includes a pre-structured scope tab if you want the one-afternoon version.

Step 2: Build the source map on regulator-published pipelines, then tier everything by authority

The most productive move in this playbook is to start your source map from the forward pipelines regulators publish themselves, for free. Most source lists begin instead with the secondary commentary that summarizes them. Build from these three first, matched to your footprint (as of 30 September 2026):

Below the pipeline layer sit two more: regulator rulebooks and open consultations (the FCA Handbook, the Federal Register, EUR-Lex, your sector regulators' consultation pages) and environment signals: enforcement actions, peer approvals and refusals, and the quality press that often surfaces supervisory mood before any instrument does. The volume argues for discipline, and it swings. The 2024 Federal Register alone ran to 106,109 pages and 3,248 final rules, up 8% on 2023's 3,018, before 2025 fell to 60,917 pages and 2,441 final rules (both per CEI's analysis of Office of the Federal Register data).

Treat sources in three levels. Primary legal and regulatory sources are official journals, legislation databases, rulebooks, consultation registers and enforcement notices. Authoritative forward-looking sources are regulatory agendas, work programs, supervisory priorities and technical standards under development. Discovery sources are trade publications, professional commentary and law-firm updates, which can raise an issue but must be checked against the primary source before anything enters a formal workflow. Keep original acts, amending acts, consolidated texts and non-binding guidance distinct in the register; losing that distinction leads to wrong conclusions about what is in force.

Tier every source by authority, because a primary regulator's rulebook is not the same input as a law-firm newsletter summarizing it, and triage should know the difference. In RegWatch, each source carries an authority tier and a health status, but whatever tool you use, the map needs these columns for every source: tier, owner, publication cadence (step 3), format, language, expected latency, and the date someone last confirmed it still works. Sources fail in predictable ways (moved URLs, discontinued feeds, pages that republish old content with new dates), so a source map needs ongoing maintenance.

Step 3: Cadence is set per layer, and date discipline is the whole game

Match the scan rhythm to the source layer:

• Daily (or on a schedule, if automated) for in-force regimes and primary regulators where a missed effective date has immediate consequences.
• Weekly for consultations and pipeline sources, where the cost of a three-day lag is near zero.
• Keyed to publication rhythm for the pipeline documents themselves: the Grid roughly twice a year, the Unified Agenda about twice a year, the Commission Work Programme annually, typically in October. Put these in the calendar as named events with a named reviewer. The Unified Agenda shows why the trigger should be "the edition published," not "it is April": the Spring 2025 edition reached the Federal Register on 22 September 2025, no edition carried the Fall 2025 name, and the next one, the 2026 edition, reached the Federal Register on 14 August 2026.

Every capture should enter the process as a structured record: issuing authority and source, title and identifier, jurisdiction, publication date, current status, consultation closing date, adoption, effective and compliance dates where known, affected topics, the source excerpt or relevant provision, the relationship to earlier or later documents, and the original URL and captured version. Preserve the source language. A summary is useful for triage but must not replace the underlying text.

The unglamorous part of step 3 is date discipline, and it is where the most common failure lives. Regulators re-publish. A 2019 guidance page moves to a new site template and suddenly carries last week's date; a corrected consultation is re-issued. An agent or a person that reads the page date will surface a years-old document as though it were newly published. That is why every RegWatch monitoring run operates in a strict date window and the results are checked against that window again before they are saved. If you run this step manually, the equivalent control is simple: every finding logs the date you captured it and the date the regulator claims, and any mismatch beyond a few days gets a human look before it enters triage. Teams that skip this ship stale items to their board pack.

Step 4: Triage is a rubric with a paper trail, including everything you suppress

Triage converts raw findings into an alert queue, and it must follow a written rubric. Three scored dimensions cover it:

1. Applicability: does this bind an entity, product or activity inside the step-1 universe? (Binary gate; if no, suppress with a reason.)
2. Impact: which existing obligations, policies or controls does it touch, and how materially?
3. Urgency: how close is the effective date or response deadline, and is there a transition period?

Add two checks that keep the queue honest: what stage the development has reached, and whether it is new, duplicative, amended or superseded. Then close every item with one of a small set of dispositions, each carrying a reason: not relevant, monitor, assess, urgent escalation, or duplicate or superseded. Relevance is judged against your regulatory profile, not keyword frequency: a narrow technical notice can matter enormously to one product while a prominent policy announcement has no direct application. Name a subject-matter expert who can validate close calls.

Two mechanical operations complete the step: deduplication (the same instrument arriving via three sources is one finding) and logged suppression reasoning, which most guides skip entirely. A dated record of what you dismissed and why is half the audit value of the entire process, and it feeds loop one: suppression patterns are how the source map gets better. Keep it in a decision log with date, item, decision, reasoning and decider. If most of what reaches triage is being suppressed, the problem is upstream in steps 1 and 2 (scope or sources too loose), not in triage itself.

In RegWatch terms this step is where a Finding becomes an Alert: triage scores it against the company profile and either accepts it with a written "Why this matters" or suppresses it, keeping the suppressed finding on record. The rubric above works identically in a spreadsheet; software changes only the throughput.

Step 5: Impact assessment maps the change to obligations you already have

An accepted alert answers "is this relevant?" Impact assessment answers "what does it change?", and the R here belongs to legal. The output is a short structured note, not a memo: which existing obligations and policies the change touches, which business units and products are affected, the effective date and transition period, and a binary conclusion: gap identified, yes or no. If yes, the note names the gap; if no, the note says why, and that "why" is another audit artifact.

Separate what you know from what you assume: confirmed requirements, reasonable interpretations, assumptions, open questions, dependencies and scenarios each get their own line. That keeps an early signal from being presented as settled law. The European Commission's Better Regulation toolbox is a useful official source of methods for identifying impacts, weighing uncertainty and designing monitoring arrangements.

The discipline that makes this step fast is doing it against a maintained inventory rather than from memory. If your obligations live in a register mapped to policies (our obligations register template is the starting point), a new instrument's impact is a lookup plus judgment. If they live in nobody's head in particular, every impact assessment is original research, which is how impact assessment becomes the bottleneck the CUBE figure measures. A structured regulatory impact assessment format, with a worked example, is in our regulatory change impact assessment template.

Step 6: A change without a named owner and a deadline is still just news

This is the handoff where horizon scanning either becomes change management or becomes a very well-organized newsletter. Every accepted change with an identified gap converts into a tracked obligation with three non-negotiable fields: a named owner (a person in the first line, not a team), a deadline derived from the effective date and transition period, and an evidence requirement, meaning the artifact that will prove, later, that the change was implemented.

The RACI matters most right here. The business-unit owner holds the R; compliance holds the A and tracks the obligation in the obligations register; legal is consulted on interpretation; the board is informed through step 7. In RegWatch, an alert converts to an obligation in one step, you assign the owner and set the effective date, and evidence attaches to it, but the mechanism is secondary to the rule: no accepted change leaves triage without landing in a register with a name and a date on it. Firms that take more than a year to implement a new regulation have usually spent that year discovering, meeting after meeting, that no one had been the owner.

Step 7: The board report is one page, and every KPI on it has a definition

Guides on this topic rarely describe what the board actually receives. We recommend a quarterly one-pager with these sections (that cadence is our practical opinion, not a rule; nothing mandates it):

1. Pipeline heatmap: jurisdictions on one axis, time-to-effective-date bands on the other (0 to 6, 6 to 12, 12 to 24 months), cells colored by count and maximum impact rating.
2. Top 5 inbound changes: instrument, one-line impact, effective date, named owner, status.
3. Obligations opened and closed this period: the flow number that shows the process converts scanning into action.
4. KPI strip: the four metrics below, with trend arrows.
5. What we're watching next: three to five H3-horizon items, each with a one-line position (why we are watching it and not yet preparing).

The KPI strip is where most programs go vague, so the table below defines each KPI and how to compute it:

Two quality measures are worth sampling each quarter alongside the four: the share of triage dispositions that change on review, and the developments reopened because an impact was missed.

Step 7 also produces the scope and source changelog, the dated record of what entered and left the scanning universe and the source map, and why. That document closes loop two, and it is the first thing I would show an examiner, because it proves the process is maintained. The whole record should let a reviewer reconstruct what you knew, what you decided, who approved it and what happened next: the source and its text, material dates, status history, the triage rationale, the impact note, approvals, owner and deadline, implementation evidence and the closure decision. Accountability regimes ask for this. GDPR Article 5(2), for one, requires controllers to be able to demonstrate compliance.

One market observation for the budget conversation this report enables: KPMG's 2024 Global CCO Survey of 765 chief compliance officers found that 84% expect regulatory expectations and scrutiny to increase over the next two years, and new regulatory requirements were the challenge they cited most often, at 34%. Boards fund the function when they are shown a heatmap, four defined KPIs and an opened-and-closed flow rather than a loose digest of what the team happened to read.

Build five artifacts before you buy any tooling

A Head of Compliance standing this up from scratch should resist the instinct to start with tooling and run the sequence in artifact order:

1. Write the scanning universe: the jurisdictions × business lines × topics table, dated, with explicit outs. One afternoon, using the template.
2. Adopt the regulator pipelines that match your footprint (the Grid, the Unified Agenda, the Commission Work Programme) as calendar events with named reviewers. Cost: zero.
3. Put the RACI in front of the people named in it and get the three contested cells (legal's R on step 5, the business's R on step 6, your permanent A) agreed in writing. That agreement decides more than any tooling choice that follows; skip it and the process breaks at these handoffs.
4. Start the triage decision log today, suppressions included. It is the cheapest artifact in this playbook and the one with the highest audit value per hour invested.
5. Ship the one-page board report next quarter with two KPIs, not four: time-to-awareness and findings turned into obligations. Add the rest when the baseline exists.

Automate only after the manual loop works, because automating an undefined process produces faster noise. When the volume outgrows your people, the evaluation criteria for tooling fall straight out of this process. Test with your own sources and scope. Does it cover your step-1 universe? Does it tier its sources and link every item to the primary source? Can reviewers see why an item was classified as relevant, override it and record a reason? Does it respect date windows, log its suppressions with reasoning and end in obligations with owners and dates? Can you export the records? And on security and governance: how is customer data isolated and encrypted, is customer content used to train shared models, which subprocessors and hosting regions are involved, and what happens to your data at contract end? We compare the field against these criteria in best regulatory horizon scanning tools.

We built RegWatch on the view that steps 2, 3 and 4 (source maintenance, date-disciplined retrieval, reasoned triage) are agent work, and steps 1, 5, 6 and 7 are human judgment that agents should feed, not replace. But the seven steps stand on their own. Run them with a spreadsheet and a calendar if you like; just run all seven, and wire up both loops.

This article is general information, not legal advice.