AI Security Framework: Which One Will an Auditor Accept?

Choosing an AI security framework used to be a matter of taste: a CISO picked the vendor diagram that matched the stack and moved on. In 2026 an auditor or a notified body will ask which framework you adopted, why, and what it produced. The market offers more than fifteen candidates, from the EU AI Act’s own Article 15 to Google’s SAIF and the CSA’s AI Controls Matrix. This article sorts them into four families, compares them in one table, and ends with a selection rule by role and the evidence an auditor accepts.

Key takeaways

• An AI security framework is a named, versioned set of threats, controls or responsibilities that another party can check you against; the four families (law, threat catalogue, control set, responsibility model) answer different questions.
• EU AI Act Article 15(5) names the attacks a high-risk system must resist: data poisoning, model poisoning, model evasion, confidentiality attacks and model flaws. That list is what you must prove you tested.
• October 2026 moved the goalposts: ISO/IEC 27090:2026 was published and EN 18286 became the first harmonised standard cited in the Official Journal.
• Only CSA AICM and Databricks DASF ship control-level crosswalks to the EU AI Act and ISO/IEC 42001; SAIF, CoSAI, AWS, Microsoft and Cisco carry no legal mapping.
• Since the Digital Omnibus, a product with digital elements can meet Article 15 cybersecurity through its Cyber Resilience Act declaration of conformity (new Article 42(3)).

What an AI security framework is, and what it is not

An AI security framework is a published, versioned set of threats, controls or responsibilities for securing an AI system (its data, model, pipeline, application layer and, since 2025, its agents) that a third party can use to check your work. The word covers four families that answer four questions. The law says what you must prove: Article 15 of the EU AI Act, Article 55(1)(d) for systemic-risk models, the Cyber Resilience Act. The threat catalogues say what you must test: MITRE ATLAS, OWASP, NIST AI 100-2. The control sets say what you must evidence: CSA AICM, DASF, ISO/IEC 42001 Annex A, ISO/IEC 27090, the NIST overlays, ETSI EN 304 223. The responsibility guidance says who owns which control: SAIF, CoSAI, the AWS and Microsoft shared-responsibility models.

Three things are not an AI security framework, whatever the search results say. An AI security posture management product is a tool category that discovers assets and misconfigurations; it can implement controls, it cannot be the claim. An AI safety framework addresses harmful outputs and misuse; Cisco argued on 16 December 2025 that security and safety are inseparable, but the AI Act keeps them in separate articles. And the AI governance framework is the wider operating model in which a security framework is one control domain. Our AI security guide explains why the obligation exists; this article is about choosing the instruments that satisfy it.

The 2026 map: the frameworks in one table

The table says what each item is, not which one to adopt; the families decide that, and the next four sections take them in turn. Two notes first. Cisco’s Integrated AI Security and Safety Framework (16 December 2025, 19 attacker objectives, more than 150 techniques) is a taxonomy and sits with the threat catalogues. And the two NIST items that comparison pages present as baselines, the Cyber AI Profile and the SP 800-53 overlays, had not reached a public draft by 30 October 2026.

Threat catalogues: what Article 15(5) tells you to test

Article 15(5) of the AI Act names the attacks. A high-risk system must be “resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities”, with measures against “data poisoning”, “model poisoning”, “adversarial examples or model evasion”, “confidentiality attacks or model flaws”. The catalogues give those classes technique names, test cases and mitigations.

MITRE ATLAS is the reference knowledge base: release 2026.10 of 28 October 2026 holds 16 tactics, 129 techniques, 92 sub-techniques, 44 mitigations and 77 case studies, with monthly releases since mid 2026. Our MITRE ATLAS guide turns a technique into a control and a record.

The OWASP Top 10 for LLM Applications 2026, released on 3 August 2026, runs from LLM01 Prompt Injection through LLM05 Data and Model Poisoning to LLM10 Improper Output Handling; the Agentic Top 10 of 9 December 2025 adds ASI01 Agent Goal Hijack to ASI10 Rogue Agents. We read both as audit evidence in our OWASP Top 10 for LLM and agentic AI security guides.

NIST AI 100-2 E2025, final on 24 March 2025, is the shared vocabulary: one taxonomy for predictive AI (evasion, poisoning, privacy) and one for generative AI (supply chain, prompt injection, agents), each class paired with mitigations, with annual updates planned. Our NIST AI 100-2 guide maps its identifiers to Article 15 evidence, and the adversarial AI explainer covers the mechanics.

Control sets: where an AI security framework becomes evidence

A control set is where an AI security framework stops being a reading list and starts producing records. Three candidates are mature enough to adopt today.

The CSA AI Controls Matrix v1.1 of 22 June 2026 holds 247 control objectives in 18 domains, organised by five pillars (control type, applicability and ownership, architectural relevance, lifecycle relevance, threat category). It ships mappings with gap analysis to ISO/IEC 42001, ISO 27001, the NIST AI RMF and AI 600-1, BSI AIC4 and the EU AI Act, a 320-question AI-CAIQ questionnaire, and a STAR for AI programme with a Level 1 self-assessment and a Level 2 certification on top of ISO 42001 or 27001. It is the natural choice when you already run the Cloud Controls Matrix or ISO 27001, since the CSA describes it as a superset of CCM v4.1.

The Databricks AI Security Framework 3.0 of 20 March 2026 covers 13 components, 97 risks and 73 controls, with a compendium that says which controls apply to which component, and mappings to ATLAS, OWASP, NIST SP 800-53, the CSF, ENISA, ISO/IEC 42001, ISO/IEC 27001 and the EU AI Act. It is platform-shaped: excellent when your models live in a lakehouse, incomplete when they do not.

ISO/IEC 42001:2023 is the only certifiable option. Its Annex A carries the controls that bear on security: requirements and specification (A.6.2.2), verification and validation (A.6.2.4), deployment (A.6.2.5), operation and monitoring (A.6.2.6), technical documentation (A.6.2.7), event logs (A.6.2.8), the data controls of A.7.2 to A.7.6, incident communication (A.8.4) and suppliers (A.10.3). What those controls mean for an AI system is now spelled out by ISO/IEC 27090:2026, published in October 2026 by SC 27: 56 pages of guidance on AI-specific security threats, not certifiable, but what an ISO 27001 or 42001 auditor will read next to your evidence. Our ISO 42001 explainer covers the management system itself.

The NIST instruments deserve a caveat. The SP 800-53 Control Overlays for Securing AI Systems exist as a concept paper of 14 August 2025 and one annotated outline of January 2026; the Cyber AI Profile is an initial preliminary draft of 16 December 2025 whose comment period closed on 30 January 2026, with NIST planning an initial public draft in 2026. Neither is a baseline you can cite yet, and the NIST AI RMF itself has no controls. ETSI EN 304 223, grown from the UK AI Cyber Security Code of Practice of 31 January 2025, is the one baseline with numbered provisions: 13 principles and 72 provisions across five phases. The NCSC and CISA guidelines of 2023 and ENISA’s FAICP are practice, not baselines. Our rule: one control set, one gap analysis against the law, kept as a living document.

Architecture and shared responsibility: SAIF, CoSAI, AWS, Microsoft

The fourth family answers the question the control sets leave open: who owns each control when the model, the platform and the application belong to different parties.

Google’s Secure AI Framework organises the system into four component areas (data, infrastructure, model, application) and maps 15 risks to 24 controls. SAIF 2.0, announced on 6 October 2025, extends it to agents with a dedicated risk map and three principles: well-defined human controllers, limited powers, observable actions and planning. Google donated the SAIF data to CoSAI in September 2025, where it lives on as the CoSAI Risk Map.

CoSAI, the OASIS coalition launched in July 2024, is now the most productive source of responsibility guidance. Its principles for secure-by-design agentic systems of 16 July 2025 (human-governed and accountable; bounded and resilient; transparent and verifiable) were followed by an AI Incident Response Framework in October 2025 with playbooks mapped to ATLAS, the AI Shared Responsibility Framework v1.0 in May 2026, five layers with one responsible party per component, and MCP Security v2.0 and Zero Trust for AI Systems in September 2026.

The cloud providers publish the same idea as a scoping exercise. The AWS Generative AI Security Scoping Matrix of October 2023 sorts a use case into five scopes from consumer app to self-trained model, and the AWS AI Security Framework of May 2026 layers cumulative controls across three phases. Microsoft’s AI shared responsibility model and its agent model of August 2026 do the same for SaaS, PaaS and IaaS agents, with risks mapped to OWASP and ATLAS.

These instruments say who owns a control and where it sits, and they do it well. None maps to Article 15, and none produces the record an authority asks for. Use them to allocate controls between you and your vendors, never to claim compliance.

The law behind the AI security framework: Article 15, Article 42(3), the CRA

Every AI security framework in the table exists because a legal text now requires security as a property of the system. Article 15(1) asks providers of high-risk AI systems to “achieve an appropriate level of accuracy, robustness, and cybersecurity” throughout the lifecycle; 15(4) requires resilience to errors and faults; 15(5) names the attacks quoted above. Article 13(3)(b)(ii) makes the instructions for use state the tested levels. For general-purpose AI models with systemic risk, Article 55(1) has applied since 2 August 2025: documented adversarial testing under point (a) and, under point (d), “an adequate level of cybersecurity protection for the general-purpose AI model with systemic risk and the physical infrastructure of the model”.

Two presumptions of conformity decide which framework an auditor will accept. Article 42(2), applicable from 2 August 2026, covers systems certified under a Cybersecurity Act scheme cited in the Official Journal. The Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026, added Article 42(3): a high-risk system within the scope of the Cyber Resilience Act that fulfils its Article 12(1) is deemed to comply with Article 15 cybersecurity. CRA Article 12 sets the conditions: the product meets the Annex I essential requirements, the manufacturer’s processes meet Annex I Part II, and the CRA declaration of conformity demonstrates the Article 15 level; AI Act notified bodies may check the CRA requirements in the same procedure. Recital 77 limits the route to cybersecurity, not robustness and accuracy.

The dates matter. After the Omnibus, the Annex III obligations apply from 2 December 2027 and the Annex I product obligations from 2 August 2028; the Cyber Resilience Act applies in full from 11 December 2027, with its Article 14 reporting duties live since 11 September 2026. On standards, October 2026 was the turning point: EN 18286, the quality management standard, became the first harmonised standard cited in the Official Journal by Commission Implementing Decision (EU) 2026/2274 of 12 October 2026, and the cybersecurity specification prEN 18282, drafted by JTC 21 working group 5 for Article 15, closed its public enquiry on 14 July 2026 against a request deadline of 28 February 2027. ENISA’s view on cybersecurity in the frontier AI era of 7 July 2026 reads NIS2, the CRA and the AI Act together for systemic-risk models. A security breach is reportable under Article 73 only when it is a serious incident under Article 3(49), as our incident reporting guide details; the high-risk classification guide tells you whether Article 15 applies to you at all.

How to choose: a selection rule by operator role

Three rules make the table work. First, one of each: one control set, one threat catalogue, one responsibility model. Three control sets give you three partial mappings and no owner for the gaps between them; the AICM already contains the ISO 42001 and NIST crosswalks. Second, map once to Article 15(5): every control should trace to one of the named classes or be marked as general hygiene, and every class should have at least one test in your catalogue. Third, keep the mapping under change control. A new framework version (ATLAS ships monthly, the AICM grew from 243 to 247 controls in a year), a new model or a first agent re-opens it, and the conformity assessment of a high-risk system is re-run after a substantial modification.

Your role is the first entry in your AI inventory, and it changes with the system: fine-tune a vendor model for a high-risk purpose and you become its provider.

From framework to audit evidence: what the AI security framework must leave behind

A framework an auditor cannot see in your records is a framework you did not adopt. Seven artefacts turn the choice into evidence.

1. The control mapping with gap analysis against Article 15. The AICM and the DASF each ship one; the mapping lists every control, its owner, its status and the Article 15(5) class it serves.
2. The threat model per system, written against the six named attack classes, naming the ATLAS or OWASP entries you consider relevant and the ones you ruled out, with the reason.
3. Adversarial test and red-team reports, dated and re-run after each material change. Our AI red teaming guide sets out what Article 55 makes mandatory and what good practice adds.
4. The Annex IV cybersecurity section and the metrics in the instructions for use: the documentation describes the measures, Article 13(3)(b)(ii) publishes the tested levels.
5. The vendor questionnaire and the shared-responsibility split: the AI-CAIQ answers, the signed matrix and the vendor’s evidence for the controls it owns, stored next to your AI bill of materials.
6. Incident playbooks and the Article 73 decision log: the CoSAI incident framework gives the playbook format; the log records, for each security event, whether it met the serious-incident definition and when the authority was told.
7. The SAIF or DASF risk report, filed as a working paper. It shows the reasoning behind the controls you picked; it is never the compliance claim.

Where the seven artefacts live decides whether they survive an audit. They belong in the governance platform that holds the inventory: one record per AI system, one control set attached to it, every piece of evidence dated and linked to the control it proves, so that compliance monitoring runs on the records the auditor will read. That is what makes an AI system auditable, and it is the loop AI Sigil runs.

FAQ

<b>What is an AI security framework?</b>

An AI security framework is a published, versioned set of threats, controls or responsibilities for securing an AI system that a third party can check you against. The term covers four families: the law (EU AI Act Article 15, the Cyber Resilience Act), threat catalogues (MITRE ATLAS, OWASP, NIST AI 100-2), control sets (CSA AICM, DASF, ISO/IEC 42001 Annex A, ISO/IEC 27090) and responsibility models (SAIF, CoSAI, AWS, Microsoft). A complete programme uses one of each.

<b>Which AI security framework does the EU AI Act require?</b>

None by name. Article 15 states the result: an appropriate level of accuracy, robustness and cybersecurity, with resilience to data poisoning, model poisoning, model evasion, confidentiality attacks and model flaws. Harmonised standards will give a presumption of conformity once cited in the Official Journal; the first, EN 18286 on quality management, was cited in October 2026, and the cybersecurity draft prEN 18282 is still in progress. Until then, any framework that maps to Article 15(5) and produces evidence is acceptable, and a CRA declaration of conformity can carry the cybersecurity part under Article 42(3).

<b>Is ISO/IEC 27090 a certifiable standard?</b>

No. ISO/IEC 27090:2026, published in October 2026 by ISO/IEC JTC 1/SC 27, is a 56-page guidance document on addressing security threats and compromises to AI systems. It defines no management system and cannot be certified on its own. Its value is interpretive: it tells an ISO/IEC 27001 or 42001 auditor what the security of an AI system means, so the controls you run under those certifiable standards are judged against a recognised reading. ISO/IEC 27091, the privacy counterpart, reached FDIS in July 2026.

<b>NIST AI RMF or the NIST Cyber AI Profile: which one is the AI security framework?</b>

Neither, yet. The AI RMF 1.0 of January 2023 is a risk framework whose “secure and resilient” characteristic and Manage function point to security without prescribing controls. The Cyber AI Profile (NIST IR 8596) is a CSF 2.0 community profile with three focus areas (securing AI components, AI-enabled defence, thwarting AI-enabled attacks), but as of October 2026 only an initial preliminary draft of December 2025 exists, and the SP 800-53 overlays are at the concept stage. Use the AI RMF for governance language and wait for the profile before citing it.

<b>Do I need an AI security framework if my vendor runs the model?</b>

Yes, a different one. As a deployer you do not design the model, but Article 26 requires you to use the system according to its instructions, monitor it and suspend it when a risk appears, and Article 73 can oblige you to report. Your framework is the shared-responsibility matrix (CoSAI, AWS or Microsoft) that records which controls the vendor owns, the AI-CAIQ questionnaire the vendor answers, and the OWASP Agentic Top 10 if the system acts as an agent. The evidence is the questionnaire, the matrix and your monitoring log.

<b>What is the difference between an AI security framework and AI security posture management?</b>

A framework is a document that says what must be true; posture management is a tool category that scans your estate for assets, misconfigurations and exposures and reports what is true today. A scanner can implement and monitor controls from the AICM or DASF, useful evidence of operation, but it cannot be the framework: an auditor needs the mapping to Article 15(5), the owners and the dated records, not a dashboard. Adopt the framework first, then choose tooling that reports against it.

Conclusion

The question “which AI security framework should we adopt” has a structured answer in 2026. The law decides what you must prove: Article 15(5) names the attacks, Article 55(1)(d) covers systemic-risk models, and Article 42(3) opens the Cyber Resilience Act route for products with digital elements. The threat catalogues decide what you test, and ATLAS, OWASP and NIST AI 100-2 are mature enough to pick from. The control sets decide what you show, with CSA AICM 1.1 and ISO/IEC 42001 Annex A read through ISO/IEC 27090:2026 as the two defensible choices today. The responsibility models decide who owns each control, which is all they decide. Pick one of each, map once to Article 15(5), keep the mapping under change control, and file the seven artefacts where an auditor can find them. If your records cannot show the framework, start with the inventory and work forward.