Building a Gen AI Security Framework, Part 3: From Risk to Controls
Part 3 of 4 in a series on building a practical, regulator-ready risk framework for generative AI.
Executive Summary
- A rated risk in a register is only useful once it is mapped to a specific control and an owner. Naming and rating risk, covered in Parts 1 and 2, is preparation, not protection.
- NIST has published official crosswalks between the AI Risk Management Framework and several standards, including ISO/IEC 42001, ISO/IEC 23894, and the OECD Recommendation on AI. NIST SP 800-53 is not among them, so any mapping from AI risk categories to security controls has to be built by the organization.
- Three control catalogs are the practical starting points: NIST SP 800-53 Revision 5, NIST Cybersecurity Framework (CSF) 2.0, and ISO/IEC 27001:2022. Each has a different scope and a different degree of existing adoption inside financial services.
- A mapping table connecting AI risk categories and known LLM attack techniques to specific control families gives the risk register something concrete to point to. This part provides a starting version of that table.
- Evidence has to be distinguished from documentation. A written policy is not proof a control works. Test results, logs, and review records are.
- This mapping and evidence layer needs a review cycle tied to the same triggers already tracked in the Part 2 risk register: a new model version, a new data source, a new vendor, or an updated version of the OWASP or MITRE ATLAS reference material.
1. Why the AI RMF Does Not Hand You a Control List
NIST has been active in publishing official crosswalks between the AI Risk Management Framework and other standards. As of this writing, published crosswalks connect the AI RMF to ISO/IEC 23894, ISO/IEC 42001, ISO/IEC 42005, ISO/IEC 5338 and 5339, the OECD Recommendation on AI, the proposed EU AI Act, Executive Order 13960, and the Blueprint for an AI Bill of Rights.
NIST SP 800-53, the government’s primary security and privacy control catalog, is not on that list. This matters because it means there is no government-issued document that tells you, for example, exactly which SP 800-53 control satisfies the information security risk category in AI 600-1. That mapping has to be built, and the organization that builds it thoughtfully has an advantage over one that skips the step entirely and simply asserts that existing IT controls already cover generative AI.
This is not a flaw in the framework. The AI RMF and its Generative AI Profile were written to describe risk outcomes and organizational practices, not to duplicate an existing control catalog. The work of connecting the two belongs to whoever is running the program, and doing that work visibly is itself evidence of a mature risk practice.
2. Three Control Catalogs to Build From
Most organizations do not need to invent a control catalog. Three existing ones cover almost everything a gen AI risk needs mapped to.
| Catalog | Scope | Official AI RMF crosswalk | Typical fit |
|---|---|---|---|
| NIST SP 800-53 Rev. 5 | General-purpose security and privacy controls, organized into 20 control families | No | Organizations already using SP 800-53 for federal work or existing security programs |
| NIST CSF 2.0 | Six functions: Govern, Identify, Protect, Detect, Respond, Recover | No, but CSF has an official informative reference mapping to SP 800-53 | Organizations that manage cybersecurity risk at the function level rather than the individual control level |
| ISO/IEC 27001:2022 | Information security management system requirements, with an Annex A control set | No, but companion standard ISO/IEC 42001:2023 has an official AI RMF crosswalk | Organizations already certified to 27001, especially those operating internationally |
NIST SP 800-53 Revision 5 is the most detailed of the three. Its 20 control families include Access Control, Audit and Accountability, Risk Assessment, System and Information Integrity, Configuration Management, Identification and Authentication, Contingency Planning, and Supply Chain Risk Management. Several of these map naturally onto gen AI risk without much translation.
NIST CSF 2.0, published February 26, 2024 as NIST CSWP 29, added Govern as a sixth function alongside Identify, Protect, Detect, Respond, and Recover. The addition of Govern in 2.0 lines up conceptually with the Govern function already at the center of the AI RMF, which makes CSF 2.0 a natural bridge for organizations that already report cybersecurity posture at the function level to a board or risk committee. NIST also publishes an informative reference mapping CSF categories directly to SP 800-53 controls, so an organization using CSF 2.0 for governance reporting still has a documented path down to specific controls.
ISO/IEC 27001:2022 is the internationally recognized standard for information security management systems, and many financial institutions operating across multiple jurisdictions are already certified against it. Its Annex A control set was reorganized in the 2022 revision into a smaller number of broad themes covering organizational, people, physical, and technological controls. For gen AI specifically, ISO also publishes ISO/IEC 42001:2023, a dedicated AI management system standard, which is the one that carries an official NIST crosswalk. An organization already built around 27001 has a shorter path to 42001 than one starting from nothing.
None of these three is a wrong choice. The right one depends on what the organization already has in place. Duplicating a second control framework alongside an existing one adds overhead without adding protection.
3. Mapping Risk Categories to Control Families
The table below covers all twelve AI 600-1 risk categories and all ten OWASP LLM Top 10 techniques. It is not an official crosswalk. Every organization should adjust it to its own architecture, since a retrieval-based chatbot and an autonomous agent will not share the same relevant controls even when the underlying risk category is the same.
AI 600-1 Risk Categories
| AI 600-1 risk category | Relevant SP 800-53 families | CSF 2.0 function |
|---|---|---|
| CBRN information | Access Control, System and Information Integrity, Incident Response | Protect, Respond |
| Confabulation | System and Information Integrity, Planning, Program Management | Protect |
| Dangerous or hateful content | System and Information Integrity, Access Control, Incident Response | Protect, Respond |
| Data privacy | Access Control, System and Information Integrity, Personally Identifiable Information Processing and Transparency | Protect |
| Environmental impact | Program Management, Planning | Govern |
| Harmful bias or homogenization | Risk Assessment, Program Management, System and Services Acquisition | Identify |
| Human-AI configuration | Access Control, Configuration Management, Awareness and Training | Protect |
| Information integrity | System and Information Integrity, Planning, Audit and Accountability | Protect, Detect |
| Information security | System and Information Integrity, Audit and Accountability, Incident Response | Detect, Respond |
| Intellectual property | System and Services Acquisition, Supply Chain Risk Management, Program Management | Identify |
| Obscene or abusive content | Access Control, System and Information Integrity, Incident Response | Protect, Respond |
| Value chain and component integration | Supply Chain Risk Management, System and Services Acquisition, Risk Assessment | Identify |
OWASP LLM Top 10 Techniques
| OWASP technique | Relevant SP 800-53 families | CSF 2.0 function |
|---|---|---|
| LLM01 Prompt Injection | System and Information Integrity, Audit and Accountability | Detect |
| LLM02 Sensitive Information Disclosure | Access Control, System and Information Integrity | Protect |
| LLM03 Supply Chain | Supply Chain Risk Management, System and Services Acquisition | Identify |
| LLM04 Data and Model Poisoning | System and Information Integrity, Configuration Management, Risk Assessment | Protect, Detect |
| LLM05 Improper Output Handling | System and Information Integrity, Configuration Management | Protect |
| LLM06 Excessive Agency | Access Control, Configuration Management, System and Services Acquisition | Protect |
| LLM07 System Prompt Leakage | System and Information Integrity, Audit and Accountability | Detect |
| LLM08 Vector and Embedding Weaknesses | System and Information Integrity, Configuration Management, Risk Assessment | Protect, Detect |
| LLM09 Misinformation | System and Information Integrity, Planning, Awareness and Training | Protect |
| LLM10 Unbounded Consumption | Contingency Planning, System and Communications Protection, Audit and Accountability | Protect, Detect |
MITRE ATLAS adds a useful check on both tables. Beyond cataloging adversary techniques, MITRE has released a working set of mitigations for AI systems covering both security concepts and specific technologies for preventing an attack from succeeding. Comparing a proposed control against the matching ATLAS mitigation is a reasonable sanity check that the control actually addresses how these systems get attacked in practice, not just how a generic IT system does.
4. Evidence: What Actually Gets Inspected
A control that exists only as a written policy will not survive an audit or an examination. The distinction that matters is between a control’s existence and a control’s operation, and the evidence has to demonstrate the second one. The table below covers each SP 800-53 control family that appears in the mapping above.
| Control family | What a policy says | What operating evidence looks like |
|---|---|---|
| Access Control | Only authorized roles can query the system and access sensitive data sources | Access review logs, role assignment records, a recent access recertification, least-privilege attestation |
| Audit and Accountability | System activity is logged, retained, and reviewed | Log retention configuration, sample query logs, alert history, evidence of periodic log review |
| Awareness and Training | Users and operators understand gen AI limitations and acceptable use | Training completion records, acceptable use acknowledgments, dated training materials |
| Configuration Management | The system is deployed and changed through a controlled process | Change records, baseline configuration documentation, approval records for model or prompt updates |
| Contingency Planning | The system can be suspended or rolled back if it behaves unexpectedly | Tested suspension procedure, rollback runbook, evidence of a tabletop or drill |
| Incident Response | Anomalous model behavior triggers a defined response | Incident response plan covering gen AI scenarios, records of any prior incidents or near-misses |
| Planning | The system’s purpose, boundaries, and risk posture are documented | System security plan or equivalent, approved use case description, documented scope boundaries |
| Personally Identifiable Information Processing and Transparency | Personal data processed by the system is authorized and minimized | Privacy impact assessment, data inventory showing what PII the model can access or output |
| Program Management | Gen AI risk is tracked at the portfolio level, not just per system | Risk register showing all use cases, ownership assignments, escalation records |
| Risk Assessment | Risks are identified and rated before deployment and on a review cycle | Completed SP 800-30 rating for the use case, documented sign-off, date of last reassessment |
| Supply Chain Risk Management | Third-party models, APIs, and data sources are vetted before use | Vendor due diligence records, model provenance documentation, third-party risk assessments |
| System and Communications Protection | The system’s network exposure is limited to what is necessary | Network segmentation documentation, egress control configuration, firewall or proxy rules |
| System and Information Integrity | The system is tested for prompt injection, output handling failures, and data poisoning | Red team test reports referencing specific OWASP or ATLAS techniques, with dates and results, output monitoring logs |
| System and Services Acquisition | Gen AI components and vendors meet defined security requirements before procurement | Security requirements in contracts, vendor security assessments, model evaluation records |
This is also where the risk register from Part 2 earns its keep. Each row already carries the risk category, the rating, and the mapped control. Adding an evidence type and a last-tested date to that same row turns the register from a list of concerns into an artifact that can answer, for a specific system, whether it has been checked and when.
5. Keeping the Mapping Current
A control mapping built once and never revisited decays quickly with generative AI, faster than with most traditional systems. A new model version can change how the system responds to the same prompt injection attempt that failed last quarter. A new data source added to a retrieval system introduces a new path for data privacy risk that the original mapping never considered. A new vendor integration reopens the supply chain question.
The practical answer is to tie the control mapping to the same review triggers already tracked in the Part 2 risk register, rather than running it on a separate schedule. When a use case is flagged for review because of a model change, a new integration, or a scheduled reassessment, the control mapping and its evidence should be checked at the same time, not treated as a one-time setup task.
For financial institutions, the more effective path is usually to fold this work into whatever model risk management or third-party risk program already exists, rather than building a parallel gen AI specific process. A control and evidence structure that only the AI team understands is harder to defend during an examination than one that plugs into a review process the rest of the institution already runs.
Conclusion
A rated risk becomes a managed risk only once it is tied to a specific control and that control has evidence behind it. This part laid out three control catalogs to choose from, a starting map from the risk categories in Part 1 to specific control families, and the distinction between a control that exists on paper and one that can be shown to operate.
Part 4 of this series puts everything together. It takes a single use case, a retrieval-based chatbot, and carries it through the full pipeline: classification into a use case pattern, a specific threat model, an SP 800-30 rating shown as qualitative, semi-quantitative, and quantitative, a control mapping like the one started here, and a completed evidence record. The goal is to show the entire framework working end to end on one real example, rather than as separate pieces.
References
- NIST. Crosswalks to the NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0). https://www.nist.gov/itl/ai-risk-management-framework/crosswalks-nist-artificial-intelligence-risk-management-framework
- NIST. AI RMF Knowledge Base, Crosswalks. https://airc.nist.gov/airmf-resources/crosswalks/
- NIST. Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Revision 5. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
- NIST. The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024. https://www.nist.gov/cyberframework
- ISO. ISO/IEC 27001:2022, Information security management systems. https://www.iso.org/standard/27001.html
- ISO. ISO/IEC 42001:2023, Artificial intelligence management system. https://www.iso.org/standard/42001.html
- NIST. Guide for Conducting Risk Assessments, SP 800-30 Revision 1. https://csrc.nist.gov/pubs/sp/800/30/r1/final
- NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, July 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
- OWASP Gen AI Security Project. OWASP Top 10 for LLM Applications, 2025. https://genai.owasp.org/llm-top-10/
- MITRE. ATLAS, Adversarial Threat Landscape for Artificial-Intelligence Systems, including mitigations. https://atlas.mitre.org/