Blog

CCO and CISO Guide to AI Governance Responsibilities Under NYDFS

A practical breakdown of CCO AI governance responsibilities, CISO cybersecurity accountability, and CRO risk obligations under NYDFS—with a RACI map you can use immediately.

12 min read

The New York Department of Financial Services has made one thing clear: when AI systems fail inside a regulated institution, the question of who owned that risk will land on specific desks. CCO AI governance responsibilities, CISO accountability for cybersecurity controls, and CRO obligations around risk appetite are no longer soft organizational questions. Under NYDFS’s evolving AI guidance, they carry regulatory weight. This post maps each executive role to its distinct obligations—so your institution can assign ownership before an examiner asks who held it. This cluster post supports the broader NYDFS AI Cybersecurity Guidance Compliance pillar, which covers the full regulatory landscape for NY-regulated financial institutions.


How NYDFS Defines the CCO’s AI Governance Mandate

The Chief Compliance Officer’s role in AI governance is not about understanding the technology. It is about ensuring the institution has a documented, enforced compliance posture that maps AI use to applicable regulatory requirements—NYDFS Part 500, DFS cybersecurity regulations, and any sector-specific guidance the department issues. Under NYDFS expectations, Chief Compliance Officer AI responsibilities cluster around three areas:

  • Policy ownership. The CCO is accountable for maintaining written AI governance policies that define permissible use cases, prohibited applications, and the review process for new AI deployments. These policies must be living documents—reviewed at least annually and updated when NYDFS issues new guidance or when the institution’s AI footprint materially changes.
  • Regulatory mapping. Every AI system in production should be traceable to a compliance determination. The CCO’s team needs to document which regulatory requirements each system implicates—fair lending, data privacy, cybersecurity, model risk—and confirm that controls exist for each. This is the foundation of any defensible chief compliance officer AI governance posture.
  • Third-party oversight. NYDFS has been explicit that regulated entities cannot outsource compliance accountability to vendors. The CCO must ensure that vendor AI systems used by the institution are subject to the same governance standards as internally built models. That means contract provisions, vendor assessments, and ongoing monitoring—not a one-time due diligence checkbox.

For institutions building out this function, the NYDFS AI Compliance Checklist and Implementation Roadmap for Banks provides a structured starting point for translating these obligations into operational tasks.


The CISO’s Role: Embedding AI into the Cybersecurity Control Framework

The CISO’s lane is narrower and more technical than the CCO’s, but no less consequential. CISO AI cybersecurity strategy is fundamentally about extending the institution’s existing cybersecurity program to cover the attack surface and operational risks introduced by AI systems. NYDFS Part 500 already requires covered entities to maintain a cybersecurity program that protects the confidentiality, integrity, and availability of information systems. AI systems are information systems. That means the CISO owns their inclusion in:

  • Threat modeling and vulnerability assessment. AI models can be attacked through adversarial inputs, data poisoning, model inversion, and prompt injection (for generative systems). The CISO must ensure these threat vectors are included in the institution’s annual penetration testing and vulnerability management programs.
  • Access controls and data governance. Training data, model weights, inference endpoints, and API keys are all high-value targets. The AI governance control framework the CISO maintains should specify who can access each layer of the AI stack, under what conditions, and with what logging requirements.
  • Incident response integration. AI-specific failure modes—model drift producing erroneous outputs, a compromised inference API, a data pipeline breach—need to be reflected in the institution’s incident response plan. The CISO is responsible for ensuring those scenarios are documented, tested, and escalated appropriately.
  • Change management for model updates. Model retraining and version updates are change events with cybersecurity implications. The CISO should have a seat at the table when models are retrained on new data or when third-party model providers push updates.

The AI governance audit framework the CISO supports should produce evidence that these controls exist and are functioning—not just that they were designed. Examiners will ask for logs, test results, and documented reviews. For a deeper look at how model-level controls connect to NYDFS requirements, see AI Model Risk Management and Validation Requirements Under NYDFS.


CRO Responsibilities: AI Risk Appetite, Governance Committee, and Escalation Paths

Chief Risk Officer AI governance sits at the intersection of strategy and structure. The CRO is not primarily a policy writer or a technical control owner—the CRO’s job is to ensure the institution has made explicit, board-approved decisions about how much AI risk it is willing to carry and has built the organizational machinery to enforce those limits.

  • AI risk appetite statement. This is the CRO’s foundational deliverable. An AI risk appetite statement should define, in concrete terms, which AI use cases the institution will and will not pursue, what concentration limits apply (e.g., no single AI system may be the sole decision-maker for credit decisions above a certain threshold), and what residual risk thresholds trigger escalation. Vague language about "responsible AI" does not satisfy a NYDFS examiner. Quantified limits and documented rationale do.
  • AI governance committee structure. The CRO typically chairs or co-chairs the institution’s AI governance committee, which is the body responsible for approving new AI deployments, reviewing ongoing model performance, and escalating material risks to the board. A functional AI governance committee structure includes representation from compliance (CCO), technology (CISO or CTO), legal, and the relevant business lines. It meets on a defined cadence—quarterly at minimum—and produces documented minutes.
  • Escalation paths. Chief risk officer AI compliance requires that the CRO maintain clear escalation protocols: what triggers a risk event, who is notified, in what timeframe, and how it reaches the board. NYDFS expects board-level awareness of material AI risks, which means the CRO must translate technical and operational risk signals into language that a board risk committee can act on.

For CRO AI risk management at investment adviser entities, the governance challenge is more complex. A dually-regulated investment adviser must ensure its AI risk appetite statement explicitly addresses both NYDFS and SEC frameworks—documenting where the two regimes align, where they diverge, and which standard governs when requirements conflict. The CRO AI risk management investment adviser function therefore requires a cross-framework mapping exercise as a prerequisite to finalizing the risk appetite statement, not an afterthought. The AI Governance Framework for Regional Banks and Credit Unions covers how smaller institutions can structure these governance bodies without building a dedicated AI risk team from scratch.


Regulatory Reporting: AI Risk Metrics the CCO and CISO Must Track

NYDFS examiners do not accept narrative assurances. They ask for evidence—and increasingly, that evidence takes the form of metrics. Regulatory reporting AI risk metrics are the quantitative backbone of any defensible AI governance posture. The CCO and CISO should be tracking and reporting on the following categories:

  • Model inventory completeness. What percentage of AI systems in production are documented in the institution’s model inventory? Any gap is a control deficiency. Report this metric to the governance committee quarterly and to the board annually.
  • Model validation coverage. Of the models in inventory, what percentage have been validated within the required review cycle? The AI governance audit framework should define those cycles and track adherence.
  • Third-party AI vendor assessment status. How many third-party AI vendors are in scope, and how many have completed the institution’s vendor risk assessment? This is a CCO metric with CISO input on technical controls.
  • Cybersecurity control coverage for AI systems. What percentage of AI systems are covered by the institution’s penetration testing program, access control reviews, and incident response playbooks? These are CISO metrics that feed into the broader AI governance control framework.
  • Incident and near-miss tracking. How many AI-related incidents or near-misses occurred in the reporting period, and what remediation was completed? This metric is jointly owned by the CISO (cybersecurity events) and the CCO (compliance failures).
  • Escalation timeliness. When AI risk events were identified, how long did it take to escalate to the governance committee and, where required, to the board? Tracking the lag is the only way to demonstrate timely escalation.

These metrics should be reviewed by the AI governance committee at each meeting and summarized in the CRO’s board risk report. The NYDFS AI Cybersecurity Guidance: What Banks and Financial Institutions Must Know provides additional context on what examiners are looking for in these reporting structures.


Assigning Ownership: A RACI for CCO, CISO, and CRO Under NYDFS

The most common failure mode in AI governance is not that no one cares—it is that multiple people think someone else owns a given task. The following RACI maps CCO AI governance responsibilities, CISO accountability, and Chief Risk Officer AI governance obligations to specific activities. Adapt it to your institution’s structure.

ActivityCCOCISOCROBoard/Audit Committee
AI use policy development and maintenanceR/ACCI
Model inventory maintenanceRCAI
Cybersecurity controls for AI systemsCR/AII
Third-party AI vendor risk assessmentsR/ACCI
AI risk appetite statementCIR/AA
AI governance committee (chair)CCR/AI
Regulatory mapping of AI use casesR/ACCI
Incident response for AI eventsCR/AII
Board-level AI risk reportingCCR/AI
AI governance audit framework designRCAI
Penetration testing coverage for AICR/AII
Regulatory reporting AI risk metricsRCAI
  • R = Responsible, A = Accountable, C = Consulted, I = Informed*

The CCO and CRO share accountability on several items intentionally—Chief Compliance Officer AI responsibilities and chief risk officer AI compliance are overlapping functions, and the governance committee is the forum where those overlaps get resolved. What matters is that accountability is documented and that the committee has a process for resolving disputes when priorities diverge. The CISO’s accountability is concentrated in cybersecurity controls and incident response. Assigning the CISO default ownership of compliance policy creates confusion about the institution’s regulatory posture and can produce conflicts when cybersecurity priorities and compliance requirements pull in different directions. For institutions evaluating technology to support this governance structure, AI Governance Tools and Platforms for NYDFS-Regulated Banks covers the platform capabilities that map to these accountability requirements.


Get Your AI Governance Readiness Assessment

If your institution is working through how to assign these responsibilities—or preparing for an NYDFS examination that will ask exactly these questions—a structured readiness assessment is the fastest way to identify gaps before an examiner does. Request a demo or AI governance readiness assessment to see how your current CCO, CISO, and CRO accountability structure maps against NYDFS expectations.

Brine

Build, hire, and govern every AI system in your environment.

Describe a workflow in plain English and Brine builds it, runs it on your data, and governs every step — costing and attributing each action to its agent and model, with a pre-dispatch cap that holds a step before it overspends and a signed audit trail as standard.

Scope a pilot More resources