Regulatory watch: definition, method and sources for cybersecurity

A regulatory watch means spotting the texts that apply to your organisation, measuring what they change and organising how they are taken into account. In cybersecurity the volume has exploded: NIS 2, DORA, the GDPR, guidance from national authorities, CERT alerts. Without a method, the watch becomes an overflowing inbox.

This guide suggests a simple set-up: a closed list of official sources, a five-step workflow, an impact rating grid and a register that keeps track of decisions. The goal is not to read everything, but to miss nothing important and be able to prove it. The examples are French, but the approach works in any EU country.

A regulatory watch is a continuous activity with three movements: spotting new or amended texts, analysing what they require of your organisation, and triggering the necessary actions (policy update, new control, budget, training). It differs from threat intelligence, which tracks attacks and vulnerabilities, although the two share some sources such as CERT-FR.

The scope includes binding texts (directives, EU regulations, national laws and decrees), but also what clarifies how they apply: delegated and implementing acts, authorities' guidance, enforcement decisions. The latter are valuable because they show how a regulator reads a text, as our analysis of the CNIL fine against a hospital illustrates.

The watch is the entry point to compliance management: it feeds the inventory of applicable requirements, which are then assessed, evidenced and tracked. This article focuses on that first link: where information comes from, how to filter it and how to keep a record of decisions.

Regulatory, legal, standards: the types of watch

The word “watch” covers several related activities that share the same mechanics but not the same subject:

• a regulatory watch follows the texts that bind the organisation: EU regulations and directives, national laws, decrees and orders;
• a legal watch widens the scope to case law, supervisory authorities' decisions and legal commentary, which show how those texts are interpreted. The two are often run together;
• a standards watch follows standards (ISO 27001, ISO 22301…), which are voluntary unless a text or a contract makes them mandatory;
• technology watch, which in security includes tracking threats and vulnerabilities, and competitive watch, which observes the market.

Regulatory watch is not specific to cybersecurity: quality, health, safety and environment (QHSE) managers have practised it for a long time, and ISO 14001, for example, requires organisations to determine their environmental compliance obligations and regularly evaluate whether they meet them. The method described here works in all these fields; the examples and sources are those of cybersecurity.

In a few years, cybersecurity has moved from good practice to legal obligation. The NIS 2 Directive extends security obligations to thousands of entities and makes management accountable; its French transposition is covered in our article on the resilience bill. The DORA Regulation has applied to the financial sector since 17 January 2025. Each text comes with implementing acts that arrive in waves, and the NIS 2 penalties put a price on missing them.

Frameworks require it too. ISO 27001 requires you to identify the requirements of interested parties, including legal and regulatory ones, and its control 5.31 is specifically about identifying and keeping up to date legal, statutory, regulatory and contractual requirements. In an ISMS, the watch is therefore a process in its own right, which the auditor will examine.

A good watch starts with the choice of sources. A dozen official sources followed rigorously beat a hundred newsletters skimmed. Here is the core set for a French organisation, with the simplest way to follow each.

Add contractual requirements, which are often forgotten: your customers' security clauses, security assurance plans, questionnaires from the companies you supply. They fall under the same ISO 27001 control and flow both ways along the supplier chain.

A useful watch works like a funnel. A lot of information comes in, little goes out, and what goes out becomes a decision. The diagram below follows one publication from start to finish.

1. Sources. Fix the list and name an owner for each source. Review it once a year.
2. Collection. Route feeds and alerts to a single entry point (shared mailbox, watch tool, GRC platform). Collection is automatic; reading is not.
3. Filtering. For each new item, one question: does it concern us, given our sector, activities and locations? Anything set aside gets a short reason.
4. Impact rating. For what remains, assess what the text changes and by when (see the grid below).
5. Decision and record. Each text kept leads to a decision: action, owner, deadline, or a reasoned decision to do nothing. Everything goes into the register.

Rating avoids two pitfalls: treating every text as urgent, or letting the one that really changes things sit unread. A three-level scale is enough in most cases, provided its criteria are written down.

For each high-impact text, also record its date of application and the specific requirements it contains. Linking them to your requirements base, rather than to the text as a whole, lets you measure compliance requirement by requirement and spot overlaps with other frameworks you already follow.

For an auditor, a watch that leaves no trace does not exist. The watch register is its memory. It can start as a spreadsheet, but it should contain at least:

• the text reference, its source and the date it was identified;
• the filtering decision (kept or set aside, with the reason);
• the impact rating and the requirements concerned;
• the action decided, its owner and its deadline;
• evidence of implementation (updated policy, committee minutes, deployed control);
• the date of the last review.

Texts set aside belong in it too. They are often what an auditor asks about: why did you decide this decree did not apply to you? A dated, reasoned line is enough. Finally, documents updated as a result of the watch, starting with the security policy, should be versioned so you can tell which rule applied on which date.

In most organisations the CISO leads the cybersecurity regulatory watch, with legal or compliance to interpret texts and the DPO for data protection. In groups, a central team can collect and filter while each subsidiary rates the impact on its own scope.

The pace works on three levels: continuous collection, weekly filtering and rating, and a monthly or quarterly committee review where high-impact texts are presented and decided. Urgent CERT-FR security alerts follow their own, shorter path to operations teams. For structuring texts such as NIS 2, plan a regular checkpoint until they are fully implemented.

Beyond a dozen texts and a few scopes, spreadsheets show their limits: manual reminders, multiple versions, scattered evidence. A structured governance, risk and compliance approach then links the text, the requirements, the actions and the evidence directly.

Going further: Phinasoft's policies editor manages standards and regulations, links them together and keeps successive versions of your frameworks and security policy.