Building a Gen AI Security Framework, Part 2: Scaling the Assessment

Part 2 of 4 in a series on building a practical, regulator-ready risk framework for generative AI.

Executive Summary

• Part 1 of this series laid out a working framework for assessing gen AI risk: NIST AI RMF as the foundation, NIST AI 600-1 to name the risks, SP 800-30 to rate them, and OWASP and MITRE ATLAS to ground those ratings in real attack behavior. That process works well for one system.
• The harder problem shows up once a company has ten gen AI use cases, then fifty, then a new one every month spun up by a different team on a different platform for a different purpose.
• Running the full five-step process from scratch on every use case does not scale. This part covers how to keep the same rigor while making it sustainable.
• The core levers are: build a reusable risk register organized by use case pattern, triage incoming use cases before assessing them, reuse ratings instead of re-deriving them, automate the intake process, and keep governance centralized while pushing assessment work to the edges.

The Bottleneck: One Assessment at a Time

The Part 1 process assumes a security or risk team sits down, maps a system against twelve risk categories, checks it against ten OWASP items, and rates likelihood and impact by hand. That is reasonable for a handful of high-stakes systems: a customer-facing chatbot, an agent with access to internal data, a coding assistant wired into production repos.

It breaks down when gen AI adoption is bottom-up. Marketing spins up a writing assistant. Support builds an internal Q&A bot on top of a vendor tool. Engineering wraps an API around a foundation model for a side feature. Each one technically needs a Map step and a risk rating, but a full manual assessment on all of them creates a backlog that never clears, and teams start deploying without waiting for review.

The fix is not to skip the framework. It is to make most of it reusable.

1. Build a Reusable Risk Register, Not a One-Off Assessment

The twelve risk categories in AI 600-1 do not change use case to use case. What changes is which categories apply and how severely. Most companies find their gen AI use cases fall into a small number of repeating patterns. The table below defines each pattern by the attributes that drive risk: what data it touches, who uses it, whether the model can take actions, and the default risk tier before any instance-specific factors are applied.

Pattern	Typical data access	User population	Model can take actions	Default risk tier
Internal knowledge assistant	Internal documents, policies, structured data	Employees only	No	Low to Medium
Customer-facing chatbot	Limited internal data, customer inputs	External, untrusted	No	Medium
Coding and dev-tool assistant	Source code, repositories, CI/CD context	Employees, developers	Sometimes (code execution)	Medium
Agent with tool access	Broad internal data, APIs, external services	Employees or automated	Yes	High
Embedded gen AI feature	Varies by host product	Varies	Varies	Inherits from host product, reassess on integration

Once your team has done a full Map and rate exercise on one system in each pattern, that assessment becomes a template. A new internal knowledge assistant does not need a fresh twelve-category walkthrough. It needs a check against the template for that pattern, with attention only to what is actually different: a new data source, a new user population, a new integration.

This is the single biggest lever for scaling: assess the pattern once, apply it many times, and only go deep when a use case breaks the pattern.

2. Triage Before You Assess

Not every use case deserves the same depth of review. A lightweight triage step, done in minutes rather than days, sorts incoming use cases into a track before any real assessment work starts. Three questions usually do most of the sorting:

1. Does it touch regulated or sensitive data (health, financial, biometric, PII)?
2. Is it exposed to external or untrusted users?
3. Can the model take actions, not just generate text (send emails, execute code, call APIs, move money)?

A “no” to all three routes to a lightweight review: confirm it matches an existing pattern in the risk register, apply the template rating, done. A “yes” to any one routes to a full assessment against the Part 1 process.

This mirrors how SP 800-30 already expects risk assessment effort to scale with stakes. The triage step makes that scaling explicit and fast instead of ad hoc.

3. Reuse Ratings, Don’t Re-Derive Them

When a new use case matches an existing pattern, its likelihood and impact ratings should start from the template rating, adjusted only for what is different. If a customer-facing chatbot pattern was already rated high likelihood for prompt injection (because OWASP and MITRE ATLAS both flag it as common and well-documented), a new chatbot on the same platform inherits that rating by default. The assessment work shifts from “figure out the rating from scratch” to “confirm nothing about this instance changes the rating.”

This also makes the OWASP and MITRE ATLAS references more useful at scale. Instead of manually walking the OWASP Top 10 for every system, maintain one mapping per pattern: which OWASP items apply, and which ATLAS techniques are realistic given that pattern’s exposure. New use cases in that pattern inherit the mapping. Only new patterns require a fresh walkthrough.

4. Automate the Repeatable Parts

The triage questions and the pattern-matching step are simple enough to run as an intake form rather than a meeting. A short questionnaire, filled out by the team requesting a new gen AI use case, can capture the data sensitivity, user exposure, and action-taking questions automatically, tag the use case to a pattern, and flag anything that does not fit cleanly for human review.

This does two things. It gives the security team a live inventory of gen AI use cases instead of a partial one built from memory and hallway conversations, which directly supports the Map function at a portfolio level, not just a system level. And it means most use cases get routed and rated within a day instead of waiting weeks for a manual review slot.

5. Keep Governance Centralized, Push Assessment to the Edges

Scaling the Measure and Map steps does not mean scaling ownership. The Govern function from Part 1 still holds: one owner, one policy, one place where risk acceptance decisions get recorded. What changes is who does the initial legwork. Teams building on an already-assessed pattern can self-serve through the intake process. Anything new, ambiguous, or high-risk still comes back to the central team for a full assessment.

This split keeps the framework credible. A board or regulator asking how gen AI risk is managed across the company needs one clear answer, backed by one risk register, even if dozens of teams are deploying gen AI features independently.

Put It Together: A Scaled Process

1. Build the risk register. Do full Part 1 assessments on one representative use case per pattern, and record the rating and the OWASP/ATLAS mapping for that pattern.
2. Triage. Route every new use case through the three-question check to decide lightweight or full review.
3. Match or assess. Lightweight cases confirm fit against an existing pattern. Anything that does not fit gets a full assessment and, if it is genuinely new, becomes a new pattern in the register.
4. Automate intake. Move the triage questions into a form so the inventory builds itself.
5. Review the register. Patterns age. A pattern rated low risk a year ago may not hold once model capabilities change or new integrations get added. Revisit the register on a fixed schedule, not just when something breaks.

Conclusion

A framework that only works for the first ten gen AI use cases is not a framework, it is a case study. The value of tying this work to NIST AI RMF, the Generative AI Profile, SP 800-30, OWASP, and MITRE ATLAS is that all five are built to apply consistently across many systems, not just one. Scaling the process is really about reusing that consistency instead of rebuilding it every time, so the answer to “how do you know your gen AI systems are safe” still holds at use case ten, fifty, and two hundred.

Part 3 of this series covers the next step: mapping the risks identified through this process to actual controls, and identifying the evidence that proves those controls work.

References

1. NIST. AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1, January 2023. https://www.nist.gov/itl/ai-risk-management-framework
2. NIST. AI RMF Playbook, companion guidance for implementing the RMF functions at scale. https://airc.nist.gov/airmf-resources/playbook/
3. 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
4. NIST. Guide for Conducting Risk Assessments, SP 800-30 Revision 1, September 2012. https://csrc.nist.gov/pubs/sp/800/30/r1/final
5. OWASP Gen AI Security Project. OWASP Top 10 for LLM Applications, 2025. https://genai.owasp.org/llm-top-10/
6. MITRE. ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. https://atlas.mitre.org/
7. ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system. https://www.iso.org/standard/77304.html