23 NYCRR Part 500 is the New York State Department of Financial Services' cybersecurity regulation for financial services companies - first adopted in March 2017 as the first regulation of its kind in the US. DFS finalized a Second Amendment that took effect November 1, 2023, adding governance, risk-assessment, and incident-reporting obligations on top of the original rule, with staggered transition periods that ran through November 2025 for different provisions and entity classes. A Covered Entity under the regulation is, in the rule's own words, "any person operating under or required to operate under a license, registration, charter, certificate, permit, accreditation or similar authorization under the Banking Law, the Insurance Law or the Financial Services Law" - which reaches banks, insurers, money transmitters, and a wide range of other DFS-licensed or -registered entities doing business in New York, regardless of where the company is headquartered.
A Third-Party Service Provider, per the regulation's own Section 500.1 definitions, is an entity that is not itself an affiliate or a government entity, that provides services to the covered entity, and that "maintains, processes or otherwise is permitted access to nonpublic information through its provision of services." That last clause is the scope test: a vendor with no access to nonpublic information and no foothold in the covered entity's information systems sits outside Section 500.11 entirely, while a cloud host, managed security provider, or SaaS vendor that touches either one is squarely inside it.
Section 500.11: what the third-party policy has to cover
Section 500.11 requires written policies and procedures, based on the covered entity's own risk assessment, addressing four things for third-party service providers generally, plus a further four contractual protections specifically for the providers with access to nonpublic information or the entity's systems:
| Section | What it requires |
|---|---|
| 500.11(a)(1) | Identification and risk assessment of third-party service providers. |
| 500.11(a)(2) | Minimum cybersecurity practices required of those providers as a condition of doing business. |
| 500.11(a)(3) | Due diligence processes to evaluate the adequacy of a provider's cybersecurity practices. |
| 500.11(a)(4) | Periodic assessment of providers, based on the risk they present and the continued adequacy of their practices. |
| 500.11(b)(1) | Contractual access controls, including multi-factor authentication under Section 500.12. |
| 500.11(b)(2) | Contractual encryption of nonpublic information in transit and at rest, per Section 500.15. |
| 500.11(b)(3) | Contractual notice to the covered entity in the event of a cybersecurity event affecting the provider. |
| 500.11(b)(4) | Representations and warranties on the provider's own cybersecurity policies and procedures. |
Read as a lifecycle, (a) is the risk-based side - who the providers are, what floor they have to clear, how that gets checked before and after signing - while (b) is the contract-drafting checklist that turns (a)'s conclusions into enforceable terms. A due-diligence process that never produces a signed 500.11(b)(3) notice clause has satisfied the assessment half of the rule while leaving the covered entity with no contractual right to hear about a vendor's own breach.
The exemption that does not reach 500.11
Section 500.19 gives a limited exemption to covered entities that fall below any one of three thresholds: fewer than 20 employees and independent contractors (counting affiliates), less than $7,500,000 in gross annual revenue in each of the last three fiscal years, or less than $15,000,000 in year-end total assets. Qualifying entities are excused from a specific, named list of sections - 500.4, 500.5, 500.6, 500.8, 500.10, 500.14(a)(1)-(2) and (b), 500.15, and 500.16. Section 500.11 is not on that list. A covered entity thin enough to qualify for the small-business exemption still has to maintain a written third-party service provider policy, still has to do due diligence on its vendors, and still has to get the Section 500.11(b) contractual protections into its vendor agreements - the exemption trims the internal-control burden, not the vendor-oversight one.
Where 500.11 meets the 72-hour breach clock
Section 500.17(a) requires a covered entity to notify the DFS superintendent "as promptly as possible but in no event later than 72 hours after determining that a cybersecurity incident has occurred" - and the trigger is an incident "at the covered entity, its affiliates, or a third-party service provider." A covered entity's own 72-hour clock can therefore start running because of something that happened inside a vendor's environment, not its own. That is exactly the gap Section 500.11(b)(3)'s contractual notice requirement exists to close: without a vendor obligated to tell the covered entity promptly, the entity cannot make its own regulatory deadline for an incident it may not learn about for weeks. A policy that satisfies 500.11(a) on paper but has no fast, contractually-backed notice path from its providers is not actually ready for 500.17.
Turning Section 500.11 into TPRM actions
- Scope the 500.11 inventory to access, not vendor category. The regulation's own test is whether a provider can access nonpublic information or the entity's systems - not whether it looks like an "IT vendor." See vendor tiering.
- Do not rely on the 500.19 exemption to skip vendor oversight. Confirm the written policy, the due-diligence step, and the four 500.11(b) contract clauses are in place even for a covered entity that clears the small-business thresholds on everything else.
- Get the 500.11(b)(3) notice clause into contracts with an actual time bound, not open-ended "prompt notice" language - the covered entity's own 500.17(a) clock does not pause to wait for a vendor that takes its time.
- Make 500.11(a)(4) periodic assessment continuous where it can be, since a provider's risk profile between scheduled reviews can change well before the next one is due. See continuous vendor monitoring.
- Treat the 500.11(a)(3) due-diligence step as a pre-contract gate, evaluated with evidence about the provider's actual practices rather than a self-reported claim of compliance.
Where this sits among TPRM platforms
Turning 500.11(a) and (b) into a durable policy, a contract-clause library, and a due-diligence record is governance workflow of the kind OneTrust and ProcessUnity are built to run, typically alongside a SIG- or CAIQ-style questionnaire (see the Shared Assessments SIG) as the due-diligence artifact. What that workflow does not answer on its own is whether a provider's environment still matches what its last assessment described, or whether a live incident at that provider is unfolding right now - the visibility a covered entity needs to make its own 500.17(a) deadline. Security-rating vendors like BitSight, SecurityScorecard, and UpGuard contribute externally observed signal toward that gap (see evidence-based risk scoring); Rescana's role is pairing that continuous monitoring with automated evidence collection so a 500.11(a)(4) review reflects current signal rather than a document that was accurate on the day it was collected.
Frequently asked questions
What does NYDFS 23 NYCRR Part 500 require for third-party service providers?
Section 500.11 requires a covered entity to maintain written policies and procedures, based on its own risk assessment, covering the identification and risk assessment of third-party service providers, the minimum cybersecurity practices required of them, the due-diligence process used to evaluate their practices, and periodic reassessment based on the risk they present. For providers with access to nonpublic information or the entity's systems, the policy must also require specific contractual protections: access controls including multi-factor authentication, encryption of nonpublic information in transit and at rest, contractual notice of a cybersecurity event affecting the provider, and representations and warranties about the provider's own security practices.
What must a Section 500.11 third-party service provider policy include?
At minimum, the four risk-management elements in Section 500.11(a) - provider identification and risk assessment, minimum required cybersecurity practices, a due-diligence process, and periodic reassessment - and, for providers with relevant access, the four contractual protections in Section 500.11(b): multi-factor authentication and access controls, encryption of nonpublic information, a contractual notice obligation for cybersecurity events at the provider, and representations and warranties covering the provider's own cybersecurity policies and procedures.
Are small companies exempt from NYDFS Section 500.11's third-party requirements?
No. Section 500.19 gives covered entities that fall under specific employee, revenue, or asset thresholds a limited exemption from a named list of sections - 500.4, 500.5, 500.6, 500.8, 500.10, 500.14(a)(1)-(2) and (b), 500.15, and 500.16. Section 500.11 is not on that list, so even a covered entity that qualifies for the small-business exemption still has to maintain a written third-party service provider policy, perform due diligence on its providers, and include the Section 500.11(b) contractual protections in its vendor agreements.
Does the NYDFS 72-hour breach notification requirement cover a cybersecurity incident at a vendor?
Yes. Section 500.17(a) requires a covered entity to notify the DFS superintendent as promptly as possible but no later than 72 hours after determining that a cybersecurity incident has occurred, and the rule's trigger explicitly includes an incident at the covered entity, its affiliates, or a third-party service provider - not only an incident inside the covered entity's own environment. That is why Section 500.11(b)(3)'s contractual requirement for a provider to notify the covered entity of its own cybersecurity events matters: without it, the covered entity has no reliable way to learn about a vendor incident quickly enough to meet its own 72-hour deadline.