Vulnerability Remediation SLAs for NIS2 and DORA

At 08:17 on a Tuesday morning in early 2026, Anna, the CISO of a fast-growing fintech, receives the first message before her coffee is finished.

The SOC has flagged active exploitation chatter around a vulnerability in a customer-facing API gateway. Engineering says the patch is available but risky, because the gateway sits in front of payment workflows. The compliance manager forwards a formal request from a national competent authority asking for evidence of “vulnerability handling and disclosure” and proof that the process has been effective over the past 12 months. Procurement adds a third problem: the gateway is managed by an MSP, and the contract only says the provider will apply “security updates in a timely manner.”

By 09:00, this is no longer only a patching issue. It is an ISO/IEC 27001:2022 evidence issue, a NIS2 cyber hygiene issue, a DORA ICT risk management issue, a supplier governance issue, and potentially an incident reporting issue if exploitation affects service continuity or personal data.

This is the practical compliance gap many organizations will face in 2026. They have scanners, dashboards, tickets, and patch tools, but they cannot answer the audit questions clearly:

• Who approved the remediation SLA?
• How is the SLA risk-based?
• What happens when a critical patch misses the deadline?
• How are internet-facing assets prioritized?
• How are suppliers held to the same timelines?
• Where is the risk acceptance record for an unpatched system?
• Which evidence proves the control operated, not merely existed?

The answer is not another spreadsheet of due dates. Vulnerability remediation SLAs must be managed as a living control system that connects asset ownership, vulnerability scoring, threat intelligence, change management, supplier SLAs, exception handling, monitoring, incident response, and management review.

That is where Clarysec’s Enterprise Vulnerability and Patch Management Policy (VPMP), SME Vulnerability and Patch Management Policy-sme (VPMP-SME), Third-Party and Supplier Security Policy-sme (TPSSP-SME), Zenith Blueprint (ZB), and Zenith Controls (ZC) become useful. Together, they turn “patch faster” into a defensible governance process that can stand up to ISO, NIS2, DORA, GDPR, NIST, and ISACA-style audit scrutiny.

Why vulnerability remediation SLAs became board-level evidence

Vulnerability remediation used to be treated as an IT hygiene metric. In 2026, it is closer to a regulated operational resilience commitment.

NIS2 makes cybersecurity a management accountability issue. Essential and important entities must have management bodies approve cybersecurity risk-management measures, oversee implementation, and receive training so they can understand risks and the impact of security practices on services. NIS2 Article 21 requires appropriate and proportionate technical, operational, and organisational measures, including risk analysis, incident handling, business continuity, supply-chain security, secure acquisition and maintenance, vulnerability handling and disclosure, cyber hygiene, training, access control, asset management, and authentication.

For financial entities, DORA is the specialised operational resilience regime. It requires governance and control arrangements for ICT risk, with the management body defining, approving, overseeing, and remaining responsible for ICT risk management. It also requires identification of ICT assets and dependencies, protection and prevention controls such as patching and change management, ICT-related incident management, digital operational resilience testing, and ICT third-party risk management.

The practical impact is significant. A missed patch deadline may indicate a failure of:

• Governance, if management has not approved risk-based SLAs
• Asset management, if the affected system owner is unknown
• Change management, if emergency patching is not controlled
• Supplier management, if the provider’s timelines are vague
• Incident response, if exploitation signs are not triaged
• Evidence management, if tickets and logs cannot prove closure
• Risk treatment, if exceptions are not approved and reviewed

ISO/IEC 27001:2022 provides the management system backbone. Clauses 4.1 to 4.3 require organizations to understand internal and external issues, interested-party requirements, legal and contractual obligations, and interfaces with other organizations. Clauses 6.1.1 to 6.1.3 require risk assessment, risk treatment, a Statement of Applicability, and risk-owner approval of residual risk. Clauses 9.1, 9.2, 9.3, 10.1, and 10.2 require monitoring, internal audit, management review, continual improvement, corrective action, and retained evidence.

In plain terms, if you want vulnerability remediation SLAs to be audit-ready, they must be part of the ISMS, not just a DevOps metric.

The SLA model auditors expect to see

A vulnerability remediation SLA should answer three questions:

1. How fast must we act?
2. Who is accountable?
3. What evidence proves the outcome?

The Vulnerability and Patch Management Policy defines a practical starting point for risk-based remediation timelines:

The organization must classify all detected vulnerabilities using a standardized methodology (e.g., CVSS v3.x) and apply remediation timelines aligned with business criticality: 5.2.1 Critical (CVSS 9.0-10.0): Immediate review; patching deadline of 72 hours maximum. 5.2.2 High (7.0-8.9): Response within 48 hours; patching deadline of 7 calendar days. 5.2.3 Medium (4.0-6.9): Response within 5 days; patching deadline of 30 calendar days. 5.2.4 Low (<4.0): Response within 10 days; patching deadline of 60 calendar days.

This clause is powerful because it separates response time from patching deadline. A high vulnerability should not sit unseen for six days and then be patched on day seven. The response clock confirms triage, ownership, impact assessment, and remediation planning. The patching deadline confirms technical closure or an approved exception.

For smaller organizations, the Vulnerability and Patch Management Policy-sme uses simpler but still auditable language:

Critical patches must be applied within 3 days of release, especially for internet-facing systems

And for the broader patch estate:

All other patches must be applied within 30 days, unless a valid exception is documented

The point is not that every organization must use identical deadlines. ISO/IEC 27001:2022, NIS2, and DORA all support proportionality. The point is that remediation SLAs must be defined, approved, risk-based, monitored, and evidenced.

This is where many companies fail. They define the SLA but do not define the evidence. From an auditor’s perspective, a policy without operational records is a promise, not a control.

Asset ownership is the hidden dependency

A scanner can tell you that a CVE exists on a server. It cannot tell you whether the server supports a critical payment process, stores special-category personal data, connects to a settlement provider, or is scheduled for decommissioning.

That context comes from asset management, data classification, supplier inventory, and risk assessment.

ISO/IEC 27001:2022 Annex A control 8.8, Management of technical vulnerabilities, is central, but it does not operate alone. It depends heavily on configuration management, change management, supplier monitoring, cloud governance, logging, monitoring, and risk treatment.

NIST CSF 2.0 expresses the same problem in outcome language. The GOVERN Function expects legal, regulatory, and contractual cybersecurity requirements to be understood and managed, risk appetite and tolerance to be documented, roles and resources to be assigned, and cybersecurity policies to be established, enforced, reviewed, and updated. IDENTIFY outcomes include hardware, software, service, system, data, and lifecycle inventories, along with vulnerability identification, risk analysis, exception management, and vulnerability disclosure processes.

In Anna’s Tuesday morning scenario, the first technical question is “where is the vulnerable component?” The first governance question is “what service and risk does it affect?”

The Zenith Blueprint, Risk Management phase, Step 13: Risk Treatment Planning and Statement of Applicability, addresses this by connecting risks to controls, owners, and timelines:

Also, assign an Owner and Timeline for each action (perhaps in a separate column or in the comments). E.g. “Owner: IT Manager, Timeline: by Q3 2025.” This makes it a true plan.

That is exactly what vulnerability remediation requires. A finding without an owner becomes backlog noise. A finding with an owner, timeline, risk treatment decision, and evidence trail becomes an auditable control.

How Zenith Controls maps the control relationships

Zenith Controls treats ISO/IEC 27002:2022 control 8.8, Management of technical vulnerabilities, as a preventive control supporting confidentiality, integrity, and availability. It connects to the cybersecurity concepts Identify and Protect, the operational capability of threat and vulnerability management, and the security domains of governance, ecosystem, protection, and defense.

This matters because remediation SLAs are not only a protection mechanism. They are also a governance mechanism and an ecosystem mechanism. Your exposure is shaped by suppliers, cloud platforms, managed services, open-source components, and internet-facing dependencies.

Zenith Controls maps 8.8 to several supporting controls:

Zenith Controls also links vulnerability management to ISO/IEC 27005:2024, especially vulnerability identification and risk scenarios involving unpatched systems. This strengthens the argument that patching deadlines should be risk-based, not arbitrary. It also connects supplier monitoring to ISO/IEC 27036-4:2016 for cloud service agreement security levels and ISO/IEC 20000-1:2018 for service delivery planning and change management.

That cross-standard structure matters during audit. If an organization says “critical vulnerabilities are patched within 72 hours,” the auditor will test whether that statement is supported by risk assessment, asset classification, supplier obligations, change records, and monitoring evidence.

NIS2 cyber hygiene: from vulnerability handling to corrective action

NIS2 Article 21 requires an all-hazards approach to network and information systems. For vulnerability remediation SLAs, several Article 21 elements are directly relevant:

• Risk analysis and information-system security policies
• Incident handling
• Business continuity and crisis management
• Supply-chain security
• Secure acquisition, development, and maintenance, including vulnerability handling and disclosure
• Procedures to assess cybersecurity effectiveness
• Basic cyber hygiene and training
• Access control and asset management
• Multi-factor authentication or continuous authentication where appropriate

NIS2 Article 20 makes management bodies accountable for approving and overseeing cybersecurity risk-management measures. That means vulnerability remediation metrics cannot live only inside an engineering dashboard. They should appear in management reporting, risk committee packs, or ISMS management review records.

Article 21 also expects entities that identify non-compliance with required measures to take corrective action without undue delay. That phrase matters. If your dashboard shows overdue critical vulnerabilities, the compliance evidence should not stop at “we know.” It should show escalation, risk review, management visibility, corrective action, and reassessment.

NIS2 Article 23 adds another dimension. If exploitation of an unpatched vulnerability causes or is capable of causing severe operational disruption, financial loss, or damage to other persons, it may become a significant incident. The reporting lifecycle includes early warning within 24 hours of becoming aware of the significant incident, incident notification within 72 hours, intermediate reports upon request, and a final report within one month after the incident notification. That final report should include severity, impact, likely root cause, mitigations, and cross-border impact where applicable.

So the SLA process must connect to incident response. A critical vulnerability with active exploitation evidence should trigger security triage, monitoring, evidence preservation, and a reporting assessment, not just a routine patch ticket.

DORA ICT risk: remediation timelines as resilience evidence

For financial entities, DORA applies from 17 January 2025 and creates uniform requirements across ICT risk management, major ICT-related incident reporting, digital operational resilience testing, information sharing, and ICT third-party risk management. It is treated as the sector-specific EU legal act for covered financial entities identified under NIS2 national rules.

DORA’s operating model is close to an integrated ISMS. Articles 5 and 6 require governance, policies, procedures, tools, annual or periodic review, audit, remediation of critical audit findings, and a digital operational resilience strategy. Article 8 requires identification and inventorying of ICT-supported business functions, information assets, ICT assets, dependencies, third-party processes, and legacy ICT risks. Article 9 requires protection and prevention controls, including patching and change management. Articles 11 and 12 require continuity, response, recovery, backup, restoration, and recovery objectives.

DORA Articles 17 to 19 require an ICT-related incident management process that detects, manages, records, classifies, escalates, reports, communicates, analyses root cause, and restores secure operations. Articles 24 to 26 require digital operational resilience testing, including appropriate testing of ICT tools and systems, vulnerability assessments, network security assessments, gap analyses, source-code reviews where feasible, penetration testing, and threat-led penetration testing for certain financial entities. Articles 28 and 30 require management of ICT third-party risk, registers of ICT service contracts, due diligence, audit and inspection rights, service levels, provider assistance during incidents, termination rights, and exit arrangements.

For remediation SLAs, DORA changes the evidence expectations in three ways.

First, vulnerability findings from testing must feed a prioritised remediation process. A scan report is not enough.

Second, remediation of critical findings must be tracked through governance and audit. DORA expects formal remediation of critical audit findings for non-microenterprises.

Third, ICT third-party providers must be held to measurable obligations. If your cloud, SaaS, or MSP provider controls the patching window, your contract and register must show how their remediation timelines support your resilience obligations.

The Vulnerability and Patch Management Policy addresses this directly:

Third-Party Patching and SaaS Risk Oversight 6.6.1 All third-party systems (SaaS, PaaS, MSP-managed) must demonstrate adequate vulnerability and patch management controls. 6.6.2 Vendor SLAs must include remediation timeframes equivalent to internally defined, criticality-based thresholds.

That clause is often the missing bridge between internal ISO evidence and DORA supplier oversight.

GDPR: when patch delays become personal data accountability failures

GDPR is not a vulnerability management standard, but it changes the consequences of patch failure.

GDPR Article 5 requires personal data to be processed securely and requires the controller to be able to demonstrate compliance. Article 32 requires appropriate technical and organisational measures to ensure a level of security appropriate to the risk. When unpatched systems process personal data, especially identity data, financial data, biometric data, health data, employment data, or KYC information, remediation SLAs become part of security-of-processing accountability.

A delayed patch may be defensible if the risk was assessed, compensating controls were applied, and residual risk was accepted by the right person. It is much harder to defend if the vulnerability was overdue, internet-facing, and unowned.

Zenith Controls maps vulnerability management to GDPR Articles 32 and 5(1)(f), because timely patching reduces risks to confidentiality and integrity of personal data. It also maps change management to GDPR Article 24 and Article 32, because changes to systems processing personal data should be risk-assessed, approved, documented, and reviewed.

The compliance lesson is straightforward: if personal data is involved, your patch evidence should include the data context. Auditors and regulators will ask not only “was it patched?” but “what data was exposed to risk, for how long, and what controls reduced that risk?”

A practical Clarysec workflow for audit-ready SLA evidence

A mature vulnerability remediation process does not begin when an auditor asks for records. It is designed to produce records every month.

Step 1: Approve the SLA policy

Start with the Vulnerability and Patch Management Policy or the Vulnerability and Patch Management Policy-sme, depending on your operating model. Tailor SLA thresholds to your risk appetite, regulatory scope, service criticality, data sensitivity, and technical constraints. Ensure approval by the CISO, risk committee, or management body.

For enterprise environments, use CVSS, asset criticality, exploitability, internet exposure, data sensitivity, and business impact. For SMEs, keep the model simple but explicit: critical patches within three days, other patches within 30 days unless a valid exception exists.

Step 2: Map assets to owners and critical services

Every vulnerability finding should resolve to:

• Asset name and unique identifier
• Business service or application
• System owner
• Technical owner
• Data classification
• Internet exposure
• Supplier dependency, if applicable
• Criticality of supported function

This supports ISO/IEC 27001:2022 risk ownership, NIS2 asset management, DORA ICT asset and dependency inventory, and NIST CSF IDENTIFY outcomes.

Step 3: Triage the vulnerability

Create a ticket for each finding or grouped set of findings. Include CVSS score, source scanner, affected asset, exploit status, threat intelligence, business criticality, and required SLA. If exploitation is suspected, link the ticket to an incident assessment.

Step 4: Execute through change management

Patching is a change. Use standard change for routine updates and emergency change for critical exploited vulnerabilities. Include testing evidence, approval, implementation timestamp, rollback plan, and post-change validation.

This matches the Zenith Controls relationship between 8.8 and 8.32, where applying patches is governed through change management to balance urgency and operational stability.

Step 5: Validate closure

Do not close tickets based only on “patch installed.” Require validation through rescanning, version confirmation, configuration verification, or compensating-control confirmation. Where the patch cannot be applied, open an exception.

Step 6: Record exceptions and residual risk

The Vulnerability and Patch Management Policy defines the required exception content:

Exception requests must include: 7.2.1 Business justification for the delay or non-remediation 7.2.2 Risk assessment (based on CVSS, asset criticality, threat intelligence) 7.2.3 Proposed compensating controls 7.2.4 Timeline for remediation or reassessment

It also defines approval and review:

Exceptions must be approved by the CISO or delegated Risk Committee and recorded in the ISMS Exception Register, with a review interval not exceeding 90 days.

That exception register becomes essential evidence for ISO/IEC 27001:2022 Clause 6.1.3 risk treatment and residual-risk acceptance, as well as management review.

This record demonstrates that the organization did not ignore the vulnerability. It assessed the risk, applied compensating controls, approved residual risk, and set a review date.

Step 7: Build the monthly evidence pack

Your monthly vulnerability remediation evidence pack should include:

For SMEs, the evidence can be lighter, but it must still be consistent. The Vulnerability and Patch Management Policy-sme requires patch logs with traceability:

Logs must include the device name, update applied, patching date, and reason for any delay

That single clause is audit gold. It turns patching from a claim into a record.

Supplier patching: the contract must match your SLA

If an MSP, SaaS provider, PaaS provider, or cloud service provider controls patch deployment, internal SLAs are useless unless supplier obligations match them.

The Third-Party and Supplier Security Policy-sme includes information security obligations as a governance requirement. For vulnerability remediation, those obligations should become measurable contract language:

• Critical vulnerability notification windows
• Critical, high, medium, and low remediation timelines
• Emergency change process
• Customer approval requirements for downtime
• Evidence format for patch completion
• Vulnerability disclosure process
• Incident assistance obligations
• Right to audit or receive assurance reports
• Subprocessor or subcontractor patch obligations
• Exit and transition support for critical services

The Zenith Blueprint, Controls in Action phase, Step 20, Control 8.21 Security of network services, states the principle clearly:

Where services are provided externally, including ISPs, SD-WAN vendors, or private cloud providers, security requirements must be built into contracts and SLAs. This includes uptime guarantees, response times for incidents, obligations for patching or mitigating vulnerabilities, and clear data handling boundaries. You should never assume that a provider is meeting your expectations unless it’s written, measurable, and auditable.

DORA makes this especially important for financial entities. ICT third-party arrangements must include service levels, provider assistance during ICT incidents, access and recovery of data, cooperation with authorities, termination rights, and stronger provisions for critical or important functions, including monitoring, audit rights, contingency plans, and security measures.

NIST CSF 2.0 says the same thing through supply-chain risk outcomes: suppliers should be known, prioritized by criticality, assessed before engagement, governed by contractual requirements, monitored throughout the relationship, included in incident planning, and managed at termination.

What auditors will actually ask

The audit conversation changes depending on the auditor’s background.

An ISO/IEC 27001:2022 auditor will start with the ISMS. They will check whether vulnerability management is included in the Statement of Applicability, whether the risk assessment identifies unpatched systems as a risk, whether risk treatment plans have owners and timelines, whether Annex A control 8.8 is implemented, whether evidence is retained, and whether internal audit and management review evaluate performance.

The Zenith Blueprint, Controls in Action phase, Step 19, makes the audit expectation explicit:

This is a high-priority control for auditors, and they will usually dive deep. Expect to be asked how often systems are patched, what process you follow when a zero-day is announced, and what systems are hardest to patch.

It continues with practical evidence expectations:

Auditors will likely request vulnerability scan results. If using tools like Nessus, OpenVAS, or Qualys, export a report showing recent vulnerabilities detected and how they were addressed. Ideally, this should include risk ratings (CVSS) and remediation timelines.

A NIS2-focused auditor or competent authority will look for board approval, proportionality, cyber hygiene, vulnerability handling, supplier security, incident handling, effectiveness assessment, corrective action without undue delay, and reporting decision records if exploitation caused significant impact.

A DORA supervisor will test whether vulnerability findings are integrated into ICT risk management, digital operational resilience testing, incident classification, root cause analysis, third-party registers, contract obligations, audit rights, and remediation of critical findings.

A NIST CSF assessor will likely organize the review around GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER. They will ask whether legal and contractual requirements are understood, whether risk tolerance is documented, whether vulnerabilities are identified and prioritized, whether exceptions are managed, whether monitoring detects exploitation, and whether response and recovery actions are coordinated.

A COBIT 2019 or ISACA-style auditor will focus on governance objectives, process capability, management practices, metrics, ownership, control design, control operation, and evidence sufficiency. They will ask whether vulnerability remediation is repeatable, measured, escalated, improved, and aligned to enterprise goals and risk appetite.

Escalation and metrics: how to prove the SLA is managed

An SLA without escalation is just a target. A defensible vulnerability remediation program needs escalation before breach, at breach, and after repeated failure.

Clarysec recommends a four-level escalation model:

1. Operational escalation, ticket owner and technical lead are notified before breach.
2. Risk escalation, asset owner and risk owner review impact when breach is likely.
3. Security governance escalation, CISO or risk committee approves exception or emergency action.
4. Management escalation, repeated or critical SLA breaches are reported to management review with corrective actions.

The Vulnerability and Patch Management Policy reinforces this audit expectation:

Periodic audits must be conducted by Internal Audit or an independent third party to verify: 5.6.1 Compliance with SLAs 5.6.2 Evidence of risk-based prioritization 5.6.3 Effectiveness of deployed patches 5.6.4 Controls over unpatched systems

Metrics should support decisions, not decorate dashboards. The strongest 2026 metrics include:

• Critical SLA compliance percentage
• High SLA compliance percentage
• Mean time to triage
• Mean time to remediate by asset class
• Number of overdue critical vulnerabilities
• Number of accepted exceptions by age
• Exceptions exceeding 90 days
• Internet-facing critical exposure count
• Supplier SLA breaches
• Vulnerabilities reopened after validation
• Emergency changes caused by exploited vulnerabilities
• Patch failures by platform or business unit

Tie these metrics to ISO/IEC 27001:2022 Clause 9.3 management review, DORA governance reporting, and NIS2 management oversight. For NIST CSF 2.0, use them to update Current and Target Profiles, gap analysis, and action plans.

The Clarysec remediation SLA checklist

Use this checklist to evaluate your current program:

• Is there an approved vulnerability and patch management policy?
• Are remediation SLAs defined by severity and business criticality?
• Are internet-facing and exploited vulnerabilities accelerated?
• Are assets mapped to owners, services, data, and suppliers?
• Are scanner findings converted into assigned tickets?
• Are patches executed through change management?
• Are emergency changes documented and reviewed?
• Are remediation results validated by rescans or version checks?
• Are exceptions risk-assessed, approved, and reviewed at least every 90 days?
• Are compensating controls documented for unpatchable systems?
• Are supplier contracts aligned with internal remediation thresholds?
• Are patch logs complete enough to prove what happened and when?
• Are SLA breaches escalated and corrected?
• Are metrics reviewed by management?
• Are incidents and breach assessments triggered when exploitation is suspected?

If several answers are “no,” the issue is not tooling. It is control design.

Next steps: turn patch deadlines into audit-ready resilience

Vulnerability remediation SLAs in 2026 must do more than satisfy a scanner dashboard. They must prove that your organization can identify exposure, prioritize risk, act within approved timelines, control exceptions, govern suppliers, and evidence decisions across ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0, and COBIT 2019 audit expectations.

Clarysec can help you move from fragmented patch tickets to an integrated, evidence-driven vulnerability remediation program using:

• Vulnerability and Patch Management Policy
• Vulnerability and Patch Management Policy-sme
• Third-Party and Supplier Security Policy-sme
• Zenith Blueprint: An Auditor’s 30-Step Roadmap
• Zenith Controls: The Cross-Compliance Guide

Start with one high-risk service. Map its assets, suppliers, vulnerabilities, tickets, changes, exceptions, and evidence. Then run the audit questions against it. If you cannot prove the SLA from detection to closure, that is your first remediation project.

The goal is not perfect patching. The goal is governed, risk-based, measurable, and auditable remediation. Download the Clarysec policy templates, run a targeted gap assessment, or book a Clarysec demo to turn vulnerability remediation from audit pressure into operational resilience.