NYDFS Just Redefined Third-Party Cyber Risk. Here’s What Every Financial Institution Must Do Now.

Ramyar Daneshgar

Ramyar Daneshgar

— 9 min read

By Ramyar Daneshgar
Security Engineer | USC Viterbi School of Engineering

Disclaimer: This article is for educational purposes only and does not constitute legal advice.

1. Executive Summary

On October 21, 2025, the New York State Department of Financial Services (NYDFS) issued a new Industry Letter titled “Guidance on Managing Risks Related to Third-Party Service Providers” addressed to all entities regulated under the New York Cybersecurity Regulation, 23 NYCRR Part 500. (CCH Business)

The document does not create new rules. Instead, it clarifies how NYDFS expects “Covered Entities” to govern cybersecurity risk posed by Third-Party Service Providers (TPSPs) - including cloud providers, managed service providers, fintech platforms, file-transfer tools, and AI vendors - across the full lifecycle of the relationship. (CCH Business)

The message is blunt:

  • Reliance on TPSPs is now a core operational and cybersecurity risk, not a side issue.
  • Boards and Senior Officers remain fully accountable for TPSP risk; they cannot “outsource compliance” to vendors or affiliates. (CCH Business)
  • NYDFS examiners and enforcement teams are actively testing whether firms have real third-party risk programs, not just a vendor list and an annual questionnaire. (Alston & Bird Data Blog)

For financial institutions, insurers, and fintechs, this Guidance is a roadmap - and a shot across the bow. For cybersecurity attorneys and advisors, it is a ready-made framework for building or upgrading a third-party risk management (TPRM) program that can withstand both regulatory exams and post-breach lawsuits.

2. Regulatory Context: NYDFS Part 500 and Third-Party Risk

NYDFS’ Cybersecurity Regulation, 23 NYCRR Part 500, has required Covered Entities to maintain a risk-based cybersecurity program since 2017, with amendments adopted in 2023 that significantly raised expectations for governance, incident response, and monitoring. (Department of Financial Services)

Section 500.11 specifically requires each Covered Entity to implement written policies and procedures designed to ensure the security of information systems and Nonpublic Information (NPI) accessible to or held by third-party service providers. Those policies must be risk-based and address, where applicable: due diligence, minimum cybersecurity practices, multi-factor authentication, encryption, notice of cybersecurity events, and contractual protections. (Legal Information Institute)

The new 2025 Industry Letter does three important things:

  1. Re-states that Covered Entities cannot delegate compliance with Part 500 to an affiliate or TPSP. The entity remains on the hook for failures by its vendors. (CCH Business)
  2. Explains how NYDFS is testing TPSP programs in examinations and investigations.
  3. Provides a lifecycle framework for managing TPSPs: identification and due diligence, contracting, ongoing monitoring, and termination. (CCH Business)

For non-New York financial institutions and SaaS providers, this is still a de facto blueprint. NYDFS Part 500 has become a national benchmark, and federal and state regulators frequently align their expectations with its structure.

3. Governance: Boards, Senior Officers, and “Credible Challenge”

The Guidance underscores that Senior Governing Bodies (boards or equivalent) and Senior Officers must be actively engaged in cybersecurity risk management, including TPSP risk. (CCH Business)

NYDFS expects:

  • The board or Senior Governing Body to have enough understanding of cybersecurity to provide a “credible challenge” to management’s decisions. That term is borrowed from FFIEC guidance: directors must be engaged, ask hard questions, and exercise independent judgment - not rubber-stamp management’s TPSP strategy. (CCH Business)
  • A Senior Officer or Senior Governing Body to review and approve the covered entity’s cybersecurity policies at least annually, including TPSP policies. (CCH Business)
  • Clear documentation that TPSP risk is integrated into the enterprise risk assessment, reporting to the board, and incident-response planning.

For counsel, that translates into concrete governance advice:

  • Ensure the board receives TPSP-specific reporting: high-risk vendors, concentration risk, cross-border data flows, and major third-party incidents.
  • Confirm your cybersecurity policy approval resolutions explicitly reference TPSP risk, Part 500.11, and any Class A or exemption status.
  • Train board members on the legal consequences of weak vendor oversight, including enforcement actions where NYDFS has penalized firms for inadequate third-party controls. (Alston & Bird Data Blog)

4. Identification, Due Diligence, and Selection: Building a Risk-Based TPSP Portfolio

NYDFS expects Covered Entities to treat TPSP onboarding more like credit underwriting or ERM, and less like a checkbox procurement form. The Guidance emphasizes that TPSP due diligence must be risk-based and tailored to the services and NPI involved. (CCH Business)

4.1 Risk classification of TPSPs

Covered Entities should classify TPSPs based on the risk they pose, considering:

  • Type and extent of access to information systems and NPI.
  • Criticality of the service to operations.
  • Location and geopolitical/jurisdictional risk of the TPSP and its affiliates.
  • Whether the TPSP has privileged access - for example, managed IT services, cloud administrators, outsourced help desks, or claims administrators. (CCH Business)

High-risk TPSPs warrant intensive due diligence and monitoring; low-risk vendors may justify lighter controls. NYDFS explicitly recognizes this risk-tiering as consistent with a proportional, resource-sensitive program. (CCH Business)

4.2 Substantive due diligence expectations

The Guidance lists a non-exhaustive set of factors that Covered Entities should evaluate when onboarding a TPSP, including: (CCH Business)

  • The TPSP’s cybersecurity program and alignment to Part 500 and industry frameworks like NIST CSF 2.0, ISO 27001, or HITRUST. (NIST Publications)
  • Access controls and authentication, including use of unique, traceable accounts for personnel and the TPSP’s ability to support audit trails consistent with Part 500.6. (Legal Information Institute)
  • Data-handling practices, including segmentation, encryption, and data-flow mapping for NPI and other sensitive information.
  • Incident response and business continuity capabilities, including testing cadence. (CCH Business)
  • The TPSP’s own use of downstream providers (“fourth parties”), and how it selects, monitors, and contracts with them.
  • Whether the TPSP operates from or stores data in high-risk jurisdictions from a legal, political, or regulatory perspective.

NYDFS is realistic about constraints. For highly concentrated markets, legacy systems, or “too big to replace” vendors, the Guidance acknowledges that options can be limited. But it insists that firms:

  • Document those constraints,
  • Implement compensating controls (enhanced monitoring, segmentation, contractual triggers), and
  • Routinely reassess whether viable alternatives have emerged. (CCH Business)

This is where best-practice guidance from NIST SP 800-161 on cybersecurity supply chain risk management can supplement your analysis, especially for complex cloud and infrastructure stacks. (NIST Computer Security Resource Center)

5. Contracting: Hard-Wiring Cybersecurity Into TPSP Agreements

NYDFS goes further than many regulators by effectively sketching out a model clause set for TPSP agreements. While recognizing market realities and negotiation limits, the Guidance makes clear that Covered Entities are expected to pursue specific categories of protection. (CCH Business)

Key contracting domains include:

5.1 Access controls

TPSPs should be required to maintain access-controls policies and procedures - including multi-factor authentication - that meet or exceed the requirements in Sections 500.7 and 500.12. That includes controls for both the TPSP’s internal environment and any access into the Covered Entity’s systems. (Legal Information Institute)

For high-risk services, this often means:

  • Named, unique accounts tied to individual users.
  • Privilege minimization and time-bound access.
  • Logging and monitoring of privileged sessions.

5.2 Encryption of data in transit and at rest

Even where a Covered Entity qualifies for certain exemptions under Section 500.19, NYDFS strongly suggests requiring encryption of sensitive data, including NPI, in transit and at rest. (CCH Business)

In practice, this means:

  • Contractual obligations to use strong industry-standard cryptography for all NPI.
  • Documentation of encryption key-management responsibilities between the Covered Entity and TPSP.
  • Restrictions on unencrypted storage in backups, logs, or test environments.

5.3 Cybersecurity event notification

The Guidance expects contracts to impose prompt notification requirements for cybersecurity events that impact the Covered Entity’s systems or NPI, aligned with Part 500’s definitions of Cybersecurity Event and Cybersecurity Incident. (CCH Business)

Covered Entities should define, in writing:

  • What constitutes a reportable event for the TPSP.
  • Notification timelines (for example, “immediate” or within a specified number of hours).
  • Required content of the notice (indicators of compromise, affected systems, data categories, interim mitigations, and planned remediation).

5.4 Compliance representations and audit rights

Contracts should include representations and warranties that the TPSP will comply with applicable laws and regulations, including Part 500 where relevant. (CCH Business)

For critical vendors, firms should seek:

  • Rights to obtain SOC 2 or ISO 27001 reports.
  • Rights to conduct on-site assessments or remote audits, where feasible.
  • Notification obligations when the TPSP’s certifications lapse or material findings arise.

This aligns closely with third-party oversight expectations from FINRA’s Regulatory Notice 21-29 for broker-dealers, which encourages vendor self-assessments, certified reporting, and onsite reviews. (FINRA)

5.5 Data location, cross-border transfers, and subcontractors

NYDFS recommends-but does not mandate-contractual provisions requiring TPSPs to:

  • Disclose where data will be stored, processed, or accessed,
  • Obtain prior approval for cross-border transfers, particularly for high-risk jurisdictions, and
  • Disclose and restrict subcontractors that access the Covered Entity’s systems or NPI. (CCH Business)

This is where cyber/privacy counsel can add real value by:

  • Harmonizing TPSP contracts with GDPR/Schrems II transfer impact analysis, SCCs, or localization obligations.
  • Requiring data-flow diagrams or inventories as part of the contract exhibits.

5.6 Data-use restrictions, AI clauses, and exit obligations

The Guidance emphasizes:

  • Restrictions on how TPSPs may use, share, or monetize data.
  • Clear exit obligations for secure deletion, return, or migration of data at termination, plus certification of completion. (CCH Business)

Notably, NYDFS recommends considering clauses that address the TPSP’s use of Artificial Intelligence, including:

  • Whether Covered Entity data may be used to train AI models.
  • Whether that data may be disclosed to additional parties through generative features. (CCH Business)

Given the regulatory focus on model training data and cross-border processing, AI-specific restrictions are quickly becoming standard for financial regulators and exam teams.

6. Ongoing Monitoring and Oversight: The Program Cannot Stop at Signature

NYDFS is explicit: a robust TPSP program is not just onboarding and contracting. Covered Entities must implement ongoing, layered, risk-informed oversight to confirm that TPSPs continue to meet cybersecurity expectations over time. (CCH Business)

In practical terms, this means:

  • Periodic, risk-based reassessments of TPSPs, with higher frequency and depth for high-risk vendors.
  • Review of updated SOC 2 and ISO 27001 reports, penetration-testing summaries, and policy updates.
  • Confirmation of vulnerability management practices, patching timelines, and remediation of previously identified issues. (CCH Business)

NYDFS also signals that third-party risk should be fully integrated into incident response and business-continuity planning under Section 500.16. Covered Entities should have plans for:

  • Rapidly transitioning to alternative vendors or internal systems if a critical TPSP suffers a prolonged outage or ransomware event.
  • Running tabletop exercises that include TPSP failure scenarios. (CCH Business)

NIST’s CSF 2.0 and NIST SP 800-161 provide useful reference models for organizing these monitoring activities under “Detect,” “Respond,” and “Recover” functions and for treating TPSPs as part of the broader supply chain risk management universe. (NIST Computer Security Resource Center)

7. Termination and Offboarding: Closing Every Door

The Guidance devotes a full section to termination, reflecting how many breaches and unauthorized accesses originate from residual vendor connections that were never properly shut down.

NYDFS expects Covered Entities, upon ending a TPSP relationship, to: (CCH Business)

  • Disable all access the TPSP has to the Covered Entity’s information systems, including:
    • revoking SSO/OAuth tokens,
    • disabling service accounts and API keys, and
    • removing access to shared storage or collaboration environments.
  • Require secure return or destruction of NPI, including destruction of backups, snapshots, and cached datasets, with written certification.
  • Verify that all data subject to legal, regulatory, or litigation holds is preserved before destruction begins.
  • Conduct a final risk review to confirm obligations are fulfilled and to capture lessons learned for future TPSP engagements.

NYDFS also warns against “hidden” or unmonitored access paths - for example, diagnostic VPN tunnels, “temporary” admin accounts, or unmanaged integrations-that may have been created during the life of the relationship. Those should be identified and remediated before termination, not discovered in a post-incident forensics report.

8. Enforcement and Litigation Risk: What Happens If You Get This Wrong

NYDFS has already brought enforcement actions where weak third-party governance was a key failure, including cases involving improper oversight of service providers, inadequate encryption, and insufficient access controls. (Alston & Bird Data Blog)

Regulatory consequences can include:

  • Civil monetary penalties.
  • Mandatory remediation plans and independent consultants.
  • Public consent orders that signal to plaintiffs’ attorneys and class-action counsel that the firm’s TPRM program is a weak spot.

Plaintiff lawyers increasingly focus on vendor involvement in breaches - especially in incidents involving file-transfer software, cloud misconfigurations, or outsourced IT providers. The new NYDFS Guidance gives them a ready benchmark: if your TPSP program diverges from this lifecycle model, they will argue you fell below the standard of care.

For cybersecurity attorneys, this Guidance is therefore both:

  • A defensive tool: you can show alignment with a well-known regulatory framework when negotiating with regulators or defending breach litigation.
  • A proactive design document: you can help clients implement the program now, before an exam or incident spotlights deficiencies.

9. Practical Implementation Roadmap for Covered Entities (and Everyone Else)

Although the Guidance is addressed to NYDFS-regulated entities, the principles apply broadly to any regulated financial institution, fintech, or SaaS provider. A practical roadmap looks like this:

  1. Map your TPSP universe.
    • Build and maintain an inventory of all third-party service providers that have access to your systems or NPI, including cloud, MSPs, and AI vendors.
  2. Risk-tier your TPSPs.
    • Classify vendors based on access, data sensitivity, criticality, and jurisdictional risk. Use this classification to drive due-diligence depth and monitoring frequency. (Nelson Mullins Riley & Scarborough LLP)
  3. Align policies and standards to Part 500.11 and NIST CSF 2.0.
    • Explicitly map your TPSP policy to the elements outlined in Section 500.11 (due diligence, minimum controls, contractual provisions, monitoring, and termination). (Legal Information Institute)
  4. Harden your templates.
    • Update MSA, DPA, and security schedules to incorporate access control, encryption, event notification, AI usage restrictions, subcontractor controls, and exit obligations as described in the Guidance.
  5. Industrialize monitoring.
    • Design repeatable review cycles, integrate TPSP risk into your risk register, and escalate material vendor issues through your governance structure all the way to the board. (CCH Business)
  6. Integrate TPSPs into incident response and BCP.
    • Include your most critical TPSPs in tabletop exercises, playbooks, and recovery time objectives.
  7. Build termination playbooks.
    • For high-risk vendors, pre-define offboarding steps, responsibilities, and timelines so termination can be executed quickly and cleanly.

10. Conclusion

NYDFS’ 2025 Guidance on managing third-party service provider risks is not just another memo; it is a detailed statement of how regulators now expect financial institutions to structure their vendor ecosystem from end to end. It blends legal obligations under 23 NYCRR Part 500 with operational best practices drawn from NIST, FFIEC, FINRA, and modern supply-chain risk frameworks. (CCH Business)

For CybersecurityAttorney.com’s audience, the takeaway is simple:
If your client’s TPSP program does not look like the lifecycle NYDFS describes - risk-based onboarding, hardened contracts, continuous oversight, and disciplined offboarding - it is now out of step with a leading regulatory standard.

The upside is that NYDFS has effectively handed practitioners a playbook. The firms that move fastest to implement it will not only be better positioned for exams and enforcement - they will materially reduce the likelihood that a vendor failure turns into their next headline breach.

Read more