Purpose of the Toolkit
The AI Risk Management Toolkit supports anyone involved in the design, operation, procurement and delivery of products empowered by or enabled by AI. It is intended as a starting point for multi-disciplinary project teams looking to implement good risk management practices across the full AI lifecycle.
Quick navigation
What's in the toolkit
Best practice aligned with the Orange Book's Risk Management Framework.
A set of probing questions to expose where AI risks are hiding for your specific solution.
A record of identified risks, their assessment and associated treatment actions.
An overall perspective on the risk profile of the AI solution with chances of different degrees of success and failure.
Why ongoing risk management matters
- AI systems change and evolve during their lifetime — there is no "final version" to validate against.
- The ability to address risks is maximised if they are identified at the outset (legal, ethical and robust by design).
- The legal, regulatory and ethical landscape, and technical capabilities, are continually evolving.
- Risks and treatments must be continuously re-assessed — new risks may arise, or treatments may lose efficacy.
The Toolkit implements Section D (Risk Management Processes): risk identification and assessment, risk treatment, risk monitoring, and risk reporting. It is designed to work together with the Cyber Assessment Framework (CAF).
The AI Risk Management Team
A multi-disciplinary team is required to drive active risk identification and management. The team should ideally be led by an identifiable individual known as an AI governance officer. An individual or smaller team may hold multiple responsibilities.
Roles and responsibilities
| Role | Responsibilities |
|---|---|
| AI governance officer | Implementation and oversight of processes, activities and policies relating to the use of AI within the organisation, directorate or team. |
| Senior leaders | Steer the direction and success of AI solutions through defining a long-term vision and setting risk appetite and tolerance. |
| Data teams | Manage the environment and process through which AI solutions are developed; manage data architecture, flows and lineage. |
| AI practitioners | Data scientists, ML/AI engineers responsible for producing AI solutions that automate tasks and solve key problems. |
| Security team | Ensure AI solutions and infrastructure function safely; monitor and minimise threat of cyber-attacks; ensure compliance. |
| Legal & compliance | Ensure AI solutions operate in alignment with applicable laws, regulations and organisational policies. |
| Business domain experts | Provide insights and expertise in the production and implementation of AI solutions within a specific context. |
| End users | Direct and indirect stakeholders who engage with and use AI solutions, including internal colleagues and external stakeholders. |
GDS encourages departments to keep a central log of AI risks and share these with GDS and DSIT's Central AI Risk Toolkit Team (CAIRF). This helps prioritise risks where investment in causal mapping and treatment options would provide maximum benefit.
AI Risk Identification
A risk is a potential future uncertain event that affects your objectives and impacts the outcomes. Your team should aim to identify as many potential scenarios as possible, however unlikely they may seem.
- When a machine learning model has sufficient monitoring to capture drift and the underlying model is updated.
- After Alpha and Beta releases.
- Upon creating a live service — continuously monitor performance and stress test.
- Use real-world Alpha/Beta scenarios to monitor unforeseen failures and analyse past incidents.
The nine AI risk categories
Use these categories to direct activities and ensure thorough investigation. Click each category to see scope.
💰 Financial
Risks that could lead to financial losses for the organisation, including increased operational costs, expenses related to fixing or maintaining AI solutions, and potential financial implications from automated decisions.
⚖️ Legal and regulatory compliance
Risks related to failing to meet legal frameworks, regulatory regimes and guidance — including data protection, equality law, and compliance with evolving AI-specific laws (e.g. EU AI Act, UK GDPR).
🔍 Appropriate transparency and explainability
Risks related to the AI solution's lack of transparency or explainability — whether users and those impacted understand how it works, its decision-making, and that they are interacting with AI.
⚖️ Fairness
Risks of the AI solution being unfair, biased, or discriminatory towards specific groups; impact on individual rights or creation of unfair market outcomes; compliance with equality laws.
👥 Accountability and governance
Risks associated with a lack of clear accountability and effective governance — identifying who is responsible, establishing risk management processes, ensuring clear communication and roles.
🛡️ Contestability and redress
Risks related to the ability of users or affected parties to contest outputs or seek redress if harmed — accessible and transparent redress mechanisms and procedures.
⚙️ Technical robustness
Risks related to the AI solution's ability to function reliably and maintain performance — data quality, model reliability, and ability to perform under unexpected situations or data.
🔒 Security
Risks from threats arising from deployment — data poisoning, leakage, cyber-attacks. Whether the organisation is more vulnerable and if security measures are in place.
🌍 Risks to people and the environment
Risks concerning impact on physical and mental well-being, safety of critical infrastructure and the environment — likelihood of safety-related incidents and mitigation steps.
AI Risk Appetite
Before planning risk treatments, the severity and likelihood of a risk must be compared to the risk appetite. This appetite should be set at an organisational level, aligned with the department's wider risk appetite, and signed off at board level.
Without clearly defined and measurable levels of risk appetite, users will encounter challenges and blockers when trying to manage risks for new AI tooling — stifling innovation. A properly communicated and appropriate risk appetite actively enables your organisation to achieve its targets.
Appetite levels (Orange Book aligned)
Appetite by risk category
Use the dropdowns below to compare appetite levels across each AI risk category.
Legal, regulatory and compliance
| Level | Definition |
|---|---|
| Averse | Zero appetite for any AI project with the chance of legal challenge, even if highly unlikely to be successful. |
| Minimal | Appetite limited to AI projects with no chance of any significant legal challenge. |
| Cautious | Appetite limited to AI projects with little chance of a successful legal challenge. |
| Open | Appetite for projects with potential to expose the department to legal challenge, but only where mitigation steps are taken and gain outweighs impact. |
| Eager | Appetite for projects with potential to expose the department to legal challenge where chances of a successful challenge are high but exceptional benefits could be realised. |
Accountability and governance
| Level | Definition |
|---|---|
| Averse | Avoid AI projects with accountability/governance risk. No decisions outside AI processes; significant resource on detection and prevention. |
| Minimal | Willing to consider low accountability/governance risk projects which support delivery of priorities; robust controls and sanctions. |
| Cautious | Willing to consider projects where benefits outweigh some risk; processes enable cautious risk taking. |
| Open | Ready to take on projects with accountability/governance risk when benefits outweigh risks; controls varied to reflect scale. |
| Eager | Ready to take on high-risk AI projects when benefits outweigh risks; processes support informed risk taking. |
Contestability and redress
| Level | Definition |
|---|---|
| Averse | Zero appetite where third parties could contest an AI decision or outcome. |
| Minimal | Limited to projects with very small likelihood of being contested. |
| Cautious | Little chance of contestation, with appropriate steps to minimise likelihood. |
| Open | Potential for contestation, with steps taken to minimise likelihood. |
| Eager | Likely to be contested — only where potential benefits outweigh risks. |
Appropriate transparency and explainability
| Level | Definition |
|---|---|
| Averse | Avoid projects with associated transparency/explainability risks; significant resource on open communication. |
| Minimal | Willing to consider low transparency/explainability risk projects supporting delivery. |
| Cautious | Appropriate processes ensure communication of information; enable cautious risk taking. |
| Open | Considered risk taking; controls varied; trade-off between accuracy and explainability. |
| Eager | High-risk projects when benefits outweigh transparency/explainability risks. |
Fairness
| Level | Definition |
|---|---|
| Averse | Zero appetite for projects that may impact rights, discriminate unfairly, or create unfair market outcomes. |
| Minimal | Low chance of repercussion to rights/discrimination; only if essential with significant mitigation (e.g. human-in-the-loop). |
| Cautious | Little chance of significant unfair impact; only if benefits outweigh risk with mitigation steps. |
| Open | Potential for impact on rights; benefits outweigh risks; appropriate controls to minimise. |
| Eager | High risk that rights will be impacted — only when exceptional benefits could be realised with appropriate steps. |
Technical robustness
| Level | Definition |
|---|---|
| Averse | Zero appetite for AI systems unable to reliably function as intended throughout the lifecycle. |
| Minimal | Only essential developments to protect current operations. |
| Cautious | Accept need for robustness with stress testing, KPIs and continuous improvement. |
| Open | Robustness considered to enable improved delivery; Agile principles may be followed. |
| Eager | New AI technologies viewed as key enabler; Agile embraced over secure-by-design. |
Environment and people
| Level | Definition |
|---|---|
| Averse | Zero appetite for high chance of repercussions to wellbeing or safety of critical infrastructure. |
| Minimal | Low chance of repercussion; only if essential with significant mitigation. |
| Cautious | Little chance of significant impact; only if benefits outweigh risk with mitigation. |
| Open | Potential for impact; benefits outweigh risks; appropriate controls. |
| Eager | High-risk projects where exceptional benefits could be realised. |
Security
| Level | Definition |
|---|---|
| Averse | No tolerance for security risks (data poisoning, leakage, perturbation, prompt injection). |
| Minimal | Minimal appetite; stringent security measures. |
| Cautious | Limited risks accepted to support business needs; appropriate security measures. |
| Open | Cautious acceptance to support business needs; controls varied to scale. |
| Eager | Willing to accept security risks to support business needs; security measures in place. |
Financial
| Level | Definition |
|---|---|
| Averse | No appetite for any financial impact or loss from the AI solution. |
| Minimal | Department willing to accept minimal financial impact if essential to delivery. |
| Cautious | Seeks safe AI delivery; cautious of residual financial loss; only if it provides benefits. |
| Open | Prepared to invest in AI for productivity benefits while minimising financial losses. |
| Eager | Prepared to invest for best possible benefits, accepting possibility of financial losses with controls. |
Quantifying AI Risks
Once risks are identified, score impact and likelihood between 1 and 5. The risk score is the product of likelihood × impact. Your team may apply weightings reflecting relative importance (e.g. an internal-facing system may weight contestability higher than financial).
Likelihood scale
| Level | Description | Probability range |
|---|---|---|
| 1 — Rare | Highly unlikely to occur | < 5% |
| 2 — Unlikely | Unlikely but possible | 5% – 20% |
| 3 — Possible | Possible to occur at some time | 20% – 50% |
| 4 — Likely | Likely to occur in many circumstances | 50% – 80% |
| 5 — Almost Certain | Almost certain to occur | > 80% |
Methods for estimating likelihood
Service uptime, frequency of use, historical user errors and bug frequency.
Accuracy, precision, recall, BERTscore — assessed during model development.
Engage AI specialists, data scientists, risk and legal experts.
Alpha/Beta user research in safe environments; iterate assumptions.
Risk matrix (Likelihood × Impact)
First identify if the impact is quantifiable. If not, consult with relevant stakeholders and experts to assign a sensible impact score. When a risk may result in multiple outcomes, assign weightings to each potential outcome, or use the highest impact score.
Impact Levels by Category
Impact scoring table from Appendix III. Quantifiable indicators are listed across four categories: Business, Staff, Service User/Citizen, and Reputation.
1 — Negligible
| Business | Staff | Service User/Citizen | Reputation |
|---|---|---|---|
| Operational downtime < 1hr; Financial loss < £10k; Service delivery delays < 1hr; Minimal strategic setback. | Turnover < 1%; Absenteeism < 1%; Training costs < £1k; No change in morale. | Access delays < 1hr; Complaints +<1%; Cost to citizen < £1k; No change in satisfaction. | Negligible media coverage; Minimal social sentiment; No public enquiries; No change in trust. |
2 — Minor
| Business | Staff | Service User/Citizen | Reputation |
|---|---|---|---|
| Downtime 1–4hrs; Loss £10k–£50k; Delays 1–4hrs. | Turnover 1–2%; Absenteeism 1–2%; Training £1k–£5k; Slight morale decrease. | Access delays 1–4hrs; Complaints +1–2%; Cost £1k–£5k. | Minor media coverage; Minor sentiment; Slight trust decrease. |
3 — Moderate
| Business | Staff | Service User/Citizen | Reputation |
|---|---|---|---|
| Downtime 4–8hrs; Loss £50k–£200k; Delays 4–8hrs. | Turnover 2–4%; Absenteeism 2–4%; Training £5k–£20k; Noticeable morale decrease. | Access delays 4–8hrs; Complaints +2–4%; Cost £5k–£20k. | Moderate media; Moderate sentiment; Noticeable trust decrease. |
4 — Major
| Business | Staff | Service User/Citizen | Reputation |
|---|---|---|---|
| Downtime 8–24hrs; Loss £200k–£1m; Delays 8–24hrs. | Turnover 4–8%; Absenteeism 4–8%; Training £20k–£100k; Significant morale decrease. | Access delays 8–24hrs; Complaints +4–8%; Cost £20k–£100k. | Major media; Significant sentiment shift; Significant trust decrease. |
5 — Catastrophic
| Business | Staff | Service User/Citizen | Reputation |
|---|---|---|---|
| Downtime > 24hrs; Loss > £1m; Delays > 24hrs; Innovation halt. | Turnover > 8%; Absenteeism > 8%; Training > £100k; Severe morale decrease. | Access delays > 24hrs; Complaints +>8%; Cost > £100k. | Severe media; Severe sentiment; Numerous public enquiries; Severe trust decrease. |
Non-quantifiable impact areas
- Strategic setback
- Resource diversion
- Innovation stagnation
- Dependence on technology
- Loss of human skills
- Morale & satisfaction
- Workplace culture
- Talent attraction
- Ethical dilemmas
- Adaptation challenges
- Citizen satisfaction
- Equity and fairness
- Social isolation
- Loss of privacy
- Public trust and confidence
- Brand perception
- Public perception of competence
- Decision-making transparency
Risk Treatment Options
Treatment options manage an identified risk to bring it within risk appetite or tolerance limits. Treatments should adhere to institutional standards and may evolve over the lifetime of the AI system.
Four treatment categories
Avoid any exposure to the risk — suitable when both potential impact and cost of mitigating are too high.
Take action to maintain risk levels within an acceptable range — a blend of acceptance and avoidance.
Shift all/portion of risk liability to third parties — appropriate when external expertise or resources are better suited.
Acknowledge the risk and accept potential impacts — appropriate when within the organisation's risk tolerance.
Suggested treatments by risk type
Poor accuracy or performance
- Limitation — Policies setting required level of human involvement in AI-augmented decision-making.
- Limitation — Policies and testing procedures for regular monitoring; metrics for fit-for-purpose and acceptable limits.
- Avoidance — Incident response procedures and real-time alerts when performance differs from pre-deployment tests.
- Avoidance — Procedures to bypass/deactivate the AI; redundant or backup systems.
- Limitation — Red-teaming/adversarial testing under stress conditions by independent experts.
- Transference — Make end users aware of limitations and responsibility for verifying outputs.
- Limitation — Proficiency standards and training material for end users.
Accountability
- Acceptance — Senior leaders own responsibility for organisational AI risk appetite.
- Acceptance — Identify a specific team or individual responsible for AI risk management across the organisation.
- Limitation — Accountability metrics for clear and transparent lines of responsibility.
- Limitation — Confidential feedback mechanisms and whistleblowing policies.
Bias and Fairness
- Limitation — Compliance with Data Protection Law, Equality Law and PSED; ICO/EHRC guidance; complete a DPIA.
- Limitation — Diverse project teams; participatory design approaches.
- Limitation — Testing and verification of data sets and models, including third parties.
- Limitation — Independent teams to counter implicit biases, groupthink and sunk cost fallacy.
Transparency
- Limitation — Standardised AI documentation with responsible owners and contact information.
- Limitation — AI model inventory system, regularly reviewed.
- Limitation — Document and review transparency tools; follow industry best practice.
- Limitation — Public disclosure of AI use and risk material (impact assessments, audits, model docs, test results).
- Limitation — Stakeholder engagement plans with feedback follow-up.
- Limitation — Transparency around decommissioning and retirement.
Explainability and interpretability
- Limitation — Develop explainable/interpretable solutions; use inherently explainable approaches (e.g. decision trees); visualisation, model extraction, feature importance; test explanations prior to deployment.
- Limitation — Document and review explainability tools; follow standards at time of use.
- Limitation — Auditability mechanisms — traceability, data sources, logging of processes/outcomes/impacts.
Privacy
- Limitation — Compliance with Data Protection Law; ICO guidance; complete a DPIA.
- Avoidance — Use privacy-enhancing technologies (PETs) and data minimisation (de-identification, aggregation).
Security
- Limitation — ML and end-point security countermeasures: robust models, differential privacy, authentication and throttling.
Hallucinations and misinformation
- Transference — Policies for end users to check AI-generated content for accuracy.
Legal compliance
- Limitation — Consider legal compliance from outset; close work with legal teams; follow EHRC/ICO and sector regulators.
- Limitation — Ongoing monitoring and review; preserve materials for forensic/regulatory/legal review.
- Limitation — Staff training and re-training on legal/regulatory considerations.
Does not deliver expected benefits
- Limitation — Policies to determine if AI is the right tool when weighing risks against benefits.
- Limitation — Define KPIs and success metrics for testing throughout the lifecycle.
- Limitation — Participatory stakeholder engagement; document and action feedback.
- Limitation — Keep narrow application scope to map benefits/risks more easily.
Failure of third party elements
- Limitation — Test, evaluate and validate third party data, software, hardware.
- Limitation — Processes for suppliers to report known or potential issues and vulnerabilities.
- Limitation — Redundancies covering third-party functions.
- Avoidance — Procedures to bypass the AI solution; redundant/backup systems for continuity.
- Transference — Robust warranty and indemnity provisions in contracts and licenses.
Risk Identification Question Bank
A condensed reference of probing questions from Appendix I. Use the search box to filter across all categories.
💰 Financial
- Are there any financial implications of using the AI tool that need to be considered (e.g. increased operational costs or scaling costs post-piloting)?
- Have financial risks from unstable AI systems and harmful results (errors requiring costly refurbishment and replacement) been considered?
- Is there a need for additional resources to fix and maintain the AI solution? Have financial implications been considered?
- Have potential financial implications related to non-compliance with legal provisions (including fines and reputational damage) been considered?
⚖️ Legal and regulatory compliance
- What legal frameworks and regulators/regulatory regimes are relevant given the deployment context?
- Have these been considered: Human Rights Law, Equality Law (PSED), Data Protection Law (UK GDPR), Intellectual Property, Social Value Act, applicable AI Laws (e.g. EU AI Act)?
- Have these regulatory regimes been considered: EHRC PSED guidance; ICO AI and data protection guidance?
- How will the AI solution be reviewed for compliance? How will the evolving landscape be regularly reviewed?
- How is the model trained? Does it involve open-source environments where compliance (e.g. Data Protection Law) is at risk?
- How is compliance ensured during deployment? When and how regularly is it monitored?
- What processes are in place if issues are discovered? Are they sufficient given the deployment context?
- Do you have the requisite internal expertise? What mandatory training do these individuals receive?
- What knowledge and skills do others in the organisation need about legal/regulatory requirements?
- What third party data, software, hardware or infrastructure is deployed? What are the terms of contract/licence?
- How do you ensure third party elements comply with relevant legal frameworks?
🔍 Appropriate transparency and explainability
- Who are the intended users? Do they need to know they are interacting with an AI? What explanations do they need?
- Who is impacted by the output and how? What are their expectations to know they are impacted by an AI?
- Have you complied with the GDS and RTA's Algorithmic Transparency Recording Standard?
- Are there minimum legal/regulatory standards for transparency and explainability?
- What action has been taken to maintain a regime that allows continued export to trading partners (e.g. EU AI Act)?
- What data is collected and what features are selected to train the model — and why? Why some data over others?
- Are users reliably aware of data obtained and how it is used? Can they access, consent or object?
- Can you explain what model was selected and why? Can you explain how it makes decisions and what influences outputs?
- Is it necessary to explain why the AI model has made a particular recommendation?
- Does deployment/scaling enable transparency about when people are interacting with AI?
- Do organisational policies promote transparency about AI use and outputs?
- Are outputs and explanations clearly and accurately communicated in a timely fashion?
- Does the organisation have the relevant internal expertise to enable the type of explanation required?
- Are there third party requirements for transparency and explainability? How are they complied with?
⚖️ Fairness
- What does fairness look like in the deployment context?
- Could the AI solution impact an individual's or organisation's legal rights?
- Does the AI solution unfairly advantage or disadvantage a particular group?
- Does the AI give biased or discriminatory outputs?
- Are there minimum legal/regulatory requirements (Equality Law, PSED, EHRC; Data Protection Law and ICO)?
- How has fairness, discrimination and bias been tested? How is it monitored?
- Have you considered intersectionality across protected characteristics?
- Could variables be proxies for protected characteristics? Can you test for proxies?
- How is selected data ensured to be a fair representation of the relevant population?
- Does the AI solution display bias toward certain groups? Is differential treatment legal and justified?
- Do you measure disparities in model predictions/outcomes? What is the remediation?
- What is the risk for the model to create toxic outputs?
- Is the service fair to those who object to automated decision making?
- Do third parties have fairness/bias requirements? How are they met?
👥 Accountability and governance
- Has an individual been identified who is ultimately accountable for the AI solution and its outputs?
- Who is responsible for AI risk management? Do they have right level of authority, human resource and budget?
- Is there a diverse team engaged in AI risk management?
- Are there legal/regulatory requirements for accountability and governance?
- Who is responsible for data collected and selected? How do they report to the overall responsible individual?
- Are data governance practices established to oversee compliance?
- Who is responsible for model selection, training, deployment, scaling and ongoing monitoring?
- How does AI risk management connect into existing organisational governance and risk controls?
- Are roles, responsibilities and lines of communication documented and clear?
- Are there policies for monitoring and mitigating AI risk across the whole lifecycle?
- Are whistleblower policies in place? Is there an incident response plan?
- Do responsible individuals have requisite skills, knowledge and authority?
🛡️ Contestability and redress
- Who are the types of users and what are their expectations to contest an AI output and seek redress?
- Who is impacted by an output and what are their contest/redress expectations?
- Are there legal/regulatory requirements for contestability and redress?
- Has GDPR's right to rectification been considered?
- Are there defined procedures for remediating harm caused by the AI solution? How are they reviewed?
- Are there redress mechanisms? Are they accessible and transparent (including for those with vulnerabilities)?
- Who is responsible for procedures and decisions on addressing harms? Do they have requisite skills/authority?
- What mechanisms address disputes for third party data/software/hardware? Is risk meaningfully passed to the third party?
⚙️ Technical robustness
- What level of performance must the AI solution maintain in its deployment context?
- Are there legal/regulatory requirements for technical robustness?
- How is performance measured and monitored? What metrics or data are used?
- Does the user have a role (human-in-the-loop)?
- What data is collected/selected to train the model? Is it suitable for the deployment context?
- How could performance/robustness be affected by data quality or pipeline issues?
- Will data be supplemented across the lifecycle? How is the dataset monitored in live deployment?
- Was the AI solution trained on data from other AI models? How are data quality and collapse risks managed?
- Is the model trained under conditions that mimic adverse conditions and natural drift?
- How is robustness ensured during deployment? When and how regularly is it tested (drift, misinformation)?
- Is a robust-by-design approach adopted?
- What processes are in place if issues are discovered?
- Do third party suppliers have contingency plans for failures/incidents?
🔒 Security
- What security threats arise from the deployment context?
- Has the organisation created new security risks by deploying the AI? Who are the new threat actors? (CAF Section A2 evidence)
- Are there legal/regulatory requirements for security?
- Has NCSC's guidance on principles for the security of machine learning been followed?
- Is there an overarching AI security strategy with clear policies/procedures? (CAF A1/B1 evidence)
- Could data collection/selection/processing cause security issues? (CAF B3 evidence)
- Is data selected from trusted sources, with management approval for exceptions?
- Are data sets tracked and verified via cryptographic hash? Uniquely identified for change detection?
- What type of data does the model ingest? Does it interact with business-critical or infrastructure?
- Could the model embed security vulnerabilities? Is training code reviewed by a responsible party?
- Is the model trained under conditions that mimic adversarial conditions?
- Are models adequately tested for vulnerabilities prior to deployment?
- Is a secure-by-design approach adopted? (CAF B1 evidence)
- Are disaster recovery and business continuity procedures in place? (CAF Objective D evidence)
- What security education exists for users and super users? (CAF B6 evidence)
- Are third party security requirements complied with? (CAF A4 Supply Chain evidence)
🌍 Environment and people
- Could the AI solution impact an individual's physical or mental well-being?
- Could it impact the safety of infrastructure or the environment?
- How will vulnerable users be protected?
- Are there legal/regulatory requirements for safety?
- How are safety risks measured and monitored?
- Could data collection/selection cause safety issues? Could data quality/pipeline issues affect safety?
- Could the chosen model cause safety issues? How could safety be affected by design and development?
- Could new safety issues arise from unexpected situations or data during deployment?
- Is a safe-by-design approach adopted? Are processes sufficient if issues are discovered?
- Does the organisation promote a culture of safeguarding end users, particularly vulnerable individuals?
- Are third party safety requirements complied with?
Additional Resources
AI Standards Hub
Standards Development Organisations (SDOs) — including ISO, IEC and IEEE SA — are actively developing standards addressing known AI risks. The AI Standards Hub has a database covering relevant standards and offers e-learning training on topics such as assessing and mitigating bias and discrimination in AI.
DSIT Central AI Risk Toolkit Team (CAIRF)
CAIRF is considering high-level AI risks by preparing common scenarios and mapping out their causes — helping teams better understand how to treat underlying causes.
Companion frameworks
Establishes risk management principles and processes for UK public sector. This toolkit implements Section D.
Evidence from CAF sections A1, A2, A4, B1, B3, B6 and Objectives C and D can be reused for AI security assurance.
Foundational principles teams can build upon when identifying risks.
GDS/RTA standard for transparency disclosure.
Key principles
- Risk management is an ongoing lifecycle activity — not a one-time task.
- A multi-disciplinary team is essential for thorough risk identification.
- Be proactive: take good risks in pursuit of opportunity, supported by appropriate controls.
- Reuse evidence from established frameworks (CAF, Orange Book) where applicable.
- Keep a central log of AI risks and share with GDS/CAIRF to support sector-wide learning.