Vulnerability Management for Financial Services: Proving Remediation to DORA and NYDFS Examiners

Introduction

The hard part of vulnerability management for financial services is no longer finding flaws. It’s proving what happened next. When a DORA or NYDFS examiner sits down with your remediation records, they want to trace a single thread: how you discovered the vulnerability, how you decided what to fix first, who owned it, when it was fixed, and how you know the fix held. Most teams can’t produce that thread without rebuilding it from scratch before each exam cycle.

The average cost of a financial services breach reached USD 5.56 million in 2025 (IBM 2025), and regulators are tightening the screws. The EU’s Digital Operational Resilience Act and the New York State Department of Financial Services Part 500 regulation now demand documented, risk-prioritized remediation with verifiable outcomes. Yet 81.6 percent of security respondents say managing findings across disconnected tools significantly affects their ability to prioritize and remediate risks (Purple Book Community 2026). Tools that were meant to make finding flaws easier have made proving fixes harder.

This article walks through what DORA and NYDFS actually expect, why those expectations expose the gaps in most remediation programs, and how a unified approach makes examiner-ready evidence a byproduct of daily operations rather than a pre-audit project.

What DORA and NYDFS Expect from Remediation Programs

Both frameworks are risk-based, not prescriptive. Neither expects you to fix everything. Both expect you to make defensible risk decisions and keep records that prove you did.

DORA: Documented, Verified Vulnerability Management

Under DORA’s Delegated Regulation (EU) 2024/1774, Article 10 requires financial entities to document vulnerability management procedures, scan assets supporting critical or important functions at least weekly, prioritize findings by risk, and verify that remediation actually resolved the vulnerability. The regulation also requires recording each vulnerability and its resolution. This isn’t a suggestion to scan more. It’s a mandate to maintain a continuous, auditable record linking each finding to a risk decision and a verified fix.

NYDFS Part 500: Timely, Risk-Prioritized Remediation

Section 500.5 of the New York cybersecurity regulation requires automated scanning at a risk-based frequency and timely remediation prioritized by the risk each vulnerability poses. Section 500.13 requires maintaining an asset inventory. Each year by April 15, covered entities must file either a certification of material compliance or an acknowledgment of noncompliance. The filing must be signed by the entity’s highest-ranking executive and CISO, or the designated senior officer responsible for cybersecurity if there is no CISO. NYDFS also requires covered entities to retain the records supporting each annual certification or acknowledgment for five years (Section 500.17), which means the remediation trail you build today needs to survive audit scrutiny well beyond the current cycle.

The Common Thread

Neither DORA nor NYDFS expects you to fix every vulnerability. Both expect you to make defensible risk decisions and document them. The difference between a program that passes an exam and one that draws findings is often not the number of patches applied. It’s whether the examiner can trace each finding to a decision, an owner, a timeline, and a verification.

Program area	DORA expectation (RTS 2024/1774, Art. 10)	NYDFS expectation (23 NYCRR 500)	Evidence to retain
Vulnerability discovery	Automated vulnerability scanning; at least weekly for ICT assets supporting critical or important functions	Automated scans at a risk-based frequency, manual review of systems not covered, and annual penetration testing (500.5(a)); asset inventory (500.13)	Scan schedules, scan coverage by asset, and the asset inventory
Risk prioritization	Prioritize patches and mitigations based on vulnerability criticality, asset classification, and risk profile	Remediation prioritized by the risk each vulnerability poses (500.5(c))	Risk score and documented rationale for each finding
Remediation timelines	Set deadlines for patches and updates, with escalation procedures if deadlines cannot be met	Timely remediation based on risk (500.5(c))	Risk-tiered SLA, owner, fix date, and escalation history
Exception handling	No separate exception process; missed patch deadlines follow documented escalation procedures	Risk assessment procedures must describe how identified risks will be mitigated or accepted (500.9(b)(3)).	Exception owner, rationale, compensating controls, approval, and expiry date
Verification	Monitor and verify the remediation of vulnerabilities	No explicit verification step; the annual certification must be based on sufficient data and documentation (500.17(b))	Re-scan or validation result and date for each fix
Documentation and reporting	Record detected vulnerabilities and monitor their resolution under documented procedures	Annual certification or acknowledgment by April 15; supporting records retained for five years (500.17(b))	End-to-end record per finding, plus board and audit reports

Why Remediation Is Hard to Prove

If the requirements are clear, why do so many teams struggle to meet them? The failure points show up during an examiner’s sample testing, and they reveal structural problems in how remediation work is recorded.

Many Scanners, No Single Record

Most financial institutions run multiple scanners across legacy cores, cloud infrastructure, and acquired environments through mergers. Each tool scores risk differently, uses its own severity scale, and maintains its own findings database. When an examiner asks to see the remediation history for a specific asset, the answer requires correlating across three or four tools that don’t talk to each other. The 82 percent of teams who say disconnected tools hurt prioritization (Purple Book Community 2026) are describing the same problem from the operational side. The examiner sees it as missing evidence.

A Closed Ticket Is Not Reduced Risk

Closing a ticket in a scanner or ITSM tool doesn’t prove the vulnerability was resolved. It proves someone clicked a button. An examiner wants verification, which means re-scanning, confirming the finding is gone, and recording the result. Most teams skip this step because their tools don’t automate it. The rationale for why a finding was closed, deferred, or accepted lives in someone’s head or in a chat thread that won’t survive an audit cycle.

Ownership Gaps and Silent Risk Acceptance

Findings on unowned or shared infrastructure are the ones most likely to miss remediation timelines. Without explicit ownership, no one is accountable. When a deadline slips, the fix doesn’t get escalated. It gets silently deferred, and a deferred fix without documented rationale becomes an undocumented risk acceptance. Examiners treat undocumented exceptions as failures.

Building Examiner-Ready Vulnerability Management

The solution isn’t another scanner. It’s a unified program that makes the evidence examiners want a byproduct of how you already work. ArmorCode’s agentic control plane for Unified Exposure Management provides the structure, grounded in the Context Risk Graph that connects every finding to its business context, owner, and remediation status.

One Unbiased Backlog

Consolidate findings from every scanner into a single, normalized backlog. Each finding carries its source tool, severity, and raw score, but the prioritization layer applies consistent business context across all of them. This eliminates the vendor-specific bias that comes from trusting one scanner’s severity scale over another’s. As Kiran Sharma, Cybersecurity and Privacy Director at Snap Finance, put it: “If you’re using a scanner that also claims to provide ASPM, it’s often biased towards its own results, limiting visibility into other tools in your security program. With ArmorCode, being tool-agnostic and vendor-neutral, I get an unbiased view, allowing me to accurately prioritize across all my tools.” Snap Finance used this approach to cut 63,000 findings down to 90 actionable tickets (ArmorCode).

Prioritization You Can Explain

Adaptive Risk Scoring combines business context, AATI, EPSS, CISA KEV, and reachability data to produce a score that reflects real-world risk, not just CVSS severity. When an examiner asks why you fixed finding A before finding B, the answer isn’t a gut call. It’s a documented calculation. The Anya Agents Risk Analyzer Agent explains the reasoning behind each score, grounded in the Context Risk Graph that links findings to assets, owners, and business impact. We have written about this in more detail: Vulnerability Risk Scoring: Why CVSS Alone Is Not Enough.

SLAs and Governed Exceptions

Risk-tiered SLAs set the clock for each finding based on its priority, with automatic ownership routing and escalation when deadlines approach. Exceptions aren’t silent. Every deferral requires an owner, a documented rationale, and an expiry date. When an examiner asks about a finding that wasn’t fixed within the SLA, the exception record shows who approved it, why, and when it expires. That’s the difference between governed risk acceptance and an audit finding.

The Decision Trail: Evidence as a Byproduct of the Work

The Decision Trail solves the evidence problem. Instead of rebuilding evidence before each exam, the program produces it continuously. Every finding carries a complete record: what it is, what business context it affects, what risk decision was made, who owns it, what SLA applies, what fix was applied, whether there’s an exception, and whether the fix was verified. NYDFS requires covered entities to retain the records and data supporting their annual certification or acknowledgment for five years. This includes remedial efforts, remediation plans, and implementation timelines. This record needs to be durable and queryable, not a spreadsheet that someone updates manually.

What a Defensible Record Contains

A single finding’s record might look like this: a critical, known-exploited vulnerability in a third-party component of a customer-facing application, scored using EPSS probability and CISA KEV inclusion. The risk decision: fix within 7 days based on active exploitation risk. The owner: the application team lead. The SLA: critical tier, 7-day remediation window. The fix: vendor patch tested and deployed. The verification: re-scan confirmed the finding is gone. No exception. This entire record was produced during normal operations, not assembled for an exam.

From Exam Project to On-Demand Report

When the record exists for every finding, producing an examiner-ready report becomes a query, not a project. Closed-loop verification confirms every fix. Persona-based reporting lets you generate a board-level summary, a detailed audit trail, or a regulator-specific view from the same data. Snap Finance’s transformation from 63,000 findings to 90 tickets (ArmorCode) is the same pattern: when the backlog is unified and prioritized with context, the evidence is already there when someone asks for it. That is the idea behind how ArmorCode helps teams accelerate compliance. Across its platform, ArmorCode reports alert volume cut by up to 90 percent, security tech debt burn-down of 80 percent or more, and remediation accelerated by 97 percent, from 240 days to hours (ArmorCode).

How ArmorCode Supports Vulnerability Management for Financial Services

ArmorCode’s platform operates as the agentic control plane for Unified Exposure Management, built on the Context Risk Graph and powered by Anya Agents that are bounded, human-led, and grounded in real business context. Here is how the capabilities map to what examiners need.

Unified Finding Aggregation

ArmorCode integrates with 400 security tools and has processed 400 billion findings, aggregating them into a single normalized backlog. Each finding retains its source, severity, and context, but prioritization applies consistent business logic across all of them. This eliminates the multi-tool correlation problem that makes examiner evidence so hard to produce.

Adaptive Risk Scoring with Anya Agents

The Risk Analyzer Agent within the Anya Agents framework explains why each finding received its score, drawing on the Context Risk Graph for business context. When an examiner asks for the rationale behind a prioritization decision, the answer is documented and reproducible, not reconstructed from memory.

SLA Tracking and Exception Governance

Risk-tiered SLAs with automatic ownership routing and escalation ensure findings don’t slip through gaps. Exceptions require documentation, ownership, and expiry dates. This supports the documented, risk-based remediation timelines that NYDFS and DORA expect.

The Decision Trail and Audit-Ready Reporting

Every finding carries a complete decision record produced during daily operations. Persona-based reporting generates examiner-ready views on demand. The Decision Trail helps keep remediation records searchable and available to support NYDFS annual filings. Covered entities must retain the records and data supporting those filings for five years.     .

Conclusion

Examiners don’t want scan counts. They want a defensible record that links each finding to a risk decision, a fix, and a verification. The teams that pass DORA and NYDFS scrutiny aren’t the ones with the most patches. They’re the ones whose daily operations produce the evidence examiners need, without a pre-audit scramble.

A unified vulnerability management program makes that record a byproduct of the work itself. When findings are consolidated into one backlog, prioritized with explainable business context, tracked against risk-tiered SLAs, and verified through closed-loop remediation, the Decision Trail builds itself. The next time an examiner sits down with your records, the question isn’t whether you can produce them. It’s how fast you can run the query.

See how ArmorCode turns remediation evidence into a byproduct of your daily vulnerability management work. Request a demo to see the Decision Trail and SLA tracking built for examiner-ready reporting.

Key Takeaways

• DORA and NYDFS examiners may review scan coverage, but they also need evidence of how you prioritized findings, remediated vulnerabilities, and verified the results.     
• Most teams rebuild remediation evidence before each exam because findings live in separate scanners with no shared record of decisions, ownership, or verification.
• A unified vulnerability management program turns the evidence examiners want into a byproduct of daily work, not a pre-audit scramble.
• Snap Finance narrowed 63,000 findings from one cloud security tool to 90 actionable tickets using ArmorCode.