NYDFS Part 500 and AI Cybersecurity Readiness Assessment

Executive overview

Independent readiness and gap assessment of a New York-licensed financial institution against 23 NYCRR Part 500, extended to cover the institution's own use of AI and the AI-enabled threats directed at it.

Business challenge

The institution had held a Part 500 program since the original regulation and had filed in each annual cycle. What it did not have was a defensible way to demonstrate that the program actually operated. Policy documents were current and tooling was reasonably modern, but when internal audit asked to see the records supporting the prior year's filing, several control owners produced screenshots and verbal assurances rather than retained evidence. Two things forced the issue: the final transitional deadlines of the Second Amendment fell on November 1, 2025, extending multi-factor authentication under Section 500.12(a) to any individual accessing any information system and requiring a documented asset inventory under Section 500.13(a); and business units had begun adopting generative AI faster than the security function could assess it, so nobody could say which systems were processing nonpublic information through a model. Management wanted an assessment that would tell them what was true, not what was documented.

Environment and constraints

• Three legal entities in scope: the chartered institution, a licensed lending subsidiary that is a covered entity in its own right, and a technology services affiliate that shares information systems with both.
• Hybrid estate spanning on-premises core banking and lending platforms, a substantial Microsoft 365 and Azure footprint, and a long tail of business-managed SaaS applications.
• A lean security function with no dedicated compliance testing capability.
• Fieldwork could not disrupt month-end and quarter-end close windows.
• A prior-year internal audit finding on privileged access review evidence was still open at kickoff.
• No AI governance forum existed, and no AI acceptable-use standard had been approved.

Objectives and success measures

• Establish, per requirement, whether each applicable Part 500 obligation is designed, implemented, operating and evidenced, with reference to what was actually examined.
• Confirm applicability across all three entities, with a Class A determination under Section 500.1(d) documented separately for each covered entity rather than assumed at group level.
• Produce an AI system and use-case inventory covering enterprise, embedded, third-party and internally built AI.
• Replace reliance on management assertion with retained, reperformable evidence.
• Give management a package specific enough to support its own annual filing decision under Section 500.17(b), and to be handed to counsel without further translation.
• Leave behind a requirements matrix the institution can maintain itself.

Role and responsibilities

Independent assessor and remediation advisor, responsible for assessment design, requirement decomposition, evidence testing, technical validation, finding classification and risk rating, the AI risk assessment, the remediation roadmap, and reporting to the CISO, the executive committee and the board risk committee. Not the certifying party — the annual filing decision rested with the institution's highest-ranking executive, its CISO and its counsel.

Architecture and design approach

• Tested applicability rather than assuming it. The lending subsidiary is a covered entity in its own right, and the Section 500.19(b) exemption was tested and found unavailable: that exemption reaches a subsidiary only to the extent it is actually covered by the affiliate's cybersecurity program, and this program was neither the parent's nor adopted from it under Section 500.2(d).
• Ran the Class A test under Section 500.1(d) separately for each covered entity, because Class A status attaches to an entity and not to a group. Both met the first limb on revenue. Neither met the second limb on headcount or on the one billion dollar revenue threshold. The two limbs aggregate affiliates differently, so the workpaper records them separately and is written to be re-run annually.
• Decomposed each applicable section into testable criteria. Section 500.13(a) is one paragraph and became seven criteria, because the regulation enumerates what an inventory must track as applicable to each asset and separately requires the tracking method and the update and validation frequency. The decomposition produced 118 criteria, each carrying a regulatory reference, applicability by entity, control objective, named owner, expected evidence, testing method, and fields for status, risk, finding and corrective action.
• Recorded which of four testing methods produced each conclusion, because the strength of a conclusion depends on how it was reached. Inquiry established what people believed the control did. Inspection examined the artifact. Observation watched the control run. Reperformance re-executed the control independently, which is the only one of the four that survives a challenge on operating effectiveness.
• Established MFA coverage from authentication method registration and sign-in telemetry rather than from policy configuration, then tested it against an enumerated inventory of access paths. Reviewed conditional access for scope gaps, exclusion groups, and report-only policies never promoted to enforcement.
• Reconciled the identity directory three ways against the HR joiner-mover-leaver record and the privileged access records, and compared asset records against endpoint, vulnerability, cloud resource graph and network discovery inventories, investigating the differences rather than reconciling them away.
• Analyzed vulnerability findings by age, exploitability and asset criticality, then traced them through to remediation tickets and closure evidence. Reviewed backup restoration results for the full period rather than the most recent success.
• Identified AI services in use from secure web gateway and cloud application telemetry, which surfaced systems that appeared in no register and would not have been found by asking.

Security and governance considerations

• The assessment worked to the standards it was testing. Evidence moved through a controlled exchange rather than email, and nonpublic information was not extracted from the environment.
• Where extraction would have created a new exposure, the procedure was executed by the institution's own staff at the console under assessor direction and recorded as observation rather than reperformance, because it is not independent and the distinction matters when someone later asks how the conclusion was reached.
• Findings describing exploitable weakness in specific systems were kept in a restricted annex, separate from the report that circulated to the board.
• Section 500.4(d) oversight was examined in substance. Minutes showed that cybersecurity reports were received; what they did not show was challenge, with no record of management being asked to justify a risk acceptance or of a resourcing decision being tested.
• All five NYDFS issuances bearing on this work were treated as guidance and not as new obligations, which is how the Department itself frames them: the October 2024 AI letter, the October 2025 third-party guidance, the February 2026 vishing letter, and both May 2026 letters.
• Where the regulation reaches a weakness it was raised as a finding against the section, with guidance cited as the Department's stated expectation for how that section is satisfied. Where only the guidance reaches it, it was raised as a recommendation and labelled as one. Presenting a guidance expectation as a regulatory breach inflates the finding count and costs the report credibility with the people who will check.

Implementation and migration approach

• Remediation ran in four tracks rather than one queue, because the constraints differ.
• Containment, days 0 to 30: work that reduced live exposure and needed no design. Blocking upload of designated nonpublic information categories to unsanctioned generative AI services, disabling residual access left behind by a decommissioned vendor, closing conditional access exclusion groups that had outlived their purpose, and starting evidence preservation where the retention gap was about to make the prior period untestable.
• Regulatory closure, days 31 to 60: the findings that mattered for the filing decision. MFA coverage on the remaining access paths, the asset inventory rebuild, third-party contract remediation, and a privileged access review workflow with recorded reviewer approval and exception tracking.
• Validation and reporting, days 61 to 90: remediation validated against evidence rather than status reports, the privileged access cycle reperformed to establish a clean baseline, a full application-stack restoration test, an executive tabletop, and the filing readiness package assembled for management and counsel.
• Program maturity, beyond ninety days: AI governance, continuous control monitoring and the metric set. These were scoped and owned but deliberately kept outside the ninety-day window, because forcing them into it would have produced a governance forum that existed on paper in time for the filing and nowhere else.
• Two NYDFS issuances during the engagement changed the sequence. The February 2026 letter on an ongoing cyberthreat campaign involving targeted vishing arrived while help-desk identity verification was an open low-rated finding, and it was re-rated and pulled forward. The May 2026 frontier AI advisory and heightened threat environment guidance arrived after the filing period and prompted a re-examination of vulnerability remediation timelines for internet-facing and end-of-life systems, and of the review path for AI-generated code.

Key decisions and trade-offs

• Reperformance over sampling on identity controls. Slower and more intrusive, but a sampled access review tells you the sample was reviewed; reperformance tells you whether the population is right.
• Kept "unable to determine" as a distinct status rather than pushing those criteria into a pass or a fail. Management pushed back, reasonably, because it reads badly. It was retained, because recording an untestable control as compliant is the failure mode that makes an annual filing indefensible later.
• Documented compensating controls rather than avoiding them. Where a system could not support the required authentication strength inside the window, the CISO approved reasonably equivalent controls in writing with an annual review date, which is the path Section 500.12(b) provides. A compensating control that has not been approved in writing and is not reviewed is not a compensating control; it is a gap with a better name.
• Restricted public generative AI rather than blocking it outright. A hard block was on the table and was rejected, because the likely result was usage moving to personal devices where no telemetry exists. An approved enterprise service with data handling terms, paired with classification-based upload controls, kept the usage visible.
• Anchored AI risks to Part 500 sections wherever the regulation reaches them rather than to a separate AI framework. NIST AI RMF and the OWASP Gen AI material structured the analysis, but a finding traces to a regulatory requirement. An AI risk with no regulatory anchor was recorded as a recommendation and labelled as one, rather than dressed up as a breach.

Results and outcomes

• Tested and evidenced 118 requirement criteria across the sections in scope, and raised 31 findings with the evidence findings and formal risk acceptances carried as dispositions alongside the severity rating rather than as separate severities.
• Established the MFA position against the Section 500.12(a) scope. Remote and privileged access were already covered; testing found legacy applications and a core platform path that authenticated on-premises users with a single factor. Some were remediated by front-ending them with the identity provider, and the remainder are carried on written CISO-approved compensating controls under Section 500.12(b), with an annual review date and a retirement path.
• Rebuilt the asset inventory to the Section 500.13(a) data points. The existing CMDB carried owner and location but not support expiration date or recovery time objective, and reconciled with no other source. Reconciliation against four authoritative inventories surfaced assets present in the network but absent from both vulnerability scanning and endpoint detection.
• Established an AI system inventory against an informal register that captured a fraction of what was actually in the environment, including AI features that had been enabled inside SaaS products already assessed before those features existed.
• Made unsanctioned generative AI use visible through gateway and cloud application telemetry, then replaced an unmanaged practice with an approved enterprise service, a classification-based upload control and a published acceptable-use standard.
• Corrected the third-party position against both the regulation and the October 2025 NYDFS guidance. Contracts missing cybersecurity event notification language were raised as findings under Section 500.11(b); the absence of subcontractor disclosure and of any position on use of institutional data for model training was raised as a recommendation, because the guidance rather than the regulation reaches it.
• Closed a vendor offboarding gap in which a provider retired more than a year earlier had its interactive accounts disabled at the time while an OAuth consent grant and a service principal with mailbox scope remained active. This drove a revised runbook covering token invalidation, key rotation, federation revocation and certified data destruction.
• Rebuilt the annual CISO report template against the six matters enumerated at Section 500.4(b), and restructured board risk committee materials so management's risk decisions are presented as decisions with the options considered, which gives the governing body something it can challenge.
• Handed over a maintained requirements matrix the institution owns and updates as controls change, so the annual filing window is a review rather than a search.

Assessment artifacts

The working artifacts from the engagement, in a self-contained interactive page: the Part 500 readiness matrix, an AI risk and control crosswalk, the evidence strength model, the finding prioritization model, a four-track remediation roadmap, an assessor question set, and a timeline showing where each NYDFS issuance landed against the work.

Lessons learned

• The institutions that struggle are rarely the ones without controls. They are the ones that cannot show a control operated during a period that has already closed. Evidence retention is a design decision, and it has to be made before the period starts.
• A control that has never been reperformed is a belief. Inquiry and inspection will confirm almost any well-run organization's own account of itself.
• AI risk did not require a new control framework here. It required the existing risk assessment, third-party process, access model, data governance and monitoring to be pointed at systems nobody had inventoried. The inventory was the hard part.
• The governing body does not need to understand conditional access policy. It does need enough information to ask why a risk was accepted, and minutes that record only receipt of a report are not evidence that oversight occurred.
• Restricting a tool people find useful, without offering a sanctioned alternative, moves the usage somewhere you cannot see it. That is worse than the risk it was meant to address.

Related technologies

• Microsoft Entra ID
• Conditional Access
• Privileged Identity Management
• Microsoft Purview
• Microsoft Defender XDR
• Microsoft Defender for Cloud Apps
• Microsoft Sentinel
• Secure web gateway telemetry
• Enterprise vulnerability management
• NIST Cybersecurity Framework 2.0
• NIST AI Risk Management Framework
• NIST AI 600-1 Generative AI Profile
• OWASP Top 10 for LLM Applications 2025
• OWASP Top 10 for Agentic Applications 2026

Related projects