bmad-plus 0.4.4 → 0.6.0

package/src/bmad-plus/packs/pack-shield/references/iso42001/iso42001-ai-risk-assessment.md

@@ -0,0 +1,258 @@
+# ISO/IEC 42001:2023 — AI Risk Assessment & AISIA Methodology
+
+This reference covers the two mandatory assessments under Clause 6.1.2:
+1. **AI Risk Assessment** — evaluates risks to the organisation from AI systems
+2. **AI System Impact Assessment (AISIA)** — evaluates risks to individuals and society from AI systems
+
+Both must be completed for every AI system in scope. Both must be maintained and updated over time.
+
+---
+
+## Part 1: AI Risk Assessment
+
+### Purpose
+Identify, analyse, and evaluate risks associated with AI systems so that appropriate treatment decisions can be made. This is a **risk-to-the-organisation** lens (complement to the AISIA which takes a societal/individual lens).
+
+### Risk Assessment Framework
+
+**Step 1: Identify AI Risks**
+
+For each AI system in scope, identify risks across these categories:
+
+#### Model Risks
+| Risk | Description | Example |
+|------|-------------|---------|
+| Bias and unfairness | Model produces systematically different outputs for protected groups | Loan approval AI approves at lower rates for certain demographic groups |
+| Hallucination / confabulation | Model generates plausible-sounding but incorrect outputs | LLM generates false legal citations |
+| Model drift | Model performance degrades as real-world data distribution shifts | Fraud detection model misses new fraud patterns 12 months post-deployment |
+| Adversarial attacks | Inputs crafted to manipulate model outputs | Adversarial examples cause image classifier to misclassify |
+| Model inversion | Training data can be reconstructed from model outputs | Privacy violation — personal data extracted from model |
+| Overfitting | Model performs well in testing but poorly in production | High accuracy in evaluation, low accuracy on live data |
+
+#### Data Risks
+| Risk | Description | Example |
+|------|-------------|---------|
+| Training data quality | Poor quality data leads to poor model performance | Incomplete labels cause systematic errors |
+| Data poisoning | Attacker inserts malicious training data to manipulate model behaviour | Supply chain compromise of training dataset |
+| Privacy in training data | Training data contains PII or sensitive data unlawfully | Medical data used for AI training without lawful basis |
+| Data representativeness | Training data doesn't represent the deployment population | Model trained on US data deployed globally — cultural bias |
+| Data provenance gaps | Origin and rights for training data unknown | Copyright or licence violations in training data |
+
+#### Operational Risks
+| Risk | Description | Example |
+|------|-------------|---------|
+| Unintended use | AI system used for purposes not covered by AISIA | Internal HR tool used to screen job applicants |
+| System failure | AI system becomes unavailable or produces errors at scale | API outage causes customer-facing decisions to fail |
+| Scope creep | AI system expanded to new use cases without re-assessment | Chatbot expanded to give medical advice without clinical review |
+| Human over-reliance | Users accept AI outputs without appropriate scrutiny | Staff approve AI recommendations without verification |
+| Lack of explainability | Cannot explain AI decisions to affected individuals | Automated rejection letter with no basis provided |
+
+#### Supply Chain Risks
+| Risk | Description | Example |
+|------|-------------|---------|
+| Third-party model risk | Pre-trained model from vendor contains bias or backdoor | Open-source LLM used without bias evaluation |
+| API dependency | AI functionality depends on external API with reliability risk | Vendor changes model behaviour mid-contract |
+| Vendor lock-in | Cannot switch AI provider without major operational disruption | All AI inference tied to single cloud provider |
+| Third-party data handling | AI vendor handles sensitive data — data protection risk | Vendor uses customer data to retrain models without consent |
+
+#### Regulatory and Reputational Risks
+| Risk | Description | Example |
+|------|-------------|---------|
+| Regulatory non-compliance | AI system violates applicable law | EU AI Act high-risk AI system deployed without conformity assessment |
+| Reputational harm | AI system behaviour causes public trust damage | Discriminatory AI hiring tool exposed in media |
+| Liability | Organisation liable for AI system harm to individuals | AI medical diagnosis system misses condition — clinical liability |
+
+---
+
+### Step 2: Assess Risk Likelihood and Severity
+
+**Likelihood scale:**
+| Score | Level | Definition |
+|-------|-------|-----------|
+| 1 | Rare | May occur only in exceptional circumstances (<5% probability in system lifecycle) |
+| 2 | Unlikely | Could occur but not expected (5–25% probability) |
+| 3 | Possible | Might occur at some point (25–50% probability) |
+| 4 | Likely | Will probably occur in most circumstances (50–80% probability) |
+| 5 | Almost certain | Expected to occur frequently (>80% probability) |
+
+**Severity scale:**
+| Score | Level | Definition |
+|-------|-------|-----------|
+| 1 | Negligible | No meaningful harm; easily corrected |
+| 2 | Minor | Limited impact; correctable with minor effort |
+| 3 | Moderate | Significant but recoverable harm; some operational disruption |
+| 4 | Major | Serious harm; difficult to reverse; significant operational or reputational impact |
+| 5 | Critical | Catastrophic harm; irreversible; severe regulatory, legal, financial, or societal impact |
+
+**Risk score = Likelihood × Severity**
+
+**Risk rating matrix:**
+```
+Severity →  1-Neg  2-Minor  3-Mod  4-Major  5-Crit
+Likelihood ↓
+1-Rare       1       2        3       4        5
+2-Unlikely   2       4        6       8       10
+3-Possible   3       6        9      12       15
+4-Likely     4       8       12      16       20
+5-Almost     5      10       15      20       25
+```
+
+| Score range | Rating | Treatment |
+|------------|--------|-----------|
+| 1–4 | Low | Monitor; accept with documented rationale |
+| 5–9 | Medium | Implement controls; review quarterly |
+| 10–16 | High | Priority treatment required; management sign-off |
+| 17–25 | Critical | Immediate treatment; may need to halt AI system until controlled |
+
+---
+
+### Step 3: Select Risk Treatment
+
+For each identified risk with rating Medium or above:
+
+| Treatment Option | When to Use | Controls to Apply |
+|----------------|------------|------------------|
+| **Modify the AI system** | Risk is inherent to current design | Retrain with better data, add guardrails, change architecture, implement bias mitigation |
+| **Add operational controls** | Risk can be managed through process | Human review checkpoints, output filtering, monitoring, incident alerting |
+| **Accept with monitoring** | Residual risk is acceptable; monitoring can detect materialisation | Document acceptance decision with senior sign-off; define alert thresholds |
+| **Avoid** | Risk cannot be reduced to acceptable level | Do not deploy AI for this use case; find non-AI alternative |
+| **Transfer** | Third-party better placed to manage | Contractual liability allocation; insurance; require vendor indemnification (A.10.2 Allocating responsibilities, A.10.3 Suppliers) |
+
+---
+
+### Step 4: Document the AI Risk Register
+
+**Required fields per risk entry:**
+```
+Risk ID | AI System | Risk Category | Risk Description | Likelihood | Severity | Score | Rating | Treatment | Control(s) Applied | Residual Risk | Owner | Review Date
+```
+
+**Example entry:**
+```
+R-001 | Loan_Approval_Model_v2 | Model - Bias | Model may produce discriminatory outcomes for applicants by protected characteristic | 3 | 5 | 15 | High | Modify: implement fairness-aware retraining + quarterly demographic disparity monitoring | A.5.4, A.5.5, A.6.2.4, A.6.2.6 | Medium (score 6) after treatment | AI Risk Owner - Credit | Q2 2025
+```
+
+---
+
+## Part 2: AI System Impact Assessment (AISIA)
+
+### Purpose
+The AISIA takes a **stakeholder and societal lens** — it assesses impacts on individuals, groups, and society from the AI system's outputs and decisions. This is mandatory under Clause 6.1.2 and directly referenced in Annex A.5 (controls A.5.2–A.5.5).
+
+### When to Conduct an AISIA
+- **Before initial deployment** of any AI system in scope
+- **When the AI system changes** significantly (new use case, new population, new output type)
+- **When operating context changes** (new regulation, new demographic affected)
+- **On a scheduled review cycle** (annually recommended for medium/high impact systems)
+
+---
+
+### AISIA Step-by-Step Process
+
+**Step 1: Document the AI System**
+| Field | Content |
+|-------|---------|
+| AI system name and version | |
+| AI system owner | |
+| Intended purpose | What the system is designed to do |
+| Output type | Decision support / Autonomous decision / Content generation / Classification / Prediction / Recommendation / Other |
+| Inputs | What data is fed into the system |
+| Deployment context | Where and how used — internal/customer-facing/regulatory context |
+| Operating conditions | Conditions under which system is expected to perform correctly |
+
+**Step 2: Identify Affected Populations**
+| Population | How Affected | Vulnerability |
+|-----------|-------------|--------------|
+| Identify all groups whose rights, opportunities, or wellbeing may be affected by AI outputs | | |
+
+Vulnerability factors: age (children/elderly), disability, socioeconomic status, minority group membership, limited AI literacy, power imbalance (employer/employee; government/citizen).
+
+**Step 3: Assess Impact Dimensions**
+
+For each affected population, assess:
+
+| Dimension | Questions to Ask |
+|-----------|----------------|
+| **Nature of impact** | What kind of harm could occur? Financial, physical, psychological, reputational, loss of rights, discrimination? |
+| **Severity** | How serious is the worst-case impact? |
+| **Breadth** | How many individuals could be affected? |
+| **Reversibility** | Can the harm be corrected if the AI system makes an error? |
+| **Duration** | Is the impact short-term or long-lasting? |
+| **Consent and awareness** | Are affected individuals aware AI is being used? Did they consent? |
+| **Human oversight** | Is there a meaningful human review of AI outputs before they affect individuals? |
+| **Recourse** | Can individuals challenge AI decisions? Is there an appeal process? |
+
+**Step 4: Classify Impact Level**
+
+| Level | Criteria | Examples |
+|-------|----------|---------|
+| **Low** | Limited impact; easily reversible; non-vulnerable individuals; AI is advisory only; robust human oversight | Product recommendation engine; internal productivity tool |
+| **Medium** | Moderate impact; partially reversible; some vulnerable individuals may be affected; AI has significant weight in decisions | Customer service routing; content moderation; credit risk scoring with human review |
+| **High** | Significant impact; hard-to-reverse; vulnerable individuals; AI drives decisions with limited human review; affects fundamental rights | Automated hiring decisions; medical diagnosis AI; benefits eligibility AI; criminal risk scoring; biometric identification |
+
+**Step 5: Determine Control Requirements Based on Impact Level**
+
+| Control Area | Low Impact | Medium Impact | High Impact |
+|-------------|-----------|--------------|-------------|
+| Transparency (A.8.2, A.8.5) | General notice that AI is used | Inform affected individuals; describe what AI does | Full disclosure; right to explanation; right to human review |
+| Human oversight (A.6.2.6) | Human oversight available on request | Structured human review for edge cases | Mandatory human review of all consequential AI outputs |
+| Verification & bias testing (A.6.2.4, A.7.4) | Basic performance testing | Fairness testing before deployment | Ongoing fairness monitoring with demographic breakdown |
+| Documentation (A.6.2.7, A.5.3) | Technical documentation | Technical + user-facing documentation | Full model card; audit trail per decision |
+| Monitoring (A.6.2.6, A.6.2.8) | Annual performance review | Quarterly monitoring | Continuous monitoring with automated alerts |
+| Recourse mechanism | General complaints process | AI-specific appeal process | Formal right to challenge AI decisions; human decision-maker available |
+| AISIA review cycle (A.5.2) | Every 3 years or at major change | Annually or at significant change | Every 6 months or at any change |
+
+**Step 6: Document AISIA Findings**
+
+**AISIA Record format:**
+```
+AISIA ID: AISIA-[number]
+AI System: [name and version]
+Assessment Date: [date]
+Assessor: [name/role]
+Review Date: [date]
+
+1. AI System Description
+2. Intended Purpose
+3. Output Type
+4. Affected Populations (table)
+5. Impact Assessment (per population)
+6. Impact Classification: [Low / Medium / High]
+7. Controls Selected (with references to Annex A)
+8. Residual Impact Assessment
+9. Approval: [AI Risk Owner signature / date]
+10. AISIA Review Schedule
+```
+
+---
+
+## Part 3: Relationship Between AI Risk Assessment and AISIA
+
+| Dimension | AI Risk Assessment | AISIA |
+|-----------|-------------------|-------|
+| **Primary lens** | Organisational risk | Individual and societal impact |
+| **Key question** | What could go wrong for the organisation? | Who could be harmed and how? |
+| **Output** | Risk register; risk treatment plan | Impact classification; control requirements |
+| **Feeds into** | SoA control selection; risk treatment plan | Transparency obligations; human oversight design |
+| **Mandatory** | Yes (Clause 6.1.2) | Yes (Clause 6.1.2) |
+| **Repeated when** | AI system changes; annually recommended | AI system changes; on defined review cycle |
+
+**Important:** A risk that is Low for the organisation may be High impact for individuals (e.g., an AI system with low organisational risk of failure but high impact on vulnerable individuals when it does fail). Both assessments are always required — one does not substitute for the other.
+
+---
+
+## Part 4: Integration with EU AI Act
+
+ISO 42001 AISIA aligns closely with **EU AI Act Fundamental Rights Impact Assessment (FRIA)** requirements for high-risk AI systems. Organisations preparing for EU AI Act compliance can use their 42001 AISIA as a foundation — extending it to cover the specific FRIA requirements for EU high-risk AI system categories:
+
+| EU AI Act Category | ISO 42001 AISIA Overlap |
+|-------------------|------------------------|
+| Biometric identification | High impact → maximum controls → maps directly |
+| Critical infrastructure management | High impact |
+| Education/vocational training | Medium-High impact |
+| Employment and worker management | High impact (especially automated decisions) |
+| Access to essential services | High impact |
+| Law enforcement | High impact |
+| Migration/asylum/border control | High impact |
+| Justice/democratic processes | High impact |
+| General purpose AI (GPAI) | A.6.2.7 technical documentation; A.8.2 and A.8.5 transparency |

package/src/bmad-plus/packs/pack-shield/references/iso42001/iso42001-clauses-requirements.md

@@ -0,0 +1,279 @@
+# ISO/IEC 42001:2023 — Mandatory Clause Requirements (Clauses 4–10)
+
+All clauses are mandatory regardless of organisational size, sector, or role (provider or user). This reference covers each clause in detail with required outputs, audit evidence, and common nonconformities.
+
+---
+
+## Clause 4 — Context of the Organisation
+
+### 4.1 Understanding the Organisation and Its Context
+**Requirement:** Determine external and internal issues relevant to the AIMS purpose and that affect the ability to achieve intended outcomes. Include AI-specific factors: regulatory environment, societal expectations of AI, market pressures to adopt AI, and technology risks.
+
+**Required outputs:**
+- Environmental/contextual analysis (PESTLE or equivalent) covering AI dimensions
+- List of external issues: AI regulations (EU AI Act, national AI laws), public trust, competitive AI landscape
+- List of internal issues: AI maturity, data infrastructure, staff competence, ethical culture
+
+**Audit evidence:** Meeting minutes, strategic planning documents, AIMS scope document.
+
+### 4.2 Understanding the Needs and Expectations of Interested Parties
+**Requirement:** Identify all parties affected by or interested in the AIMS and their requirements.
+
+**AI-specific interested parties:**
+- Individuals affected by AI decisions (customers, citizens, employees)
+- Regulators (data protection authorities, sector-specific regulators, AI regulators)
+- AI model providers/vendors
+- Civil society and advocacy groups
+- Employees who interact with or are affected by AI
+- Investors and insurers requiring AI governance assurance
+
+**Required outputs:** Stakeholder register with requirements matrix.
+
+### 4.3 Determining the Scope of the AIMS
+**Requirement:** Document the boundary and applicability of the AIMS — which AI systems, processes, organisational units, and locations are in scope.
+
+**Key scope decisions:**
+- Which AI systems are in scope? (All? Only high-impact? Only AI systems developed in-house?)
+- Are AI systems used by third parties on the organisation's behalf in scope?
+- Which organisational functions (R&D, operations, customer service) are included?
+
+**Required outputs:** AIMS Scope Document — must specify: what is included, what is explicitly excluded, and the justification for exclusions.
+
+**Common nonconformity:** Scope excludes AI tools used in HR (e.g., AI screening tools) without documented justification.
+
+### 4.4 AI Management System
+**Requirement:** Establish, implement, maintain, and continually improve the AIMS including all processes and their interactions.
+
+---
+
+## Clause 5 — Leadership
+
+### 5.1 Leadership and Commitment
+**Requirement:** Top management must demonstrate active commitment to the AIMS — not just sign documents, but actively support AI governance as a strategic priority.
+
+**Evidence of commitment:**
+- AI policy approved and signed by senior leadership (CEO, Board, or equivalent)
+- AI governance included in management meeting agendas
+- Resources allocated for AIMS implementation
+- AI-related KPIs/objectives set at leadership level
+
+**Audit tip:** Auditors will interview top management — leaders must be able to explain the AIMS scope and their personal role in AI governance.
+
+### 5.2 AI Policy
+**Requirement:** Top management must establish an AI Policy that:
+- Is appropriate to the organisation's purpose and context
+- Provides a framework for setting AI objectives
+- Includes commitment to responsible and ethical AI
+- Includes commitment to comply with applicable requirements
+- Includes commitment to continual improvement of the AIMS
+
+**AI Policy must also address (ISO 42001-specific):**
+- The organisation's responsible AI principles (fairness, transparency, accountability, safety, privacy, reliability, inclusivity)
+- Commitment to conduct AI risk and impact assessments
+- Human oversight of AI systems proportionate to risk/impact
+
+**Required outputs:** AI Policy document (documented, communicated, available to interested parties as appropriate).
+
+### 5.3 Organisational Roles, Responsibilities and Authorities
+**Requirement:** Define roles accountable for AI governance.
+
+**Minimum required roles:**
+| Role | Responsibilities |
+|------|----------------|
+| AIMS Owner (top management) | Strategic accountability for AIMS; approves AI policy |
+| AI Risk Owner (per AI system) | Accountable for AI risk assessment and treatment decisions |
+| AI System Owner | Day-to-day management of specific AI system in scope |
+| Data Governance Lead | Accountable for A.7 data controls |
+| AIMS Internal Auditor | Conducts internal AIMS audits |
+| AI Incident Manager | Manages AI-specific incident response |
+
+**Required outputs:** RACI matrix or roles/responsibilities document; job descriptions updated.
+
+---
+
+## Clause 6 — Planning
+
+### 6.1 Actions to Address Risks and Opportunities
+**Requirement:** Plan how to address risks and opportunities relevant to the AIMS context and objectives.
+
+#### 6.1.1 General
+Determine risks and opportunities that could affect AIMS achievement. Plan actions to address them.
+
+#### 6.1.2 AI Risk Assessment and AI System Impact Assessment (AISIA)
+**This is the most distinctive clause in ISO 42001.** Two separate assessments are required:
+
+**AI Risk Assessment:**
+- Identify risks associated with AI systems (model risks, data risks, operational risks, supply chain risks)
+- Assess likelihood and severity
+- Determine treatment: modify, accept, avoid, or transfer
+- Document results and decisions
+- Must be repeated when AI systems change significantly or on a defined schedule
+
+**AI System Impact Assessment (AISIA):**
+- Assess potential impacts on individuals and society (not just organisational risk)
+- Consider: who is affected, what decisions the AI makes, how severe and reversible the impact is
+- Classify impact level (Low / Medium / High) → drives control selection
+- Must be performed for each AI system in scope
+- Must be updated when the AI system's purpose or operating context changes
+
+**Required outputs:**
+- AI Risk Assessment register (per AI system or per risk category)
+- AISIA records (per AI system)
+- Risk treatment decisions documented
+
+**Common nonconformity:** AISIA completed once during implementation but never revisited; risk assessment covers organisational risk only, not AI-specific risks.
+
+#### 6.1.3 AI Risk Treatment
+**Requirement:** Select and implement risk treatment options for AI risks identified in 6.1.2. Prepare a risk treatment plan with ownership, timelines, and residual risk acceptance.
+
+**Statement of Applicability (SoA):**
+- List all 38 Annex A controls
+- For each: applicable or not? Justification. Implementation status.
+- Exclusions of applicable controls must be justified — "not currently a priority" is not sufficient
+
+### 6.2 AI Objectives and Planning to Achieve Them
+**Requirement:** Establish AI objectives at relevant functions and levels.
+
+**AI objectives must be:**
+- Consistent with the AI policy and responsible AI principles
+- **Measurable** (not aspirational only)
+- Monitored and communicated
+- Updated as appropriate
+
+**Examples of measurable AI objectives:**
+- Achieve bias score below X across demographic groups in AI system Y by Q3
+- Complete AISIA for all in-scope AI systems by [date]
+- Achieve 100% AI awareness training completion for all staff by [date]
+- Reduce AI incident mean time to resolution (MTTR) below X hours
+- Achieve ISO 42001 certification by [date]
+
+---
+
+## Clause 7 — Support
+
+### 7.1 Resources
+**Requirement:** Provide resources needed for AIMS: budget, personnel, tooling, infrastructure.
+
+**AI-specific resource considerations:**
+- Data labelling/annotation capacity and quality assurance
+- Model evaluation and testing infrastructure
+- AI ethics expertise (internal or external)
+- Legal and regulatory monitoring for AI law changes
+
+### 7.2 Competence
+**Requirement:** Determine competence needed for AI roles; provide training; evaluate effectiveness.
+
+**Competence requirements by role:**
+| Role | Competence Areas |
+|------|----------------|
+| AI developers | Responsible AI practices, fairness-aware ML, secure ML development |
+| AI system operators | Understanding AI system limitations, human oversight procedures, incident detection |
+| Compliance/risk staff | AIMS clause requirements, AISIA methodology, AI risk assessment |
+| Procurement | AI-specific supplier due diligence, contractual AI requirements |
+| All staff | AI acceptable use policy, what AI is being used for, how to report AI concerns |
+
+**Required outputs:** Competence matrix, training records, training effectiveness evaluations.
+
+### 7.3 Awareness
+**Requirement:** All persons working under the organisation's authority must be aware of: the AI policy, their contribution to AIMS effectiveness, consequences of non-conformance.
+
+### 7.4 Communication
+**Requirement:** Determine internal and external communications relevant to AIMS: what to communicate, when, to whom, how.
+
+**AI-specific communications:**
+- External: transparency disclosures to AI-affected individuals (links to A.8.2 and A.8.5)
+- Internal: AI incident alerts, policy updates, training announcements
+- Regulatory: AI incident notifications where required
+
+### 7.5 Documented Information
+**Requirement:** Maintain and retain documented information required by ISO 42001, plus any the organisation determines necessary for AIMS effectiveness.
+
+**Mandatory documented information (retain):**
+- AIMS scope document
+- AI policy
+- AI risk assessment records
+- AISIA records
+- SoA
+- AI objectives
+- Internal audit reports and results
+- Management review records
+- Nonconformities and corrective actions
+
+---
+
+## Clause 8 — Operation
+
+### 8.1 Operational Planning and Control
+**Requirement:** Plan, implement, and control processes to meet AIMS requirements; implement control plans; manage planned changes; address unintended changes.
+
+**Key operational controls:**
+- AI system development follows documented lifecycle (A.6)
+- Data governance controls applied (A.7)
+- Impact assessments completed before deployment
+- Change management process for AI systems — reassess risk/impact when systems change
+
+### 8.2 AI Risk Assessment
+**Requirement:** Execute AI risk assessments per the method established in 6.1.2. Retain documented results.
+
+### 8.3 AI Risk Treatment
+**Requirement:** Implement the risk treatment plan. Retain documented evidence of treatment.
+
+---
+
+## Clause 9 — Performance Evaluation
+
+### 9.1 Monitoring, Measurement, Analysis and Evaluation
+**Requirement:** Monitor and measure AI system performance, AIMS process effectiveness, and progress against AI objectives.
+
+**Metrics to consider:**
+- AI system performance metrics (accuracy, precision/recall, bias scores) vs defined thresholds
+- AISIA completion rate across in-scope AI systems
+- AI incident count, severity, and MTTR
+- SoA control implementation progress
+- Training completion rates
+- Supplier AI assessment completion rates
+
+**Required outputs:** Monitoring reports, dashboard or metrics register.
+
+### 9.2 Internal Audit
+**Requirement:** Conduct internal audits at planned intervals to determine AIMS conformance and effective implementation.
+
+**Audit programme requirements:**
+- Audit frequency defined (typically annual minimum)
+- Auditor competence and independence — cannot audit own work
+- Audit plan covering all AIMS clauses and applicable controls over the audit cycle
+- Audit reports with findings, nonconformities, and opportunities for improvement
+- Audit records retained
+
+### 9.3 Management Review
+**Requirement:** Top management reviews the AIMS at planned intervals.
+
+**Management review agenda must cover:**
+- Status of actions from previous reviews
+- Changes in external/internal issues affecting the AIMS
+- AI risk and impact assessment results
+- Performance and metrics against AI objectives
+- Internal audit results
+- Nonconformities and corrective actions
+- Opportunities for improvement
+
+**Required outputs:** Management review minutes with decisions and action items.
+
+---
+
+## Clause 10 — Improvement
+
+### 10.1 Continual Improvement
+**Requirement:** Continually improve the suitability, adequacy, and effectiveness of the AIMS.
+
+### 10.2 Nonconformity and Corrective Action
+**Requirement:** When a nonconformity occurs: react, control, evaluate root cause, implement corrective action, review effectiveness.
+
+**AI-specific nonconformity examples:**
+- AI system deployed without completed AISIA
+- Training data bias testing skipped for a model
+- AI incident not reported within required timeframe
+- Staff using public AI tools without following acceptable use policy
+- Supplier AI assessment overdue
+
+**Required outputs:** Nonconformity records, corrective action log with root cause, action taken, and effectiveness review.