NYDFS makes third-party policy a recurring control record

The policy begins with a defined relationship

The direct answer in 23 NYCRR Part 500 is that a covered entity's third-party service-provider policy is a maintained control record, not a completed questionnaire. Section 500.11 ties the policy to information systems and nonpublic information that a third party can access or hold. The regulation separately defines a third-party service provider as a non-affiliate, non-governmental person that provides services and maintains, processes, or is permitted access to nonpublic information through those services.

A defensible inventory should therefore preserve the contracting entity, provider legal entity, service, access path, information and system context, affiliate status, owner, source, review date, and scope decision. A broad vendor list can support discovery, but it should not silently assert that every supplier falls within the defined relationship or that an omitted relationship is out of scope.

Due diligence and minimum practices are different tests

Section 500.11 lists both minimum cybersecurity practices required for a provider to do business with the covered entity and due-diligence processes used to evaluate the adequacy of the provider's practices. The first is an organization's stated threshold; the second is the evidence-and-judgment process applied to a particular relationship. Combining them into a single score obscures who set the threshold, what evidence was reviewed, and what exception or acceptance decision followed.

The operating record should retain the requirement version, evidence requested and received, evidence period and scope, unresolved questions, reviewer, finding, remediation or exception, decision authority, and next review trigger. A provider statement, certification, assessment report, rating, or control response is evidence with limits. None independently proves that every relevant control is implemented or effective for the service in scope.

Periodic assessment makes the record time-bound

The regulation requires periodic assessment based on the risk a third party presents and the continued adequacy of its cybersecurity practices. That language makes both cadence and change triggers operational. A review marked complete should identify the risk basis, evidence cut-off, changed service or access, incident or control signal, open action, and the date or event that will trigger the next assessment.

Software should preserve prior assessments rather than replacing them with the latest result. Buyers can test whether a platform reconstructs what was known at onboarding, what changed, which evidence supported the review, who accepted a residual issue, and whether a reassessment was triggered. Continuous feeds may surface signals; qualified owners still determine relevance, materiality, response, and relationship disposition.

Contract guidance is connected but not interchangeable

Section 500.11 also calls for relevant guidelines for due diligence and contractual protections, including access controls, encryption, event notice, and representations and warranties where applicable. A contract clause, technical configuration, provider assertion, and tested control are separate objects. The platform should link them without converting one into proof of the others or inferring legal sufficiency from clause presence.

A buyer should ask for clause lineage, agreement and service scope, negotiated variance, obligation owner, notice path, evidence, review, renewal, and termination history. This analysis does not determine whether an organization is a covered entity, whether a provider falls within Section 500.11, whether any policy or contract is adequate, or whether Part 500 has been satisfied. Those decisions require the complete current regulation and appropriate cybersecurity, supervisory, procurement, and legal judgment.

What we will watch next

Third Party Current will watch for later primary-source evidence that changes the maintained company, capability, or standards record. The next useful evidence may include implementation documentation, release details, regulator findings, corrected methods, product packaging, customer-observable workflow, or a subsequent company statement. Until then, the dated source and its stated boundary remain attached to this analysis.