CVD for NIS2 and DORA: ISO 27001 Evidence Map

At 08:17 on a Tuesday, the security mailbox receives a message from an independent researcher. The subject line is calm, almost polite: “Potential account takeover in your customer portal.” The body is less comfortable. The researcher claims that a chained vulnerability in your SaaS application allows one tenant to access another tenant’s invoice records. A proof of concept is attached, encrypted with your published PGP key.

For Maria, the new CISO at FinanTechSaaS, the timing could not be worse. Her company has just signed a major contract with a top-tier EU bank. The client’s due diligence team has already asked for a “Coordinated Vulnerability Disclosure Policy” and evidence of implementation, explicitly referencing NIS2 and DORA. The company has a security@ email address, but it is monitored by one developer. There is no formal intake register, no defined validation SLA, no management escalation path, and no audit trail.

Three clocks start at once.

The first clock is operational. Is the vulnerability real? Is it exploitable in production? Is anyone actively abusing it?

The second clock is regulatory. If customer data is exposed, the GDPR breach assessment begins. If service delivery is affected for an essential or important entity under NIS2, incident reporting thresholds may be triggered. If the company is a financial entity or an ICT provider supporting financial services, DORA’s incident management, classification, escalation, and client communication rules may become relevant.

The third clock is evidential. Six months later, an ISO/IEC 27001:2022 auditor, financial sector supervisor, customer assurance team, or internal audit committee may ask: “Show us how this vulnerability was handled.”

That question is where many organizations discover that coordinated vulnerability disclosure is not just a security mailbox. It is a governance system. It needs policy ownership, a public reporting channel, a triage workflow, remediation SLAs, supplier escalation, incident decision logic, privacy review, management reporting, and defensible evidence.

Clarysec treats CVD as an integrated control pattern, not a standalone inbox. In Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, vulnerability handling appears in the Controls in Action phase, Step 19: Technological Controls I, where the guidance is clear: organizations should not archive vulnerability findings passively, but triage them, assign them, and track them to closure. The same standard applies to external disclosures. If someone tells you how your service can fail, the real question becomes: can you prove that you received, assessed, prioritized, remediated, communicated, and learned from it?

Why CVD is now a board-level issue under NIS2 and DORA

For years, security-conscious organizations invited ethical hackers to report vulnerabilities because it was good practice. Under NIS2 and DORA, that practice has become part of regulated digital resilience.

NIS2 applies to many medium-sized and larger entities in high-criticality and other critical sectors, including digital infrastructure providers, cloud computing service providers, data centre service providers, managed service providers, managed security service providers, and certain digital providers such as online marketplaces, search engines, and social networking platforms. It can also apply regardless of size to categories such as trust service providers, DNS service providers, TLD registries, and providers of public electronic communications networks or services.

NIS2 Article 21 requires essential and important entities to implement appropriate and proportionate technical, operational, and organizational cybersecurity risk-management measures using an all-hazards approach. One of the minimum areas is security in network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosure. The same baseline also covers incident handling, supply chain security, business continuity, access control, asset management, training, cryptography, and procedures to assess control effectiveness.

NIS2 Article 20 also makes management accountability explicit. Management bodies must approve cybersecurity risk-management measures, oversee implementation, and follow training. For a CVD program, this means the board or senior management should understand the reporting channel, the vulnerability response team, validation deadlines, remediation expectations, supplier dependencies, and incident reporting triggers.

DORA creates a sector-specific regime for financial entities from 17 January 2025. It covers ICT risk management, ICT-related incident reporting, digital operational resilience testing, information sharing, ICT third-party risk, contractual requirements, oversight of critical ICT third-party providers, and supervisory cooperation. For financial entities covered by DORA, DORA generally takes precedence over NIS2 for ICT risk management and incident reporting because it is the sector-specific Union legal act. But the practical requirement remains the same: financial entities and ICT providers serving them must operate a structured, documented, testable process for identifying, analysing, classifying, escalating, remediating, and learning from ICT weaknesses.

A vulnerability report can begin as a technical finding, become a security event, escalate into an incident, trigger a GDPR personal data breach assessment, require supplier action, and later appear in the ISO/IEC 27001:2022 Statement of Applicability. That is why CVD should be designed as a single operating model across security, compliance, engineering, legal, privacy, procurement, and management.

The ISO 27001 foundation: from disclosure to ISMS evidence

ISO/IEC 27001:2022 gives CISOs and compliance leaders the management system that makes CVD auditable.

Clauses 4.1 to 4.4 require the organization to understand internal and external issues, interested-party requirements, ISMS boundaries, and dependencies with other organizations. This is where NIS2, DORA, GDPR, customer contracts, supplier obligations, and vulnerability disclosure commitments enter the ISMS.

Clauses 5.1 to 5.3 create leadership accountability. Top management must align information security with strategic direction, provide resources, assign responsibilities, and ensure the ISMS achieves intended outcomes. For CVD, that means appointing a Vulnerability Response Team, defining authority to accept residual risk, and escalating high-impact vulnerabilities to management.

Clauses 6.1.1 to 6.1.3 provide the risk engine. The organization must define risk criteria, assess information security risks, assign risk owners, select risk treatment options, compare controls against Annex A, produce a Statement of Applicability, and obtain approval for residual risk. Clauses 8.1 to 8.3 then require operational control, planned changes, control of externally provided processes, risk assessments at planned intervals or after significant changes, and evidence of treatment results.

In Zenith Blueprint, Risk Management phase, Step 13, the Statement of Applicability is described as more than a compliance spreadsheet:

“The SoA is effectively a bridging document : it links your risk assessment/treatment to the actual controls you have.”
Source: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Risk Management phase, Step 13: Risk Treatment Planning and Statement of Applicability (SoA) Zenith Blueprint

For coordinated vulnerability disclosure, the SoA should bridge regulatory obligations, business risk, Annex A controls, policy clauses, and operational evidence.

The goal is not to create parallel compliance silos. The CVD policy should be a controlled ISMS process that supports ISO/IEC 27001:2022 certification, NIS2 compliance, DORA readiness, customer assurance, and security operations at the same time.

The policy baseline: what your CVD policy must say

The first visible control is the public disclosure channel. Researchers, customers, suppliers, and partners must know where to report vulnerabilities and how to protect sensitive evidence.

Clarysec’s Coordinated Vulnerability Disclosure Policy Coordinated Vulnerability Disclosure Policy provides the enterprise baseline:

“Public Disclosure Channels: The organization shall maintain a clear channel for vulnerability reporting, such as a dedicated security contact email address (for example, security@company.com) or a web form. This information shall be published on the company website security page together with the organization’s PGP public key to enable encrypted submissions.”
Source: Coordinated Vulnerability Disclosure Policy, Implementation Requirements, clause 6.1

This clause solves a common audit failure. Many organizations claim they accept reports, but the reporting route is buried, unencrypted, or owned by the wrong team. A mature channel is public, secure, monitored, and assigned to a responsible function.

The next control is response discipline. A critical report followed by silence creates disclosure risk, reputation risk, and exploitation risk. The Coordinated Vulnerability Disclosure Policy sets a concrete acknowledgement and validation expectation:

“Triage and Acknowledgement: Upon receipt of a report, the VRT shall record it and send an acknowledgement to the reporter within 2 business days, assigning a tracking reference. The VRT shall perform a preliminary severity assessment, for example using CVSS scoring, and validate the issue, including with support from IT and development teams where necessary, within a target timeframe of 5 business days. Critical vulnerabilities, such as those enabling remote code execution or a major data breach, shall be expedited.”
Source: Coordinated Vulnerability Disclosure Policy, Implementation Requirements, clause 6.4

This wording creates immediate evidence points: receipt time, acknowledgement time, tracking reference, preliminary severity, validation outcome, and expedited handling decision.

For SMEs, Clarysec uses the same logic with proportionate implementation. The Application Security Requirements Policy-sme Application Security Requirements Policy - SME requires organizations to:

“specify obligations for vulnerability disclosure, response times, and patching.”
Source: Application Security Requirements Policy-sme, Governance Requirements, clause 5.3.2

You do not need a large product security team to be accountable. You need explicit obligations, realistic timelines, named owners, and evidence that the process operates.

The CVD intake workflow: from researcher email to decision record

A good intake workflow is simple enough to run under pressure and complete enough to satisfy an auditor. It should start with a dedicated channel such as security@[company], a web form, or a published security.txt file. The submission route should allow encrypted evidence, affected product or endpoint, reproduction steps, reporter contact details, preferred disclosure timing, and any indication of data exposure or active exploitation.

Once received, the Vulnerability Response Team should create a record in a GRC tool, ticketing platform, vulnerability management system, or controlled register. The tool matters less than consistency and evidence quality.

The workflow should then move through seven operational steps.

1. Intake, the report is received through the public channel and automatically or manually logged.
2. Acknowledgement, the VRT responds within 2 business days and assigns a tracking reference.
3. Validation, the technical team reproduces the issue, confirms affected systems, and performs preliminary severity scoring.
4. Event assessment, the VRT determines whether the vulnerability is only a weakness, an information security event, or an incident.
5. Escalation, high or critical issues are sent to system owners, the CISO, privacy, legal, suppliers, and management as needed.
6. Remediation, the responsible team applies a fix, mitigation, compensating control, or temporary restriction.
7. Closure, the VRT verifies the fix, communicates with the reporter, updates the evidence file, and records lessons learned.

Clarysec maps this operational step to ISO/IEC 27002:2022 control A.5.25, Assessment and decision on information security events, and control A.8.8, Management of technical vulnerabilities, through Zenith Controls: The Cross-Compliance Guide Zenith Controls. For A.5.25, Zenith Controls explains that event assessment is the triage function between raw monitoring alerts and formal incident handling, using logs, thresholds, and decision criteria to determine escalation. For A.8.8, Zenith Controls connects technical vulnerability management to malware protection, configuration management, change management, endpoint security, threat intelligence, monitoring, secure development, event assessment, and incident response.

One Zenith Controls passage is especially useful when active exploitation is suspected:

“Threat intelligence informs which vulnerabilities are actively exploited, guiding patch prioritization.”
Source: Zenith Controls: The Cross-Compliance Guide, ISO/IEC 27002:2022 control 8.8, tie to control 5.7 Threat Intelligence Zenith Controls

This is an important governance point. Severity is not only CVSS. A medium-scored vulnerability actively exploited against your sector may outrank a theoretical critical issue on a non-exposed test system.

When a vulnerability becomes an incident

Not every vulnerability report is an incident. A missing security header on a staging environment is not the same as an exploited authorization bypass exposing customer invoices. But every credible vulnerability report should pass through an incident decision gate.

NIS2 Article 23 requires essential and important entities to notify their CSIRT or competent authority without undue delay of incidents that significantly impact service provision. A significant incident is one that has caused or is capable of causing severe operational disruption or financial loss, or that has affected or is capable of affecting others by causing considerable material or non-material damage. The reporting sequence includes an early warning within 24 hours of becoming aware, an incident notification within 72 hours, intermediate reports when requested, and a final report within one month of the 72-hour notification.

DORA Articles 17 to 20 require financial entities to detect, manage, record, classify, escalate, notify, and communicate ICT-related incidents and significant cyber threats. Major ICT-related incidents must be escalated to senior management and the management body. Client communication may be required when financial interests are affected.

For SMEs, the reporting culture must be equally clear. Clarysec’s Incident Response Policy-sme Incident Response Policy - SME states:

“Staff must report any suspicious activity or confirmed incident to incident@[company] or verbally to the General Manager or IT provider.”
Source: Incident Response Policy-sme, Policy Implementation Requirements, clause 6.2.1

In Zenith Blueprint, Controls in Action phase, Step 16: People Controls II, the principle is even simpler:

“When in doubt, report.”
Source: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Controls in Action phase, Step 16: People Controls II (A.6.5 to A.6.8)

That phrase should apply to developers, support teams, supplier managers, privacy leads, executives, and outsourced providers. A vulnerability that may affect confidentiality, integrity, availability, customer trust, regulatory reporting, or financial operations should be recorded and assessed, not handled informally in chat.

Remediation, patching, and compensating controls

Once a vulnerability is validated, it must be treated. Treatment should be risk-based, evidence-backed, and time-bound.

The Coordinated Vulnerability Disclosure Policy sets the enterprise expectation:

“Remediation Plan: A remediation or mitigation plan shall be developed for all confirmed vulnerabilities. Implementation of the fix shall be prioritized based on severity. For example, critical vulnerabilities shall be fixed or mitigated within 14 days where feasible, or sooner where active exploitation is detected, while lower-severity issues shall be addressed within a reasonable timeframe. Where a full fix is delayed, compensating controls or temporary mitigation measures, such as disabling vulnerable functionality or increasing monitoring, shall be implemented.”
Source: Coordinated Vulnerability Disclosure Policy, Implementation Requirements, clause 6.6

For SME patching discipline, the Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy - SME states:

“Critical patches must be applied within 3 days of release, especially for internet-facing systems”
Source: Vulnerability and Patch Management Policy-sme, Policy Implementation Requirements, clause 6.1.1

These timelines are not contradictory. A vendor patch for an internet-facing system may need a very fast deployment. A product vulnerability requiring code changes, regression testing, customer coordination, and staged release may require a remediation plan with interim mitigations. The key is that the decision is documented, risk-owned, and approved where residual risk remains.

A practical case flow looks like this:

1. A researcher reports an authorization bypass in the customer billing API.
2. The VRT logs CVD-2026-014 with a timestamp and acknowledges within 2 business days.
3. Product security validates the flaw in 24 hours and assigns High severity due to cross-tenant data access.
4. Privacy performs a GDPR breach assessment because invoice records may contain personal data.
5. The incident manager opens an event assessment under ISO/IEC 27002:2022 control A.5.25.
6. The system owner disables the vulnerable endpoint through a temporary feature flag.
7. Engineering creates a hotfix under ISO/IEC 27002:2022 control A.8.32, Change management.
8. Monitoring rules are added for exploitation indicators, linked to A.8.15, Logging, and A.8.16, Monitoring activities.
9. The CISO informs senior management because the issue is high-risk.
10. The VRT coordinates with the researcher on retesting and disclosure timing.
11. The risk owner approves closure only after verification testing and customer impact review.
12. The SoA, risk register, ticket, logs, management notification, and lessons learned are updated.

That is the difference between “we patched it” and “we can prove we governed it.”

Supplier and cloud dependencies: the hidden failure point

Many CVD failures are supplier failures in disguise. The vulnerability may affect a SaaS component, cloud service, managed security provider, payment gateway, authentication broker, open-source library, outsourced development team, or subcontractor.

NIS2 Article 21 requires supply chain security, including relationships with direct suppliers and service providers. Supply-chain measures should consider supplier vulnerabilities, product quality, cybersecurity practices, and secure development procedures.

DORA Articles 28 to 30 go deeper for financial entities. They require ICT third-party risk to be managed as part of the ICT risk framework, with registers of ICT service contracts, critical or important function distinctions, pre-contracting due diligence, contractual security requirements, incident assistance, cooperation with authorities, audit rights, termination rights, and exit strategies. Financial entities remain fully responsible for DORA compliance even when using ICT third-party providers.

Clarysec’s Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME includes a simple escalation rule:

“Must notify the GM immediately of any security breach, change, or incident”
Source: Third-Party and Supplier Security Policy-sme, Roles and Responsibilities, clause 4.4.3

For enterprise supplier contracts, Zenith Blueprint, Controls in Action phase, Step 23, recommends including confidentiality obligations, access control responsibilities, technical and organizational measures, incident reporting timelines, right to audit, subcontractor controls, and end-of-contract provisions. It states:

“What matters is that they exist, and that they are understood and accepted by both parties.”
Source: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Controls in Action phase, Step 23: Organizational controls (5.19 to 5.37)

CVD supplier readiness should answer these questions:

• Does the supplier publish a vulnerability reporting channel?
• Are vulnerability notification timelines defined in the contract?
• Are critical supplier vulnerabilities reported without undue delay?
• Are customer-impacting weaknesses linked to incident assistance obligations?
• Can the supplier provide remediation evidence or security advisories?
• Are subcontractor vulnerability obligations flowed down?
• Is there an exit strategy if remediation is inadequate?

This is where NIS2, DORA, and ISO/IEC 27001:2022 converge. Supplier vulnerability management is not a procurement checkbox. It is part of operational resilience.

Evidence mapping for ISO 27001, NIS2, DORA, GDPR, and COBIT

The strongest CVD programs are evidence-first. They assume that any significant report may later be reviewed by internal audit, certification auditors, regulators, customers, insurers, or a board risk committee.

Clarysec’s Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy - SME captures a detail many teams miss:

“Metadata (e.g., who collected it, when, and from which system) must be documented.”
Source: Audit and Compliance Monitoring Policy-sme, Policy Implementation Requirements, clause 6.2.3

A screenshot of a patched server is weak if nobody knows who captured it, when, from what system, and how it maps to the vulnerability. A ticket with timestamps, scanner output, pull request, change approval, deployment logs, monitoring query, retest confirmation, and metadata is much stronger.

A more detailed traceability matrix helps during client due diligence and internal audit.

Different auditors will test the same process through different lenses.

An ISO/IEC 27001:2022 auditor will start with the ISMS. They will ask whether vulnerability disclosure obligations are included in interested-party requirements, whether risks are assessed consistently, whether controls appear in the SoA, whether operating evidence exists, and whether management reviews trends and overdue items.

A DORA or financial services reviewer will focus on operational resilience. They will examine ICT risk integration, incident classification, senior management escalation, client communication, third-party dependencies, testing, and lessons learned. If the vulnerability affects a critical or important function, they will expect tight linkage between the technical ticket, business impact, continuity implications, and supplier obligations.

A GDPR reviewer will focus on personal data. Was personal data involved? Was there unauthorized access, loss, alteration, or disclosure? Were controller and processor roles clear? Was the breach threshold assessed? Were safeguards such as encryption, access control, logging, and minimization relevant?

A COBIT 2019 or ISACA auditor will focus on governance, accountability, performance, and assurance. They will look for defined ownership, metrics, escalation, control objectives, management oversight, and exception tracking. An overdue critical vulnerability is not only a technical problem. It is a governance issue unless formally escalated and risk-accepted.

A NIST-oriented assessor will think in terms of Identify, Protect, Detect, Respond, and Recover. They will want asset ownership, vulnerability identification, prioritization, protective change, exploitation detection, response coordination, and recovery validation.

The advantage of an integrated CVD model is that the same evidence spine can support all of these reviews.

The monthly control loop: metrics management can use

CVD does not end when the ticket closes. The Coordinated Vulnerability Disclosure Policy requires ongoing log review:

“The VRT shall maintain a vulnerability disclosure log tracking each report from receipt through closure. The log shall be reviewed monthly to ensure timely progression of open items. Overdue items shall be escalated.”
Source: Coordinated Vulnerability Disclosure Policy, Monitoring and Audit, clause 9.1

This monthly review turns vulnerability disclosure into board-ready governance. Management does not need every technical detail. It needs trend, exposure, accountability, and overdue risk.

In a mature Clarysec implementation, this monthly log review feeds the risk register, Statement of Applicability, secure development backlog, supplier reviews, incident lessons learned, internal audit plan, and management reporting pack.

Build the process before the serious report arrives

The worst time to design coordinated vulnerability disclosure is after a researcher has posted your weakness publicly or a critical bank client has frozen onboarding. NIS2, DORA, GDPR, ISO/IEC 27001:2022, NIST-style resilience expectations, and COBIT 2019 governance all point in the same direction: vulnerability disclosure must be planned, owned, tested, evidenced, and improved.

Start with these five actions:

1. Adopt or tailor the Coordinated Vulnerability Disclosure Policy.
2. Build the intake and triage workflow using Zenith Blueprint, especially Step 13 for SoA traceability, Step 16 for reporting culture, Step 19 for technical vulnerability management, and Step 23 for supplier agreements.
3. Map the workflow through Zenith Controls, focusing on ISO/IEC 27002:2022 controls A.8.8, A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16, A.8.25, and A.8.32.
4. Add SME-ready clauses from Incident Response Policy-sme, Vulnerability and Patch Management Policy-sme, Third-Party and Supplier Security Policy-sme, Application Security Requirements Policy-sme, and Audit and Compliance Monitoring Policy-sme where proportionality matters.
5. Run a tabletop exercise that simulates a researcher report affecting personal data and a supplier-hosted component, then test acknowledgement, triage, incident classification, patching, customer communication, evidence capture, and management escalation.

Clarysec can help you turn this into a working CVD policy, intake register, ISO/IEC 27001:2022 evidence map, NIS2 and DORA decision tree, supplier escalation model, and audit-ready control pack. The goal is simple: when the next vulnerability report arrives, your team should not improvise. It should execute with confidence, evidence, and control.