DORA Vulnerability Scanning

DORA establishes comprehensive vulnerability scanning requirements that go beyond traditional approaches in several key dimensions. First, DORA requires systematic and continuous vulnerability identification across all ICT systems, not just periodic assessments. This includes automated scanning tools, manual security assessments, and regular penetration testing. Second, DORA mandates risk-based prioritization that considers business impact, threat landscape, and operational criticality, rather than just technical severity scores. Third, the regulation requires integration with broader ICT risk management frameworks, ensuring vulnerability management supports overall operational resilience. Fourth, DORA emphasizes timely remediation with clear accountability and escalation processes, particularly for critical vulnerabilities. Fifth, the regulation requires comprehensive documentation and reporting capabilities for regulatory oversight. Finally, DORA mandates regular validation through penetration testing and security assessments to verify the effectiveness of vulnerability management processes. Financial institutions must implement vulnerability management programs that provide continuous visibility, intelligent prioritization, rapid remediation, and regular validation while maintaining comprehensive audit trails for regulatory compliance.

Determining appropriate scanning frequency and coverage under DORA requires a risk-based approach that considers multiple factors. For scanning frequency, critical systems and internet-facing assets typically require continuous or daily scanning, while internal systems may be scanned weekly or monthly based on risk assessment. DORA emphasizes that scanning frequency should reflect the criticality of systems, exposure to threats, and rate of change in the environment. For coverage, institutions must ensure comprehensive scanning across all ICT systems, including infrastructure, applications, databases, network devices, and cloud services. This includes both authenticated and unauthenticated scans to identify different vulnerability types. Special attention must be paid to critical or important functions as defined under DORA, which may require more frequent and thorough scanning. The approach should also consider different scanning types: network vulnerability scans, web application scans, database scans, configuration assessments, and compliance checks. Additionally, institutions should implement event-driven scanning triggered by significant changes, new deployments, or emerging threats. The scanning strategy must balance thoroughness with operational impact, using techniques like scan scheduling, bandwidth throttling, and agent-based scanning to minimize disruption. Regular review and adjustment of scanning frequency and coverage based on risk assessment, incident trends, and regulatory feedback ensures the program remains effective and proportionate.

Effective vulnerability assessment and prioritization under DORA requires sophisticated methodologies that go beyond simple CVSS scoring. The foundation is risk-based assessment that considers multiple dimensions: technical severity (CVSS score), exploitability (availability of exploits, ease of exploitation), asset criticality (business impact, data sensitivity), threat context (active exploitation, threat actor interest), and environmental factors (compensating controls, network segmentation). Leading approaches include the Stakeholder-Specific Vulnerability Categorization (SSVC) framework, which considers exploitation status, technical impact, and mission impact to determine prioritization. The Exploit Prediction Scoring System (EPSS) provides data-driven probability of exploitation within specific timeframes. Many institutions implement custom scoring models that weight these factors based on their specific risk profile and business context. The prioritization methodology should integrate with asset management systems to understand business criticality and with threat intelligence feeds to incorporate current threat landscape. Automated prioritization engines can process these multiple inputs to generate risk scores and recommended remediation timelines. The approach should define clear priority levels (e.g., Critical, High, Medium, Low) with associated SLAs for remediation. For DORA compliance, prioritization must explicitly consider operational resilience impact and regulatory requirements. Dynamic prioritization that adjusts based on changing threat landscape, new exploits, or business changes ensures resources focus on highest-risk vulnerabilities. Regular validation through penetration testing and red team exercises verifies that prioritization accurately reflects real-world risk.

Selecting appropriate vulnerability scanning tools for DORA compliance requires evaluation across multiple critical dimensions. First, coverage capabilities must be comprehensive, including network vulnerability scanning, web application scanning, database scanning, container and cloud security scanning, and configuration assessment. The tools should support both authenticated and unauthenticated scanning across diverse technology stacks. Second, accuracy and reliability are crucial

Establishing appropriate remediation timelines under DORA requires risk-based SLAs that balance security needs with operational realities. For critical vulnerabilities (CVSS 9.0‑10.0) affecting internet-facing systems or critical functions, immediate action is typically required with remediation within 24‑48 hours. This includes emergency patching procedures and temporary mitigations if patches are not immediately available. High-severity vulnerabilities (CVSS 7.0‑8.9) generally require remediation within 7‑14 days, with prioritization based on exploitability and asset criticality. Medium-severity vulnerabilities (CVSS 4.0‑6.9) typically have 30-day remediation windows, while low-severity issues may have 90-day timelines. However, DORA emphasizes that these timelines must be adjusted based on contextual factors: active exploitation in the wild may require immediate action regardless of CVSS score, while vulnerabilities in isolated systems with strong compensating controls may allow longer remediation windows. The SLA framework should include escalation procedures for missed deadlines, exception processes for vulnerabilities that cannot be immediately remediated, and requirements for compensating controls when patches cannot be applied. Documentation requirements include tracking remediation status, justification for any timeline extensions, and evidence of risk acceptance for vulnerabilities that cannot be remediated. Regular reporting to senior management and risk committees ensures visibility into remediation performance. The SLA framework should be regularly reviewed and adjusted based on remediation performance, incident trends, and regulatory feedback to ensure it remains effective and achievable.

Integrating threat intelligence into vulnerability management significantly enhances both DORA compliance and security effectiveness by providing contextual risk assessment. The integration should begin with establishing feeds from multiple sources: commercial threat intelligence providers, open-source intelligence (OSINT), information sharing communities (ISACs/ISAOs), vendor security advisories, and government cybersecurity agencies. These feeds provide information on actively exploited vulnerabilities, emerging threats, threat actor tactics and techniques, and industry-specific threats. The integration architecture should automatically correlate vulnerability scan results with threat intelligence data to identify vulnerabilities that are actively being exploited or targeted by threat actors. This correlation enables dynamic risk scoring that considers not just technical severity but also real-world threat context. For example, a medium-severity vulnerability being actively exploited by ransomware groups would be elevated to critical priority. The system should also monitor for new exploits or proof-of-concept code releases that increase exploitability of known vulnerabilities. Threat intelligence should inform scanning priorities, with increased scanning frequency for vulnerability types currently being exploited. The integration should support automated alerting when vulnerabilities in your environment match active threat campaigns. Additionally, threat intelligence provides valuable context for security assessments and penetration testing, helping focus testing on attack vectors currently used by threat actors. For DORA compliance, this integration demonstrates proactive threat-informed risk management and supports the requirement for continuous monitoring of the threat landscape. Regular threat intelligence briefings to security teams and management ensure organizational awareness of current threats and inform strategic security decisions.

Vulnerability management in cloud and hybrid environments under DORA presents unique challenges requiring specialized approaches. First, responsibility models must be clearly understood: in IaaS, institutions are responsible for OS and application vulnerabilities; in PaaS, responsibility shifts more to the provider; in SaaS, the provider handles most vulnerability management. However, DORA requires institutions to maintain oversight and assurance regardless of the model. For scanning approaches, cloud environments require both agent-based and agentless scanning to handle dynamic infrastructure. Container scanning must address both container images and runtime environments, with integration into CI/CD pipelines for shift-left security. Serverless functions require specialized scanning tools that can assess function code and dependencies. API security scanning is critical as APIs are primary attack surfaces in cloud environments. Configuration scanning must verify cloud security settings, IAM policies, storage permissions, and network configurations against security baselines. The dynamic nature of cloud environments requires continuous scanning rather than periodic assessments, with automation to handle auto-scaling and ephemeral resources. Multi-cloud environments need unified vulnerability management across different cloud providers, requiring tools that support multiple platforms. For hybrid environments, scanning must cover both on-premise and cloud resources with consistent policies and reporting. Cloud-specific vulnerabilities like misconfigured storage buckets, overly permissive IAM roles, and exposed management interfaces require specialized detection. Integration with cloud-native security tools (AWS Security Hub, Azure Security Center, GCP Security Command Center) provides comprehensive visibility. For DORA compliance, institutions must demonstrate effective vulnerability management across all deployment models, with clear accountability for cloud provider and institution responsibilities, comprehensive scanning coverage, and rapid remediation capabilities.

Managing false positives is critical for maintaining efficient vulnerability management programs while ensuring DORA compliance. The challenge is balancing thoroughness with operational efficiency, as excessive false positives can overwhelm security teams and delay remediation of real vulnerabilities. The approach should begin with tool selection and configuration: choose scanning tools with high accuracy rates and configure them appropriately for your environment, including authenticated scanning where possible to reduce false positives. Implement a structured false positive validation process with clear criteria for determining whether a finding is a true vulnerability or false positive. This process should include technical validation (attempting to exploit the vulnerability), environmental context (checking for compensating controls), and vendor confirmation (consulting with application or system vendors). Establish a false positive repository that documents validated false positives with justification, allowing automatic suppression of recurring false positives in future scans. However, DORA compliance requires that false positive determinations be regularly reviewed, as environmental changes or new exploit techniques may make previously dismissed findings relevant. Implement risk-based validation prioritization, focusing detailed validation efforts on high-severity findings while using automated validation for lower-severity issues. Use multiple scanning tools with different detection engines to cross-validate findings and reduce false positives. Integrate with asset management and configuration management databases to provide context that helps distinguish false positives from real vulnerabilities. Establish metrics tracking false positive rates by tool, vulnerability type, and system category to identify patterns and improve scanning accuracy. Regular tuning of scanning tools based on false positive analysis improves efficiency over time. For DORA compliance, maintain comprehensive documentation of false positive determinations, including technical justification and approval by qualified security personnel. Regular audits of false positive decisions ensure the process remains rigorous and defensible during regulatory examinations.

Integrating penetration testing with vulnerability scanning creates a comprehensive security assessment program that satisfies DORA requirements for operational resilience testing. While vulnerability scanning provides automated, continuous identification of potential weaknesses, penetration testing validates exploitability and assesses real-world attack scenarios. The integration should follow a structured approach: vulnerability scanning results inform penetration testing scope and priorities, focusing testing efforts on areas with high vulnerability concentrations or critical assets. Penetration testing validates whether identified vulnerabilities are actually exploitable in your specific environment, considering security controls, network segmentation, and defense-in-depth measures. This validation helps prioritize remediation efforts based on actual risk rather than theoretical severity. Penetration testing also identifies vulnerabilities that automated scanning may miss, such as business logic flaws, complex authentication bypasses, and sophisticated attack chains that require multiple steps. The testing should include both external and internal perspectives, simulating attacks from internet-facing positions and from compromised internal accounts. For DORA compliance, penetration testing must be performed at least annually and after significant changes to ICT systems. However, leading practices suggest more frequent testing for critical systems and continuous security validation through automated breach and attack simulation tools. The integration should include clear handoff processes: vulnerability scan results are provided to penetration testers before engagements, and penetration testing findings are fed back into vulnerability management to improve scanning coverage and accuracy. Post-testing, both vulnerability scanning and penetration testing results should be analyzed together to identify systemic weaknesses and inform security architecture improvements. Documentation should demonstrate how the combined program provides comprehensive security assessment coverage.

Container and Kubernetes security scanning requires specialized approaches to address the unique characteristics of containerized environments under DORA. The scanning strategy must cover multiple layers: container images, running containers, Kubernetes configurations, and the underlying orchestration platform. For container images, implement scanning in the CI/CD pipeline to identify vulnerabilities before deployment, with policies that prevent deployment of images with critical vulnerabilities. Image scanning should analyze all layers, including base images, application dependencies, and custom code. Maintain a secure container registry with automated scanning of all stored images and regular rescanning to detect newly disclosed vulnerabilities. For running containers, implement runtime scanning that monitors container behavior and detects anomalies that may indicate exploitation of vulnerabilities. Kubernetes-specific scanning must assess cluster configurations, including RBAC policies, network policies, pod security policies, and admission controllers. Common Kubernetes vulnerabilities include overly permissive service accounts, containers running as root, exposed dashboards, and insecure API server configurations. The scanning should verify compliance with Kubernetes security benchmarks like CIS Kubernetes Benchmark. For DORA compliance, special attention is needed for supply chain security: verify the provenance of base images, scan third-party containers, and maintain software bill of materials (SBOM) for all container images. Implement image signing and verification to prevent deployment of tampered images. The scanning program should integrate with container orchestration platforms to automatically scan new deployments and enforce security policies. Regular scanning of the Kubernetes control plane and worker nodes ensures the underlying infrastructure is secure. Vulnerability management for containers must address the ephemeral nature of containers, with automated remediation through image rebuilding and redeployment rather than traditional patching. Documentation should demonstrate comprehensive coverage of all container security layers and integration with the overall vulnerability management program.

Effective vulnerability management under DORA requires comprehensive metrics that demonstrate both operational effectiveness and risk reduction. Key metrics should be organized into several categories. Coverage metrics include percentage of assets scanned, scanning frequency compliance, and time to scan new assets after deployment. These demonstrate that the scanning program has comprehensive visibility. Detection metrics track total vulnerabilities identified, vulnerabilities by severity level, new vulnerabilities detected per period, and vulnerability density (vulnerabilities per asset). These show the program's effectiveness at identifying security issues. Remediation metrics are critical for DORA compliance: mean time to remediate (MTTR) by severity level, percentage of vulnerabilities remediated within SLA, remediation backlog size and age, and percentage of vulnerabilities with compensating controls. These demonstrate the institution's ability to address identified vulnerabilities promptly. Risk metrics include risk score trends over time, percentage of critical assets with high-severity vulnerabilities, and exposure time for critical vulnerabilities. These show whether the program is effectively reducing risk. Operational metrics track false positive rates, scanning tool coverage and accuracy, and vulnerability management team productivity. Process metrics include percentage of vulnerabilities with documented risk acceptance, compliance with vulnerability management policies, and audit findings related to vulnerability management. For DORA-specific compliance, track metrics related to ICT third-party risk, including vulnerabilities in third-party components and vendor response times to vulnerability disclosures. Trend analysis is essential: track how metrics change over time to demonstrate continuous improvement. Metrics should be reported regularly to senior management and risk committees, with clear targets and thresholds that trigger escalation. Benchmark metrics against industry standards and peer institutions to provide context. The metrics program should be regularly reviewed and refined to ensure it provides meaningful insights into vulnerability management effectiveness and supports data-driven decision making.

Managing vulnerabilities in third-party components and open-source libraries is critical for DORA compliance, as these components often represent significant attack surfaces. The approach must begin with comprehensive inventory: maintain a software bill of materials (SBOM) for all applications, documenting all third-party components, libraries, frameworks, and dependencies. This inventory should include version information, licensing details, and dependency relationships. Automated tools should continuously monitor this inventory against vulnerability databases (NVD, vendor advisories, GitHub Security Advisories) to identify newly disclosed vulnerabilities. For open-source components, implement software composition analysis (SCA) tools that scan application code and dependencies to identify vulnerable libraries. These tools should integrate into CI/CD pipelines to prevent deployment of applications with known vulnerable dependencies. The challenge with third-party components is that remediation often requires updating to newer versions, which may introduce compatibility issues or breaking changes. Therefore, establish a risk-based approach: critical vulnerabilities in actively exploited components require immediate action, while lower-severity issues may be addressed during planned maintenance windows. For components where updates are not immediately available, implement compensating controls such as web application firewalls, runtime application self-protection (RASP), or network segmentation to reduce exploitation risk. Vendor management is crucial: establish processes for engaging with software vendors about vulnerability disclosures, patch availability, and remediation timelines. For critical third-party software, negotiate SLAs that include vulnerability response commitments. The DORA framework specifically requires oversight of ICT third-party service providers, so vulnerability management must extend to cloud services, SaaS applications, and managed services. Regular security assessments of third-party providers should include review of their vulnerability management practices. For open-source components, consider the maintenance status and community support: actively maintained projects with responsive maintainers present lower risk than abandoned projects. Establish policies for acceptable use of third-party components, including security requirements and approval processes. Documentation should demonstrate comprehensive tracking of third-party component vulnerabilities and systematic remediation processes.

Automation is essential for achieving efficient and effective vulnerability management under DORA, given the scale and complexity of modern financial institution IT environments. Automation should be implemented across the entire vulnerability management lifecycle. For discovery and scanning, automated tools should continuously scan networks, systems, and applications without manual intervention, with scheduling that ensures comprehensive coverage while minimizing performance impact. Asset discovery automation ensures new systems are automatically added to scanning schedules, preventing coverage gaps. For vulnerability assessment, automated correlation with threat intelligence feeds provides real-time risk scoring based on exploitability and active threats. Automated prioritization algorithms can rank vulnerabilities based on multiple factors: technical severity, asset criticality, exploitability, threat intelligence, and business context. This automation helps security teams focus on the most critical issues first. For remediation, automation can include automatic patch deployment for low-risk systems, automated creation of remediation tickets with relevant context, and automated verification scanning after remediation to confirm vulnerabilities are resolved. Workflow automation ensures vulnerabilities are routed to appropriate teams, escalated when SLAs are at risk, and tracked through resolution. For reporting, automated dashboards provide real-time visibility into vulnerability management metrics, with automated alerts when thresholds are exceeded or critical vulnerabilities are detected. Automated compliance reporting demonstrates DORA adherence to regulators and auditors. However, automation must be balanced with human oversight: critical decisions about risk acceptance, remediation approaches for complex vulnerabilities, and validation of automated findings should involve security professionals. The automation framework should include exception handling for scenarios that require manual intervention. Regular review of automation rules and algorithms ensures they remain effective as the threat landscape evolves. For DORA compliance, automation demonstrates operational maturity and enables the continuous monitoring and rapid response that the regulation requires.

DORA imposes comprehensive reporting and documentation requirements for vulnerability management that demonstrate operational resilience and regulatory compliance. Regular reporting to senior management and the board should include vulnerability management metrics, trends in vulnerability detection and remediation, risk exposure levels, and significant security issues. These reports should be provided at least quarterly, with more frequent reporting for critical issues. The reports must demonstrate that vulnerability management is effectively reducing ICT risk and supporting operational resilience. For regulatory reporting, institutions must be prepared to provide evidence of vulnerability management effectiveness during supervisory reviews and audits. This includes documentation of vulnerability management policies and procedures, evidence of regular scanning and assessment activities, records of vulnerability remediation with timelines, and documentation of risk acceptance decisions for vulnerabilities that cannot be immediately remediated. Incident reporting under DORA requires that major ICT-related incidents be reported to regulators, and if such incidents result from unpatched vulnerabilities, the institution must explain why the vulnerability was not addressed. Documentation standards should include comprehensive records for each identified vulnerability: discovery date, technical details, affected systems, risk assessment, assigned priority, remediation plan, actual remediation date, and verification of remediation. For vulnerabilities that cannot be immediately remediated, document compensating controls, risk acceptance justification, and approval by appropriate authority. The documentation should demonstrate compliance with established SLAs and policies. For third-party vulnerabilities, maintain records of vendor notifications, vendor response times, and coordination of remediation efforts. Audit trails should demonstrate that vulnerability management processes are consistently followed and that exceptions are properly justified and approved. The documentation framework should support both internal governance and external regulatory requirements, with clear retention policies that ensure records are available for regulatory examinations. Regular internal audits of vulnerability management should be documented, including findings and remediation of any deficiencies.

Continuous improvement is fundamental to maintaining effective vulnerability management under DORA's operational resilience framework. The improvement process should be systematic and data-driven, using metrics and lessons learned to enhance program effectiveness. Begin by establishing baseline metrics for all key performance indicators: scanning coverage, detection rates, remediation timelines, false positive rates, and risk reduction. Regular analysis of these metrics identifies trends and areas for improvement. After security incidents, conduct thorough post-incident reviews to determine if vulnerabilities played a role and whether the vulnerability management program could have prevented or detected the issue earlier. These lessons learned should drive specific improvements to scanning coverage, detection capabilities, or remediation processes. Regular program assessments should evaluate the effectiveness of vulnerability management tools, processes, and resources. This includes reviewing scanning tool accuracy and coverage, assessing whether remediation SLAs are appropriate and achievable, evaluating the effectiveness of prioritization algorithms, and determining if security teams have adequate resources and training. Benchmark against industry standards and peer institutions to identify gaps and opportunities for improvement. The threat landscape continuously evolves, so the vulnerability management program must adapt: regularly update scanning tools and signatures, incorporate new vulnerability databases and threat intelligence feeds, adjust scanning frequencies based on threat levels, and update remediation priorities based on current attack trends. Technology changes also drive improvement needs: as the institution adopts new technologies (cloud services, containers, IoT devices), the vulnerability management program must expand to cover these new attack surfaces. Stakeholder feedback is valuable: regularly solicit input from system owners, application teams, and business units about the vulnerability management process, identifying friction points and opportunities to improve efficiency. The improvement process should include regular training for security teams on new tools, techniques, and threats. For DORA compliance, document all improvement initiatives, demonstrating a culture of continuous enhancement of operational resilience. The improvement program should be overseen by senior management, with regular reporting on improvement initiatives and their outcomes.

Effective vulnerability management under DORA requires integration with multiple security and risk management processes to provide comprehensive operational resilience. Integration with asset management is foundational: vulnerability management systems must have accurate, up-to-date information about all IT assets, their criticality, ownership, and configuration. This integration ensures comprehensive scanning coverage and enables risk-based prioritization. Integration with configuration management provides context about system configurations, helping distinguish between actual vulnerabilities and false positives based on compensating controls or security configurations. Integration with patch management is critical: vulnerability management identifies what needs to be patched, while patch management handles the deployment process. These systems should share data about patch availability, deployment status, and verification of successful patching. Integration with incident response ensures that vulnerability information is available during incident investigations, and that incidents inform vulnerability management priorities. If an incident exploits a vulnerability, the vulnerability management program should immediately scan for similar vulnerabilities across the environment. Integration with threat intelligence provides context about which vulnerabilities are being actively exploited, enabling dynamic risk scoring and prioritization. Integration with security information and event management (SIEM) systems allows correlation of vulnerability data with security events, helping identify potential exploitation attempts. Integration with risk management frameworks ensures vulnerability data feeds into overall risk assessments and that vulnerability management priorities align with enterprise risk appetite. For DORA compliance, integration with ICT third-party risk management is essential: vulnerability management must extend to third-party services and products, with processes for coordinating vulnerability remediation with vendors. Integration with business continuity and disaster recovery planning ensures that vulnerability management considers business impact and recovery priorities. Integration with compliance management tracks vulnerability management requirements from multiple regulations and standards, ensuring comprehensive compliance. The integration architecture should include automated data sharing between systems, unified dashboards that provide holistic security visibility, and coordinated workflows that span multiple security domains. This integrated approach demonstrates the comprehensive operational resilience that DORA requires.

Zero-day vulnerabilities present unique challenges under DORA as they are unknown to vendors and have no available patches. Preparation begins with establishing a zero-day response framework that includes detection capabilities, response procedures, and communication protocols. Detection relies on multiple layers: behavioral analysis and anomaly detection can identify exploitation attempts even without signature-based detection, threat intelligence feeds provide early warning of zero-day exploits in the wild, and security monitoring should be configured to detect unusual activities that may indicate zero-day exploitation. When a zero-day vulnerability is identified, the response must be rapid and comprehensive. Immediate actions include assessing exposure by identifying all systems potentially affected by the vulnerability, implementing emergency compensating controls such as network segmentation, access restrictions, or web application firewall rules to reduce exploitation risk, and enhancing monitoring for indicators of compromise related to the vulnerability. Communication is critical: notify senior management and risk committees immediately, coordinate with affected business units about potential service impacts, engage with vendors for patch timelines and workarounds, and participate in information sharing communities to learn from peer experiences. For DORA compliance, the response must balance security with operational continuity: if compensating controls adequately reduce risk, systems may remain operational while awaiting patches; if risk is unacceptable, systems may need to be taken offline despite business impact. Document all decisions with risk-based justification. Once vendor patches are available, prioritize deployment based on exposure and criticality, with expedited testing and deployment processes for critical systems. Post-incident, conduct thorough analysis to determine if the zero-day was exploited in your environment, assess the effectiveness of detection and response, and identify improvements to prevent or detect similar threats. The zero-day response framework should be regularly tested through tabletop exercises and updated based on lessons learned. For DORA compliance, demonstrate that the institution has systematic processes for handling unknown threats and can maintain operational resilience even when facing novel vulnerabilities.

Legacy systems present significant vulnerability management challenges under DORA, as they often cannot be patched due to vendor support ending, compatibility issues, or business criticality preventing downtime. The strategy must focus on risk mitigation through compensating controls and eventual modernization. Begin with comprehensive risk assessment: identify all legacy systems, document their business criticality, assess their vulnerability exposure, and evaluate the feasibility of patching or replacement. For systems that cannot be patched, implement defense-in-depth compensating controls. Network segmentation isolates legacy systems from general networks and the internet, reducing attack surface. Strict access controls limit who can access legacy systems, with multi-factor authentication and privileged access management. Enhanced monitoring provides early detection of exploitation attempts through SIEM integration, anomaly detection, and file integrity monitoring. Application-level controls include web application firewalls for legacy web applications, database activity monitoring for legacy databases, and runtime application self-protection where feasible. Virtual patching through network security devices can block exploitation attempts even when systems cannot be patched. For DORA compliance, document all legacy systems with justification for continued operation, risk assessments showing residual risk after compensating controls, and plans for eventual modernization or replacement. Regular testing verifies that compensating controls remain effective. The documentation must demonstrate that the institution has systematically addressed legacy system risks and that senior management has accepted residual risks. Develop modernization roadmaps with timelines for replacing or upgrading legacy systems, prioritized by risk and business impact. In the interim, consider containerization or virtualization to isolate legacy systems and facilitate eventual migration. For critical legacy systems, negotiate extended support agreements with vendors if possible. Regular reviews ensure legacy system inventory remains current and that modernization plans progress. The strategy should balance operational continuity with progressive risk reduction, demonstrating to regulators that the institution is actively managing legacy system risks rather than simply accepting them indefinitely.

Supply chain vulnerability management is critical under DORA given the regulation's emphasis on ICT third-party risk management. The approach must address vulnerabilities throughout the software supply chain, from development tools and libraries to third-party services and hardware. Begin with supply chain visibility: maintain comprehensive software bill of materials (SBOM) for all applications, documenting all components, dependencies, and their sources. This visibility enables rapid assessment when vulnerabilities are disclosed in supply chain components. For software development, implement secure development practices including dependency scanning in CI/CD pipelines, verification of component integrity through checksums and signatures, use of private artifact repositories with security scanning, and policies restricting use of components from untrusted sources. Monitor for supply chain attacks such as dependency confusion, typosquatting, and compromised packages. For third-party software and services, establish vendor security requirements including vulnerability disclosure policies, patch management SLAs, and security assessment rights. Vendor risk assessments should evaluate their vulnerability management practices, incident response capabilities, and security track record. Contractual agreements should include requirements for timely vulnerability notifications and remediation. For critical third-party services, consider alternative providers or contingency plans if vulnerabilities cannot be promptly addressed. Hardware supply chain security requires verification of component authenticity, assessment of firmware vulnerabilities, and secure supply chain logistics. For DORA compliance, demonstrate comprehensive oversight of ICT third-party risks including vulnerability management. This includes documentation of third-party security assessments, monitoring of third-party security incidents and vulnerabilities, and processes for responding to third-party vulnerabilities that affect your environment. Participate in information sharing communities to receive early warning of supply chain vulnerabilities. The supply chain vulnerability management program should include regular audits of third-party security practices, testing of third-party incident response coordination, and continuous monitoring of supply chain threat intelligence. As supply chain attacks become increasingly common, this comprehensive approach demonstrates the operational resilience that DORA requires.

Coordinating vulnerability management with regulatory requirements under DORA requires systematic alignment of technical security practices with compliance obligations and supervisory expectations. Begin by mapping vulnerability management processes to specific DORA requirements: Article

8 (ICT risk management framework), Article

9 (protection and prevention), Article

11 (testing of ICT systems), and Articles 28‑30 (ICT third-party risk management). Document how vulnerability management supports each requirement, providing evidence of compliance. Establish governance structures that ensure regulatory alignment: vulnerability management policies should explicitly reference DORA requirements, senior management and board oversight should include vulnerability management metrics and risk reporting, and internal audit should regularly assess DORA compliance of vulnerability management practices. For supervisory engagement, prepare comprehensive documentation demonstrating vulnerability management effectiveness: policies and procedures aligned with DORA requirements, metrics showing scanning coverage and remediation performance, evidence of continuous improvement initiatives, and documentation of major vulnerabilities and their remediation. Be prepared to explain risk-based prioritization decisions and risk acceptance for vulnerabilities that cannot be immediately remediated. When major vulnerabilities are identified, particularly those affecting critical systems or resulting from third-party services, assess whether they meet DORA's incident reporting thresholds. Establish clear criteria and processes for determining when vulnerability-related incidents must be reported to supervisors. For cross-border operations, coordinate with supervisors in multiple jurisdictions, ensuring vulnerability management practices meet requirements in all relevant markets. Participate in regulatory consultations and industry working groups to stay informed of evolving supervisory expectations. The coordination should include regular self-assessments against DORA requirements, with gaps addressed through remediation plans. For examinations and audits, maintain readily accessible evidence of vulnerability management activities, organized to demonstrate DORA compliance. The regulatory coordination framework should be regularly reviewed and updated as supervisory guidance evolves, ensuring vulnerability management practices remain aligned with regulatory expectations while supporting operational resilience.