Security teams at spent much of 2025 watching AI governance obligations pile up from three directions at once: (1) US Federal guidance; (2)international standards and (3) US state law. California's SB 53 adds a compliance layer that has direct teeth for companies operating in the state, where if your organization deploys AI systems that touch employees or customers in California, the question is no longer whether you need an AI governance framework - it is whether the one you have actually connects to your security controls program.
Most do not. What passes for AI governance at many companies is a policy document, a risk register someone built in a spreadsheet and a vendor questionnaire that gets sent out annually. That is not a governance program. It is a paper exercise that will not hold up under a regulatory inquiry or an incident postmortem.
Three (3) regulatory developments converged in a way that made AI governance a genuine operational requirement rather than a future aspiration:
(1) California SB 53 became effective January 1, 2026. The law requires developers of certain AI systems to implement and document reasonable security safeguards, including the ability to disable AI systems that pose unreasonable risks. It focuses on large frontier model developers but sets a precedent for the documentation and control requirements that will cascade to enterprises deploying those models. California's track record on privacy - CCPA, CPRA -suggests these requirements will be enforced.
(2) The California Consumer Privacy Act (CCPA) / California Privacy Rights Act (CPRA) affects Automated Decision-Making (ADM) rules that extend beyond existing privacy obligations to AI-driven decisions. If your systems make or meaningfully contribute to decisions about consumers (e.g., pricing, content moderation, hiring, credit-adjacent decisions, etc.) you need documented processes for opt-out rights, logic explanations and impact assessments. These are not hypothetical. They require operational controls.
(3) The EUAI Act is in phased implementation through 2026 and 2027. “High-risk” AI system categories include biometric systems, hiring tools, credit scoring and law enforcement applications. If your company has any EU market presence or processes data from EU residents through AI systems, the Act's requirements for transparency, human oversight and technical documentation apply to you. Prohibited AI practices under the Act have already taken effect.
Adding additional complexity to the discussion, these frameworks are not perfectly aligned with each other: they use different terminology, have different thresholds and require different artifacts. An AI governance framework that only satisfies one of them probably does not satisfy the others.
The NIST AI RMF is the most widely cited framework for AI governance in the United States. It was published in January 2023 and is structured around four (4) core functions: Govern, Map, Measure and Manage:
(1) GOVERN. The Govern function is where most organizations underestimate the scope. It is not just about having an AI policy. NIST AI RMF expects organizations to establish accountability structures, assign roles and responsibilities for AI risk and integrate AI risk into the broader enterprise risk management program. That means connecting AI governance to your existing GRC structure, not treating it as a separate workstream.
(2) MAP. Map requires you to identify and classify AI systems by their risk level and context of use. This means maintaining an inventory of AI systems in use across the organization, understanding the data they consume and assessing the potential impact of their outputs. Many security teams have not done this for AI any more rigorously than they did for shadow IT five years ago.
(3) MEASURE. Measure is where you need technical controls: bias testing, performance monitoring, adversarial testing and output auditing. These are not one-time activities. They require repeatable processes with documented results.
(4) MANAGE. Manage is the response function: what happens when an AI system produces harmful outputs, when a model is found to have systematic bias, or when a third-party AI component introduces risk. This maps directly to incident response but requires AI-specific playbooks.
The NIST AI RMF is a risk management framework, not a controls framework. It tells you what to do at a functional level. It does not tell you which specific controls to implement or how to document them for audit purposes. That gap is exactly where a controls framework becomes necessary.
ISO/IEC 42001 is the international standard for AI management systems. Published in 2023, it follows the same high-level structure as ISO 27001, which makes it easier to integrate into existing information security management programs.
The standard applies when an organization is developing, providing, or using AI systems and wants to establish a structured management system around them. For commercial tech companies, that is a wide aperture. If you build AI-powered products, use AI in internal operations, or both - ISO42001 is relevant.
Its requirements cover AI policy, organizational roles, impact assessment processes, supplier and partner management and operational controls for AI lifecycle management. The standard requires documented evidence of conformance, which means your controls need to be implemented and verifiable, not just described in a policy.
The practical question most CISOs ask is whether ISO 42001certification is required or just useful. For most commercial tech companies, it is not currently required by any regulation in the United States. However, enterprise customers, especially in regulated industries, are beginning to ask for evidence of AI governance maturity. ISO 42001 provides a structured way to demonstrate that maturity and to integrate AI governance into the same audit framework as ISO 27001.
Whatever framework you align to, a functional AI governance framework operates at three layers. Skipping any one of them means the others do not hold.
Before you can govern AI risk, you need to know what AI systems exist and what they do. This starts with an AI system inventory - not just the models your data science team built, but the AI components embedded in third-party software, the API calls going to foundation model providers and the AI-assisted features that showed up in productivity tools your employees adopted without formal approval.
Once you have the inventory, each system needs a risk classification based on its function, the data it processes and the consequences of its outputs. A recommendation engine that influences marketing emails carries different risk than a system that informs hiring decisions or security alert triage. Risk level should drive the depth of controls applied.
AI-specific impact assessments are the output of this layer. These documents need to capture who is affected by AI system outputs, what the potential harms are and what mitigations are in place. They become the evidentiary record regulators ask for.
This is where a governance program either has operational substance or does not. Controls for AI systems span several domains:
- Data quality and provenance controls ensure training data is documented, validated and governed. This is not just a data engineering concern - it is a security control.
- Model access management applies standard identity and access principles to AI systems: who can query a model, who can modify it, who can deploy a new version.
- Bias and fairness monitoring requires ongoing measurement against defined metrics, with escalation paths when thresholds are breached.
- Third-party AI vendor risk management extends your existing vendor risk program to cover AI-specific considerations: model provenance, training data practices, output monitoring and contractual obligations around AI system changes.
- AI incident response requires playbooks specific to AI failure modes - model drift, adversarial inputs, unexpected output patterns and data poisoning.
These controls are not new categories invented for AI governance. They are extensions of controls security programs already manage. The question is whether they are being applied to AI systems specifically.
AI systems degrade in ways that other software does not. Model drift is the phenomenon where a model's performance deteriorates as the real-world data it encounters diverges from its training data. A system that performed well at deployment may produce increasingly unreliable outputs six months later without any code change.
Monitoring at this layer requires defined performance metrics with baselines, automated alerting when outputs shift, periodic adversarial testing and human review processes for high-risk decisions. Audit logs for AI system inputs and outputs need to be retained in a way that supports incident investigation and regulatory review.
This layer also covers the governance processes: committee reviews, policy updates as the regulatory environment changes and integration with the broader security program's vulnerability and risk management cycle.
Building an AI governance program does not mean building anew control framework. The Secure Controls Framework (SCF) already provides documented security controls that map to both NIST AI RMF and ISO 42001 requirements. This matters because both of those frameworks point to controls - they describe what needs to be done without specifying the controls catalog you use to do it.
SCF covers the control domains that AI governance requires: data management and quality, access control for systems and models, third-party risk management, incident response and monitoring. When a regulator or auditor asks for evidence that your AI governance controls are implemented, SCF gives you a documented, mapped control set with the traceability to show which regulatory and framework requirements each control addresses.
The practical advantage is that SCF maps to over 200cybersecurity laws, regulations and frameworks. If your organization already uses SCF as the control foundation for ISO 27001 or NIST CSF compliance, adding AI governance does not require building a parallel control library. You extend what you have. The AI-specific control requirements in NIST AI RMF and ISO42001 map into the same SCF structure your team already knows.
This approach prevents a common failure mode: organizations that build AI governance policies disconnected from their security controls program. When an incident occurs or an audit begins, the inability to demonstrate that controls are implemented and monitored - not just described -is where governance programs collapse. SCF provides the operational layer that sits underneath your governance program and makes it auditable.
Ninety (90) days is enough time to establish a foundation, not finish the work. Here is what matters most in that window.
- Days 1 to 30: Inventory and classify. Run an AI system discovery effort. Talk to engineering, product, procurement and IT operations. Document every AI system in use, including third-party components and API integrations. Assign a preliminary risk level to each. This inventory does not need to be perfect - it needs to exist.
- Days 31 to 60: Map your control gaps. Take the SCF control domains relevant to AI governance and assess your current state against each one. Where do you have documented, implemented controls? Where do you have policies but no controls? Where do you have nothing? This gap analysis becomes the roadmap for your program.
- Days 61 to 90: Implement priority controls and establish monitoring baselines. Focus on the highest-risk AI systems identified in your inventory. Implement or extend controls in access management, data governance and incident response for those systems specifically. Define the metrics you will use to monitor AI system performance and set up the logging infrastructure to support it.
- At 90 days, you will not have a complete AI governance program. You will have an inventory, a gap analysis, implemented controls for your highest-risk systems and a documented roadmap. That is a defensible starting position if a regulator comes asking or an incident occurs.
AI risk management is not a strategy problem for most security teams. They know they need to govern AI systems. It is an execution problem - specifically, how to build a program that is operationally real, auditable and integrated with the security work already underway.
The answer is not to build a new control library from scratch or to purchase a point solution that sits outside your GRC program. The answer is to use a control framework that already maps to the regulatory requirements you face and extend it to cover AI-specific control domains.
SCF is free, open-source and built for exactly this kind of extension. If your organization needs to demonstrate compliance with NIST AIRMF, ISO 42001, California SB 53, or any combination of AI governance requirements, SCF gives you the documented control foundation to do it.
Download SCF at https://securecontrolsframework.com/free-content/scf-downloadand review the control mappings relevant to your AI governance requirements. Your AI governance framework needs controls underneath it. SCF provides them.
%20(white).png)
.png)