Security frameworks & regulations
The shared language for AI security — which acronyms are laws, frameworks, standards, and threat references, how they stack together, and how Microsoft turns them into practice.
AI security comes with a crowd of acronyms, and they do not all do the same job. The EU AI Act, NIST AI RMF, ISO/IEC 42001, MITRE ATLAS, and OWASP Top 10 for LLM Applications tend to appear on the same slide, which makes them look interchangeable. They aren’t: a regulation can fine you, a standard can certify you, and a threat catalogue helps you build defenses — but none of them stands in for the others.
This guide sorts them out. By the end you should be able to look at any AI initiative and tell which items are legal obligations, which are governance systems, which are audit evidence, and which are engineering threat references — and why you need all four rather than a favourite.
What to take away
- Start by asking what kind of document you are holding. A law tells you what is mandatory. A framework organizes risk. A standard gives you something auditable. A threat knowledge base tells you how attackers behave.
- The EU AI Act is use-case law, not model law. The same model can be low risk in one product and high risk in another. Classification comes before architecture.
- NIST AI RMF and ISO/IEC 42001 are not competitors. NIST gives you the risk-management language; ISO 42001 gives you a certifiable AI management system.
- MITRE ATLAS and the OWASP LLM Top 10 belong closer to engineering. They turn “AI risk” into attack paths, design checks, and code-review questions.
- Compliance Manager helps prove governance. Use Purview for assessments and evidence; use build and runtime controls for the ATLAS and OWASP layer.
What is what
| Bucket | What it is | Do you have to follow it? | Useful analogy |
|---|---|---|---|
| Regulation / law | Government rules with legal force and penalties | Yes, if you are in scope | The speed limit |
| Framework | A structured way to organize and manage risk | Voluntary, but often expected | A playbook |
| Standard | A precise specification you can be audited or certified against | Voluntary unless a contract or regulator requires it | A certifiable building code |
| Threat knowledge base | A catalogue of how attackers behave | Reference material | The attacker’s pattern book |
| Build checklist | Practical risks and controls for implementation teams | Voluntary, but directly actionable | A code-review checklist |
Once you know the bucket, you know the job. Regulations say what must be true. Frameworks and standards help you run the program. Threat catalogues and checklists help you build and test the system.
The landscape
| Name | Bucket | The question it answers |
|---|---|---|
| EU AI Act | Regulation | Are we legally allowed to run this AI system, and under which obligations? |
| NIST AI RMF | Framework | How do we manage AI risk in a repeatable way? |
| ISO/IEC 42001 | Standard | Can we prove we govern AI through a formal management system? |
| MITRE ATLAS | Threat knowledge base | How do attackers target AI systems in practice? |
| OWASP Top 10 for LLM Applications | Build checklist | What should engineers check when designing and reviewing LLM apps? |
Read that table top to bottom and you move from the boardroom and legal team down into the architecture review and the pull request.
The Big Five
These are the five documents at the heart of the guide, in the order you meet them on a project — from the law that binds you down to the checklist your engineers run.
The EU AI Act
The EU AI Act is the legal layer. Like GDPR, it reaches beyond Europe: if an AI system is placed on the EU market, put into service in the EU, or its outputs are used in the EU in ways the Act covers, non-EU organizations can still be in scope.
The important design idea is that the Act regulates uses of AI, not AI in the abstract. The same foundation model can sit behind a low-risk writing assistant, a limited-risk chatbot, or a high-risk employment-screening system. The use case decides the tier.
| Risk tier | What it means | Examples |
|---|---|---|
| Unacceptable risk | Prohibited | Harmful manipulation, social scoring, certain exploitative or biometric uses |
| High risk | Allowed, but heavily regulated | Employment, education, credit, critical infrastructure, medical devices, law enforcement, migration, democratic processes |
| Transparency risk | Disclosure duties | Chatbots, deepfakes, and certain AI-generated content |
| Minimal or no risk | No specific AI Act obligations | Spam filters, many game or productivity features |
For architects, the first design decision is classification. A high-risk system carries obligations — risk management, logging, human oversight, robustness, and more — that have to be built in from the start, not added as paperwork later. So the practical move is to classify the use case early, document the reasoning, and design conservatively whenever a system might land in the high-risk tier.
The Act phases in over several years, and the exact dates have already shifted once. The order is the stable part: prohibitions first, then transparency duties, then high-risk obligations, with AI embedded in already-regulated products (medical devices, machinery) given the longest runway.
NIST AI RMF
The NIST AI Risk Management Framework is not a law. It is a voluntary framework for managing AI risk across the lifecycle. It gives teams a shared language, especially useful when security, legal, data science, product, and engineering all need to talk about the same system without collapsing into different vocabularies.
NIST organizes the work around four functions:
| Function | What it does |
|---|---|
| Govern | Establish roles, policies, accountability, culture, and oversight |
| Map | Understand the use case, context, stakeholders, impacts, and risk sources |
| Measure | Test and evaluate risks with metrics, evidence, and monitoring |
| Manage | Prioritize, mitigate, respond, and improve over time |
Govern wraps around the other three, which is the architectural clue: AI risk management is not a one-time gate. You classify, test, deploy, monitor, learn, and adjust.
NIST also published the Generative AI Profile (NIST AI 600-1), which applies the same Govern, Map, Measure, Manage structure to generative AI risks: hallucination, data leakage, toxic or harmful content, misuse, provenance, model supply chain, and other issues that show up more sharply with foundation models.
ISO/IEC 42001
ISO/IEC 42001 is the standard layer. It defines an AI Management System (AIMS): the policies, roles, objectives, controls, risk treatment, monitoring, and continual improvement process an organization uses to govern AI responsibly.
The easiest comparison is ISO/IEC 27001. ISO 27001 does not secure one server; it certifies that an organization has an information-security management system. ISO 42001 does the same kind of job for AI governance. It does not replace technical testing, threat modeling, or legal classification. It gives you a management system that can be audited.
That makes it useful in three situations:
- A customer asks for proof that your organization governs AI responsibly.
- A regulator or procurement process wants auditable evidence, not just a slide deck.
- Your organization already runs on ISO systems and wants AI governance to fit the same operating model.
ISO/IEC 23894 sits nearby. It is guidance for AI risk management, not a certifiable management-system standard. In practice, 23894 helps with the risk thinking; 42001 helps with the auditable system.
MITRE ATLAS
MITRE ATLAS is not a compliance framework. It is a threat knowledge base for AI-enabled systems, modeled in the spirit of MITRE ATT&CK.
That distinction matters. The EU AI Act may require cybersecurity and risk management. NIST may tell you to measure and manage risk. ISO may ask for evidence that your process works. ATLAS helps you ask the concrete security question: how would someone actually attack this thing?
ATLAS organizes adversary behavior into tactics, techniques, case studies, and mitigations. It covers AI-specific patterns such as data poisoning, model evasion, model theft, prompt injection, and attacks against the data and tooling around the model.
Use it when you threat-model:
| Architecture area | ATLAS-style question |
|---|---|
| Training and tuning data | Can an attacker poison the data or influence what gets learned? |
| Model endpoint | Can they extract, evade, or manipulate the model? |
| Retrieval layer | Can they plant malicious content that changes the model’s answer? |
| Tools and agents | Can they cause the AI to take an unauthorized action? |
| Telemetry and response | Would we know if any of this happened? |
ATLAS turns vague “AI is risky” concern into a concrete list of attack paths you can accept, mitigate, monitor, or rule out.
OWASP Top 10 for LLM Applications
The OWASP Top 10 for LLM Applications is the most engineering-facing item in this guide. It is the list you hand to the people designing, building, and reviewing LLM applications.
The 2025 list is:
| ID | Risk | Plain meaning |
|---|---|---|
| LLM01 | Prompt Injection | Malicious input overrides or hijacks the model’s instructions |
| LLM02 | Sensitive Information Disclosure | The app leaks secrets, personal data, or protected enterprise content |
| LLM03 | Supply Chain | Models, datasets, plugins, dependencies, or providers are compromised |
| LLM04 | Data and Model Poisoning | Tainted data changes model or application behavior |
| LLM05 | Improper Output Handling | The system trusts model output too much |
| LLM06 | Excessive Agency | The AI can do too much, too autonomously, with too little control |
| LLM07 | System Prompt Leakage | Hidden instructions or internal policy prompts are exposed |
| LLM08 | Vector and Embedding Weaknesses | The retrieval layer can be manipulated, poisoned, or queried unsafely |
| LLM09 | Misinformation | Confident wrong output causes decisions or actions that harm the business |
| LLM10 | Unbounded Consumption | Cost, compute, or availability is exhausted through abuse or runaway use |
Prompt injection deserves special attention because it is the AI-native version of untrusted input. Any design that lets a model read email, web pages, tickets, documents, chat messages, or other user-controlled content has to assume those inputs may contain instructions meant for the model, not for the human.
A few more worth knowing
Not every useful reference needs a full section, but these are worth placing on the map.
| Reference | Where it fits | Why it matters |
|---|---|---|
| Microsoft Responsible AI Standard | Responsible AI governance | Microsoft’s internal standard built on fairness, reliability and safety, privacy and security, inclusiveness, transparency, and accountability |
| Microsoft Secure Future Initiative | Security operating model | Microsoft’s security-wide engineering and governance push; useful context for how Microsoft frames AI security alongside identity, telemetry, and secure-by-design work |
| ISO/IEC 27001 | Security management system | Not AI-specific, but still the security-management foundation many AI controls sit on |
How the layers stack
The clean way to use these references is to stack them, not choose one.
| Layer | Primary references | Architect’s question |
|---|---|---|
| Law | EU AI Act | Are we allowed to do this, and what is mandatory? |
| Govern | NIST AI RMF, ISO/IEC 23894 | How do we manage the risk lifecycle? |
| Prove | ISO/IEC 42001 | Can we show an auditable AI management system? |
| Threat-model | MITRE ATLAS | How will attackers target this design? |
| Build and review | OWASP Top 10 for LLM Applications | What must engineering check before and after release? |
The layers reinforce each other. A threat model based on ATLAS and design review based on OWASP gives you evidence for NIST Measure and Manage. A NIST-shaped operating model gives substance to ISO 42001. That same evidence helps with EU AI Act obligations where the system is in scope.
Where Microsoft fits
Frameworks and threat catalogues only matter if something turns them into daily practice. On Microsoft, the starting point is proving the governance; from there, a range of runtime controls secure the agents that governance covers.
Purview Compliance Manager
The frameworks are documents. Microsoft Purview Compliance Manager is where some of them become assessments: scored controls, improvement actions, ownership, evidence, and progress tracking.
Compliance Manager includes premium AI templates for:
| Framework or regulation | Guide layer | Compliance Manager template |
|---|---|---|
| EU AI Act | Law | EU Artificial Intelligence Act |
| NIST AI RMF 1.0 | Govern | NIST AI Risk Management Framework (RMF) 1.0 |
| ISO/IEC 42001:2023 | Prove | ISO/IEC 42001:2023 |
| ISO/IEC 23894:2023 | Govern | ISO/IEC 23894:2023 |
This is useful because the same improvement action can support more than one assessment. Logging, human oversight, data governance, access control, documentation, and incident response show up across multiple frameworks. Do the control once, keep the evidence clean, and it can improve more than one score.
Build and Runtime Controls
Compliance Manager proves the program. Securing the running system is a separate job, and the right controls depend on how each system is built and what it does.
For agentic AI, the through-line is Microsoft Agent 365 — it gives every agent an identity and brings it under the same security controls you use for users and devices — combined with the guardrails inside the tools and platforms agents are built on. But AI is more than agents, so every capability that provides security and data protection — across identity, data, and threat detection — matters at some point.
The point isn’t the product list. It’s the order: prove the program first, then bring the running system under the controls that fit how it was built.
Where to start
For a new AI system, run the stack in this order:
- Classify the use case. Start with the EU AI Act risk tier if the EU is in scope, and document the reasoning.
- Pick the governance spine. Use NIST AI RMF to structure roles, risk mapping, measurement, and management. Use ISO/IEC 42001 if you need certification-ready governance.
- Threat-model the architecture. Walk MITRE ATLAS against the model, retrieval layer, data pipeline, tools, identities, and monitoring path.
- Review the build. Use OWASP Top 10 for LLM Applications as the design and code-review checklist.
- Operationalize the evidence. Create the relevant Compliance Manager assessments and assign owners for improvement actions.
- Operationalize the defense. Wire telemetry, posture findings, red-team results, and runtime detections into the security operating model.
The mistake is doing these in reverse: building the agent, writing a compliance story afterward, and hoping the evidence appears. The right pattern is the opposite. Decide the legal tier, design the governance and evidence trail, threat-model the system, and then build the controls into the product.