The New York Department of Financial Services adopted 23 NYCRR Part 500 in 2017 as the first state-level cybersecurity regulation with prescriptive controls aimed at financial institutions. The rule applies to "covered entities" — any person operating under a license, registration, charter, certificate, permit, accreditation or similar authorization under the New York banking, insurance, or financial services laws. In practice it sweeps in banks chartered or licensed in New York, insurance companies and producers, mortgage servicers, money transmitters, virtual currency licensees, and a long list of other regulated entities. The November 1, 2023 second amendment (effective with staged compliance dates running through November 2024 for most provisions and November 2025 for Section 500.7 governance and Section 500.9 risk assessment provisions) is the most substantive revision since adoption, and the parts of the amendment that touch third-party software risk are the focus of this analysis.
The amendments reorganized the rule around a tier of "Class A companies" (defined by size thresholds — at least $20 million in gross annual revenue from New York operations averaged over the last two fiscal years and either more than 2,000 employees averaged over the last two fiscal years or more than $1 billion in gross annual revenue including affiliates), required CEO and CISO certifications under penalty of perjury, and added or tightened a number of specific control requirements. For software supply chain purposes, the most important additions are the strengthened third-party service provider requirements in Section 500.11, the expanded vulnerability management and patch management requirements in Section 500.5 and 500.7, and the more rigorous risk assessment requirements in Section 500.9.
What did the November 2023 amendments actually change for third-party software risk?
Section 500.11 (third party service provider security policy) was tightened in several ways. Covered entities now have to base their third-party policies on the covered entity's risk assessment, which is itself updated annually or upon material changes to the covered entity's business or technology. The minimum policy elements include identification and risk assessment of third-party service providers, minimum cybersecurity practices required to be met by third-party service providers in order to do business with the covered entity, due diligence processes used to evaluate the adequacy of cybersecurity practices, and periodic assessment of the continued adequacy of third-party cybersecurity practices.
The amendment also requires that the third-party policies include, where appropriate, encryption requirements, multi-factor authentication requirements, notice requirements following any cybersecurity event affecting the covered entity's information systems or nonpublic information, and representations and warranties from the third party. The "where appropriate" qualifier gives covered entities discretion, but the discretion is bounded by the risk assessment — if the risk assessment identifies a category of third party as high-risk and the policy does not impose MFA on that category, the covered entity has a problem.
Section 500.9 (risk assessment) was expanded to require annual updating and to require explicit assessment of risks from third-party service providers and from supply-chain compromises. The amendment's preamble explicitly cites recent supply-chain incidents as a motivator for the expanded scope. Covered entities now have to document how their risk assessment process produces the inputs that drive the third-party policy under 500.11, the access controls under 500.7, and the vulnerability management under 500.5.
How is "third-party service provider" being interpreted in software-vendor scenarios?
The defined term "third party service provider" covers any person that provides services to the covered entity and maintains, processes or otherwise is permitted access to nonpublic information through its provision of services to the covered entity. The expansive "permitted access" language sweeps in most SaaS vendors, most managed-service providers, and a meaningful fraction of on-premises software vendors who maintain support access to the covered entity's deployment. The amendment did not narrow this definition.
The practical implication for software-supply-chain governance is that covered entities have to maintain a current inventory of third-party software whose vendors fall within the definition, classify those vendors by risk based on the type and volume of nonpublic information accessible, and apply the appropriate cluster of controls (MFA, encryption, notification, representations and warranties) to each. Covered entities have largely settled on a tiered model in which the most critical third parties (core banking software vendors, payment processors, KYC/AML data providers) sit in a Tier 1 with the most rigorous due diligence and ongoing assessment, mid-tier vendors get a streamlined process with annual attestation, and the long tail gets a baseline questionnaire and a contractual flow-down of minimum security requirements.
The amendment's notification provision has produced operational headaches. Section 500.1(g) defines a "cybersecurity event" broadly enough that covered entities receive notifications from third parties for incidents that may or may not affect their nonpublic information, and the resulting flow of inbound notifications has been hard to triage. Mature programs have invested in workflows that ingest third-party incident notifications, map them against the covered entity's actual use of the third party, and produce a defensible record of the determination of whether the incident affected covered entity systems or nonpublic information.
How are covered entities handling the CISO certification?
The amendment requires the CISO and the chief executive officer (or equivalent) to annually certify compliance with the regulation, with the certification submitted to DFS. The certification can take one of two forms: a certification of material compliance, or an acknowledgment of areas requiring material improvement with a remediation plan. The "acknowledgment" alternative is the meaningful change from the prior single-CISO certification, because it gives covered entities a path to honesty about gaps without immediately exposing themselves to enforcement. DFS has signaled, both in formal guidance and informally through speeches, that the agency wants to see the acknowledgment path used when warranted and considers a defensible acknowledgment with a credible remediation plan more favorable than a certification of compliance that turns out to be inaccurate.
For software supply chain specifically, the CISO certification has put pressure on programs to have a clear-eyed view of third-party risk exposure. A CISO who certifies material compliance and then experiences a supply chain incident where it turns out the covered entity had no inventory of the affected software and no documented risk assessment for the affected vendor is in a difficult position with DFS. The Eisai matter (settled in 2024 under earlier Part 500 enforcement authority) and the more recent enforcement settlements in 2025 have emphasized the agency's willingness to look at the gap between certification and operational reality.
The CEO certification adds a layer of executive accountability that has changed how the rule is implemented at covered entities. The CEO does not have to understand the regulation in detail, but the CEO does have to rely on someone who does, and the rule has implicitly forced a more formal CISO-to-CEO reporting relationship at many institutions. Quarterly cybersecurity briefings to the CEO and to a designated board committee are now baseline practice.
How does Part 500 interact with federal banking regulators in 2026?
Covered entities supervised by federal banking regulators (the OCC for national banks, the Federal Reserve for state member banks and bank holding companies, the FDIC for state nonmember banks) face a federal-state compliance overlay. The federal interagency Computer Security Incident Notification Rule (effective May 2022) requires notification of computer-security incidents to the primary federal regulator within 36 hours of determining that a "notification incident" has occurred. Part 500 has its own notification requirements running to DFS. Covered entities have to satisfy both clocks, and the two notification triggers are not identically defined.
The federal interagency Third-Party Risk Management guidance (issued June 2023) overlaps substantially with Part 500's 500.11 third-party requirements, and most large covered entities run a single third-party risk program designed to satisfy both. The federal guidance is principles-based while Part 500 is prescriptive, so the operative compliance floor for software-vendor risk is typically set by Part 500 even where the federal guidance would tolerate more discretion.
The result is that for large covered entities, Part 500 is the de facto national-floor regulation for software-vendor risk management, with federal guidance and other state regulations (Texas, California, Massachusetts) layered on top. The 2026 reality is that covered entities maintain a single third-party risk dataset and a single SBOM-backed software inventory that supports certification under Part 500 and contemporaneous notification under federal banking law, without maintaining separate compliance silos.
How Safeguard Helps
Safeguard gives Part 500 covered entities the production evidence base the rule increasingly assumes is in place. The platform maintains a continuously updated inventory of every third-party software component and SaaS dependency, generates SBOMs that serve as the canonical compliance artifact your annual risk assessment and CISO certification can rest on, and ingests third-party security advisories and incident notifications to produce the defensible record DFS examiners ask for. Griffin AI maps third-party vendor responses to the 500.11 control families, surfaces gaps where vendor practices fall short of your risk-assessment-driven minimums, and drafts the contemporaneous documentation that supports CISO and CEO certifications. Policy gates in Safeguard enforce minimum cybersecurity practices for third parties at the point of integration, generate audit-ready evidence packages, and integrate with the federal interagency 36-hour notification workflow so covered entities run a single incident clock rather than reconciling parallel ones. TPRM workflows collect and refresh attestations from your third-party software vendors on the cycle DFS expects, with evidence linked to the underlying SBOM and vulnerability state.