Risk and control isn't a fifth pillar. It runs through all four.
Governance, Compliance, Security, and Engineering are the site's structure-defining pillars. The Risk Library and Control Library underneath them are domain-spanning by construction — a prompt-injection risk is genuinely both a Security and an Engineering concern, not one or the other. This page is the orientation for how that library is built, not a duplicate of it.
Last reviewed: 2026-07-29
Nine categories, each mapped to one or more pillars.
48 risks across these nine categories, anchored to 14 standards and regulations. The domain tags shown here are what each pillar's own "Risks and controls in this domain" section queries live.
Model & Application Security
Attacks against the model or the application wrapped around it: prompt injection, insecure output handling, excessive agency.
Adversarial ML & Model Integrity
Attacks against the model artefact itself, and the operational discipline that catches them: evasion, extraction, backdoors, and the testing coverage that finds them before an adversary does.
Data Protection & Privacy
Lawful basis, minimisation, and the automated-decision safeguards that keep an AI system inside UK GDPR, not just inside what the model technically allows.
Fairness, Bias & Impact
Disparate outcomes across groups, and the impact-assessment discipline that catches them before deployment, not after a complaint.
Governance & Accountability
Who owns an AI system, who signs off on it, and whether that accountability is documented or assumed.
Third-Party & Supply Chain
Vendor and model provenance risk — carries the third-party lens (see below) and is the category most closely tied to SS2/21.
Operational Resilience
Whether AI is mapped into your important-business-service inventory, has an impact tolerance, and has been tested to fail — the SS1/21 lens applied to AI specifically.
Transparency & Explainability
Whether an AI system’s outputs and decisions can actually be explained to the person affected by them, not just logged.
Prohibited & High-Risk Practices
The EU AI Act's Article 5 bans — social scoring, real-time public biometric ID, manipulative systems. Deliberately thin on mapped controls: the correct response to a legal prohibition is not building it, not a technical control.
Four severity tiers.
Consistent across every risk in the library, regardless of category — severity is about harm potential, not about how technically interesting the risk is.
Critical
Realistic potential for material regulatory, financial, or safety harm if unmitigated — the risks that would stop a launch.
High
Significant harm potential, but bounded — usually mitigable with a defined, achievable control set rather than a redesign.
Medium
Real but contained harm potential, often already partially addressed by controls built for other purposes.
Low
Limited harm potential on its own — worth tracking and mapping, rarely worth a dedicated control in isolation.
How a risk connects to everything else.
Three separate mapping relationships, not one flat list of tags.
Risk → control, by effectiveness
Every risk–control mapping in the library is tagged primary, supporting, or compensating — not a flat "this control addresses this risk" list. A primary control is the main line of defence; a supporting control reduces likelihood or impact without fully addressing the risk; a compensating control is a fallback where the primary control isn’t feasible.
Risk → framework clause
Where a risk is cited by a specific regulatory or standards clause — an EU AI Act article, an ISO/IEC 42001 Annex A control, an SS1/21 or SS2/21 expectation — that citation is a direct reference, not an inferred theme match.
Risk → domain, resource, and lens
The v4 taxonomy adds facets on top of the original category: which of the four pillars a risk belongs to (a risk can span more than one), which industry it’s specific to, and whether it carries the third-party lens — see the taxonomy spec for the full mechanism.
Frequently asked questions
How many risk categories does the Axiom Verity Risk Library use?
Nine: Model & Application Security, Adversarial ML & Model Integrity, Data Protection & Privacy, Fairness/Bias & Impact, Governance & Accountability, Third-Party & Supply Chain, Operational Resilience, Transparency & Explainability, and Prohibited & High-Risk Practices.
What severity levels does the Risk Library use?
Four: Critical (realistic potential for material regulatory, financial, or safety harm), High (significant but bounded harm potential), Medium (real but contained harm, often already partially addressed), and Low (limited harm potential on its own).
Why do the EU AI Act Article 5 prohibited-practice risks have so few mapped controls?
Deliberately: the correct response to a legal prohibition is not building the system, not a technical control that manages the risk of building it anyway.
What does it mean for a control to be "primary," "supporting," or "compensating"?
A primary control is the main line of defence against a risk; a supporting control reduces its likelihood or impact without fully addressing it; a compensating control is a fallback used where the primary control isn't feasible.
Is risk a separate pillar alongside Governance, Compliance, Security, and Engineering?
No — it's the cross-cutting spine that runs through all four. A prompt-injection risk, for instance, is genuinely both a Security and an Engineering concern; treating risk as a fifth pillar would force an artificial split rather than reflecting how risk actually spans the other four.
The library itself is where the detail lives.
This page is the map. Every individual risk and control — severity, mappings, and framework citations — is in the libraries themselves.