Financial services has the most mature third-party risk regime of any industry, and it still gets caught flat-footed when a critical vendor goes down. The MOVEit campaign in 2023 and the CrowdStrike outage in July 2024 both reached deep into bank and broker-dealer operations through vendors that had passed every TPRM checklist. The 2026 baseline has to account for the fact that paper assessments do not survive a real incident.
This post is about the controls that actually hold up under regulator scrutiny and during a live event. We focus on DORA, the NYDFS Part 500 amendments, and the OCC's revised third-party risk guidance, with attention to where the regulatory text and the operational reality diverge.
What does DORA actually require for ICT third-party risk?
DORA's ICT third-party risk requirements, which became fully enforceable in January 2025, are more prescriptive than most US-based financial institutions are used to. The regulation requires a maintained register of all ICT third-party arrangements, with explicit classification of critical providers, and contractual provisions that include audit rights, exit strategies, and defined service levels. The European Supervisory Authorities have been clear in their early supervisory letters that they expect the register to be live, queryable, and tied to incident reporting workflows.
The harder requirement is the concentration risk assessment. DORA expects financial entities to map their dependencies through subcontractors, not just direct vendors, and to identify where multiple critical functions rely on a single underlying provider. In practice this means knowing that your trading platform vendor, your CRM vendor, and your data warehouse vendor all run on the same cloud region, and modeling what happens when that region degrades. Most institutions are still building this view in 2026, and the regulators know it.
How have the NYDFS Part 500 amendments changed expectations?
The NYDFS Part 500 amendments that took effect through 2024 raised the bar substantially on vulnerability management, asset inventory, and third-party service provider risk. Covered entities must now maintain a vulnerability management program that covers third-party software and includes documented prioritization criteria, which is harder than it sounds when the average covered entity has thousands of third-party SaaS arrangements with no centralized inventory.
The 72-hour notification requirement for cybersecurity events, with extended reporting for ransomware payments, has changed the operational rhythm around incidents. Institutions that relied on quarterly TPRM reviews quickly discovered they had no way to determine within 72 hours whether a given vendor's incident affected their environment. The 2026 baseline includes maintaining live vendor inventories with mapped data flows, SBOMs for in-scope software, and pre-built incident query workflows. The institutions that handled the 2024 incidents well had these in place. Most did not.
What about the OCC's revised third-party risk guidance?
The OCC, FDIC, and Federal Reserve issued joint third-party risk management guidance in June 2023, and the supervisory letters since then have made clear that examiners expect to see lifecycle controls, not just onboarding controls. A meaningful 2026 TPRM program covers ongoing monitoring, contract change management, and termination procedures with the same rigor as initial due diligence. Most institutions are still under-resourced on the ongoing-monitoring side, where the actual risk lives.
The guidance is risk-tiered, but the supervisory practice has been to push back when institutions classify too many vendors as low-risk. A SaaS provider that handles customer PII or processes transactions is almost always going to be in scope for enhanced diligence regardless of contract size. Examiners increasingly ask to see the criteria used to tier vendors and the evidence that the tiering reflects actual data flows, not contract dollar value.
Which threats are actually hitting financial institutions in 2026?
The dominant threat in 2026 is still supply chain compromise of widely-deployed financial services SaaS, with credential theft and lateral movement from there. The 2024 Snowflake-customer credential incidents showed how a single SaaS configuration weakness, combined with weak customer-side controls, can produce mass breaches across the industry. The 2025 pattern continued with several incidents at trading and reconciliation platform vendors where attackers exfiltrated customer data through compromised support tooling.
The other meaningful threat is targeted attacks on the open-source dependencies of in-house quant and analytics platforms. Several institutions reported finding malicious packages in their Python ML environments in 2024 and 2025, often introduced through typosquats or compromised maintainer accounts. These attacks do not generate the headlines that ransomware does, but they routinely produce material data exfiltration before they are caught, and they are squarely in scope under DORA Article 28 even though the affected components are open source.
What does a defensible vendor exit strategy look like?
DORA explicitly requires documented exit strategies for critical third-party arrangements, and the early supervisory feedback has been that boilerplate exit clauses are not sufficient. A defensible 2026 exit strategy includes a technical migration plan with named target systems, a data extraction process that has been tested, and an estimated transition timeline that reflects actual implementation effort. Institutions that have run live exit tests, even for a single critical vendor, are dramatically better positioned than those that have only documented the strategy on paper.
The practical question is what triggers an exit. Most contracts have ambiguous termination-for-convenience clauses and unclear thresholds for triggering a regulatory exit. The 2026 baseline includes defined service-level breach thresholds, defined security incident thresholds, and a board-level decision process that can move in days rather than months. Several institutions in 2025 found themselves trapped in vendor contracts after security incidents because the exit triggers were too vague to invoke.
How Safeguard Helps
Safeguard maintains a live inventory of every software supplier in your portfolio, mapped to the regulatory frameworks that apply, with concentration risk visualization that surfaces where multiple critical functions share an underlying dependency. Griffin AI correlates vendor incidents with your specific exposure inside the 72-hour reporting window, replacing the manual phone-tree workflow most institutions still run. SBOM ingestion with reachability analysis filters CVE noise to the issues that actually affect your deployed code, and TPRM scoring captures vendor response history. Policy gates enforce SBOM delivery and severity thresholds at build time for in-house systems, including the Python ML environments where supply chain compromise has been most active.