From Scans to Evidence: ISO 27001:2022, NIS2, DORA

It is 08:16 on a Monday. A critical remote code execution vulnerability has just appeared on the dashboard for an internet-facing application server. The infrastructure team says the vendor patch is available. The application owner warns that the server supports a revenue-critical customer workflow. Legal asks whether exploitation could trigger NIS2, DORA or GDPR reporting. The CISO, Maria, opens the audit calendar and sees the real problem: the ISO 27001:2022 surveillance audit starts next week, a NIS2 readiness review is already in progress, and a major fintech customer has requested DORA evidence.

The scanner shows red. The ticket board shows activity. The spreadsheet shows effort. But none of that automatically proves control.

This is the gap many organizations discover too late. Vulnerability scanning is not the same as vulnerability management audit readiness. A scan tells you something may be wrong. Audit evidence proves that your organization knew what it had, assessed risk, assigned ownership, acted within policy, controlled change, documented exceptions, verified results and reviewed the outcome.

For ISO/IEC 27001:2022, NIS2 and DORA, that evidence chain matters as much as the technical fix. The scanner starts the story. The asset inventory, vulnerability register, ticket, risk decision, change record, patch log, validation evidence, exception approval and management review complete it.

Clarysec’s approach is simple: do not treat vulnerability management as a monthly technical ritual. Treat it as a governed evidence workflow.

Why Scan Reports Fail as Audit Evidence

A vulnerability scan is a point-in-time technical observation. It may identify a CVE, missing patch, unsupported library, exposed service or weak configuration. That is useful, but it is incomplete.

An auditor will ask different questions:

• Was the affected asset in scope?
• Who owns the asset and business service?
• Was the vulnerability assessed using exposure, exploitability, business impact and data sensitivity?
• Was remediation completed within the defined timeframe?
• If remediation was delayed, who accepted the residual risk?
• Was the patch deployed through controlled change management?
• Was the fix verified by rescan or technical validation?
• Was the evidence retained and reviewed by management?

A folder of scanner exports rarely answers those questions. In an ISO 27001:2022 audit, the auditor is testing whether the ISMS operates as designed. Under NIS2, management bodies must approve and oversee cybersecurity risk-management measures. Under DORA, financial entities need a documented ICT risk management framework, incident lifecycle, resilience testing and ICT third-party risk controls. Under GDPR, the issue becomes whether appropriate technical and organisational measures protected personal data, and whether accountability can be demonstrated.

ISO/IEC 27001:2022 clauses 4.1 to 4.4 require the organization to understand its context, interested parties, requirements and ISMS scope. Vulnerability and patch management cannot be designed in isolation. It must reflect customer contracts, regulators, cloud dependencies, outsourced ICT services, data protection obligations and critical services.

ISO/IEC 27001:2022 clauses 6.1.1 to 6.1.3 require risk assessment, risk treatment, control selection, a Statement of Applicability and risk-owner approval for residual risk. That means vulnerability evidence should connect to the risk register, the treatment plan and the SoA.

ISO/IEC 27005:2022 reinforces this model by encouraging organizations to consolidate requirements from Annex A, sector obligations, regulations, contracts, internal rules and existing controls into the risk assessment baseline. It also emphasizes criteria for likelihood, consequence, legal obligations, supplier relationships, privacy impact and third-party impact. In practical terms, a vulnerability is not just a CVSS number. It is a risk event connected to assets, obligations, stakeholders and business consequences.

The Regulatory Pressure Behind Patch Evidence

Modern cybersecurity regulation is less tolerant of informal patching.

NIS2 applies to many medium and large entities in high-criticality and critical sectors, and can also reach certain entities regardless of size. Its scope includes digital infrastructure providers such as cloud computing services, data centre services, content delivery networks, public electronic communications providers, trust services, DNS and TLD services, plus ICT service management providers such as managed service providers and managed security service providers. It also covers important digital providers such as online marketplaces, online search engines and social networking platforms.

Article 20 of NIS2 makes cybersecurity a management-body responsibility. Article 21 requires appropriate and proportionate technical, operational and organisational measures, including risk analysis, incident handling, business continuity, supply chain security, secure acquisition, secure development, secure maintenance, vulnerability handling and disclosure, effectiveness assessment, cyber hygiene, access control, asset management and authentication. Article 23 creates a staged significant-incident notification process, including early warning within 24 hours, notification within 72 hours and a final report within one month where applicable.

DORA creates a directly applicable digital operational resilience rulebook for financial entities from 17 January 2025. It covers ICT risk management, major ICT incident reporting, operational resilience testing, cyber threat intelligence sharing, ICT third-party risk management and oversight of critical ICT third-party service providers. Articles 5 and 6 place ICT risk governance under the management body and require a documented, integrated and regularly reviewed ICT risk management framework. Article 8 reinforces the need to identify ICT-supported business functions, information assets, ICT assets and dependencies. Articles 17 to 20 require detection, recording, classification, escalation, reporting, communication, remediation and learning for ICT-related incidents. Articles 28 to 30 require ICT third-party risk to be controlled through registers, due diligence, contractual safeguards, audit rights, exit planning and oversight.

For financial entities covered by DORA, DORA generally supersedes equivalent NIS2 risk-management and reporting obligations. But NIS2 still matters for ecosystem coordination and entities outside DORA coverage. For SaaS, MSP and MSSP providers serving financial clients, the practical reality is direct: customers may require your vulnerability evidence to satisfy their DORA obligations.

GDPR adds another layer. Articles 2 and 3 can apply to EU-established organizations and non-EU organizations offering goods or services to people in the EU or monitoring their behaviour. Article 5 requires protection of personal data and accountability for compliance. Article 4 defines a personal data breach as a security incident leading to accidental or unlawful loss, destruction, alteration, unauthorised disclosure of, or access to personal data. A delayed patch on a database, identity platform or customer portal may become a privacy accountability issue.

From Policy to Proof

The first step is defining the rules. A strong vulnerability and patch management policy is not only an audit document. It is the operating constitution for the control.

For enterprise environments, Vulnerability and Patch Management Policy explicitly connects technical patching to cross-compliance:

This policy supports compliance with ISO/IEC 27001 Annex A Control 8.8 and ISO/IEC 27002 guidance and addresses regulatory requirements under DORA Article 8, NIS2 Article 21, GDPR Article 32, and COBIT 2019 DSS and APO domains.

From section “Purpose”.

The same policy sets the governance expectation for the core evidence artifact:

A centralized Vulnerability Management Register must be maintained by the Security Operations Team and reviewed monthly by the CISO or delegated authority.

From section “Governance Requirements”, policy clause 5.1.

It also defines scan cadence:

All systems must be scanned at least monthly; high-risk or externally exposed assets must be scanned weekly.

From section “Policy Implementation Requirements”, policy clause 6.1.1.

And it prevents urgent patching from becoming uncontrolled technical activity:

All remediation activities must be coordinated through the Change Management process (per P5 - Change Management Policy) to ensure stability and preservation of the audit trail.

From section “Governance Requirements”, policy clause 5.5.

For SMEs, the same evidence principles can be implemented more simply. Vulnerability and Patch Management Policy-sme states:

Maintain accurate records of applied patches, outstanding issues, and exceptions to ensure audit readiness

From section “Objectives”, policy clause 3.4.

It then defines the patch log as audit evidence:

A patch log must be maintained and reviewed during audits and incident response activities

From section “Governance Requirements”, policy clause 5.4.1.

And it specifies the minimum content:

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

From section “Governance Requirements”, policy clause 5.4.2.

For urgent internet-facing exposure, the SME policy sets a measurable requirement:

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

From Vulnerability and Patch Management Policy-sme, section “Policy Implementation Requirements”, policy clause 6.1.1.

These clauses turn technical work into evidence. The policy defines expectations. The register records findings. The ticket assigns work. The change record controls deployment. The patch log proves action. The risk register captures exceptions. The review minutes prove oversight.

The Clarysec Evidence-First Model

Clarysec’s evidence-first model starts with one principle: every vulnerability finding must be traceable from discovery to decision.

In Zenith Blueprint: An Auditor’s 30-Step Roadmap, the Controls in Action phase, Step 19: Technological Controls I, treats vulnerability management as a repeatable control rather than a theoretical requirement:

Managing vulnerabilities is one of the most critical areas of modern cyber hygiene. While firewalls and antivirus tools provide protection, they can be undermined if unpatched systems or misconfigured services are left exposed.

The same step explains that organizations should use regular patching schedules, vulnerability scanners, triage, assignment, remediation tracking, compensating controls and residual-risk acceptance. Most importantly, it frames the audit mindset correctly:

The control is not about perfection, it’s about having an organized, transparent, and accountable process.

For auditors, that distinction matters. A mature organization can have open vulnerabilities and still demonstrate control, provided it has risk-based prioritization, documented ownership, approved exceptions, compensating controls and verified remediation.

The Zenith Blueprint also warns that auditors will inspect this area closely:

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.

This is why a CISO should not walk into an audit with only a scanner dashboard. The evidence package must show governance, process, execution, verification and improvement.

Mapping ISO 27002 Controls to Audit Evidence

Zenith Controls: The Cross-Compliance Guide acts as a cross-compliance compass by mapping ISO/IEC 27002:2022 controls and showing how they relate to audit expectations. For vulnerability and patch management, three ISO/IEC 27002:2022 controls form the operating triangle.

ISO/IEC 27002:2022 control 8.8, Management of Technical Vulnerabilities, is the central control. It is preventive, supports confidentiality, integrity and availability, aligns with Identify and Protect cybersecurity concepts and connects to threat and vulnerability management.

ISO/IEC 27002:2022 control 8.32, Change Management, is also preventive. It connects patching to controlled deployment, testing, approval, rollback and auditability.

ISO/IEC 27002:2022 control 5.36, Compliance with Policies, Rules and Standards for Information Security, ensures the process is not optional or dependent on individual heroics. It connects vulnerability management to policy compliance, assurance and oversight.

This mapping avoids a common audit failure. Security says, “We patched it.” Operations says, “We deployed it.” Compliance says, “We cannot prove the sequence.” A mapped evidence chain gives all three teams the same story.

The Evidence Chain Auditors Want

A defensible vulnerability management evidence chain has seven stages.

The practical difference between “we run scans” and “we are audit-ready” is continuity. If a vulnerability cannot be traced from discovery to closure, the control is weak. If exceptions exist but no one approved them, the process is weak. If patches bypass change management, the audit trail is weak. If critical vulnerabilities remain open without compensating controls, governance is weak.

Audit and Compliance Monitoring Policy supports automation as part of this model:

Automated tools shall be deployed to monitor configuration compliance, vulnerability management, patch status, and privileged access.

From section “Policy Implementation Requirements”, policy clause 6.4.1.

For SMEs, Audit and Compliance Monitoring Policy-sme defines technical control verification in practical terms:

Technical control verification (e.g., backup status, access control configuration, patch records)

From section “Policy Implementation Requirements”, policy clause 6.1.1.2.

Small organizations do not need enterprise-grade tooling to become audit-ready. They need consistent evidence. A lightweight register, ticketing board, patch log and monthly review can be sufficient if they are complete, current and tied to risk.

Example: One Critical Finding, Fully Audit-Ready

Maria’s weekly external scan identifies CVE-2026-12345 on an internet-facing payment API gateway. The scanner rates it critical. The service processes customer identity and transaction metadata, so GDPR and DORA implications are possible. The gateway is owned by Platform Engineering, but the patch requires a short outage.

Here is the audit-ready workflow.

1. Create the vulnerability register entry

The security team records the finding in the central register:

• Finding ID: VULN-2026-0142
• Source: weekly external scan
• Discovery date and time
• Asset: api-gw-prod-01
• Owner: Platform Engineering
• Exposure: internet-facing
• Data context: customer identity and transaction metadata
• Severity: critical
• SLA: 72 hours or stricter based on policy
• Ticket: SEC-4821
• Change record: CHG-10988
• Status: remediation planned

2. Triage using business and regulatory context

The team checks exploit availability, attack surface, authentication requirements, business impact and data sensitivity. Because the system is internet-facing and supports customer workflows, the vulnerability remains critical. The risk owner is the Head of Platform, and the CISO is notified because of possible NIS2, DORA and GDPR implications.

ISO/IEC 27005:2022 clauses 7.1 to 7.4 support risk identification, ownership, consequence, likelihood and prioritization. Clauses 8.2 to 8.6 support treatment selection, control determination, SoA linkage, treatment planning and residual-risk approval.

3. Open a controlled emergency change

The patch is scheduled for the same evening. The change record includes the vendor reference, affected services, test plan, rollback plan, maintenance window, customer communication decision, approvals and post-deployment validation requirement.

This directly supports ISO/IEC 27002:2022 control 8.32 and the enterprise policy requirement to coordinate remediation through change management.

4. Apply the patch and update the patch log

The patch log records device name, update applied, patching date and delay reason if any. If patching had been delayed, the team would document compensating controls such as web application firewall rules, temporary access restrictions, increased logging, isolation or enhanced monitoring.

5. Verify and close

Security rescans the API gateway. The vulnerability no longer appears. The ticket is updated with clean scan evidence, patch version, deployment timestamp and change record link. The vulnerability register status changes to “Closed, verified.”

6. Review reporting impact

If there was no exploitation and no service disruption, NIS2 or DORA incident reporting may not be triggered. If indicators of compromise are found, the incident process must classify impact and escalation. Under NIS2, a significant incident may require early warning and staged reporting. Under DORA, a major ICT-related incident requires classification and reporting through the applicable competent authority process.

7. Feed lessons into management review

At month-end, the CISO review notes that the vulnerability was detected by weekly external scanning, remediated within SLA, verified by rescan and closed without incident. If similar issues recur, the treatment plan may include secure configuration baselines, automated patch deployment, supplier escalation or application modernization.

When an auditor asks about CVE-2026-12345, Maria can present a curated package instead of emails and screenshots.

That is audit-ready. Not because the organization had no vulnerabilities, but because it had control.

One Evidence Set, Multiple Obligations

A well-designed vulnerability and patch management program can satisfy multiple frameworks without duplicating work.

For ISO 27001:2022, the evidence supports the risk-based ISMS, Annex A control implementation, Statement of Applicability, risk treatment plans, internal audit and continual improvement. If ISO/IEC 27002:2022 control 8.8 is applicable in the SoA, the organization should be able to show the legal, regulatory, risk or business rationale. That rationale often includes NIS2 Article 21, DORA ICT risk obligations, GDPR accountability, customer contracts and operational resilience needs.

For NIS2, the same evidence helps demonstrate Article 21 measures, including risk analysis, vulnerability handling, incident handling, business continuity, supply chain security, cyber hygiene, access control and effectiveness assessment. Article 20 is demonstrated through CISO review, board reporting, management approval and cybersecurity training. Article 23 becomes relevant if exploitation causes or could cause severe operational disruption, financial loss or harm to others.

For DORA, vulnerability and patch evidence supports the ICT risk management framework, management-body oversight, resilience strategy, incident detection and classification, resilience testing and ICT third-party oversight. Where an ICT provider hosts or manages the affected system, Articles 28 to 30 require due diligence, contractual protections, audit rights, incident assistance and exit considerations.

For GDPR, the same evidence supports Article 5 accountability and the security posture expected under Article 32. If a vulnerability leads to unauthorised access, alteration, loss or disclosure of personal data, the vulnerability timeline, patch records, monitoring logs and breach assessment notes become essential.

For COBIT 2019 and ISACA-style assurance, vulnerability management is assessed through operational security, control monitoring, change enablement and governance accountability. The Zenith Blueprint cross-compliance references call out COBIT 2019 DSS05.04 and BAI09.02, plus ITAF assurance expectations over vulnerability management, patching and secure change management.

Supporting ISO standards strengthen the operating model. ISO/IEC 27005:2022 supports risk assessment and treatment. ISO/IEC 27035:2023 supports incident response when vulnerabilities are exploited. ISO/IEC 30111 supports vulnerability handling processes. ISO/IEC 29147 supports vulnerability disclosure and advisories. ISO/IEC 27017 supports cloud vulnerability management. ISO 22301 supports continuity planning where technical vulnerabilities could disrupt business services.

How Different Auditors Test the Same Process

Different assessors use different lenses. The evidence can be the same, but the questions change.

The policy says what should happen. The operational evidence shows what did happen. The review records show management knew, challenged and acted.

Common Reasons Patch Management Fails an Audit

Most findings are not caused by the absence of a scanner. They are caused by broken traceability.

The asset inventory is incomplete.
If a scanner finds assets that are missing from the CMDB or asset register, ownership and business impact cannot be assessed reliably. This undermines ISO 27001:2022 scope, risk assessment and treatment.

Vulnerabilities are tracked only in the scanner.
Scanner dashboards are not governance registers. They often lack risk-owner approval, exception rationale, change references and business context.

Critical findings have no SLA evidence.
A policy may say critical vulnerabilities are fixed within three days. The audit question is whether records prove that happened.

Exceptions are informal.
Legacy systems, outage constraints and supplier delays happen. But “we could not patch it” must become a documented exception with compensating controls, expiry date and residual-risk approval.

Emergency patching bypasses change management.
Emergency changes are still changes. If there is no approval, testing or rollback evidence, auditors may conclude that remediation created operational risk.

Third-party systems are invisible.
Under NIS2 and DORA, supplier and ICT third-party risk are central. If a provider patches the platform, you still need evidence, contractual rights, service reporting and escalation routes.

No one reviews trends.
Recurring vulnerabilities may indicate weak configuration management, poor secure development practices, unsupported assets or supplier failure. Monthly review turns technical data into governance action.

The Clarysec Vulnerability Audit Pack

For an upcoming ISO 27001:2022, NIS2 or DORA readiness review, Clarysec helps organizations assemble a vulnerability and patch management audit pack with the following:

• Vulnerability and Patch Management Policy, including scope, roles, scan cadence, patch SLAs and exception rules
• Asset inventory extract showing in-scope systems, owners, criticality and exposure
• Latest internal and external vulnerability scan reports
• Central Vulnerability Management Register with open, closed and exception items
• Patch logs showing device, update, patch date and delay reasons
• Change records for sampled critical and high vulnerabilities
• Evidence of rescans or validation after remediation
• Exception and residual-risk approvals for delayed or unpatchable systems
• Security advisory monitoring process for vendors, libraries and cloud services
• Monthly CISO or management review minutes
• Crosswalk to ISO 27001:2022, NIS2, DORA, GDPR and COBIT 2019 obligations
• Internal audit or technical control verification results

In the Zenith Blueprint, Audit, Review & Improvement phase, Step 24, Clarysec stresses traceability between the Statement of Applicability, risk register and treatment plan:

Your SoA should be consistent with your Risk Register and Risk Treatment Plan. Double-check that every control you chose as a risk treatment is marked “Applicable” in the SoA.

This is especially important for vulnerability management. If control 8.8 is applicable, the audit pack should prove not only that scanning happens, but that findings are governed through risk treatment and continual improvement.

A 30-Day Readiness Sprint

If your audit is close, do not start by rewriting everything. Start by building evidence fast.

This sprint will not eliminate all technical debt. It will change the audit conversation. Instead of defending a messy scanner export, you can show a governed process with owners, timelines, actions, decisions and oversight.

Move From Scans to Defensible Evidence

Vulnerability and patch management audit readiness is not about proving you have no vulnerabilities. It is about proving you can find them, understand them, prioritize them, fix them, control exceptions and demonstrate oversight.

Clarysec’s Zenith Blueprint, Zenith Controls, Vulnerability and Patch Management Policy, Vulnerability and Patch Management Policy-sme, Audit and Compliance Monitoring Policy and Audit and Compliance Monitoring Policy-sme provide the structure to build that evidence workflow.

If your organization is preparing for ISO 27001:2022 certification, NIS2 readiness, DORA digital operational resilience, customer due diligence or internal audit, start with one question:

Can every critical vulnerability be traced from scan to closure?

If the answer is no, Clarysec can help you build the register, policy set, cross-compliance mapping, management review pack and audit-ready evidence workflow that turns technical scanning into defensible governance.