NIS2 Implementing Regulation 2024/2690: What Engineering Teams Must Do

Most writing about NIS2 stops at the directive's ten headline measures: risk analysis, incident handling, supply chain security and the rest. For cloud providers, managed service providers and nine other kinds of digital provider, the European Commission turned those headlines into detailed, binding requirements in Implementing Regulation (EU) 2024/2690. It has applied since November 2024, and it reads less like a policy document and more like an audit checklist.

This guide is for engineering and security teams at SaaS, cloud, hosting and managed service companies that fall under NIS2 in at least one EU member state. It covers who the regulation applies to, what it asks of software supply chain, development and vulnerability handling, when an incident becomes reportable, and a script that checks a vulnerability register against the record-keeping points in its annex.

The short answer

Commission Implementing Regulation (EU) 2024/2690 sets the technical and methodological requirements behind NIS2's Article 21 risk-management measures for DNS service providers, TLD registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, online marketplaces, search engines, social networks and trust service providers. It was adopted on 17 October 2024 and entered into force 20 days after publication, on 7 November 2024. Its annex requires, among much else, a supplier registry, contract clauses that oblige suppliers to handle vulnerabilities, information on the software components in ICT products you buy, documented security testing, patches checked for integrity, vulnerability scans with recorded evidence, and a written reason for every vulnerability you decide needs no remediation. It also defines when an incident is significant, which starts NIS2's 24-hour early warning clock.

Who it applies to

The regulation names eleven kinds of entity, which it calls "relevant entities":

Whether a given company is in scope still depends on NIS2 itself and on the member state's transposition: the size thresholds and the registration of essential and important entities happen at national level. What changes with the implementing regulation is the content of the obligations. For these entity types the measures are spelled out once, at EU level, as a directly applicable regulation, rather than left to each member state to define. It also repealed Implementing Regulation (EU) 2018/151, which did a lighter version of the same job for digital service providers under the first NIS directive.

How the annex is organised

Article 2 points to an annex with thirteen sections, mapped to Article 21(2)(a) to (j) of the directive. The sections that land on engineering teams most directly are:

Two rules in Article 2 shape how you read the rest. Requirements apply in proportion to your exposure, size and the likelihood and severity of incidents. And where the annex says "where appropriate", "where applicable" or "to the extent feasible" and you decide a point doesn't apply, you must document your reasoning "in a comprehensible manner". In practice that means a written decision for every point you skip.

Supply chain: point 5

Point 5.1 requires a supply chain security policy for your direct suppliers and service providers. Selection criteria must include their cybersecurity practices, "including their secure development procedures", and the quality and resilience of their products. Point 5.1.4 says contracts must specify, where appropriate:

• cybersecurity requirements for the supplier, including the acquisition requirements in point 6.1;
• an obligation to notify you of incidents that present a risk to your systems, without undue delay;
• a right to audit or to receive audit reports;
• an obligation to handle vulnerabilities that present a risk to your systems;
• rules for subcontracting, and what happens to your information when the contract ends.

Point 5.2 adds a registry of direct suppliers and service providers, with a contact point for each and the ICT products, services and processes they provide. Point 5.1.6 requires you to monitor changes in suppliers' practices at planned intervals and after significant incidents.

Buying and building software: points 6.1 and 6.2

When you acquire ICT products or services that are critical to your security, point 6.1.2 says your process must cover security requirements, security updates "throughout the entire lifetime" or replacement after end of support, and "information describing the hardware and software components used". The regulation doesn't name a format, but a software bill of materials is the obvious way to meet that last point for software, and it's the evidence most vendors can already produce.

Point 6.2 requires secure development rules covering specification, design, development, implementation and testing, applied to in-house and outsourced development alike. Teams must analyse security requirements at design time, apply secure coding principles, set requirements for development environments, build security testing into the life cycle, and protect, sanitise and anonymise test data based on risk.

Testing, patching and vulnerability handling: points 6.5, 6.6 and 6.10

These three points produce most of the day-to-day evidence:

The regulation sets no fixed deadlines here. "Reasonable time", "without undue delay" and "planned intervals" are yours to define, and then yours to prove you kept. That's why the record matters as much as the fix.

When an incident is significant

NIS2's Article 23 requires an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month of that notification. The implementing regulation decides what "significant" means for these entities. Any one of these criteria is enough:

• direct financial loss above EUR 500,000 or 5% of annual turnover, whichever is lower;
• exfiltration of trade secrets;
• death, or considerable damage to a person's health;
• successful, suspectedly malicious and unauthorised access capable of causing severe operational disruption;
• recurring incidents: at least twice in six months, with the same apparent root cause, which together meet the financial loss threshold;
• the entity-specific thresholds in Articles 5 to 14.

For cloud computing, content delivery and managed (security) service providers, those entity-specific thresholds are similar: the service is completely unavailable for more than 30 minutes; availability is limited for more than 5% of users in the Union or more than 1 million users, whichever is smaller, for more than an hour; or the integrity, confidentiality or authenticity of data related to the service is compromised, either as a result of a suspectedly malicious action or with an impact above the same 5% or 1 million line. Trust service providers have tighter limits, starting at 20 minutes of complete unavailability.

The malicious-compromise criterion has no size threshold. A compromised dependency or build pipeline that touches service data can meet it on its own, which is one reason the supply chain points above matter.

Check your vulnerability register

The annex points on patching and vulnerability handling are mostly about records, and records are easy to check automatically. This script reads a vulnerability register and a scan log as CSV files and reports gaps against points 6.6 and 6.10. It uses only the Python standard library. The day limits are your own policy, because the regulation doesn't set numbers:

#!/usr/bin/env python3
"""Check a vulnerability register and scan log against the record-keeping points in
Implementing Regulation (EU) 2024/2690, Annex points 6.6 and 6.10.

Usage: python3 nis2_vuln_register.py register.csv scans.csv [--scan-days 30] [--critical-days 14] [--today YYYY-MM-DD]

register.csv columns: id, asset, critical_to_operations (yes/no), found, status
  (open, fixed, accepted, not_affected), patch_available (yes/no), plan, due,
  justification, additional_measures
scans.csv columns: asset, date, tool, evidence (path or link to the stored result)
The day limits are your own policy. The regulation says "planned intervals" and
"without undue delay"; it does not set numbers.
"""
import argparse, csv, datetime as dt

def day(s):
    return dt.date.fromisoformat(s.strip()) if s and s.strip() else None

def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("register"); ap.add_argument("scans")
    ap.add_argument("--scan-days", type=int, default=30)
    ap.add_argument("--critical-days", type=int, default=14)
    ap.add_argument("--today", default=dt.date.today().isoformat())
    a = ap.parse_args()
    today = day(a.today)
    reg = list(csv.DictReader(open(a.register)))
    scans = list(csv.DictReader(open(a.scans)))
    gaps = []

    last = {}
    for s in scans:
        d = day(s["date"])
        if not s.get("evidence", "").strip():
            gaps.append(("6.10.2(b)", s["asset"], f"scan on {d} has no stored evidence"))
        if d and (s["asset"] not in last or d > last[s["asset"]]):
            last[s["asset"]] = d
    for asset in sorted({r["asset"] for r in reg} | set(last)):
        if asset not in last:
            gaps.append(("6.10.2(b)", asset, "no recorded scan"))
        elif (today - last[asset]).days > a.scan_days:
            gaps.append(("6.10.2(b)", asset, f"last scan {last[asset]}, over {a.scan_days} days ago"))

    for r in reg:
        rid, status = r["id"], r["status"].strip().lower()
        found, due = day(r["found"]), day(r.get("due"))
        has = lambda k: bool(r.get(k, "").strip())
        if status == "open":
            if r["critical_to_operations"].strip().lower() == "yes" and found and (today - found).days > a.critical_days:
                gaps.append(("6.10.2(c)", rid, f"critical to operations, open {(today - found).days} days"))
            if not has("plan"):
                gaps.append(("6.10.3", rid, "open with no mitigation plan"))
            elif due and due < today:
                gaps.append(("6.10.3", rid, f"plan due {due} has passed"))
            if r["patch_available"].strip().lower() == "no" and not has("additional_measures"):
                gaps.append(("6.6.1(d)", rid, "no patch available and no additional measures recorded"))
        elif status in ("accepted", "not_affected") and not has("justification"):
            point = "6.6.2" if status == "accepted" and r["patch_available"].strip().lower() == "yes" else "6.10.3"
            gaps.append((point, rid, f"{status} with no documented reason"))

    for point, ref, msg in sorted(gaps):
        print(f"{point:10} {ref:14} {msg}")
    print(f"\n{len(reg)} register entries, {len(scans)} scan records, {len(gaps)} gaps")
    return 1 if gaps else 0

if __name__ == "__main__":
    raise SystemExit(main())

On a small example register for four services:

$ python3 nis2_vuln_register.py register.csv scans.csv --today 2026-10-18
6.10.2(b)  auth-service   last scan 2026-08-30, over 30 days ago
6.10.2(b)  ops-dashboard  scan on 2026-10-12 has no stored evidence
6.10.2(c)  VR-101         critical to operations, open 46 days
6.10.2(c)  VR-105         critical to operations, open 18 days
6.10.3     VR-101         plan due 2026-09-20 has passed
6.10.3     VR-107         open with no mitigation plan
6.6.1(d)   VR-105         no patch available and no additional measures recorded
6.6.2      VR-104         accepted with no documented reason

7 register entries, 4 scan records, 8 gaps

None of these gaps means a service is insecure. They mean that an auditor asking for evidence under points 6.6 and 6.10 wouldn't find it: a scan with no stored result, an accepted risk with no reason, a critical finding open past your own target. Run it on a schedule and the register stays audit-ready instead of being rebuilt the week before a review.

Collecting that evidence from each system as it's produced, rather than by hand, is the part tools help with most. Here's Safeguard's interactive walkthrough of automated evidence collection:

What to do

1. Confirm scope. Check whether you're one of the eleven entity types and whether a member state where you operate has registered you as essential or important.
2. Map the annex to what you already have. ISO 27001 and SOC 2 controls cover much of it. ENISA's technical implementation guidance, published in June 2025, gives practical advice, examples of evidence and mappings of the requirements.
3. Write down your numbers. Define "reasonable time" for patches, "planned intervals" for scans and "without undue delay" for critical findings, then measure against them.
4. Fix the supplier paperwork. Build the point 5.2 registry, add vulnerability-handling and incident-notification clauses to critical contracts, and ask critical software suppliers for component information.
5. Document every exception. Each skipped patch, accepted risk and "not applicable" annex point needs a written reason. Our post on NIS2 supply chain evidence covers the supplier side in more depth.

The fair view

Much of this is ordinary security hygiene, and a team with a mature ISO 27001 or SOC 2 programme will find most of the annex familiar. The regulation's restraint helps: it sets outcomes and record-keeping, not specific tools or deadlines, and it explicitly scales with size and risk.

The cost is in the documentation. Every "where appropriate" becomes a decision someone has to write down, and every vague term becomes a number you choose and then have to meet. For smaller providers that's real overhead. But the alternative, being asked by a regulator after an incident what your patch policy was and having nothing written, is worse.

Check yourself