Navigating NIS2 and ISO 27001: The Need for Defensible Remediation Records

Navigating NIS2 and ISO 27001 The Need for Defensible Remediation Records
Back to blog
The Shift to Continuous Compliance Evidence
NIS2: What Article 21 and Article 23 Actually Require
Article 21: Ten Risk-Management Measures
Article 23: The Incident-Reporting Cascade
Where NIS2 Enforcement Actually Stands in 2026
ISO 27001:2022 Annex A 8.8: Managing Technical Vulnerabilities
The Remediation Gap
Choosing a System of Record
Conclusion
Navigating NIS2 and ISO 27001: The Need for Defensible Remediation Records
For modern CISOs and compliance officers, the regulatory landscape has moved well past the checkbox exercise it used to be. Frameworks like SOC 2 traditionally let organizations demonstrate compliance through point-in-time audits — a written policy and a sample of patched systems from last quarter was often enough. The NIS2 Directive and the updated ISO/IEC 27001:2022 standard represent a real shift away from that model.

Regulators and auditors increasingly expect organizations to show, not just tell, that they find, prioritize, and remediate vulnerabilities within defined timelines. Bridging the gap between detecting a vulnerability and proving it was fixed on schedule is now a core compliance requirement — and, for NIS2's essential entities, a matter of significant financial exposure. This article breaks down what NIS2 and ISO 27001 actually require around vulnerability management, where NIS2 enforcement stands as of mid-2026, and why fragmented spreadsheets and Slack threads no longer hold up under audit.

The Shift to Continuous Compliance Evidence
The expectation from regulators has changed. Rather than a vulnerability management policy plus a quarterly sample of patched systems, auditors now look for an ongoing, documented trail: when a vulnerability was found, how it was risk-assessed, who owned the fix, and exactly when it was resolved.

Part of what's driving this is simply the pace of exploitation — attackers routinely move on newly disclosed CVEs within hours, so a security posture that's only checked once a quarter tells you very little about current risk. Static, backward-looking evidence doesn't answer the question regulators are actually asking: is this organization managing risk right now?

That kind of evidence is hard to produce from fragmented tooling — a vulnerability scanner here, a Jira ticket there, a Slack thread nobody archived. Organizations increasingly need a centralized way to tie remediation activity directly to the specific legal and technical requirements they're being assessed against.

NIS2: What Article 21 and Article 23 Actually Require
The NIS2 Directive (Directive (EU) 2022/2555) is EU legislation covering roughly 18 sectors and an estimated 160,000 entities across the bloc. It distinguishes between "essential" entities (energy, healthcare, transport, banking, digital infrastructure, and similar) and "important" entities, with essential entities facing stricter obligations. Member states were required to transpose NIS2 into national law by 17 October 2024 — not, as is sometimes reported, some later 2026 date. Non-compliance penalties for essential entities can reach €10 million or 2% of global annual turnover, whichever is higher.

Article 21: Ten Risk-Management Measures
Article 21 is the operational core of the directive. It requires essential and important entities to take "appropriate and proportionate" technical, operational, and organizational measures under an all-hazards approach — covering not just cyberattacks but physical and environmental threats too. Article 21(2) lists ten minimum measure categories, including:

Risk analysis and information system security policies
Incident handling
Business continuity and crisis management, including backup and disaster recovery
Supply chain security, including assessing suppliers' own security practices
Security in the acquisition, development, and maintenance of systems — explicitly including vulnerability handling and disclosure
Policies to assess the effectiveness of risk-management measures
Basic cyber hygiene practices and security training
Cryptography and encryption policies
Human resources security, access control, and asset management
Multi-factor authentication, secured communications, and secured emergency communication systems, where appropriate
For compliance officers, the relevant takeaway is that vulnerability handling isn't a side concern under NIS2 — it's named explicitly within Article 21(2), and it extends to the software supply chain, not just an organization's own code.

Article 23: The Incident-Reporting Cascade
Article 23 sets out a staged reporting obligation to the national CSIRT (Computer Security Incident Response Team) or competent authority whenever a "significant" incident occurs — one causing or capable of causing severe operational disruption, financial loss, or considerable damage to others:

Within 24 hours of becoming aware of the incident: an early warning indicating whether malicious activity is suspected and whether the incident has cross-border implications.
Within 72 hours: a fuller incident notification, including an initial severity and impact assessment and any available indicators of compromise.
Within one month of the 72-hour notification: a final report detailing severity, root cause, and the mitigation measures applied (or a progress report if the incident is still ongoing).
An intermediate report can also be requested by the authority in between. Because the 24-hour clock starts the moment an organization becomes aware of an incident — not when the incident itself occurred — and runs continuously, manual, ad hoc workflows are a real liability here. If an incident traces back to a known vulnerability an organization failed to handle under Article 21, that generally compounds both the reputational and regulatory fallout.

Where NIS2 Enforcement Actually Stands in 2026
This is worth spelling out because it's changed a lot since the directive was first discussed, and coverage of NIS2 varies in accuracy. The October 2024 transposition deadline came and went with most member states missing it — the European Commission opened infringement proceedings against 19 states in mid-2025 for failing to fully transpose the directive. By mid-2026, the picture has largely caught up: most member states have completed national transposition, though a handful — including France, Ireland, and Luxembourg — were still finalizing legislation as of spring 2026, and countries like the Netherlands have flagged that formal obligations under their national law don't bite until the implementing legislation is actually in force, even though the underlying EU obligations already apply in part.

Enforcement is no longer theoretical. National CSIRTs have begun issuing fines — for example, Belgium, Italy, and Hungary have each imposed early NIS2 penalties in the low-to-mid six figures, and reported incident volume has increased sharply since the directive took effect, alongside a meaningful rise in EU cybersecurity spending attributed to NIS2 compliance. The practical implication for compliance officers: don't wait for your specific jurisdiction's implementing law to fully settle before building Article 21 evidence — regulators are already acting, and national timelines are a patchwork that keeps shifting.

ISO 27001:2022 Annex A 8.8: Managing Technical Vulnerabilities
Where NIS2 sets a legal mandate across the EU, ISO/IEC 27001:2022 provides a globally recognized framework for an Information Security Management System (ISMS). The 2022 revision consolidated the older 2013-edition controls 12.6.1 (Management of Technical Vulnerabilities) and 18.2.3 (Technical Compliance Review) into a single, more holistic control: Annex A 8.8.

Annex A 8.8 requires that information about technical vulnerabilities in systems currently in use be obtained, that the organization's exposure be evaluated, and that appropriate action be taken. In practice, this breaks down into three stages — identification, risk evaluation, and remediation — and the 2022 update added more explicit expectations around cloud service providers, external vulnerability disclosures (like bug bounty reports), and integration with change management so that patching doesn't itself introduce instability.

A practical implementation of Annex A 8.8 generally involves:

An accurate, current asset inventory. You can't manage exposure on infrastructure you don't know you have — unpatched shadow IT and forgotten cloud instances are a common audit finding.
Continuous vulnerability identification through scanning, vendor advisories, penetration testing, and threat intelligence. Scan cadence should be set by risk, not fixed arbitrarily — guidance generally points to more frequent (often weekly) scanning for critical, internet-facing systems, with less frequent cycles for lower-risk assets, plus scans after significant infrastructure changes.
Risk-based prioritization, factoring in exploitability, severity, and business impact rather than treating every CVE identically.
Timely remediation — patching, configuration changes, or documented compensating controls where patching isn't immediately possible.
Third-party and open-source exposure management, since the control explicitly covers vulnerabilities introduced by suppliers and dependencies, not just first-party code.
Crucially for audit purposes, Annex A 8.8 expects organizations to maintain records of vulnerability identification, risk assessment, remediation actions, and any explicit decisions to accept or defer risk. Auditors are checking for that documented trail — not just the absence of open vulnerabilities.

The Remediation Gap
Most organizations today are reasonably good at finding vulnerabilities. SAST, DAST, dependency scanners, and CSPM tools generate a steady, often overwhelming, stream of alerts. Where things break down is the gap between an alert firing in a security console and a fix actually landing in production.

By the time a compliance officer sits down to prepare evidence for an ISO 27001 audit, or to draft a NIS2 incident report explaining whether a known vulnerability contributed to a breach, that remediation history is often scattered — a CVE logged in a scanner, discussed informally in Slack, half-documented in a ticket, and eventually closed in a pull request with no clear link back to the original finding. Reconstructing that lifecycle after the fact is slow, and it tends to produce incomplete records — which is exactly what generates audit non-conformities.

Choosing a System of Record
The practical fix is tooling that treats vulnerability remediation as a tracked, evidenced workflow rather than something reconstructed after the fact. At minimum, that generally means:

Automatic ingestion of findings, with severity-based SLA deadlines attached at the point of detection
Clear ownership assignment, so a finding doesn't sit unassigned
A time-stamped record of the full lifecycle — detection, assignment, remediation, verification
A structured way to document risk acceptance when patching isn't feasible, including expiry and review dates
Exportable, audit-ready evidence rather than a dashboard only useful internally
One example of this category is InstaSLA, a GitHub-native tool built around managing SLAs for GitHub security alerts (including Dependabot findings). It lets teams define severity-based remediation deadlines, assign ownership, run coordinated "fix campaigns" across repositories for recurring dependency issues, and configure escalation and reminder workflows. For compliance purposes, it exports row-level remediation evidence — what was open, who owned it, when it was due, and whether it breached SLA — intended to support SOC 2 and ISO 27001 evidence requests. It's worth being clear-eyed about scope here: it's focused on GitHub's own security-alert ecosystem rather than acting as a universal aggregator across every scanner an organization might run, so larger or more heterogeneous environments (multiple SAST/DAST tools, cloud posture management, on-prem infrastructure) will typically need it alongside — or organizations will look toward broader GRC platforms that ingest from more sources.

Whichever tool an organization chooses, the underlying requirement from both NIS2 and ISO 27001 is the same: be able to show, on demand, that a specific vulnerability was found at a specific time, assessed for risk, assigned an owner, and closed within a defined SLA — or that a documented, approved decision was made to accept the risk instead.

Conclusion
Security through paperwork alone doesn't hold up under NIS2 or ISO 27001:2022 anymore. Article 21's explicit inclusion of vulnerability handling, Article 23's aggressive incident-reporting clock, and Annex A 8.8's expectation of a documented remediation trail all point the same direction: continuous, evidenced vulnerability management rather than periodic point-in-time attestations. With NIS2 enforcement now active across most of the EU and audits increasingly testing operational reality rather than policy documents, organizations that are still stitching together evidence from spreadsheets and chat logs at audit time are taking on real regulatory risk. A dedicated system of record for vulnerability remediation won't replace good engineering practice, but it closes the specific gap — proving the fix happened, and happened on time — that keeps tripping organizations up in front of auditors.

This article reflects the regulatory status of NIS2 transposition and enforcement as of mid-2026 and ISO/IEC 27001:2022 Annex A 8.8 guidance as commonly published by accredited certification bodies. National NIS2 implementation details vary by member state and continue to evolve — always confirm current requirements with your national competent authority or a qualified compliance advisor before relying on this for a specific audit.