NIS2 in Plain English: What the EU Now Expects From Your Vulnerability Management

Who NIS2 Actually Covers

The original NIS directive covered a narrow set of operators like energy grids and banks. NIS2 widened the net dramatically: digital infrastructure, cloud providers, data centers, managed service providers, online marketplaces, search engines, and social platforms are in scope, alongside sectors like health, transport, water, food, and manufacturing of critical products.

The size threshold matters for startups: the directive generally applies to companies with 50 or more employees or more than 10 million euros in annual revenue operating in a covered sector. That sounds like a "not my problem yet" clause, until you notice the indirect route: NIS2 obliges covered entities to manage supply chain risk, which means their vendors get security questionnaires. If you sell software or services to a covered company, their NIS2 duties flow down to you contractually, regardless of your size. For most SaaS founders, that is how NIS2 arrives: not as a regulator's letter, but as a 40-question vendor security review blocking a deal.

The Ten Minimum Measures

Article 21 lists the minimum risk-management measures every covered entity must implement. Vulnerability management appears explicitly, not as an afterthought:

Two of these, vulnerability handling and effectiveness testing, are impossible to satisfy with a one-time penetration test. They describe a loop: scan, fix, verify, repeat, with records.

The Reporting Clock

NIS2's incident reporting is a three-stage escalation for significant incidents: an early warning to the national CSIRT within 24 hours of becoming aware, an incident notification with an initial assessment within 72 hours, and a final report within one month. ENISA's threat landscape reporting shows why regulators insisted on speed: exploitation of known, unpatched vulnerabilities remains one of the most common initial access vectors, and the median time from CVE publication to observed exploitation has collapsed to days.

The practical implication is uncomfortable: you cannot report what you cannot see. A team with no scanning, no dependency auditing, and no log review does not have fewer incidents. It has undiscovered ones, plus a legal duty it cannot meet.

Management Liability Is the Real Teeth

The fine schedule gets the headlines: up to 10 million euros or 2 percent of worldwide annual turnover for essential entities, 7 million euros or 1.4 percent for important entities. But the sharper change is Article 20: management bodies must approve the risk-management measures, oversee their implementation, and can be held personally liable for infringements. Some member states' transpositions allow temporary bans on individuals exercising management functions.

This is why NIS2 questionnaires from enterprise customers are so much more detailed than the pre-2024 versions. The person signing your vendor assessment is now personally on the hook for believing you.

What a Small Team's Compliance Actually Looks Like

You do not need a GRC platform and a CISO to clear the vulnerability-management bar. You need a loop that runs without anyone remembering to run it, and produces evidence.

// ❌ BAD — "our vulnerability management process"
// 1. Someone tweets about a CVE
// 2. We check if we use that package
// 3. We probably update it
// (no records, no schedule, no coverage of our own code)

# ✅ GOOD — a minimal, evidenced loop
# .github/workflows/security.yml
on:
  schedule:
    - cron: "0 5 * * 1"   # every Monday
  pull_request:
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: trivy fs --exit-code 1 --severity HIGH,CRITICAL .
      - run: gitleaks detect --no-git --exit-code 1

Then close the gaps CI cannot see. Tools like VibeDoctor's Vibe Check (vibedoctor.io) automatically scan both your repository and your live site for known CVEs, exposed secrets, unauthenticated API routes, and missing security headers, and flag specific file paths and line numbers, which doubles as the written evidence a NIS2 questionnaire asks for. Free to sign up.

Add a coordinated vulnerability disclosure route (a security.txt file and a monitored inbox), keep the scan reports, and you have a defensible answer to the vulnerability-handling row of any vendor assessment.

NIS2 vs CRA: Which One Is Yours?

Founders mix these up constantly. The short version: NIS2 regulates entities (organizations running services), the Cyber Resilience Act regulates products (software and connected devices placed on the EU market). A SaaS company in a covered sector answers to NIS2 for how it runs; the desktop app or CLI it distributes answers to the CRA for what it ships. Many companies end up under both, but the vulnerability-management work overlaps almost completely, so building the loop once serves both regimes.

FAQ