AI Evidence a CISO Should Hold Before Signing the NYDFS Part 500 Annual Certification

What the certification asks of the CISO

Each Covered Entity must file by April 15 either a written certification that it materially complied with Part 500 during the prior calendar year, or a written acknowledgment that it did not materially comply with all requirements. The highest-ranking executive and the CISO sign. The certification must be based on data and documentation sufficient to accurately determine and demonstrate material compliance. That can include documentation covering officers, employees, outside vendors and other individuals or entities, plus reports, certifications and schedules.

The NYDFS industry letter of October 2024 on AI-related cybersecurity risks states that it adds no new requirements beyond Part 500. It explains how Covered Entities should use the Part 500 framework to assess and address AI risks. This shapes how to build the evidence file. AI is not a separate compliance regime. Employee use of generative AI, AI agents, third-party AI services and AI-enabled coding tools fall under requirements that already exist, so evidence should be organized under those headings and measured against them.

Applicability comes first. Which sections apply depends on whether the entity qualifies for a Section 500.19 exemption or is a Class A Company. Confirm that before mapping any artifact, as of November 2026.

Runtime evidence versus evidence assembled afterward

Evidence can be produced in two ways. Runtime enforcement evidence is created when a policy decision is made on an individual interaction or tool call: the request, the policy applied, the outcome (allow, redact, block, escalate) and any human approval. Retrospective evidence is assembled later from scattered logs, interviews, screenshots and point-in-time assessments.

The certification standard asks for documentation sufficient to demonstrate compliance, and a reasonable reading is that evidence tied to the reporting year is easier to defend. Records created at the moment of a decision are attributable to that period and show what was actually permitted. Records reconstructed in March show what someone believes happened. This is a judgment about defensibility, not a rule in the regulation.

The two types support different needs. Runtime records best support access, nonpublic information protection, monitoring and human-approval questions, because they show behavior. Periodic artifacts such as the risk assessment, policy approvals, vendor due diligence and training records are inherently dated documents, and they remain necessary. A sound file holds both, and does not use one to stand in for the other.

Retention, residency and record integrity

Evidence has to exist when it is needed, so retention should be set deliberately for AI records. Define how long each evidence class is kept, and make sure that period covers the certification and any supporting-documentation obligations your legal team identifies under the current text of Part 500.

Two further decisions matter. First, where records are stored: if AI interactions can contain nonpublic information, the evidence about them can too, so storage location and data residency settings should follow the entity's own data handling policy. Second, whether records can be altered. An examiner reviewing an enforcement record will reasonably ask who could change it. Write-once storage, access restrictions on the evidence store and a documented chain of custody make the evidence easier to rely on.

Retention costs real storage at volume, and redaction affects what the evidence contains. Decide up front whether records hold full content, redacted content or metadata only, and document that choice.

Closing gaps, or acknowledging them

Walk the inventory against the checklist and mark each requirement area as supported, partially supported or unsupported. Common gaps include AI tools adopted by teams without review, vendor AI features switched on after due diligence, and policies that predate agent and coding assistant use.

Assess each gap against existing Part 500 requirements, not against the industry letter, since the letter creates no new obligations. Whether a gap is material is a determination the entity must make and defend, and Part 500 does not define materiality for AI-related gaps. Document the reasoning either way.

If the entity concludes it did not materially comply, it files an acknowledgment of noncompliance. That filing must identify every section not materially complied with and describe the nature and extent of the noncompliance. DFS's checklist adds that it must provide a remediation timeline or confirmation that remediation is complete. Having this analysis done before the signing meeting is better than assembling it during one.

Where runtime enforcement fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, applying allow, redact, block, rate limit and escalate-for-human-approval decisions to individual interactions and tool calls. The audit-ready evidence generated by that enforcement is mapped to NYDFS, among other frameworks, and code provenance records origin, licence and security context. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

This addresses the access, monitoring and nonpublic information rows above. It does not replace the risk assessment, policy approvals, vendor due diligence or training records, which the entity must still produce. Trussed's deepest experience is in insurance, another regulated sector where examiners ask what a system was allowed to do and what it did.