NYDFS Third-Party Service Provider Security Policy

NYDFS 23 NYCRR § 500.11 requires a covered entity to maintain written third-party service provider security policies and procedures that protect information systems and nonpublic information a third party can access or hold. To operationalize it quickly, inventory third parties, tier them by risk, set minimum security requirements, perform due diligence before onboarding, contract for security and incident notice, and reassess providers on a risk-based cadence. (23 NYCRR Part 500)

Key takeaways:

• You need a written, board/CCO-owned third-party security policy that covers the full lifecycle: intake, due diligence, contracting, monitoring, and offboarding. (23 NYCRR Part 500)
• The control center is “minimum cybersecurity practices” plus enforceable contract terms for access control and incident notification. (23 NYCRR Part 500)
• Evidence wins exams: a complete third-party inventory, risk ratings, due diligence records, executed security addenda, and monitoring results. (23 NYCRR Part 500)

“NYDFS third-party service provider security policy requirement” under 23 NYCRR § 500.11 is a documentation and operating model requirement, not a single checklist item. NYDFS expects you to prove that third parties with access to your information systems or nonpublic information are identified, risk-assessed, contractually bound to minimum security expectations, and monitored over time. (23 NYCRR Part 500)

For a CCO or GRC lead, the fastest path is to treat § 500.11 as a lifecycle program: you set the security bar (policy), you test providers against it (due diligence), you enforce it (contracting and access controls), and you keep testing (ongoing assessments). The practical trap is relying on procurement questionnaires without tying results to risk decisions, contract clauses, and real monitoring.

This page translates § 500.11 into an operator-ready playbook: who it applies to, what “written policies and procedures” must contain, the artifacts to retain, and the exam questions that commonly cause delays. References are limited to NYDFS’s Cybersecurity Regulation text and summary in 23 NYCRR Part 500. (23 NYCRR Part 500)

Regulatory text

Regulatory requirement (excerpt): “Each covered entity shall implement written policies and procedures designed to ensure the security of information systems and nonpublic information that are accessible to, or held by, third-party service providers.” (23 NYCRR Part 500)

Operator interpretation: NYDFS expects a governed third-party security program, captured in writing, that prevents unmanaged third-party access to systems and nonpublic information, and reduces the chance that a third party becomes your breach. The “written policies and procedures” must be usable: they need defined roles, decision points, minimum requirements, and a monitoring model that matches third-party risk. (23 NYCRR Part 500)

Plain-English interpretation (what the rule demands)

You must be able to answer “yes” to these exam-style statements and show evidence for each: (23 NYCRR Part 500)

1. We know every third party that can access our systems or handle our nonpublic information (including cloud/SaaS, MSPs, consultants, and data processors).
2. We classify third parties by risk (based on access type, data sensitivity, and operational criticality).
3. We have written minimum cybersecurity practices that apply to third parties by tier.
4. We perform due diligence before onboarding (or have a documented exception process) and decide based on risk.
5. Our contracts require security outcomes, including access controls and incident notification duties consistent with our policy.
6. We periodically reassess and take action when a third party no longer meets requirements.

Who it applies to (entity and operational context)

Covered entities: Any organization that is a “covered entity” under NYDFS Cybersecurity Regulation and uses third-party service providers that access information systems or nonpublic information. The provided applicability examples include financial institutions and state-registered advisers. (23 NYCRR Part 500)

Operational contexts that typically fall in-scope:

• SaaS platforms used for customer data, finance, HR, and CRM
• Hosting, cloud infrastructure, managed security providers, SOC services
• Core banking/fintech processors and data aggregators
• Contractors with VPN/admin access or database extracts
• Third parties receiving exported files containing nonpublic information (23 NYCRR Part 500)

What you actually need to do (step-by-step)

1) Build (or fix) the third-party inventory

• Pull sources: procurement/AP, contract repository, IAM, SSO app catalog, network/VPN lists, data-sharing logs, and business owner attestations.
• Define “third party” scope: include affiliates and subcontractors where they touch systems or nonpublic information, if your operating model routes access that way.
• Normalize entries: legal name, service description, business owner, systems touched, data types, access method, and whether they store/process/transmit nonpublic information. (23 NYCRR Part 500)

Output: a single inventory that you can defend in an exam.

2) Tier third parties by inherent risk (before controls)

Use a simple decision matrix and document it in the policy: (23 NYCRR Part 500)

Factor	Low	Medium	High
Data sensitivity	Public/internal	Confidential	Nonpublic information / regulated
Access depth	No system access	User access	Admin/API/VPN or privileged
Criticality	Non-critical	Important	Operationally critical service
Connectivity	None	Limited	Persistent integration

Rule of thumb: if a third party can materially impact confidentiality, integrity, or availability, treat it as higher risk and require stronger controls and reassessment. (23 NYCRR Part 500)

3) Define “minimum cybersecurity practices” by tier (write it down)

NYDFS expects your policy to state minimum requirements that match risk, not vague “appropriate security.” The 2023 amendments referenced in the provided summary highlight minimum cybersecurity practices, access controls, and incident notification by third parties. (23 NYCRR Part 500)

Minimum requirements you should codify (tailor by tier):

• Access control: least privilege, MFA for remote/admin access, joiner/mover/leaver timelines, logging.
• Data protection: encryption in transit; encryption at rest where the third party stores nonpublic information; secure disposal.
• Vulnerability and patching expectations: defined patch SLAs for critical vulnerabilities (your policy can set expectations even if you negotiate specifics per provider).
• Security incident notification: contractual duty to notify you of cybersecurity events affecting your data/systems, including timeframe language you can enforce.
• Subcontractor controls: requirement to flow down relevant obligations to subcontractors that touch your data. (23 NYCRR Part 500)

4) Implement due diligence that supports a risk decision

A workable due diligence model has three layers:

• Baseline intake: security questionnaire mapped to your minimum practices.
• Independent evidence: SOC reports, ISO certificates, penetration test summary, vulnerability management summary, incident response overview, or other artifacts the provider can share.
• Targeted deep-dive for high risk: architecture review, privileged access review, data flow mapping, and incident notification walk-through. (23 NYCRR Part 500)

Decision discipline: every review ends in one of four outcomes: approve, approve with conditions (tracked), reject, or accept risk with signed exception and compensating controls.

5) Contracting: make security enforceable

Put your minimum practices into a security addendum or master services agreement clauses, then require it for in-scope third parties. Focus on what auditors check first under § 500.11: (23 NYCRR Part 500)

• Scope of services and data handled
• Minimum security requirements (by reference to your policy or explicit clauses)
• Right to assess/audit (even if limited)
• Incident notification obligations and cooperation requirements
• Access control requirements for privileged access
• Subcontractor restrictions/flow-downs
• Data return/destruction on termination

6) Ongoing monitoring and periodic reassessment (risk-based)

Your policy should define:

• What triggers reassessment: material scope change, new data types, new integration, major incident, or adverse findings.
• What “periodic” means in practice: set a tier-based cadence internally (your choice) and record completion.
• Continuous signals: breach notifications, major control changes, failed attestations, and service disruption. (23 NYCRR Part 500)

7) Offboarding and access removal

Operationalize a clean exit:

• Confirm data return/destruction (attestation or certificate where feasible).
• Disable access (SSO, API keys, VPN, shared accounts).
• Capture lessons learned for future contracting and tiering. (23 NYCRR Part 500)

Required evidence and artifacts to retain

Keep artifacts in a format that a regulator or examiner can follow from policy → inventory → risk decision → contract → monitoring. (23 NYCRR Part 500)

Core artifacts:

• Third-party service provider security policy and procedures, versioned and approved
• Third-party inventory with risk tiers and owners
• Due diligence packages per third party (questionnaire, evidence received, review notes)
• Risk assessment results and approval records
• Exceptions register with rationale, compensating controls, and sign-off
• Executed contracts/security addenda with incident notification and access control language
• Monitoring logs: reassessment dates, findings, remediation tracking, termination evidence

Common exam/audit questions and hangups

Expect these lines of questioning under § 500.11: (23 NYCRR Part 500)

• “Show me your complete list of third-party service providers with system or nonpublic information access.”
• “How do you decide which third parties are high risk?”
• “Where are your minimum cybersecurity practices written, and how are they enforced in contracts?”
• “Show evidence of periodic assessment for your highest-risk third parties.”
• “How do you ensure third-party access is removed when work ends?”
• “How do you handle third-party incident notification and escalation?”

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Inventory built only from procurement. Fix: reconcile against SSO/app catalog and IAM logs so shadow SaaS is captured.
2. Mistake: One questionnaire for all third parties. Fix: tier first, then scale diligence depth to risk. (23 NYCRR Part 500)
3. Mistake: Due diligence findings don’t change decisions. Fix: require an explicit outcome (approve/condition/reject/exception) with sign-off.
4. Mistake: Contracts lack actionable security terms. Fix: standardize a security addendum with incident notification and access control requirements aligned to your policy. (23 NYCRR Part 500)
5. Mistake: No reassessment mechanism. Fix: build a calendar and triggers, and treat completion evidence as an audit artifact.

Enforcement context and risk implications

No public enforcement case sources were provided in the referenced source catalog for this requirement, so this page does not cite specific NYDFS actions. Operationally, § 500.11 is high-impact because third-party failures commonly create regulatory reporting, customer notification, and operational outage risk. Your strongest defense is provable governance: written policy, risk-based diligence, enforceable contracts, and monitoring records. (23 NYCRR Part 500)

Practical 30/60/90-day execution plan

First 30 days (stabilize and prove scope)

• Publish or refresh the written third-party security policy to explicitly cover identification, risk assessment, minimum practices, due diligence, and periodic assessment. (23 NYCRR Part 500)
• Build an authoritative inventory from procurement + SSO/IAM + business attestations.
• Stand up risk tiering and label every in-scope third party.
• Identify the top set of highest-risk third parties for immediate review (critical services, admin access, or nonpublic information storage).

Days 31–60 (make it enforceable)

• Implement tier-based due diligence playbooks and decision templates.
• Create security addendum language aligned to minimum practices, access controls, and incident notification.
• Start contracting updates for new third parties first, then renewals and high-risk incumbents. (23 NYCRR Part 500)
• Create an exceptions process with required compensating controls and sign-off.

Days 61–90 (operationalize monitoring)

• Establish reassessment cadence by tier and build a tracking mechanism.
• Add triggers for reassessment (scope change, new integration, incident, adverse findings).
• Run reassessments for the high-risk group and document outcomes and remediation tracking.
• Test offboarding: pick a recently terminated third party and confirm access removal plus data disposition evidence. (23 NYCRR Part 500)

Where Daydream fits: If you need to move fast without building a patchwork of spreadsheets, Daydream can centralize third-party inventory, tiering, due diligence workflows, exception approvals, and renewal/reassessment tracking so you can produce examiner-ready evidence on demand.

Frequently Asked Questions

Do we need a separate “NYDFS third-party security policy,” or can it be part of our vendor management policy?

It can be integrated, but it must explicitly address security of information systems and nonpublic information accessible to or held by third parties, including risk assessment, minimum cybersecurity practices, due diligence, and periodic assessment. The exam test is whether your written policy maps to § 500.11 expectations. (23 NYCRR Part 500)

Which third parties are in-scope under § 500.11?

Any third party service provider that can access your information systems or handle nonpublic information is in-scope. Include SaaS, managed service providers, consultants with VPN/admin access, and data processors. (23 NYCRR Part 500)

What evidence is strongest for “minimum cybersecurity practices”?

A written standard tied to your tiering model, plus contracts that incorporate those requirements, plus due diligence results showing the provider meets them or has tracked gaps. Standalone questionnaires without enforcement and follow-up tend to fall short. (23 NYCRR Part 500)

How do we handle providers that refuse to sign our security addendum?

Treat it as a risk decision. Document the refusal, assess impact versus your minimum requirements, add compensating controls where possible (access restrictions, encryption, tokenization, monitoring), and record a formal exception with sign-off. (23 NYCRR Part 500)

How often do we need to reassess third parties?

§ 500.11 requires periodic assessment based on risk, but the regulation text provided here does not set a fixed interval. Define a tier-based cadence in your policy and prove you follow it. (23 NYCRR Part 500)

Does § 500.11 require on-site audits of third parties?

The excerpt requires written policies and procedures designed to ensure security; it does not mandate a specific audit method in the provided text. Use a risk-based approach: request independent reports where available, perform deeper reviews for high-risk relationships, and document decisions. (23 NYCRR Part 500)