Regulatory mapping

Most companies do not need to invent AI governance. They need to align to the standards that already apply to their business. A crosswalk makes that alignment explicit: here is a control the framework implements; here is the external standard clause it satisfies (or partially satisfies).

This page is a starting crosswalk. Every organization's live crosswalk should be tuned to its own scope (sector, geography, customer commitments).

How to read the crosswalk

Each row answers: "If the standard asks for X, what does our framework provide?" A cell may read Implements, Partially implements, or Out of scope (with explanation).

The crosswalk is not a certification. It is the map Audit uses to answer the question "do we meet the clause?" faster.

The anchor standards

NIST AI Risk Management Framework (AI RMF 1.0)

Published January 2023¹. Core functions: Govern, Map, Measure, Manage. The GenAI Profile (NIST AI 600-1) supplements for generative systems.

NIST function	Framework artifact
Govern 1 (policies)	AUP, Charter
Govern 2 (accountability)	RACI & decision rights
Govern 3 (workforce capability)	Training needs
Govern 4 (culture)	AUP + acknowledgements + philosophy
Govern 5 (external stakeholders)	Vendor DPAs + Comms
Map 1 (context of use)	Risk classification
Map 2 (categorisation of system)	Risk classification
Map 3 (AI capabilities)	Vendor standards scorecard
Measure 1 (metrics)	Measurement
Measure 2 (trustworthy characteristics)	V.E.R.I.F.Y. + C.L.E.A.R.
Manage 1 (risk response)	Risk classification + tier implications
Manage 2 (response planning)	Incident response
Manage 3 (third-party risks)	Vendor standards
Manage 4 (documentation and communication)	Audit trail

ISO/IEC 42001:2023

The AI Management System standard². Structured like ISO/IEC 27001 (information security), adapted for AI.

ISO 42001 clause	Framework artifact
4 (context)	Charter + scope
5 (leadership)	Sponsor; RACI
6 (planning)	Risk classification; roadmap phases
7.2 (competence)	Training plan
7.5 (documented information)	Audit trail
8 (operation)	Frameworks (S.C.A.F.F., V.E.R.I.F.Y., etc.)
9 (performance evaluation)	Measurement; quarterly framework review
10 (improvement)	Phase 3 cadences; Phase 4 sunset
Annex A (AI-specific controls)	Per-control mapping maintained in internal crosswalk

EU AI Act (Regulation (EU) 2024/1689)

The EU's horizontal AI regulation³. Its staged application runs through 2025–2027. Key implications for AI-assisted software development:

• Not every use is "high-risk". Most AI coding assistants, used internally by engineers to produce code, are general-purpose AI systems (GPAI) and do not fall into Title III high-risk categories by default.
• AI systems embedded in specific high-risk use cases (e.g., software component of a medical device, or part of credit-scoring infrastructure) inherit the high-risk obligations from the system they are part of.
• Some coding use cases may be reclassified as high-risk in sectoral guidance, particularly in critical infrastructure, health, and finance, where the code produced with AI assistance is part of a high-risk system.

The practical implications for companies operating in the EU or serving EU customers:

• Maintain audit trail for AI involvement in code generation (per Audit trail). The AUP's tagging discipline is how this is produced.
• Document transparency obligations where customers interact with AI outputs. For internal coding assistance this is typically implicit; for customer-facing AI, it becomes explicit.
• GPAI obligations on vendors. The vendor, not the using company, carries most GPAI compliance obligations under Article 51 and related provisions. Your job is to use compliant vendors.
• Governance article mapping. The Act's governance clauses expect controls the framework already provides (policy, training, documentation, risk management).

EU AI Act area	Framework artifact
Article 9 (risk management system), for high-risk embedded use	Risk classification + Manage functions
Article 10 (data governance), for training data	Typically vendor's obligation; data handling covers our side
Article 12 (record-keeping)	Audit trail
Article 13 (transparency)	Data handling + external comms
Article 14 (human oversight)	V.E.R.I.F.Y., C.L.E.A.R.
Article 15 (accuracy, robustness, cybersecurity)	S.H.I.E.L.D., incident response
GPAI Chapter V	Consumed as user; feeds vendor standards

OWASP Top 10 for LLM Applications

Security-focused, evolving⁴. The current list (as of the 2025 refresh) addresses risks like prompt injection, sensitive information disclosure, supply chain, improper output handling, excessive agency, system-prompt leakage, and vector/embedding weaknesses.

OWASP LLM Top 10 category	Framework artifact
LLM01 Prompt Injection	Incident response scenarios; S.H.I.E.L.D.; training
LLM02 Sensitive Information Disclosure	AUP prohibited data; data handling
LLM03 Supply Chain	SCA, slopsquatting scenarios
LLM04 Data and Model Poisoning	Vendor standards; training-data provenance
LLM05 Improper Output Handling	C.L.E.A.R., V.E.R.I.F.Y.
LLM06 Excessive Agency	RACI for agent write access; Critical-tier rules
LLM07 System Prompt Leakage	Engineering patterns; review
LLM08 Vector / Embedding Weaknesses	Vendor standards; sector addenda
LLM09 Misinformation	Transparency; training on hallucination patterns
LLM10 Unbounded Consumption	Cost controls; rate limits; operational guardrails

Sector-specific mapping

Each regulated sector carries its own obligations. The table below is a starting point; live crosswalks go deeper.

Financial services (US / EU / UK)

Obligation	Framework touchpoint
SOX controls over financial reporting systems	Risk classification (Critical tier includes SOX scope); V.E.R.I.F.Y. Level 3
PCI DSS	AUP prohibits PCI data in AI prompts; vendor standards require PCI-compatible handling
DORA (EU)5: ICT operational resilience	Incident response; vendor standards; audit trail
SEC cyber-incident disclosure6	Incident response; Comms RACI row
FINRA / CFTC AI guidance (sector-specific)	Vendor standards; training

Healthcare (US)

Obligation	Framework touchpoint
HIPAA Privacy + Security Rules	AUP prohibits PHI in non-BAA tools; BAA required for any tool processing PHI
HITECH breach notification	Incident response; data-breach-mapped severity
FDA software-as-a-medical-device (if applicable)	Risk classification (Critical); explicit V&V; EU AI Act high-risk overlap

EU / UK data protection

Obligation	Framework touchpoint
GDPR Article 5 (principles)	Data handling
Article 25 (data protection by design)	Data handling + philosophy
Article 28 (processors)	Vendor DPAs
Articles 32/33/34 (security, breach notification)	Incident response
Article 35 (DPIA)	For customer-facing AI or high-volume data, DPIA performed per Phase 0/1

Public sector / defense (US)

Obligation	Framework touchpoint
FedRAMP / FedRAMP High	Vendor standards (residency + attestation); tier-specific approvals
CJIS	Prohibited data + approved tenants
OMB M-24-10 (federal AI guidance)7	Risk classification + incident response
Export controls (ITAR / EAR)	Data handling. AI tools are export-controlled endpoints for regulated data

Critical infrastructure (cross-sector)

Obligation	Framework touchpoint
NIS2 (EU)8	Incident response; vendor standards
CIRCIA (US, cyber incidents)	Incident response timelines
ENISA AI threat guidance	Informs training and incident scenarios

Producing the live crosswalk

A live crosswalk is a spreadsheet or structured document that:

• Lists every in-scope standard clause or control.
• Maps each to one or more framework artifacts (or explicitly to "not applicable" / "compensating control").
• Cites the evidence location (Audit trail).
• Tracks the last-review date per clause.
• Is signed off by Internal Audit (or equivalent) annually.

The crosswalk is produced in Phase 2, reviewed quarterly in Phase 3, and updated any time a standard is revised or a new one becomes in-scope.

Handling regulatory change

The regulatory landscape moves. Concrete practice:

• Subscribe to authoritative change feeds: NIST publications, ISO revisions, EU Commission AI Office announcements, sector regulators.
• Timeboxed review on change. Any material update triggers a CoE review within 30 days.
• Versioned crosswalk. Changes are tracked in the DR log, not quietly edited.
• Regulator contact list. Named contacts for each regulator you report to; updated as you rotate.

Anti-patterns

Don't

• Don't claim "compliance" with a standard you have not mapped clause-by-clause. Alignment is a process; compliance is an outcome that requires attestation.
• Don't confuse the EU AI Act's GPAI obligations with your obligations. As a user of a GPAI tool, you carry different obligations than the tool's provider.
• Don't maintain one crosswalk per standard. One crosswalk with per-standard columns is both less work and more accurate.
• Don't hide behind the vendor's certifications. A vendor SOC 2 is not your SOC 2. It is a component in your own assessment.

External references

• UK ICO AI auditing framework⁹.
• Singapore IMDA Model AI Governance Framework¹⁰.
• Bank of England / FCA AI discussion papers¹¹ for UK financial services.
• ENISA AI landscape reports¹².

Next

• Audit trail: the evidence that populates the crosswalk.
• Acceptable Use Policy: the policy that implements most Govern-function clauses.
• Incident response: the Manage-function implementation.

---

1. NIST, NIST AI 100-1: AI Risk Management Framework, Jan 2023. ↩

2. ISO, ISO/IEC 42001:2023. ↩

3. European Union, Regulation (EU) 2024/1689 (AI Act), Jul 2024. ↩

4. OWASP, Top 10 for LLM Applications. ↩

5. European Union, Regulation (EU) 2022/2554 (DORA). ↩

6. US SEC, Cybersecurity disclosure rule, Jul 2023. ↩

7. US OMB, M-24-10: Advancing Governance, Innovation, and Risk Management for Agency Use of AI, Mar 2024. ↩

8. European Union, Directive (EU) 2022/2555 (NIS2). ↩

9. UK ICO, Auditing AI toolkit. ↩

10. Singapore IMDA, Model AI Governance Framework. ↩

11. Bank of England + FCA, DP5/22 Artificial intelligence and machine learning, Oct 2022. ↩

12. ENISA, AI Threat Landscape. ↩