Key takeaways
- The NIST AI RMF and CSF 2.0 are voluntary, and both give examiners and auditors a shared vocabulary for reviewing an AI policy.
- The AI RMF covers AI-specific risks through GOVERN, MAP, MEASURE and MANAGE, while CSF 2.0 covers the security controls around AI tools.
- NIST states that AI RMF 1.0 is being revised, and the Cyber AI Profile remains a preliminary draft, so date every mapping.
- A useful mapping has an evidence column naming the control that enforces each clause and the record it produces.
- CSF 2.0 GV.PO-01 expects policy to be communicated and enforced, so a clause with no enforcing control is a gap.
Why map an AI policy to the NIST AI RMF at all?
A mapping shows that each rule in your AI policy ties to a recognized risk outcome and to a control that enforces it. Neither the NIST AI Risk Management Framework (AI RMF) nor the Cybersecurity Framework (CSF) 2.0 is mandatory for a private firm, and NIST describes the AI RMF as voluntary. Their value is the shared vocabulary.
When an examiner, an auditor or an institutional client's due diligence questionnaire asks how your firm governs AI, "we follow our policy" invites follow-up questions. A mapping lets you answer in terms the reviewer already uses: this clause addresses GOVERN 6.1, this control produces the evidence for DE.CM-03, and here is last quarter's log. For an RIA or broker-dealer, the same document also supports the annual review of written policies that compliance staff already run.
Mapping also exposes gaps. A clause that maps to nothing may not be needed. A framework outcome that no clause covers is a risk the policy does not address yet.
How do the NIST AI RMF and CSF 2.0 divide the work?
The NIST AI RMF covers risks specific to AI, and CSF 2.0 covers the security controls around the tools, so a complete mapping uses both.
The AI RMF (NIST AI 100-1, January 2023) organizes AI risk into four functions: GOVERN, MAP, MEASURE and MANAGE. It covers risks specific to AI, such as validity of outputs, third-party models and monitoring after deployment. NIST's Generative AI Profile (NIST AI 600-1, July 2024) applies it to tools like chat assistants. NIST states on its AI RMF page that AI RMF 1.0 is being revised as part of the White House AI Action Plan, with no date given.
CSF 2.0 (NIST CSWP 29, February 2024) organizes cybersecurity outcomes into six functions: Govern, Identify, Protect, Detect, Respond and Recover. It covers the security controls around an AI tool: accounts, data protection, logging and incident response.
NIST is building a bridge between the two. The Cyber AI Profile (NIST IR 8596) was released as a preliminary draft on December 16, 2025, organized by CSF 2.0 functions and three focus areas: securing AI systems, using AI for defense, and thwarting AI-enabled attacks. Its comment period closed January 30, 2026, and NIST has said comments will inform an initial public draft. Until a final version exists, map to AI RMF 1.0 and CSF 2.0 directly and note the profile as a reference.
How do you map each policy clause?
Take each clause of your AI policy and assign one or two subcategories from each framework. Keep it tight. A clause mapped to eight subcategories usually means the clause is too broad. The common clauses map like this:
- Approved tools list. AI RMF GOVERN 1.6: mechanisms are in place to inventory AI systems. CSF ID.AM-02: inventories of software, services and systems are maintained.
- Data rules (what may and may not go into an AI tool). AI RMF GOVERN 1.1: legal and regulatory requirements involving AI are understood, managed and documented. CSF GV.OC-03 for legal requirements, ID.AM-07 for data inventories, and PR.DS-01 and PR.DS-02 for protecting data at rest and in transit.
- Roles and approvals. AI RMF GOVERN 2.1: roles, responsibilities and lines of communication are documented. CSF GV.RR-02: roles, responsibilities and authorities are established.
- Vendor review before a tool is approved. AI RMF GOVERN 6.1: policies and procedures address AI risks from third-party entities. CSF GV.SC-05 for contract requirements and GV.SC-07 for understanding supplier risk. Our guide to what GV.SC asks of small firms covers the vendor side in more depth.
- Firm accounts only, no personal AI accounts. CSF PR.AA-05: access permissions are defined in policy, managed, enforced and reviewed. The AI RMF has no direct equivalent, so this clause maps mainly to CSF.
- Human review of AI output before it reaches a client. AI RMF MEASURE 3.3 for feedback processes that let users report problems, and MANAGE 2.4 for mechanisms to supersede or disengage a system that is not performing as intended.
- Training. AI RMF GOVERN 2.2: personnel and partners receive AI risk management training. CSF PR.AT-01: personnel receive awareness and training.
- Monitoring and logging of AI use. AI RMF MANAGE 4.1: post-deployment monitoring plans are implemented. CSF DE.CM-03: personnel activity and technology usage are monitored.
- Incidents, such as client data pasted into an unapproved tool. AI RMF GOVERN 4.3 and MANAGE 4.3 for identifying and communicating incidents. CSF RS.MA-01: the incident response plan is executed.
- Annual review of the policy. CSF GV.PO-02: policy is reviewed, updated, communicated and enforced. CSF ID.IM-01: improvements are identified from evaluations.
What does a finished mapping look like?
A finished mapping is a table with four columns: the policy clause, the AI RMF reference, the CSF 2.0 reference, and the evidence. The evidence column is the one a reviewer will test.
Evidence names the control that enforces the clause and the record it produces. For the approved tools list, the evidence might be the web filter category that blocks unapproved AI sites and the monthly report of blocked attempts. For data rules, it might be the data loss prevention policy that flags account numbers in AI prompts and its alert log. For firm accounts only, it might be the sign-in policy that blocks personal accounts on firm devices.
CSF 2.0 makes the point itself. GV.PO-01 says policy for managing cybersecurity risk is "communicated and enforced." Writing it down is the first step. A clause with no enforcing control and no record maps to a framework on paper only.
Where do mappings usually break?
Watch for four problems when a policy meets a reviewer:
- Every clause maps to GOVERN and nothing else. Govern outcomes describe intent. Reviewers also want the Protect and Detect outcomes that show the intent was carried out. Our piece on the CSF 2.0 Govern function explains what Govern should and should not carry on its own.
- The policy covers standalone AI tools and ignores AI features built into software the firm already uses, such as email, CRM and document platforms. Those belong on the inventory under GOVERN 1.6 and ID.AM-02.
- The mapping is undated. With the AI RMF under revision and the Cyber AI Profile still in draft, record which version of each framework you mapped against.
- Nobody owns the mapping. Assign it to the same person who owns the policy, and review both together.
What should you do this quarter?
You can build a first mapping in a few working sessions:
- Pull the current AI policy and number every clause.
- Map each clause to one or two AI RMF subcategories and one or two CSF 2.0 subcategories, using the list above as a starting point.
- For each clause, write down the control that enforces it and the record that control produces. Mark any clause where the answer is "none."
- Look the other way: scan GOVERN 1.6, GOVERN 6.1, MANAGE 4.1 and DE.CM-03 and confirm a clause covers each one.
- Close the "none" gaps with a control or rewrite the clause so it matches what the firm actually does.
- Date the mapping, name the framework versions, and add it to the annual policy review.
How does s90 help?
s90 enforces AI policies through AI guardrails and AI platform policy enforcement: approved tool lists, account controls, data loss prevention and usage monitoring that produce the evidence column of a mapping like this one. If you would like help mapping your current policy, we are happy to start with the clauses you already have.




