CISA KEV List and GDPR Article 32: What EU Developers Must Do When a CVE Goes Critical

The US Cybersecurity and Infrastructure Security Agency (CISA) maintains the Known Exploited Vulnerabilities (KEV) Catalogue — a curated list of software vulnerabilities with confirmed active exploitation in the wild. As of May 2026, the catalogue contains over 1,200 entries spanning operating systems, web frameworks, network appliances, and cloud infrastructure components.

EU developers often treat CISA KEV as an American concern. It is not. When a vulnerability enters the KEV list, it triggers a legal cascade under three EU frameworks simultaneously: GDPR Article 32, NIS2 Article 21, and — for financial sector companies — DORA Article 13. This post explains the cascade and what your vulnerability response process must include to remain compliant.

Why CISA KEV Matters for GDPR Compliance

GDPR Article 32 requires controllers and processors to implement "appropriate technical and organisational measures" to ensure security "appropriate to the risk." The standard is risk-based, not prescriptive — which means the question is always: given what you knew or should have known, was your response proportionate?

The CISA KEV catalogue is now a global standard of what constitutes known, confirmed risk. When a CVE enters the KEV list, it means:

1. The vulnerability is actively exploited — not theoretical
2. The exploitation is documented and reproducible
3. Patch timelines exist — US federal agencies must remediate KEV entries within 15 days (critical) or 25 days (high)

From a GDPR Art. 32 perspective, a EU supervisory authority auditing a breach will ask: was this vulnerability on the KEV list? How long before the breach was it listed? When did you patch it? A 60-day gap between KEV listing and breach is very difficult to defend as "appropriate" technical measures. The Austrian DPA (DSB) has cited failure to patch known vulnerabilities as a violation of Art. 32(1)(d) — the requirement to have a "process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures."

The NIS2 Article 21 Patch Management Obligation

NIS2 Directive Article 21(2)(e) explicitly requires essential and important entities to implement "policies and procedures for assessing the effectiveness of cybersecurity risk-management measures." Recital 79 specifies that this includes vulnerability disclosure and patch management.

The ENISA Technical Guidelines for NIS2 Article 21 (published Q4 2025) go further, recommending:

• A maximum 30-day remediation window for critical vulnerabilities in production systems
• 48-hour detection-to-response requirement for actively exploited vulnerabilities (referenced from KEV-equivalent catalogues)
• Mandatory documentation of patch prioritisation decisions in the security risk register

For NIS2 entities, a CISA KEV entry functions as an automatic escalation trigger: it is confirmation of active exploitation, which under the ENISA guidelines immediately categorises the vulnerability as Priority 1 with the 48-hour response clock.

Which companies are NIS2 essential or important entities? The threshold is broader than most EU developers assume:

• Digital infrastructure providers (DNS, cloud, data centres) — automatic essential entity status
• SaaS platforms serving >50 employees OR >€10M revenue in an EU member state
• Any company in a sector covered by Annex I/II (energy, transport, health, financial services, digital infrastructure, manufacturing of critical products)

Many B2B SaaS companies with EU customers meet the NIS2 important entity threshold without realising it.

The DORA Intersection for Financial Sector APIs

If your application processes financial data, connects to banking infrastructure, or serves EU financial institutions under the Digital Operational Resilience Act (DORA), the KEV cascade adds a third layer.

DORA Article 13(1) requires financial entities to "detect anomalous activities" and maintain "up-to-date patching and updating policies." DORA RTS (Regulatory Technical Standards) on ICT Risk Management (published February 2025) specify that actively exploited vulnerabilities must be patched within 72 hours of confirmed exploitation confirmation — essentially the moment a CVE enters the KEV list.

DORA Article 19 further requires financial entities to report major ICT incidents to their national competent authority within 4 hours of classification. A breach originating from a KEV-listed, unpatched vulnerability would almost certainly be classified as major under the DORA incident classification criteria in Commission Delegated Regulation 2024/1772.

What Your EU-Compliant Vulnerability Response Process Must Include

To satisfy the combined requirements of GDPR Art. 32, NIS2 Art. 21, and (if applicable) DORA Art. 13, your vulnerability management process needs these elements:

1. KEV Monitoring as a Compliance Signal

Subscribe to CISA KEV updates via the official feed (https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json) or integrate with a vulnerability database that tracks KEV status (Grype, Trivy, Snyk, and Dependabot all expose KEV flags). When a dependency you use enters the KEV list, your alerting pipeline must fire immediately — not on the next weekly scan.

2. A Tiered Response Policy With Legal Deadlines

Document a tiered response policy in your ISMS (Information Security Management System):

The tiered policy must be documented and tested — GDPR Art. 32(1)(d) requires a "process for regularly testing, assessing and evaluating." Testing means running tabletop exercises against KEV scenarios, not just writing the policy down.

3. Third-Party Component Inventory (SBOM)

You cannot patch what you cannot see. GDPR Art. 32 assessments, NIS2 Art. 21 risk management, and CRA Article 13 (for product manufacturers) all require knowing what software components your systems run. A Software Bill of Materials (SBOM) in CycloneDX or SPDX format, maintained and updated with each deployment, is the minimum baseline.

The EU Cyber Resilience Act (CRA), which applies to products with digital elements from 2027, explicitly mandates SBOM availability for all covered products. Starting this practice now — especially if you sell B2B software — means you will not be scrambling when CRA enforcement begins.

4. Incident Reporting Triggers Linked to KEV Status

Your incident response runbook must explicitly include KEV status as a classification trigger. If your systems are breached and the attack vector matches a KEV-listed CVE that you had not patched, you face:

• GDPR Art. 33: 72-hour DPA notification (if personal data is affected)
• NIS2 Art. 23: 24-hour early warning, then 72-hour incident notification (NIS2 entities)
• DORA Art. 19: 4-hour notification to NCAs (financial entities)

These clocks run from the moment you discover the incident, not when you patch. Having KEV monitoring integrated into your SOC or SIEM means you may also have a pre-incident detection signal — SIEM rules that flag exploitation patterns matching active KEV entries can convert reactive breach response into proactive detection.

Infrastructure as a Compliance Variable

One frequently overlooked factor in vulnerability response is who controls the patching timeline. When your application runs on a managed platform — shared Kubernetes cluster, cloud provider managed services, third-party serverless runtime — your ability to remediate a KEV-listed vulnerability in the underlying runtime may depend entirely on your vendor's patching cadence.

Under GDPR Art. 28, your cloud provider is your data processor, and your Data Processing Agreement (DPA) must specify security requirements. If your vendor's SLA allows 30+ days for critical patch deployment, you are potentially in breach of your own GDPR Art. 32 obligations — even if you have no control over the timeline.

This is where infrastructure sovereignty matters in practice. On a platform where you control the full stack — including runtime, OS, and dependency updates — you can respond to a KEV entry within hours. On shared multi-tenant infrastructure with opaque patching processes, you inherit your vendor's vulnerability posture and have limited contractual recourse.

EU-native infrastructure providers operating under NIS2 (as essential digital infrastructure entities) have their own mandatory patching obligations, which creates an alignment of incentives: your provider's compliance requirements mirror your own. With US-headquartered cloud providers, there is no equivalent structural alignment — their NIS2 obligations, if any, are indirect and depend on complex jurisdictional analysis.

Practical Checklist: When a CVE Enters the KEV List

When you receive a KEV alert for a component in your stack, run through this checklist:

• Is this component present in our SBOM and deployed in production?
• What data does this component have access to? (Personal data = GDPR scope)
• Are we a NIS2 entity? If yes, 48h response clock starts now
• Are we a DORA entity? If yes, 72h patching target applies
• Can we patch immediately, or does the vendor control this? (If vendor-controlled, send formal urgent request and document it)
• Is there a compensating control available while we prepare the patch? (Network segmentation, WAF rule, feature flag to disable affected functionality)
• Update incident response log — KEV listing date, our awareness date, remediation date
• Schedule a post-patch test to confirm the vulnerability is closed

This checklist is not a compliance substitute — it is a starting point for building a documented process that will withstand regulatory scrutiny.

Regulatory Context: ENISA's 2026 Guidance

ENISA published its Threat Landscape 2025 report in late 2025, identifying unpatched known vulnerabilities as the second most common initial access vector in EU incidents (after phishing), responsible for 34% of significant incidents in the energy and digital infrastructure sectors. ENISA explicitly recommended that EU organisations treat KEV-listed vulnerabilities as P1 incidents requiring immediate escalation.

The European Commission's NIS2 transposition review, ongoing across member states in 2026, has highlighted patch management as a top enforcement priority for national competent authorities. Several member states — including Germany (BSI), France (ANSSI), and the Netherlands (NCSC-NL) — have published national implementation guidance that specifically references KEV-equivalent catalogues as the benchmark for "known exploited" status.

For EU developers, this regulatory convergence means that KEV monitoring is no longer optional infrastructure practice — it is a legally relevant compliance signal that must be integrated into your security governance framework.

Summary

When a CVE enters the CISA KEV catalogue, EU developers face overlapping legal obligations under GDPR Art. 32, NIS2 Art. 21, and DORA Art. 13 — with response windows ranging from 48 to 72 hours for active exploitation. The gap between US federal remediation timelines and EU regulatory requirements is narrowing. The practical steps are: automate KEV monitoring, document your tiered response policy with explicit legal deadlines, maintain an SBOM, and ensure your infrastructure agreements give you contractual leverage on your vendor's patching timeline.

Running EU-compliant infrastructure means choosing providers who share your regulatory obligations. sota.io is a EU-native PaaS where data stays in Europe, under European jurisdiction, with full-stack control for rapid vulnerability response. No US parent company, no CLOUD Act exposure.