NYDFS Part 500 AI Compliance Checklist for Covered Entities

Section 500.14(a)(1) of the amended 23 NYCRR 500 requires risk-based policies, procedures and controls designed to monitor the activity of authorized users and detect unauthorized access or use of, or tampering with, nonpublic information by those users. Section 500.1(b) defines an authorized user as any employee, contractor, agent or other person who participates in business operations and is authorized to access the entity's information systems and data. An underwriter pasting a policyholder file into a chat window fits both sentences exactly, which is why a NYDFS Part 500 AI compliance checklist starts there rather than with model selection.

I would settle the Class A question before running any other check, because five of them change depending on the answer.

TL;DR

• Determine Class A status first under 500.1(d), because privileged access monitoring, centralized logging and endpoint detection carry extra requirements for those entities.
• Section 500.13(a) requires a complete, accurate and documented asset inventory with owner, location, classification, support expiration date and recovery time objectives. Every AI route is an asset.
• Section 500.7(a)(4) requires review of all user access privileges at least annually, and 500.7(a)(6) requires prompt termination of access following departures.
• Section 500.17(a)(1) requires electronic notice to the superintendent no later than 72 hours after determining a cybersecurity incident occurred at the entity, an affiliate, or a third-party service provider. The annual filing under 500.17(b) is due by April 15.

Check 1: settle covered entity and Class A status

Owner: Legal and regulatory compliance.

Pass condition: The file records the authorization under the Banking Law, Insurance Law or Financial Services Law that makes the entity covered under 500.1(e), and applies the Class A test in 500.1(d). That test sets a floor of at least $20,000,000 in gross annual revenue across each of the two most recent fiscal years, counting all operations of the entity plus the New York operations of its affiliates. On top of the revenue floor the entity must also meet one of two conditions: over 2,000 employees averaged across those same two years, including affiliate staff wherever located, or over $1,000,000,000 in gross annual revenue in each of them across the entity and every affiliate.

Evidence: authorization reference, revenue and headcount calculation with the affiliate scope from 500.1(d), any limited exemption claimed under 500.19, signed determination. When calculating, affiliates count only where they share information systems, cybersecurity resources, or part of the cybersecurity program.

Check 2: put AI routes in the asset inventory

Owner: The CISO with security architecture.

Pass condition: Section 500.13(a) requires written policies and procedures designed to produce and maintain a complete, accurate and documented asset inventory of the entity's information systems, tracking for each asset as applicable the owner, location, classification or sensitivity, support expiration date, and recovery time objectives, plus the frequency for updating and validating the inventory. Each authenticated path from a person or agent to an LLM appears with those fields filled.

Evidence: inventory extract showing AI routes, owner assignments, classification, validation frequency, last validation date. The route that usually appears late is an internal assistant somebody stood up on a personal API key, which is both an inventory failure and an access failure.

Check 3: test access privileges on the model request

Owner: The IAM lead with the AI platform owner.

Pass condition: Section 500.7(a)(1) limits user access privileges to information systems providing access to nonpublic information to only those necessary to perform the user's job. Paragraph (a)(2) limits the number of privileged accounts and their functions, (a)(3) limits use of privileged accounts to when those functions are required, (a)(4) requires review of all user access privileges at least annually with removal of accounts and access no longer necessary, and (a)(6) requires prompt termination of access following departures.

Evidence: policy version, role mapping, permit and deny events on the AI route, annual review record with removals, departure termination log. Test a departed user's credential against the route and confirm the denial rather than trusting the directory sync.

Class A companies additionally must monitor privileged access activity and implement a privileged access management solution under 500.7(c)(1), plus an automated method of blocking commonly used passwords under (c)(2), with CISO-approved written infeasibility and compensating controls as the only alternative.

Check 4: prove monitoring of authorized user activity

Owner: Security operations.

Pass condition: Section 500.14(a)(1) requires risk-based policies, procedures and controls designed to monitor the activity of authorized users and detect unauthorized access or use of, or tampering with, nonpublic information by those users. For AI, the artifact is a per-request record showing the caller, the model destination, the policy version, the decision, and the response treatment, together with a detection rule for nonpublic information patterns and a real alert that fired.

Evidence: records including denials and redactions, classification rules with versions, alert history, investigation dispositions. Class A companies must also implement an endpoint detection and response solution monitoring anomalous activity including lateral movement, and a solution that centralizes logging and security event alerting, under 500.14(b), unless the CISO has approved reasonably equivalent or more secure compensating controls in writing.

Check 5: check encryption and MFA

Owner: Platform engineering with the IAM lead.

Pass condition: Section 500.15(a) requires a written policy requiring encryption that meets industry standards to protect nonpublic information held or transmitted both in transit over external networks and at rest. Where encryption at rest is infeasible, 500.15(b) permits effective alternative compensating controls reviewed and approved in writing by the CISO, whose feasibility review runs at least annually. Multi-factor authentication requirements sit in 500.12.

Evidence: written encryption policy, TLS configuration on the outbound model leg, storage encryption for prompt and response records, key custody, any CISO-approved infeasibility with its annual review date, MFA configuration and exception records.

Check 6: cover data retention and secure disposal

Owner: The records owner with the CISO.

Pass condition: Section 500.13(b) requires policies and procedures for the secure disposal on a periodic basis of nonpublic information identified in 500.1(k)(2) and (3) that is no longer necessary for business operations or other legitimate business purposes, except where retention is otherwise required by law or regulation, or where targeted disposal is not reasonably feasible given how the information is maintained.

Evidence: retention schedule covering AI request records, disposal job output, exception reasoning where records are held for examination purposes, review date. My opinion is that prompt and response stores are the most commonly forgotten repository in a Part 500 disposal programme, because they were built by a platform team that never saw the records policy. The AI audit log retention guide covers the tradeoff between disposal and evidence availability.

Check 7: drill the 72 hour notice and the April 15 filing

Owner: The CISO with regulatory reporting.

Pass condition: Section 500.17(a)(1) requires notifying the superintendent electronically in the form on the department's website as promptly as possible and no later than 72 hours after determining that a cybersecurity incident occurred at the covered entity, its affiliates, or a third-party service provider. Paragraph (a)(2) requires promptly providing any information the superintendent requests and creates a continuing obligation to update on material changes or newly available information. Section 500.17(b)(1) requires an annual electronic submission by April 15, either a written certification of material compliance for the prior calendar year based on data and documentation sufficient to accurately determine and demonstrate it, or a written acknowledgment that the entity did not fully comply.

Evidence: timed drill artifact producing the AI request population for an incident window, named determiner and determination timestamp, submission confirmation, the prior year's April 15 filing with supporting documentation index.

The word that does the work in 500.17(b)(1) is "materially complied", supported by data and documentation. A certification signed without an evidence index behind it is the exposure, not the control gap it papers over.

DeepInspect

DeepInspect sits between authenticated users or agents and HTTP-based LLM endpoints. On routed traffic it evaluates the identity and policy context the application supplies, permits, redacts or denies the request, inspects the response, and writes a per-decision record. Those records feed the monitoring duty at 500.14(a)(1), evidence the access limits at 500.7(a), populate the AI rows of the asset inventory at 500.13(a), and give the CISO a queryable population when the 72 hour clock in 500.17(a)(1) starts.

Encryption key management, endpoint detection, privileged access management tooling, penetration testing under 500.5, the risk assessment under 500.9, third-party service provider policies under 500.11, and the April 15 certification itself remain with their existing owners. Direct provider traffic from an unmanaged device, local execution, and opaque vendor inference sit outside the routed path. The NYDFS AI compliance overview covers the programme context, and the AI gateway for banks guide covers deployment. Book a demo today.