Skip to content

Governance frameworks

This page catalogs the standards, regulations, and reference frameworks that an AI-coding adoption program is expected to align with. For each entry: the owner, the status (regulation vs voluntary standard), the jurisdiction, a one-paragraph summary of what it requires, and a cross-link to where in this site we map to it.

The full crosswalk lives in regulatory mapping; this page is the source-of-record index that page draws from.

Scope

The frameworks below are the ones an AI-coding program touches directly. Sector-specific obligations (e.g., FDA SaMD, MiFID II, state-level US privacy laws) may apply on top; this page lists the core layer.


AI-specific frameworks

NIST AI Risk Management Framework (AI RMF 1.0)

  • Owner. US National Institute of Standards and Technology (NIST).
  • Status. Voluntary framework; widely treated as the de facto baseline for AI risk programs in the United States.
  • Jurisdiction. US federal context, but used internationally.

What it requires. AI RMF 1.0 organizes AI risk management around four functions — Govern, Map, Measure, Manage — and provides a Generative AI Profile that adapts the core to generative systems. The framework expects an organization to articulate its risk tolerance, classify AI use cases, instrument them with measurable risk indicators, and act on those indicators1.

Where we map to it.

NIST Generative AI Profile (NIST AI 600-1)

  • Owner. NIST.
  • Status. Profile of AI RMF 1.0 specifically for generative AI risks, published 2024.
  • Jurisdiction. Companion to AI RMF.

What it requires. Calls out generative-AI-specific risks (confabulation, data leakage through prompts, intellectual property, information integrity) and aligns mitigations to the AI RMF functions2.

Where we map to it. Cautionary tales and security incidents tag the same risks with real-world examples; the framework practices in S.H.I.E.L.D. and S.E.C.U.R.E. instrument the mitigations.

ISO/IEC 42001:2023 — AI Management System

  • Owner. International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC).
  • Status. International standard; certifiable. First-edition published 2023.
  • Jurisdiction. Global; common contractual ask in enterprise procurement.

What it requires. Specifies a management-system standard for AI analogous to ISO 27001 for information security. Requires an AI policy, roles and responsibilities, planning (risk and opportunity), operational controls, performance evaluation, and continual improvement3.

Where we map to it.

EU AI Act — Regulation (EU) 2024/1689

  • Owner. European Union.
  • Status. Regulation; in force 1 August 2024 with phased applicability through 2026 and beyond.
  • Jurisdiction. EU; extraterritorial effect on AI systems placed on the EU market or whose output is used in the Union.

What it requires. Risk-tiered obligations for AI systems: prohibited, high-risk, limited-risk (transparency obligations), and minimal-risk categories, plus distinct obligations for general-purpose AI (GPAI) model providers. High-risk systems require risk management, data governance, technical documentation, human oversight, accuracy/robustness/cyber- security testing, and post-market monitoring. Phased timelines apply to prohibited practices, GPAI obligations, and high-risk obligations4.

Where we map to it.

  • Risk classification — the framework's tiering reads against the AI Act's tiering, with the important distinction that the framework classifies the company's systems that use AI, while the Act classifies AI systems themselves placed on the market.
  • Regulatory mapping — full crosswalk and timeline.

OWASP Top 10 for LLM Applications

  • Owner. Open Worldwide Application Security Project (OWASP).
  • Status. Community-maintained reference; not a standard.
  • Jurisdiction. Global; widely used in security review.

What it requires. Catalogs the top application-security risks specific to LLM-backed applications: prompt injection, insecure output handling, training-data poisoning, model denial of service, supply- chain risk, sensitive information disclosure, insecure plugin design, excessive agency, overreliance, and model theft5.

Where we map to it.

  • S.H.I.E.L.D. — control selection.
  • S.E.C.U.R.E. — verification of LLM-application code.
  • Security incidents — most named incidents on this site map cleanly to one or more OWASP LLM Top 10 entries (Chevy → prompt injection; DeepSeek → sensitive information disclosure; Replit → excessive agency).

Information security and assurance frameworks

ISO/IEC 27001:2022 — Information Security Management Systems

  • Owner. ISO/IEC.
  • Status. International standard; certifiable.
  • Jurisdiction. Global.

What it requires. Specifies requirements for an information security management system (ISMS), including a risk-based selection of controls from Annex A (which in the 2022 edition consolidates and modernizes the control set). Common contractual baseline for enterprise vendors6.

Where we map to it. Audit trails & evidence, Vendor & tool selection, and Data handling follow ISO 27001 control families. AI-specific controls layer on top via 42001.

SOC 2 (Trust Services Criteria)

  • Owner. AICPA (American Institute of Certified Public Accountants).
  • Status. Audit framework; SOC 2 Type II reports are the common customer-facing artifact.
  • Jurisdiction. US-origin; international acceptance in B2B SaaS.

What it requires. An attestation against the Trust Services Criteria — Security (required), and optionally Availability, Confidentiality, Processing Integrity, and Privacy. Type II reports describe controls over a period (typically 6–12 months), not at a point in time7.

Where we map to it. Vendor & tool selection treats SOC 2 Type II as a baseline ask for AI vendors that hold prompts or outputs.


Privacy and data-protection frameworks

GDPR — Regulation (EU) 2016/679

  • Owner. European Union.
  • Status. Regulation; in force since 2018.
  • Jurisdiction. EU; extraterritorial.

What it requires. Lawful basis for processing personal data, data- subject rights, data-processing agreements with processors, international-transfer safeguards, breach notification, and (where applicable) Data Protection Impact Assessments8.

Where we map to it. Data handling & residency, Vendor & tool selection. AI prompts that contain personal data are processing events; the AUP treats them as such.

HIPAA — US health privacy

  • Owner. US Department of Health and Human Services (HHS).
  • Status. Federal regulation; enforcement via the Office for Civil Rights.
  • Jurisdiction. US; applies to covered entities and business associates.

What it requires. Safeguards (administrative, physical, technical) for Protected Health Information (PHI); Business Associate Agreements (BAAs) with vendors that handle PHI; breach notification9.

Where we map to it. Risk classification treats PHI as a Restricted data class; AI vendors processing PHI require an executed BAA, captured in vendor standards.

PCI DSS 4.0

  • Owner. PCI Security Standards Council.
  • Status. Industry standard; contractually required by card brands.
  • Jurisdiction. Global, where cardholder data is processed.

What it requires. Twelve high-level requirements covering network security, cardholder data protection, vulnerability management, access control, monitoring, and policy. Version 4.0 introduced customized implementations and tightened authentication requirements10.

Where we map to it. Payment-handling systems land at Critical; the AUP forbids AI processing of cardholder data on tools that lack equivalent control attestation.


Sector-specific frameworks

FFIEC — US banking generative-AI guidance

  • Owner. Federal Financial Institutions Examination Council (FFIEC), through its member agencies (OCC, FRB, FDIC, NCUA, CFPB).
  • Status. Supervisory guidance, building on existing Model Risk Management (SR 11-7) expectations.
  • Jurisdiction. US banking and credit unions.

What it requires. AI / generative-AI use is treated under the existing model-risk and third-party-risk frameworks, with emphasis on governance, documentation, validation, and ongoing monitoring. SR 11-7 remains the foundational document on model risk11.

Where we map to it. Regulatory mapping crosswalks SR 11-7 controls onto the framework's verification levels.

NIS2 — EU critical-infrastructure cybersecurity

  • Owner. European Union.
  • Status. Directive (EU) 2022/2555; transposed into Member State law.
  • Jurisdiction. EU; expanded scope vs the original NIS Directive.

What it requires. Risk management measures, incident reporting, and supply-chain security for essential and important entities across an expanded set of sectors12.

Where we map to it. Incident response incorporates NIS2 incident-notification timelines for in-scope entities. AI-tool vendors that operate as ICT service providers can fall in scope.


How to use this catalog

By company size

  • Small (< 50 people). You probably need to align with a smaller subset — typically GDPR if you serve EU customers, SOC 2 Type II if you sell B2B SaaS, plus OWASP LLM Top 10 as your practical control list. NIST AI RMF is a useful free reference; ISO 42001 certification is unlikely to be required at this stage.
  • Mid (50–500). SOC 2 Type II is usually customer-driven by this stage; ISO 27001 may follow. Begin tracking ISO 42001 and EU AI Act timelines if you sell into the EU.
  • Enterprise (500+). Plan to align with all of the above simultaneously. The regulatory mapping page is the working document; this page is the source list.

Status drift

Regulatory documents move quickly. Each footnote below points at the current canonical source; if a URL changes, the source-of-truth is the issuing body, not this page. The review_by date on this page is 90 days for that reason.