Templates and tools

[INSTITUTION NAME]

AI GOVERNANCE COMMITTEE CHARTER

Document Reference: AIG-CHR-001 Version: 1.0 Effective Date: [DD/MM/YYYY] Ratified by: Board Risk Committee Board Resolution Reference: [BRC-YYYY-NNN] Next Review Date: [DD/MM/YYYY] (annual) Owner: Chair, AI Governance Committee

Article 1: Establishment and Authority

1.1 Establishment

The AI Governance Committee (hereafter "the Committee") is established by resolution of the Board Risk Committee of [Institution Name] on [Date] under Board Resolution [Reference Number] to discharge the institution's responsibility for the governance of all artificial intelligence and machine learning systems deployed in, developed by, or procured for the institution.

1.2 Source of Authority

The Committee operates under authority delegated by the Board Risk Committee, which holds the underlying fiduciary responsibility for the institution's enterprise risk position. The Committee's authority is the operating expression of the Board's risk appetite for AI-related enterprise risk.

1.3 Reporting Line

The Committee reports to the Board Risk Committee through quarterly written reports and an annual presentation. The Committee Chair maintains a direct reporting line to the Board Risk Committee Chair for matters requiring escalation between scheduled reports.

1.4 Scope of Authority

The Committee holds authority over:

• All AI and machine learning models deployed in production across the institution
• All AI and machine learning models in development with planned production deployment
• All AI vendor relationships at tier-one and tier-two classification
• All AI-related policies and standards across the institution
• All AI-related incident classifications at severity-one and severity-two
• All cross-jurisdictional AI deployments

1.5 Limits of Authority

The Committee does not hold authority over:

• Board-reserved decisions on AI strategic investment exceeding [threshold amount]
• Board-reserved decisions on entry into prohibited use case categories
• Decisions reserved to the Audit Committee on internal audit findings
• Decisions reserved to the Sharia Supervisory Board on Sharia compliance interpretation (Islamic finance institutions)

Matters touching the limits above are escalated to the Board Risk Committee with a Committee recommendation.

Article 2: Composition

2.1 Chair

The Committee is chaired by the Chief Risk Officer of the institution. The Chair serves at the pleasure of the Board Risk Committee for a renewable two-year term.

2.2 Voting Members

The Committee comprises seven voting members holding the following roles:

• Chief Risk Officer (Chair)
• Chief Compliance Officer
• Chief Information Security Officer
• Chief Data Officer
• Chief Technology Officer
• Head of AI Governance Office
• Head of Internal Audit (observer for independence; voting only on matters where independence is not compromised)

2.3 Non-Voting Standing Attendees

• General Counsel (legal advisor)
• Sharia Advisor (Islamic finance institutions)
• AI Ethics Committee Chair (when ethical matters are on the agenda)
• Secretary to the Committee (records and administration)

2.4 Quorum

A quorum is five voting members including the Chair. Decisions requiring unanimous voting member approval (see Article 3.2) require all seven voting members present.

2.5 Member Tenure

Voting members serve in their committee capacity for the duration of their executive role. The Committee composition is reviewed annually by the Board Risk Committee.

2.6 Conflicts of Interest

Each member declares conflicts at the start of every meeting. A member with a declared conflict on a specific matter recuses from voting and may be required to leave the room during deliberation at the Chair's discretion.

Article 3: Decision Rights

3.1 Decisions the Committee Makes

The Committee holds final authority for:

• Production approval of all tier-one and tier-two AI models (Gate 4 decisions)
• Ratification of all AI-related policies and standards
• Classification override for severity-one incidents where initial classification is disputed
• Approval of AI vendor selections at tier-one and tier-two classification
• Approval of changes to the prohibited use case registry on advice from the AI Ethics Committee
• Approval of the institution's annual AI governance plan
• Approval of conditions attached to conditional model approvals and verification of condition satisfaction

3.2 Decisions Requiring Unanimous Voting Member Approval

• Production approval of tier-one AI models
• Approval of any AI deployment in a category previously on the prohibited use case registry
• Override of a Model Validation Forum recommendation to reject

3.3 Decisions the Committee Recommends to the Board Risk Committee

The Committee recommends, with rationale:

• AI strategic investment exceeding [threshold amount]
• Entry into new AI-enabled product categories with regulatory implications
• Material changes to the institution's AI risk appetite
• Annual AI governance budget
• AI-related regulatory engagement strategy

3.4 Decisions Delegated to Subordinate Forums

The Committee delegates the following to the Model Validation Forum, with reporting back at each Committee meeting:

• Gate 1 model use-case approval (tier-two and tier-three)
• Gate 2 model data sourcing approval (tier-two and tier-three)
• Gate 3 model methodology validation (all tiers, with tier-one decisions ratified by the Committee)
• Tier classification of new models

Article 4: Operating Cadence

4.1 Standing Meetings

The Committee meets monthly on the [second Tuesday] of each month at [time] for a duration not to exceed three hours.

4.2 Annual Strategic Review

The Committee convenes annually for a two-day strategic review in [month]. The Board Risk Committee Chair attends Day Two.

4.3 Extraordinary Meetings

The Chair may convene an extraordinary meeting on:

• Any severity-one incident requiring immediate Committee action
• Any regulatory enforcement notice
• Any urgent vendor termination requirement
• Any other matter the Chair determines requires Committee action before the next scheduled meeting

Extraordinary meetings may be convened with twenty-four hours notice. Quorum requirements remain in force.

4.4 Reporting Cycle

• Quarterly written report to the Board Risk Committee, submitted no later than [fifteen days] after quarter-end
• Annual presentation to the Board Risk Committee within [thirty days] of the strategic review
• Ad hoc escalation to the Board Risk Committee Chair as required

Article 5: Agenda Architecture

5.1 Standing Agenda Items (Every Meeting)

1. Opening and conflicts declaration (10 minutes)
2. Minutes ratification and action item review (10 minutes)
3. Model inventory delta since last meeting (10 minutes)
4. Incident log review (15 minutes)
5. Regulatory horizon scan (10 minutes)
6. KRI dashboard review (15 minutes)
7. Decision items (60-90 minutes)
8. Strategic item (rotating, 30 minutes)
9. Closing and action assignment (10 minutes)

5.2 Pre-Read Pack Discipline

All decision items require complete pre-read packs distributed at least seventy-two hours before the meeting. Decision items without complete pre-read packs are removed from the agenda at the Chair's discretion. The pre-read pack for a model approval includes the model card, validation report, bias audit, Sharia approval (where applicable), and the validator's recommendation.

5.3 Rotating Strategic Items

• Vendor portfolio review (Quarter 1)
• Policy review cycle (Quarter 2)
• Sharia validation cycle review (Quarter 3, Islamic finance institutions)
• Training and capability development review (Quarter 4)

Article 6: Record-Keeping

6.1 Secretariat

The Head of AI Governance Office designates a Committee Secretary responsible for agenda preparation, minute-taking, action item tracking, and decision register maintenance.

6.2 Minutes

Minutes are drafted within five business days of each meeting and circulated to all attendees for review. Minutes are ratified at the next standing meeting and become the institutional record.

6.3 Decision Register

The Committee maintains a decision register recording for each decision: date, matter, decision, rationale, voting record (including dissents), accountable owner for implementation, due date, and verification of completion.

6.4 Dissent Protocol

Members who vote against a decision may require their dissent and rationale recorded in the minutes. Dissent recording cannot be denied by the Chair. Dissents on decisions later reversed are referenced in the reversal record.

6.5 Retention

Minutes, pre-read packs, and the decision register are retained for the period the institution's records management policy specifies for governance committee records, with a minimum of ten years and extension where regulatory or litigation hold applies.

Article 7: Review and Amendment

7.1 Annual Charter Review

The Committee reviews this charter annually. The review assesses:

• Whether the scope of authority remains current
• Whether the composition remains appropriate
• Whether the decision rights remain calibrated to institutional risk
• Whether the operating cadence remains operable
• Whether the agenda architecture remains effective

7.2 Amendment Protocol

Amendments are proposed by the Chair following the annual review and ratified by the Board Risk Committee. Amendments take effect at the meeting following ratification.

7.3 Committee Effectiveness Assessment

The Committee conducts an annual self-assessment of its effectiveness, with results reported to the Board Risk Committee. An external effectiveness review is conducted biennially.

Article 8: Signature Block

This charter is ratified by the Board Risk Committee on the date below and takes effect immediately upon ratification.

End of Charter Template. Usage Notes: Charter length should not exceed eight pages when populated against the institution's reality. The decision rights section is the load-bearing element. If the decision rights are vague, the Committee will discover its boundaries by colliding with the boundaries of other committees, which is the most expensive way to discover them.

Mirrors the structure of Template 1 with adapted decision rights centered on the prohibited-use registry, override authority on AI Governance Committee approvals on ethical grounds, advisory opinions on contested use cases, and recommended public commitments on AI ethics to the Board. Composition mandates a minimum of two external members and a quorum that must include at least one external member. Operating cadence is quarterly standing with extraordinary meeting trigger on any model escalated on ethical grounds.

Structure

• Decision rights centered on prohibited-use registry
• Override authority on AI Governance Committee approvals on ethical grounds
• Advisory opinions on contested use cases
• Recommended public commitments on AI ethics to the Board
• Composition (minimum two external members; quorum must include at least one external member)
• Operating cadence (quarterly standing; extraordinary meeting trigger on model escalated on ethical grounds)

Charter follows Template 1 architecture with tier-based scrutiny protocols (Tier 1 requires three voting members plus external validator opinion for novel methodologies; Tier 2 standard forum review; Tier 3 expedited review delegated to chair plus one voting member). Excluded persons include model developers, business sponsors, and anyone with a performance interest in model approval. Documentation discipline anchored to Template 12 validation report format.

Structure

• Tier-based scrutiny protocols (Tier 1 three voting members plus external validator opinion for novel methodologies; Tier 2 standard forum review; Tier 3 expedited review delegated to chair plus one voting member)
• Excluded persons (model developers, business sponsors, anyone with a performance interest in model approval)
• Documentation discipline anchored to Template 12 validation report format

Five-section structure: Opening (10 min), Standing Reports (30 min), Decision Items (60-90 min), Strategic Items rotated quarterly (30 min), Closing (10 min). Pre-read pack discipline is non-negotiable. The Chair's role is to refuse to consider a decision item that did not have a complete pre-read pack distributed seventy-two hours in advance.

Structure

• Opening (10 min)
• Standing Reports (30 min)
• Decision Items (60-90 min)
• Strategic Items rotated quarterly (30 min)
• Closing (10 min)

Six-section structure: Opening, Prohibited-Use Registry Review, Escalated Model Reviews (40 minutes per model), Stakeholder Engagement Report, Public Commitment Review (semi-annual), Closing. The forty-minute per-model allocation is a discipline, not a ceiling.

Structure

• Opening
• Prohibited-Use Registry Review
• Escalated Model Reviews (40 minutes per model)
• Stakeholder Engagement Report
• Public Commitment Review (semi-annual)
• Closing

Two-dimensional matrix with rows as decisions (fourteen typical decisions from Gate 1 use-case approval through annual model inventory attestation) and columns as roles (thirteen typical roles from Model Owner through Board Risk Committee Chair). Rules: one A per row; multiple R, C, I permitted; empty cells deliberate. The RACI resolves committee boundary disputes by being the cited reference rather than the subject of further deliberation.

Structure

• Rows: decisions (fourteen typical decisions from Gate 1 use-case approval through annual model inventory attestation)
• Columns: roles (thirteen typical roles from Model Owner through Board Risk Committee Chair)
• Rules: one A per row; multiple R, C, I permitted; empty cells deliberate

Twelve-month grid layered by frequency: Monthly (committee meetings, KRI dashboards), Quarterly (Board Risk Committee report, vendor portfolio review, Ethics Committee), Semi-Annually (Sharia validation cycle, crisis simulation, external validator engagement), Annually (policy review, charter review, model inventory attestation, bias audit refresh, operator certification), Biennially (external committee effectiveness review, external MRM framework audit, regulatory exam readiness simulation). Published as a dashboard linking each entry to the artifact it produces.

Structure

• Monthly (committee meetings, KRI dashboards)
• Quarterly (Board Risk Committee report, vendor portfolio review, Ethics Committee)
• Semi-Annually (Sharia validation cycle, crisis simulation, external validator engagement)
• Annually (policy review, charter review, model inventory attestation, bias audit refresh, operator certification)
• Biennially (external committee effectiveness review, external MRM framework audit, regulatory exam readiness simulation)

Six-phase sequenced checklist spanning twenty-six weeks: Phase 1 Mandate (weeks 1-2), Phase 2 Foundation (weeks 3-6), Phase 3 Policy and Inventory (weeks 7-10), Phase 4 Operating Rhythm (weeks 11-13), Phase 5 Capability and Communication (weeks 13-16), Phase 6 First Audit Cycle (weeks 17-26). The sequencing matters because the AI Governance Committee meets after the policies it ratifies exist, not before.

Structure

• Phase 1 Mandate (weeks 1-2)
• Phase 2 Foundation (weeks 3-6)
• Phase 3 Policy and Inventory (weeks 7-10)
• Phase 4 Operating Rhythm (weeks 11-13)
• Phase 5 Capability and Communication (weeks 13-16)
• Phase 6 First Audit Cycle (weeks 17-26)

FIRST 90 DAYS PLAN

HEAD OF AI GOVERNANCE OFFICE

Document Reference: AIG-90D-001 Appointee: [Name] Reporting Line: Chief Risk Officer Plan Owner: Appointee (with weekly check-in to CRO) Plan Approval: Chief Risk Officer

Phase Overview

Phase 1: Discovery (Weeks 1-2)

Week 1

Monday: Onboarding with CRO. Receive office mandate, budget, and any prior governance artifacts. Set up office space, email, system access. Schedule introductory meetings. Tuesday: Stakeholder interview block 1.

• 09:00 Chief Risk Officer (60 min, deep brief)
• 11:00 Chief Compliance Officer (45 min)
• 14:00 Chief Data Officer (45 min)
• 16:00 Chief Information Security Officer (45 min)

Wednesday: Stakeholder interview block 2.

• 09:00 Chief Technology Officer (45 min)
• 11:00 Head of Internal Audit (45 min)
• 14:00 Three business unit heads with active AI deployments (45 min each, sequential)

Thursday: Stakeholder interview block 3.

• 09:00 Chief Executive Officer (30 min, strategic posture)
• 11:00 Board Risk Committee Chair (30 min, expectations)
• 14:00 General Counsel (45 min, regulatory posture)
• 16:00 Head of Procurement (45 min, vendor pipeline)

Friday: Document review. Read every existing AI policy, every model card in the institution, every prior incident report from the past twelve months. Note gaps, contradictions, and missing artifacts.

Week 2

Monday: Inventory baseline initiation. Request from each business unit a list of every AI model in production, every AI vendor under contract, every AI use case in active development. Tuesday-Wednesday: Regulatory baseline. Catalogue applicable regulators across all operating jurisdictions. Identify current expectations from each regulator. Identify enforcement actions against peer institutions in past twelve months. Thursday: Capability baseline. Inventory current headcount with AI governance experience. Identify skill gaps. Draft initial hiring profile for the office team. Friday: Week 2 synthesis. Draft discovery summary for CRO review. One page maximum. Three findings, three risks, three immediate actions.

Phase 2: Diagnosis (Weeks 3-4)

Week 3

Monday: Governance maturity assessment using the MESA Maturity Model in Appendix A. Score the institution across all five domains. Tuesday: Top-five risk areas identification. Rank by likelihood and impact. Tie each risk to a remediation pathway. Wednesday: Top-five capability gaps identification. Rank by criticality. Tie each gap to a closure pathway (hire, train, vendor, restructure). Thursday: Board pre-read drafting begins. Three-section structure: current state (with maturity assessment), target state (with twelve-month horizon), ninety-day plan. Friday: Week 3 check-in with CRO. Confirm direction. Adjust.

Week 4

Monday-Tuesday: Board pre-read completion and routing to CRO for review. Wednesday: Initial team hiring kickoff. Open positions for two validators, one data governance lead, one vendor risk lead, one administrator. Thursday: Initial RACI matrix drafted. Routes to CRO and legal for review. Friday: Week 4 synthesis. Phase 2 closes with: maturity assessment complete, top five risks named, top five gaps named, board pre-read in CRO review.

Phase 3: Build (Weeks 5-8)

Week 5

Monday: AI Governance Committee Charter drafted (Template 1). Routed for legal review. Tuesday: Model Validation Forum Charter drafted (Template 3). Routed for legal review. Wednesday: AI Ethics Committee Charter drafted (Template 2) if applicable. Routed for legal review. Thursday: AI Acceptable Use Policy drafted (Template 32). Routed for legal review. Friday: Week 5 check-in. Three charters and one policy in legal review.

Week 6

Monday: Model Development Policy drafted (Template 33). Routed for legal review. Tuesday: Vendor Management Policy drafted (Template 34). Routed for legal review. Wednesday: Data Governance Policy drafted (Template 35). Routed for legal review. Thursday: Initial team hires extended. First validator and first data governance lead targeted for week 8 start. Friday: Week 6 synthesis. Four policies in legal review. Hiring underway.

Week 7

Monday: Model inventory baseline finalization. Every model from week 2 inventory catalogued with tier rating, owner, validation status, last refresh. Tuesday: First KRI set defined. Five to seven indicators with thresholds. Sample set: tier-one model count, models with overdue validation, models with red drift status, severity-one incidents trailing twelve months, vendor scorecards in red, days since last bias audit refresh, prohibited-use registry items added trailing quarter. Wednesday: Charters and policies route to AI Governance Committee for ratification at first meeting (which will be in week 9). Thursday: First Model Validation Forum members identified and invited. Forum charter routed to forum chair for ratification. Friday: Week 7 check-in with CRO. Direction confirmed.

Week 8

Monday-Tuesday: Initial team onboarding. First validator and data governance lead arrive. Office space, system access, briefing pack. Wednesday: First AI Governance Committee meeting agenda drafted (Template 4). Pre-read pack assembled. Thursday: Pre-read pack distributed to AI Governance Committee members (seventy-two hour discipline). Friday: Week 8 synthesis. Phase 3 closes with: charters drafted and routed, policies drafted and routed, team onboarding, first committee meeting scheduled for week 9.

Phase 4: Operate (Weeks 9-13)

Week 9

Monday: First AI Governance Committee meeting held. Agenda: charter ratification, policy ratification, KRI dashboard preview, model inventory baseline review. Tuesday: Meeting minutes drafted. Action items assigned. Decision register opened. Wednesday: First Model Validation Forum meeting held. Agenda: forum charter ratification, validation methodology review, current model validation status. Thursday-Friday: First KRI dashboard published. Distributed to AI Governance Committee, CRO, Board Risk Committee Chair.

Week 10

Monday: First incident log review conducted with Head of AI Incident Response. Tuesday: Initial vendor portfolio assessment. Each tier-one and tier-two vendor identified with current scorecard status, contract review status, exit clause status. Wednesday-Thursday: Initial regulatory horizon scan. Each operating jurisdiction's recent regulatory activity catalogued. Friday: Week 10 synthesis. Operating rhythm beginning.

Week 11

Monday: Operator certification training scope defined. Curriculum drafted. Tuesday-Wednesday: Communications campaign launched. Intranet hub goes live. First internal newsletter article on AI governance published. Thursday: First stakeholder briefing to Board Risk Committee Chair (informal, in advance of formal 90-day report). Friday: Week 11 check-in. Adjustments noted.

Week 12

Monday: Internal audit engagement scoped. Coordination with Head of Internal Audit on first independent validation of a tier-one model. Tuesday: 90-day report drafting begins. Wednesday-Thursday: 90-day report completed. Reviewed by CRO. Friday: 90-day report finalized.

Week 13

Monday: 90-day report delivered to Board Risk Committee. Tuesday: Q+1 plan drafted. Three priorities for the next ninety days identified. Wednesday: Office retrospective held with team. What worked. What did not. What to adjust. Thursday: Q+1 plan finalized and shared with CRO. Friday: Phase 4 closes. Ninety days complete. The office is operating.

Phase Gates

Risks and Mitigations

End of 90-Day Plan Template. Usage Notes: The discovery phase is non-negotiable. Office heads who skip discovery and start with policy drafting produce policies the institution rejects. The fifteen days of interviews are the diplomatic foundation for everything the office subsequently asks of the institution.

For each role, a one-page description containing: Role Title, Reporting Line, Purpose Statement (two sentences), Key Responsibilities (five to seven bullets), Decision Authority (independent, recommended, escalated), Required Qualifications, Preferred Qualifications, Performance Metrics, Career Path. Twelve roles defined: Head of AI Governance Office, Head of Model Validation, Senior Model Validator, Model Validator, Head of AI Data Governance, Senior Data Governance Officer, Head of AI Vendor Risk, Senior Vendor Risk Officer, Head of AI Incident Response, AI Ethics Officer, AI Governance Administrator, Sharia AI Advisor (Islamic finance institutions).

Structure

• Role Title
• Reporting Line
• Purpose Statement (two sentences)
• Key Responsibilities (five to seven bullets)
• Decision Authority (independent, recommended, escalated)
• Required Qualifications
• Preferred Qualifications
• Performance Metrics
• Career Path

MODEL CARD

[MODEL NAME] v[VERSION]

Card Reference: MC-[MODEL-ID]-v[VERSION] Card Version: [Version] Card Date: [DD/MM/YYYY] Card Owner: [Model Owner Name and Role] Card Approver: AI Governance Committee Next Review Due: [DD/MM/YYYY]

Section 1: Model Overview

Sample completed entry (illustrative):

Model ID: MDL-2026-0142 Model Name: Retail Credit Default Predictor Model Version: 2.3.1 Tier Rating: Tier 1 Tier Rating Justification: Customer-facing credit decision with material financial impact; affects more than 50,000 customers annually; protected attribute exposure assessed in Section 4. Model Type: Gradient-Boosted Classification (XGBoost) Intended Use Cases: Predict probability of 90-day default on personal loan applications between AED 10,000 and AED 250,000 for UAE-resident retail customers. Out-of-Scope Uses: Corporate lending decisions; loan amounts above AED 250,000; non-UAE-resident applicants; collections triage; refinancing decisions.

Section 2: Training Data

Sample completed entry (illustrative):

Dataset Name: RCD-2024-2025-FULL Time Period Covered: 01/01/2022 to 31/12/2024 Sample Size: 487,331 records (60% train, 20% validation, 20% test) Data Sources: Core banking system (consent basis: contractual necessity as the UAE PDPL provides); credit bureau (Al Etihad Credit Bureau, consent basis: the applicable UAE PDPL processing ground with customer notification); third-party employment verification (consent basis: explicit consent at loan application). Data Localization Status: All training data resided in UAE-based data centers during development. No cross-border transfer occurred.

Section 3: Performance Metrics

In-Sample vs Out-of-Sample Performance: [Gap analysis, overfitting indicator] Cross-Validation Results: [k-fold results with variance] Performance Over Time: [Stability across the training period] Performance by Subgroup: [Summary table; full analysis in Section 4] Sample completed entry (illustrative):

AUC-ROC: 0.847 (Production Threshold 0.78, Pass) Accuracy: 0.823 (Production Threshold 0.75, Pass) The in-sample to out-of-sample AUC gap is 0.018, which is within the institutional overfitting tolerance of 0.05. Five-fold cross-validation produced AUC values between 0.831 and 0.852, indicating stable performance across data partitions.

Section 4: Fairness and Bias

Bias Mitigation Methods Applied: [Pre-processing, in-processing, post-processing, with effectiveness] Residual Bias Accepted: [Statement with rationale] Reference to Bias Audit Report: [Template 13 report reference]

Section 5: Explainability

Section 6: Limitations and Risks

Known Model Limitations: [Specific scenarios where model performs below threshold] Known Failure Modes: [Specific input patterns producing unreliable output] Risk to the Institution: [Operational, reputational, regulatory, with mitigation] Risk to Customers: [Decision impact, recourse availability] Recourse Pathway: [How customers contest model decisions]

Section 7: Validation and Approval

Section 8: Production Monitoring

Retraining Cadence: [Frequency and trigger criteria] Retirement Triggers: [Conditions that initiate retirement under Template 15]

Section 9: Audit Trail

Section 10: MENA Jurisdictional Overlays

10.1 SDAIA AI Ethics Principles Overlay (Saudi deployments)

10.2 CBUAE AI Guidance Overlay (UAE deployments)

• Customer-facing model use registered with CBUAE: [Yes/No, registration reference]
• Compliance with CBUAE customer protection expectations: [Statement]
• Notification register entry: [Reference]

10.3 SAMA AI Guidance Overlay (KSA deployments)

• SAMA submission reference: [Where required]
• Alignment with SAMA expectations: [Statement]

10.4 PDPL Overlay

• Lawful basis citation per data category: [As in Section 2]
• Data Protection Officer review: [Date and outcome]
• DPIA reference (Template 17): [DPIA-XXX]

10.5 AAOIFI Overlay (Islamic finance institutions)

• Sharia Advisor approval reference: [As in Section 7]
• Applicable AAOIFI standards: [Citation]
• Beneficial use verification: [Statement per Template 22]

10.6 Sectoral Overlay

• Healthcare, telecommunications, securities, insurance overlays as applicable.

Section 11: Operator-Facing Summary

For non-validator readers (business sponsors, audit, board). What the model does (one paragraph, plain language). What the model does not do (explicit limitations). What could go wrong (failure modes in operator terms). What we do if it goes wrong (incident response summary, referenced to Template 30). Available in: Arabic, English.

Section 12: Sign-Off

End of Model Card Template. Usage Notes: The twelve-section structure is calibrated for tier-one and tier-two models. Tier-three models use a simplified five-section card (Sections 1, 2, 3, 7, 9) so the discipline scales without the documentation overhead overwhelming the model risk. The discipline is to update the card at every change, not to write it once. A model card twelve months stale is not a model card. It is an artifact of the institution the model used to live in.

MODEL VALIDATION REPORT

[MODEL NAME] v[VERSION]

Report Reference: VR-[MODEL-ID]-v[VERSION] Report Date: [DD/MM/YYYY] Validator(s): [Names and Roles] Reviewer: [Head of Model Validation Name] Receiving Forum: [Model Validation Forum / AI Governance Committee] Recommendation: [Approve / Approve with Conditions / Reject / Defer Pending Remediation]

Section 1: Executive Summary

Model Identification: [Model ID, Name, Version, Tier] Validation Scope: [One paragraph] Methodology Summary: [One paragraph] Findings Summary:

• Severity 1: [Count]
• Severity 2: [Count]
• Severity 3: [Count]
• Severity 4: [Count]

Recommendation: [Statement with rationale, three to five sentences] Validator Attestation: I confirm that I was not involved in the development of the model under validation. I confirm that I had unrestricted access to the model artifacts, training data, and development team. I confirm that this report represents my independent assessment. Signed: [Name, Date]

Section 2: Validation Scope

What was validated:

• [Item 1]
• [Item 2]
• [Item N]

What was explicitly out of scope (with rationale):

• [Item 1, Rationale]
• [Item 2, Rationale]

Validation Methodology:

• Conceptual soundness review
• Data review
• Performance review (independent test on validator-held data)
• Fairness review
• Implementation review
• Ongoing monitoring design review

Independence Attestation: [Statement]

Section 3: Conceptual Soundness Review

Use Case Appropriateness: [Assessment, evidence reference] Methodology Appropriateness: [Assessment, evidence reference] Alignment with Regulatory Expectations: [Per applicable jurisdiction] Alignment with Internal Policy: [Per Template 33] Findings: [Numbered list with severity rating]

Section 4: Data Review

Data Quality Assessment (Six Dimensions per Chapter 13):

Data Lineage Verification: [Status per Template 19] Consent Basis Verification: [Status per Template 17] Data Localization Verification: [Status per Template 28] Findings: [Numbered list with severity rating]

Section 5: Performance Review

Independent Test Performance (validator-held data, not developer-supplied):

Performance Under Stress Conditions: [Stress scenarios applied and results] Performance Comparison to Challenger Models: [Where applicable] Findings: [Numbered list with severity rating]

Section 6: Fairness Review

Reference to Bias Audit Report: [Template 13 report reference] Subgroup Performance Analysis Summary: [Reference to bias audit, key findings] Findings: [Numbered list with severity rating]

Section 7: Implementation Review

Production Code Review: [Code matches validated specification, Pass/Fail] Production Data Pipeline Review: [Pipeline matches validated specification, Pass/Fail] Production Monitoring Configuration: [Per Template 16, Pass/Fail] Findings: [Numbered list with severity rating]

Section 8: Findings Register

Severity Scale:

• Severity 1: Model cannot proceed to production without remediation. Examples: protected attribute exposure breaching PDPL; methodology error invalidating outputs; bias finding exceeding institutional tolerance.
• Severity 2: Model can proceed to production with conditions. Examples: monitoring gap that must close within ninety days; documentation deficiency that must be remediated before next attestation.
• Severity 3: Model can proceed to production with monitoring. Examples: design choice the validator would not have made but cannot establish as defective; minor inconsistency that does not affect operational reality.
• Severity 4: Observation, not finding. Recorded for institutional learning.

Section 9: Validator Recommendation

Recommendation: [Approve / Approve with Conditions / Reject / Defer Pending Remediation] Rationale: [Two to three paragraphs] Conditions Attached (if Conditional):

Re-Validation Triggers:

• [Trigger 1]
• [Trigger 2]

Section 10: Sign-Off

Section 11: Appendices

A. Validation Test Results (detailed) B. Data Quality Diagnostic Outputs C. Subgroup Performance Tables (full) D. Production Code Review Notes E. Reviewed Documents Register

Section 12: Distribution

• AI Governance Committee
• Model Validation Forum
• Model Owner
• Head of AI Governance Office
• Chief Risk Officer
• Internal Audit (notification)
• Regulatory examination evidence file

Section 13: Retention

This report is retained per the institution's records management policy, with a minimum retention of [ten years] from the date of model retirement, and extension under regulatory or litigation hold. End of Validation Report Template. Usage Notes: Validation reports under thirty pages are usually incomplete. Validation reports over eighty pages are usually unfocused. Use Section 1's executive summary as the regulator's entry point and the findings register as the regulator's destination. Everything in between is the evidence trail that supports the findings.

BIAS AUDIT REPORT

[MODEL NAME] v[VERSION]

Report Reference: BA-[MODEL-ID]-v[VERSION] Audit Date: [DD/MM/YYYY] Auditor(s): [Names and Roles] Approving Authority: [Model Validation Forum / Ethics Committee / AI Governance Committee] Recommendation: [Approve / Approve with Conditions / Reject]

Section 1: Audit Scope

Auditor Independence Attestation: I confirm that I had no role in the development of the model under audit. I confirm that I had unrestricted access to the data required for the audit. I confirm that this report represents my independent assessment. Signed: [Name, Date]

Section 2: Protected-Attribute Inventory

Excluded Attributes (with rationale):

• [Attribute]: [Rationale, e.g., not collected, prohibited as input, not statistically meaningful in deployment population]

Section 3: Fairness Metrics

For each protected attribute and each fairness metric, the table records observed value, threshold, and pass/fail.

Section 4: Subgroup Performance

Performance Gap Analysis: [Subgroups where gap exceeds institutional tolerance, with statistical significance assessment]

Section 5: Mitigation Methods Applied

Trade-off Analysis: [Where mitigation reduced overall accuracy or shifted error distribution, document the trade-off and the rationale for accepting it]

Section 6: Residual Bias

Statement of Residual Bias: [Description per attribute] Rationale for Acceptance (if accepted): [Three to five sentences, explaining why the residual is consistent with the institution's commitments and why further mitigation would produce worse outcomes] Compensating Controls:

• Customer recourse pathway: [Reference]
• Human review trigger: [Threshold and process]
• Decision override authority: [Role]
• Enhanced monitoring: [Reference to Template 16]

Section 7: Recommendation

Recommendation: [Approve / Approve with Conditions / Reject] Rationale: [Two paragraphs] Conditions Attached:

Re-Audit Triggers:

• [Annual cycle baseline]
• [Material change in protected-attribute taxonomy]
• [Production drift exceeding threshold per Template 16]
• [Customer complaint pattern indicating undetected bias]

Section 8: Sign-Off

Appendix A: Jurisdictional Protected-Attribute Reference

• Saudi PDPL: protects personal data categories including religious or political opinion, ethnic origin, criminal record, health data. Saudi context recognizes nationality-related protections.
• UAE federal PDPL: protects sensitive personal data including religion, ethnicity, political opinions, biometric data, with sectoral overlays for financial and healthcare contexts.
• AAOIFI governance principles: recognize fairness obligations toward customers in Islamic finance contexts that extend beyond conventional protected-attribute frameworks, including obligations against gharar in customer decisions.
• CBUAE sectoral overlay: recognizes specific customer protections in financial contexts.
• SAMA sectoral overlay: recognizes customer protections in Saudi banking and insurance.

End of Bias Audit Report Template. Usage Notes: Bias audits that report a single fairness metric are not bias audits. They are bias-metric reports. Report multiple metrics across multiple protected attributes because no single metric captures fairness. The metrics will sometimes disagree. The committee's role is to decide which disagreement the institution accepts, with documented rationale.

Database structure with one row per model and twenty-one fields per row: Model ID, Model Name, Model Version, Owner Role, Owner Individual, Business Unit, Deployment Status, Tier Rating, Use Case Category, Decision Impact Level, Production Deployment Date, Last Validation Date, Next Validation Due Date, Last Bias Audit Date, Next Bias Audit Due Date, Sharia Approval Status, Sharia Approval Expiry Date, Linked Model Card URL, Linked Validation Report URL, Linked Bias Audit URL, KRI Status. The inventory is queried, not browsed. A database, not a spreadsheet.

Structure

• Model ID
• Model Name
• Model Version
• Owner Role
• Owner Individual
• Business Unit
• Deployment Status
• Tier Rating
• Use Case Category
• Decision Impact Level
• Production Deployment Date
• Last Validation Date
• Next Validation Due Date
• Last Bias Audit Date
• Next Bias Audit Due Date
• Sharia Approval Status
• Sharia Approval Expiry Date
• Linked Model Card URL
• Linked Validation Report URL
• Linked Bias Audit URL
• KRI Status

Seven-section checklist: Retirement Decision Documentation, Replacement Model Status, Production Disablement, Data Retention, Stakeholder Notification, Inventory Update, Sign-Off. Zombie models (retired in intent but receiving production traffic) are the most common audit finding when retirement discipline is absent. The checklist forces verification that retirement is operational, not merely declared.

Structure

• Retirement Decision Documentation
• Replacement Model Status
• Production Disablement
• Data Retention
• Stakeholder Notification
• Inventory Update
• Sign-Off

Six-section per-model structure: Data Drift Monitoring (features, metric per feature, detection window, amber and red thresholds, escalation owner), Concept Drift Monitoring, Prediction Drift Monitoring, Bias Drift Monitoring, Alert Workflow (routing, SLA, escalation path, resolution documentation), Configuration Review Cadence. Drift configurations are reviewed quarterly because the underlying data distribution shifts and the thresholds need recalibration.

Structure

• Data Drift Monitoring (features, metric per feature, detection window, amber and red thresholds, escalation owner)
• Concept Drift Monitoring
• Prediction Drift Monitoring
• Bias Drift Monitoring
• Alert Workflow (routing, SLA, escalation path, resolution documentation)
• Configuration Review Cadence

Seven-section structure: Processing Description, Necessity and Proportionality, Data Subject Rights, Risk Assessment, Mitigation Measures, Jurisdictional Overlays (Saudi PDPL, UAE federal PDPL, GDPR, sectoral, AAOIFI), Approval. The overlay approach lets the institution maintain a single core DPIA with jurisdiction-specific sections updated as each regime evolves.

Structure

• Processing Description
• Necessity and Proportionality
• Data Subject Rights
• Risk Assessment
• Mitigation Measures
• Jurisdictional Overlays (Saudi PDPL, UAE federal PDPL, GDPR, sectoral, AAOIFI)
• Approval

DATA CATALOG SPECIFICATION

Document Reference: DG-CAT-001 Version: 1.0 Owner: Head of AI Data Governance Approver: AI Governance Committee Review Cadence: Quarterly schema review; continuous content updates

Section 1: Catalog Scope

In Scope:

• All data assets used as inputs to any AI or machine learning model in production or development
• All data assets used in feature engineering pipelines
• All data assets used in model training, validation, or testing
• All data assets used in model performance evaluation or monitoring

Out of Scope (catalogued separately):

• Data assets used solely for operational reporting without AI integration
• Personal productivity datasets

Section 2: Catalog Entry Schema

Each data asset has one catalog entry with the following fields.

2.1 Identification

2.2 Ownership

2.3 Classification

2.4 Source and Lineage

2.5 Quality

2.6 Storage and Access

2.7 AI Consumption

2.8 Lifecycle

Section 3: Sample Catalog Entry

Section 4: Catalog Operations

4.1 New Asset Onboarding

1. Business owner submits new asset request via catalog system
2. Data steward populates schema fields
3. Data classification review by AI Data Governance Officer
4. Sharia classification review by Sharia Advisor (Islamic finance institutions)
5. Approval and activation in catalog

4.2 Asset Update Triggers

• Source system change
• Schema change in source
• Classification change
• Quality score change beyond threshold
• New AI consumer added or removed

4.3 Asset Deprecation

• Deprecation proposed by business owner or data steward
• Impact analysis on downstream consumers (90-day notification)
• Migration plan for consumers
• Retirement after consumer migration

4.4 Quality Assessment Cadence

• Tier-one model inputs: monthly
• Tier-two model inputs: quarterly
• Tier-three model inputs: semi-annually

Section 5: Catalog Governance

Catalog Authority: Head of AI Data Governance Schema Change Authority: AI Governance Committee (any change to mandatory fields) Quality Threshold Authority: Model Validation Forum (sets minimum quality scores for tier-one and tier-two model inputs) Audit Cadence: Annual external audit of catalog completeness, accuracy, and operational discipline End of Data Catalog Specification. Usage Notes: Catalogs that are populated at creation and never maintained become misleading. The discipline is to integrate catalog updates into the workflow that creates the change. A source system change triggers a catalog review notification, not a calendar reminder. Workflow integration is the only sustainable maintenance discipline.

Per-element record with twelve fields: source system, source field, source consent basis, source data classification, extraction method, transformation pipeline (each step documented), quality checks applied, storage location after transformation, consuming models, consuming reports, refresh cadence, lineage owner. Each tier-one model lineage rendered as a directed graph from sources through transformations to model inputs, regenerated at every pipeline change. Lineage generated from pipeline metadata where possible.

Structure

• Source system
• Source field
• Source consent basis
• Source data classification
• Extraction method
• Transformation pipeline (each step documented)
• Quality checks applied
• Storage location after transformation
• Consuming models
• Consuming reports
• Refresh cadence
• Lineage owner

Per-category structure with ten fields: category name, default retention period, retention basis (regulatory or contractual citation), legal hold protocol, disposal method, disposal certification, customer override rights, regulatory override, cross-jurisdictional considerations, Sharia overlay. Retention periods anchored in citable sources rather than defended by argument.

Structure

• Category name
• Default retention period
• Retention basis (regulatory or contractual citation)
• Legal hold protocol
• Disposal method
• Disposal certification
• Customer override rights
• Regulatory override
• Cross-jurisdictional considerations
• Sharia overlay

Five-section per-process structure: Source Data Description, Anonymization Technique (method, parameters, rationale), Residual Risk Assessment (direct attack, linkage attack, inference attack), Validation (independent re-identification attempt), Approval. Anonymization is not binary; the discipline is to document residual risk so the institution makes an informed decision rather than treating "anonymized" as a synonym for "safe."

Structure

• Source Data Description
• Anonymization Technique (method, parameters, rationale)
• Residual Risk Assessment (direct attack, linkage attack, inference attack)
• Validation (independent re-identification attempt)
• Approval

HALAL DATA CERTIFICATION CHECKLIST

Document Reference: SHC-DATA-001 Version: 1.0 Owner: Sharia Advisor Approving Authority: Sharia Supervisory Board Certification Validity: 12 months from approval date

Section 1: System Identification

Section 2: Data Source Sharia Review

For each data source feeding the AI system:

Source Screening Criteria Applied:

• [ ] Source does not derive from prohibited activities (riba-based interest income reporting, gambling, alcohol, pork, conventional insurance, weapons manufacturing)
• [ ] Source does not aggregate data from prohibited counterparties without segregation
• [ ] Source does not include data acquired through prohibited means (deception, coercion, unauthorized surveillance)
• [ ] Source consent mechanism aligns with Sharia principles of informed consent
• [ ] Source data ownership is clear and transferable per Sharia principles

Excluded Sources (with rationale):

• [Source]: [Reason for exclusion]

Sharia Advisor Sign-Off on Source List: Signed: ____________________ Name: __________ Date: __________

Section 3: Data Use Sharia Review

For each intended use case of the AI system:

Use Case Screening Criteria Applied:

• [ ] Use case does not enable a riba-based product (conventional interest-bearing lending, conventional insurance, conventional derivatives)
• [ ] Use case does not enable gharar (excessive uncertainty harming customer)
• [ ] Use case does not enable maysir (gambling-like risk transfer without underlying transaction)
• [ ] Use case does not target population in ways that exploit vulnerability
• [ ] Use case does not violate Sharia obligations to protect customer benefit
• [ ] Use case does not enable activities prohibited under AAOIFI standards

Excluded Use Cases (with rationale):

• [Use Case]: [Reason for exclusion]

Sharia Advisor Sign-Off on Use Case List: Signed: ____________________ Name: __________ Date: __________

Section 4: Consent Sharia Review

Sharia Advisor Sign-Off on Consent Mechanism: Signed: ____________________ Name: __________ Date: __________

Section 5: Beneficial Use Verification

Sharia Advisor Sign-Off on Beneficial Use: Signed: ____________________ Name: __________ Date: __________

Section 6: Annual Recertification Findings (Recertifications Only)

For recertifications, the following review compares current operational reality to prior certification.

Section 7: Certification Decision

Decision: [ ] Certified [ ] Certified with Conditions [ ] Recertification Denied Conditions (if applicable):

Certification Valid From: [Date] Certification Valid Until: [Date] Next Recertification Due: [Date]

Section 8: Sign-Off

Appendix: AAOIFI Standards Referenced in This Certification

• AAOIFI Governance Standard No. [X]
• AAOIFI Accounting Standard No. [Y]
• AAOIFI Sharia Standard No. [Z]

End of Halal Data Certification Checklist. Usage Notes: Halal data certification is not a one-time event. The annual recertification is the discipline that catches operational drift. A data source that was halal at certification can become non-halal if its operational use shifts. The Sharia advisor's annual review is the catching mechanism.

Five-section per-system structure: Use Case Alignment, Data Source Alignment, Decision Outcome Review (sample of production decisions reviewed for Sharia compliance), Customer Impact Review (complaints, recourse cases, explanation quality), Recommendation (continued operation, conditional, suspension, remediation). The Sharia review examines production reality versus approval documentation rather than reapproving the original specification.

Structure

• Use Case Alignment
• Data Source Alignment
• Decision Outcome Review (sample of production decisions reviewed for Sharia compliance)
• Customer Impact Review (complaints, recourse cases, explanation quality)
• Recommendation (continued operation, conditional, suspension, remediation)

VENDOR DUE DILIGENCE QUESTIONNAIRE

AI VENDORS

Document Reference: AVR-DDQ-001 Vendor Name: [Vendor] Service Under Evaluation: [Service Name] Tier Classification: [Tier 1 / Tier 2] Issuance Date: [DD/MM/YYYY] Response Due Date: [DD/MM/YYYY] Issuing Authority: AI Vendor Risk Office, [Institution Name] Vendor Instructions: Provide complete responses to every applicable question. Mark any question as Not Applicable only with rationale. Attach supporting documentation as referenced. Incomplete responses or unsubstantiated answers will be returned for completion.

Section 1: Vendor Corporate Profile

1.1 Provide the full legal name of the vendor entity that will contract with the institution, the jurisdiction of incorporation, and the date of incorporation. 1.2 Provide the names and jurisdictional standing of all entities holding more than ten percent equity in the vendor or its parent entities. 1.3 Provide the vendor's audited financial statements for the prior three fiscal years and a current-year management account. 1.4 Disclose any material legal proceedings, regulatory enforcement actions, or settlements in the prior five years exceeding USD 1 million in aggregate exposure. 1.5 Disclose any criminal proceedings or regulatory investigations against current executive officers in the prior ten years. 1.6 Provide the vendor's primary regulator(s) and the licensing status maintained in each regulated jurisdiction. 1.7 Disclose any changes of control, mergers, acquisitions, or divestitures planned, pending, or under negotiation.

Section 2: Service Description

2.1 Provide a detailed description of the AI service being proposed, including all components, integrations, and dependencies. 2.2 Specify the deployment model (vendor-hosted SaaS, customer-hosted, hybrid, edge) and any deployment model options available. 2.3 Specify the data residency for processed institutional data, including primary, backup, and disaster recovery locations. 2.4 Describe the support architecture: support hours, response time SLAs by issue severity, escalation paths, and the support team's geographic distribution. 2.5 Provide the standard service-level commitments (uptime, latency, throughput) with the historical performance data for the prior twelve months. 2.6 Describe any planned material changes to the service (architecture, model updates, pricing) over the next twenty-four months.

Section 3: Information Security

3.1 Provide current ISO 27001 certification status, the certification body, the certificate number, the scope statement, and the certificate expiry date. Attach the certificate. 3.2 Provide the date of the most recent SOC 2 Type II audit, the auditor's identity, the report's overall opinion, the audit period, and the management remediation status of any control exceptions identified. Attach the report or a redacted summary. 3.3 Describe the encryption standards applied to institutional data at rest and in transit, including algorithm, key length, and key management infrastructure. 3.4 Describe the access control architecture for personnel accessing institutional data, including authentication mechanisms, authorization model, privileged access management, and access review cadence. 3.5 Describe the vendor's penetration testing cadence, the most recent test date, the testing firm, the scope, and the remediation status of findings. 3.6 Disclose every security incident in the prior thirty-six months that affected customer data, including incident type, scope of impact, regulatory notifications made, and remediation completed. 3.7 Describe the vendor's vulnerability management program, including detection mechanisms, patching SLAs by severity, and validation of patch effectiveness. 3.8 Describe the vendor's secure software development lifecycle, including code review requirements, security testing in CI/CD, and dependency vulnerability scanning.

Section 4: Data Governance

4.1 Describe the technical and contractual mechanisms by which institutional data is segregated from other customer data, including encryption key separation, tenant isolation architecture, and audit log separation. 4.2 Provide the current list of sub-processors with access to institutional data, including each sub-processor's role, jurisdiction, and the security certifications maintained. 4.3 Describe the data deletion guarantees provided upon contract termination, including the timeline, the method, the certification of disposal, and the handling of backup copies. 4.4 Describe any vendor use of institutional data for vendor's model improvement, training of vendor models, or other secondary purposes, with the contractual mechanism to restrict such use. 4.5 Describe the cross-border data transfer mechanism, including the legal basis for transfers from each jurisdiction in which institutional data may be processed. 4.6 Describe the data lineage documentation available to the institution for institutional data processed through the vendor service.

Section 5: Privacy Compliance

5.1 Describe the vendor's compliance posture against the Saudi Personal Data Protection Law and the UAE federal Personal Data Protection Law, including the named Data Protection Officer and the regulatory registrations maintained. 5.2 Describe the vendor's compliance posture against GDPR for any institutional data subjects with EU residence. 5.3 Describe the vendor's mechanism for handling data subject access requests originating from data subjects whose data was processed on behalf of the institution, including request routing, fulfillment timelines, and verification protocols. 5.4 Describe the vendor's consent management capability for institutional deployments requiring granular customer consent capture and withdrawal. 5.5 Describe the vendor's breach notification capability, including the maximum time to notify the institution of a confirmed breach affecting institutional data, the notification mechanism, and the information included in the initial notification. 5.6 Disclose any privacy regulator enforcement actions, fines, or consent decrees in the prior five years.

Section 6: Model Governance

6.1 Provide the model card, validation summary, and bias audit results for each AI model included in the proposed service. State the cadence at which these documents are refreshed and the mechanism by which the institution receives updated documents. 6.2 Describe the vendor's model validation methodology, the independence of the validation function from the development function, and the qualifications of the validation team. 6.3 Describe the vendor's bias assessment methodology, the protected attributes assessed, the fairness metrics reported, and the mitigation techniques applied. 6.4 Describe the explainability features available for model outputs, including global explainability, local explainability, counterfactual explanations, and customer-facing explanations in Arabic and English. 6.5 Describe the vendor's model monitoring capability, including data drift, concept drift, prediction drift, and bias drift, with the thresholds and alerting mechanisms. 6.6 Describe the vendor's model retraining cadence, the triggers for unscheduled retraining, the notification provided to the institution before retraining, and the institution's ability to validate retrained models before deployment. 6.7 Describe the vendor's model retirement protocol, including the institution's notice period for retirement, the data return for institutional data used in training, and the support for institutional migration to a successor model. 6.8 Describe any human-in-the-loop or human-on-the-loop mechanisms available in the service, including the trigger criteria, the reviewer authority, and the documentation of human decisions.

Section 7: Operational Resilience

7.1 Provide the Recovery Time Objective and Recovery Point Objective for the proposed service, the geographic redundancy architecture supporting these objectives, and the most recent disaster recovery exercise outcome. 7.2 Describe the vendor's business continuity plan, the most recent exercise date, and the lessons learned register. 7.3 Describe the vendor's incident response capability, including the on-call team structure, escalation paths, and customer communication protocols during active incidents. 7.4 Disclose any service outages in the prior twenty-four months exceeding the SLA threshold, with root cause and remediation summary. 7.5 Describe the vendor's capacity management for surge demand, including the maximum throughput supported and the scaling response time.

Section 8: Regulatory Engagement

8.1 Provide the list of regulators in MENA jurisdictions with whom the vendor has had formal engagements in the prior three years, the nature of each engagement, and the outcome. 8.2 Describe the vendor's mechanism for responding to regulatory inquiries directed to the institution but requiring vendor cooperation, including the named cooperation contact and the standard cooperation timeline. 8.3 Describe the vendor's audit cooperation posture, including the institution's audit rights, the cadence of permitted audits, and the cost-sharing model. 8.4 Disclose any regulatory examinations of the vendor's AI products in the prior five years, with summary findings and remediation status.

Section 9: Sharia Compliance (Islamic Finance Institutions)

9.1 Describe the vendor's Sharia governance structure, including the constitution of any Sharia board, the qualifications of board members, and the cadence of Sharia review. 9.2 State the AAOIFI standards the vendor's products are aligned to, with the specific standards cited. 9.3 Describe the vendor's willingness to undergo Sharia review by the institution's Sharia Supervisory Board, including the access provided to source code, training data, and operational logs. 9.4 Describe the vendor's data source screening for Sharia compliance, including the exclusion of data derived from prohibited activities and the certification of source halal status. 9.5 Describe the vendor's use case screening for Sharia compliance, including the prohibition on use cases enabling riba, gharar, maysir, or other prohibited activities. 9.6 Describe the vendor's customer-facing transparency mechanisms aligned with Sharia principles of informed consent and beneficial use.

Section 10: Exit and Transition

10.1 Describe the data return protocol upon contract termination, including the data formats, the return timeline, the destruction certification provided for residual copies, and the transition support offered to alternative vendors. 10.2 Describe the source code or model escrow arrangements available, including the escrow agent, the release conditions, and the support provided to the institution upon release. 10.3 Describe the alternative-vendor migration support available, including the technical support, the data migration assistance, and the timeline. 10.4 Describe the vendor's contract termination rights for cause and for convenience, including notice periods, fee implications, and transition obligations. 10.5 Describe any termination fees, early-exit charges, or other costs associated with contract termination before the end of the initial term.

Vendor Attestation

The undersigned attests that the responses provided in this questionnaire are accurate and complete to the best of vendor knowledge, that supporting documentation referenced is current, and that material changes to any response will be communicated to the institution within fifteen business days of becoming known. Vendor Signatory Name: ____________________ Title: ____________________ Date: ____________________ Signature: ____________________

Institutional Use Only

End of Vendor Due Diligence Questionnaire. Usage Notes: The questionnaire is the diagnostic, not the decision. Vendors who answer all questions thoroughly are not necessarily approved. Vendors who decline to answer specific questions reveal their boundaries, which is information the institution uses. The discipline is to treat refusal as a finding rather than as a failure of the questionnaire.

Eight-section structure: Institutional Background and Use Case, Functional Requirements, Non-Functional Requirements, Governance Requirements, Sharia Requirements (Islamic finance institutions), Commercial Requirements, Submission Requirements, Evaluation Methodology. The discipline is to disclose the scoring weights so vendors compete on the dimensions the institution cares about.

Structure

• Institutional Background and Use Case
• Functional Requirements
• Non-Functional Requirements
• Governance Requirements
• Sharia Requirements (Islamic finance institutions)
• Commercial Requirements
• Submission Requirements
• Evaluation Methodology

AI VENDOR CONTRACT: AI-SPECIFIC CLAUSES MODULE

Note: This module supplements the institution's standard procurement contract. The clauses below address risks specific to AI vendor engagements. Legal counsel review and adaptation to applicable jurisdiction is required before execution.

Article 1: Data Use Rights

1.1 Permitted Use: Vendor may process Institutional Data solely for the purposes of delivering the Services described in Schedule [X] and for no other purpose. 1.2 Prohibition on Model Training: Vendor shall not use Institutional Data to train, retrain, fine-tune, or otherwise improve any vendor-developed AI model, whether deployed for the Institution or for any other vendor customer, without the Institution's explicit prior written consent. 1.3 Prohibition on Third-Party Disclosure: Vendor shall not sell, license, lease, transfer, or otherwise disclose Institutional Data to any third party except (a) sub-processors approved under Article 6, (b) as required by applicable law with prior notice to the Institution where lawful, or (c) with the Institution's prior written consent. 1.4 Aggregated Data: Vendor's use of aggregated or anonymized data derived from Institutional Data shall be permitted only where (a) the data has been irreversibly anonymized to the residual-risk standard of [reference institutional anonymization policy], (b) the Institution has provided prior written consent, and (c) the anonymized data is not used in a manner that would harm the Institution's competitive position. Sample Clause Language: "Vendor acknowledges that Institutional Data is a strategic asset of the Institution. Vendor's processing rights are limited to those expressly granted in this Agreement. Any processing beyond the express grant constitutes a material breach."

Article 2: Model Documentation Delivery

2.1 Initial Delivery: Within thirty days of contract execution, Vendor shall deliver to the Institution (a) model cards for all AI models included in the Services, (b) validation reports for all such models, (c) bias audit reports for all such models conducted within the prior twelve months, and (d) any current regulatory documentation or certifications. 2.2 Refresh Cadence: Vendor shall refresh and re-deliver the documentation in Section 2.1 at the earlier of (a) annual cycle commencing on the contract anniversary, (b) any material change to a model included in the Services, or (c) any change in regulatory documentation requirements affecting the Services. 2.3 Format and Standards: Documentation shall conform to the institutional Model Card Template (Appendix B Template 11), Validation Report Template (Template 12), and Bias Audit Report Template (Template 13) standards, or to substantively equivalent vendor formats with mapping documentation provided. Sample Clause Language: "Vendor shall provide all documentation required for the Institution to satisfy its regulatory documentation obligations under SDAIA, CBUAE, SAMA, PDPL, AAOIFI (where applicable), and any other regulatory framework applicable to the Institution's deployment of the Services."

Article 3: Audit Rights

3.1 Annual Audit Right: The Institution may, no more than once in any twelve-month period, conduct or commission an audit of Vendor's controls relevant to the Services, including security controls, data governance controls, model governance controls, and Sharia compliance controls (where applicable). 3.2 Audit Scope: The audit scope shall be reasonable in light of the Services and the Institution's risk profile, and shall include the right to (a) interview Vendor personnel, (b) review Vendor documentation, (c) inspect Vendor facilities where Institutional Data is processed, and (d) test Vendor controls. 3.3 Auditor Selection: The Institution may use its internal audit function or a qualified third-party auditor. Vendor may object to a specific third-party auditor only on grounds of demonstrable conflict of interest. 3.4 Cost Allocation: The Institution bears the cost of routine audits. Vendor bears the cost of remediation of audit findings and of any follow-up audit triggered by material findings. 3.5 Regulatory Audit Cooperation: Vendor shall cooperate with any audit conducted by a regulator with jurisdiction over the Institution, including providing access to facilities, personnel, and documentation as the regulator requires. Sample Clause Language: "Vendor's audit obligations are fundamental to the Institution's regulatory compliance posture. A material breach of audit obligations constitutes a material breach of this Agreement giving rise to termination rights under Article 11."

Article 4: Regulatory Cooperation

4.1 Notification of Regulatory Engagement: Vendor shall notify the Institution within five business days of any (a) regulatory inquiry, investigation, or enforcement action affecting the Services or Vendor's general operations relevant to AI services, (b) regulatory examination scheduled that may affect the Institution's data or models, or (c) material change in regulatory licensing or certification status. 4.2 Cooperation with Institution's Regulators: Vendor shall cooperate with the Institution's regulators upon request, including providing testimony, documentation, and access to personnel and systems as the regulator requires, subject to vendor's reasonable confidentiality protections. 4.3 Dedicated Cooperation Contact: Vendor shall designate a named individual as the regulatory cooperation contact, with authority to coordinate vendor's response to regulatory matters affecting the Institution. Sample Clause Language: "Vendor recognizes that the Institution operates in regulated industries and that regulatory cooperation is a non-negotiable institutional obligation that flows through to Vendor as a service provider."

Article 5: Incident Notification

5.1 Maximum Notification Time: Vendor shall notify the Institution of any (a) confirmed or reasonably suspected unauthorized access to Institutional Data, (b) confirmed or reasonably suspected compromise of Vendor systems processing Institutional Data, (c) material service disruption, (d) material change in model behavior affecting Institutional outcomes, or (e) other incident reasonably likely to affect the Institution's interests, within four hours of detection. 5.2 Notification Content: Initial notification shall include the nature of the incident, the data and systems affected, the estimated scope of impact, the containment actions taken, and the dedicated incident contact. Updates shall follow at intervals not exceeding twelve hours during active incidents. 5.3 Joint Incident Response: For incidents materially affecting Institutional Data or Services, Vendor's incident commander shall join the Institution's incident bridge and participate in joint response activities including evidence preservation, root cause analysis, and remediation planning. 5.4 Regulatory Notification Support: Vendor shall provide the information the Institution requires to meet regulatory notification deadlines under applicable frameworks, including providing such information within twelve hours of Institution request. Sample Clause Language: "Time is of the essence in incident notification. The Institution's regulatory notification clocks begin at the time of breach discovery, which may include the time of vendor discovery. Vendor's prompt notification is essential to the Institution's regulatory compliance."

Article 6: Sub-Processor Restrictions

6.1 Approval Requirement: Vendor shall not engage any sub-processor with access to Institutional Data without the Institution's prior written approval. 6.2 Approved Sub-Processor List: Vendor shall maintain a list of approved sub-processors as Schedule [Y] of this Agreement. The Schedule may be updated only by written amendment. 6.3 Notification of Proposed Changes: Vendor shall provide thirty days notice of any proposed addition, removal, or material change to a sub-processor. The Institution may object within the notice period. 6.4 Right of Objection: If the Institution objects to a proposed sub-processor, the parties shall negotiate in good faith. If agreement cannot be reached, the Institution may terminate the affected portion of the Services without penalty. 6.5 Sub-Processor Flow-Down: Vendor shall flow down to each sub-processor obligations substantively equivalent to Vendor's obligations under this Agreement regarding data protection, security, and incident notification.

Article 7: Data Residency

7.1 Permitted Storage Locations: Institutional Data shall be stored and processed only in the locations specified in Schedule [Z]. The default permitted locations are [list jurisdictions]. 7.2 Prohibition on Transfer: Vendor shall not transfer Institutional Data outside the permitted locations without the Institution's prior written approval, except as required by applicable law with prior notice to the Institution where lawful. 7.3 Cross-Border Transfer Mechanism: Where cross-border transfer is approved, the parties shall execute the appropriate mechanism (Standard Contractual Clauses, Binding Corporate Rules, adequacy reliance) before the transfer occurs. 7.4 Sub-Processor Locations: Sub-processor locations shall be specified in Schedule [Y] and shall not exceed the locations approved for Vendor's direct processing.

Article 8: Service Levels

8.1 Performance Commitments: Vendor commits to the service levels specified in Schedule [X], including uptime, latency, throughput, accuracy (where applicable), and incident response times. 8.2 Service Credits: Failure to meet service level commitments triggers service credits per the schedule, which the Institution may apply against future invoices or take as a refund. 8.3 Sustained Breach Termination: Sustained breach of service level commitments (defined as material breach in three of any twelve consecutive months) constitutes material breach giving rise to termination rights under Article 11. 8.4 Performance Reporting: Vendor shall provide monthly performance reports against committed service levels, with detailed breakout of any non-conformance.

Article 9: Exit Clauses

9.1 Data Return: Upon contract termination or expiration, Vendor shall return all Institutional Data within thirty days, in the formats specified in Schedule [W], with certification of completeness. 9.2 Data Destruction: Following return, Vendor shall destroy all residual copies of Institutional Data within sixty days, with destruction certified in writing by Vendor's Data Protection Officer or equivalent role. 9.3 Transition Support: Vendor shall provide transition support to the Institution and to any alternative vendor selected by the Institution for a period of [180 days] following termination notice, at fees not exceeding the standard service fees in effect at termination. 9.4 Source Code or Model Escrow: Where the Services include vendor-proprietary models or code essential to the Institution's continued operations, Vendor shall maintain escrow with a qualified escrow agent. Release conditions shall include vendor bankruptcy, vendor material breach uncured after notice, and vendor inability to continue providing the Services. 9.5 Knowledge Transfer: Vendor shall provide knowledge transfer to the Institution's personnel or to alternative vendor personnel, including documentation, training sessions, and access to subject-matter experts during the transition period.

Article 10: Sharia Cooperation (Islamic Finance Institutions)

10.1 Sharia Review Cooperation: Vendor shall cooperate with Sharia review conducted by the Institution's Sharia Supervisory Board, including providing access to source code, training data, operational logs, and personnel as the Sharia Advisor reasonably requires. 10.2 Sharia Findings Remediation: Vendor shall remediate Sharia findings within the timelines agreed with the Institution's Sharia Advisor, recognizing that material Sharia non-compliance may constitute grounds for service suspension. 10.3 AAOIFI Alignment: Where applicable, Vendor shall maintain alignment with AAOIFI governance, accounting, and Sharia standards as specified in Schedule [V]. 10.4 Halal Data Source Verification: Vendor shall provide annual attestation that data sources used in the Services maintain halal status per the standards referenced in Template 22.

Article 11: Termination Rights

11.1 Termination for Convenience: Either party may terminate this Agreement for convenience upon [180 days] written notice. 11.2 Termination for Cause: Either party may terminate this Agreement for cause upon written notice without cure period for (a) material breach not capable of cure, (b) bankruptcy, insolvency, or similar event, or (c) acts of fraud, willful misconduct, or gross negligence. 11.3 Termination for Material Breach with Cure: Either party may terminate this Agreement for material breach capable of cure if the breach is not cured within [thirty days] of written notice specifying the breach. 11.4 Institution Termination for Specific Causes: The Institution may additionally terminate without penalty for (a) any security breach affecting Institutional Data where Vendor's response was materially deficient, (b) any regulatory enforcement action against Vendor that materially affects the Services, (c) sustained service level breach as defined in Article 8.3, (d) material breach of audit obligations under Article 3, (e) material breach of incident notification obligations under Article 5, or (f) failure of Sharia recertification (Islamic finance institutions). 11.5 No Termination Penalty for Cause: Termination for cause shall not trigger early termination fees or other penalty payments.

Article 12: Liability and Indemnity

12.1 Vendor Indemnity: Vendor shall indemnify the Institution against (a) third-party claims arising from Vendor's breach of this Agreement, (b) regulatory penalties imposed on the Institution arising from Vendor's failure to meet obligations under this Agreement, (c) third-party intellectual property claims arising from the Services, and (d) claims arising from Vendor's negligence or willful misconduct. 12.2 Liability Cap, General: Vendor's aggregate liability under this Agreement is capped at the greater of (a) [USD amount] or (b) [multiple, e.g., 3x] of fees paid under this Agreement in the twelve months preceding the event giving rise to liability. 12.3 Liability Cap, Carveouts: The liability cap in Section 12.2 does not apply to (a) Vendor's indemnity obligations under Section 12.1, (b) Vendor's breach of data protection obligations, (c) Vendor's breach of confidentiality obligations, (d) regulatory penalties under Section 12.1(b), or (e) liability arising from Vendor's gross negligence, willful misconduct, or fraud. 12.4 Insurance: Vendor shall maintain professional indemnity insurance, cyber liability insurance, and general liability insurance in amounts not less than those specified in Schedule [U], with the Institution named as additional insured where commercially available.

End of AI-Specific Clauses Module. Usage Notes: AI-specific clauses are routinely the last issues resolved in contract negotiation because vendors push back hardest on audit rights, data use restrictions, and exit clauses. The discipline is to treat these clauses as non-negotiable institutional requirements rather than as starting positions. Vendors who cannot meet them reveal a vendor-institution misalignment that contract negotiation cannot fix.

Seven-section per-vendor structure: Vendor Identification, Performance Metrics (SLA achievement, incident count, MTTR, customer impact), Governance Metrics (documentation completeness, validation/audit/regulatory cooperation ratings), Security Metrics (incidents, vulnerabilities, penetration test results, certification currency), Commercial Metrics (spend, pricing trajectory, renegotiation requests), Composite Risk Rating (aggregate green/amber/red with quarterly trend), Sign-Off. Sample weighting tier-one: Performance 30%, Governance 25%, Security 25%, Commercial 20%. Composite thresholds: Green 80%+, Amber 60-79%, Red below 60%.

Structure

• Vendor Identification
• Performance Metrics (SLA achievement, incident count, MTTR, customer impact)
• Governance Metrics (documentation completeness, validation/audit/regulatory cooperation ratings)
• Security Metrics (incidents, vulnerabilities, penetration test results, certification currency)
• Commercial Metrics (spend, pricing trajectory, renegotiation requests)
• Composite Risk Rating (aggregate green/amber/red with quarterly trend)
• Sign-Off

Database with one row per transfer flow and fourteen fields: Transfer ID, Source Jurisdiction, Destination Jurisdiction, Data Categories Transferred, Volume Estimate, Frequency, Recipient, Legal Basis Source, Legal Basis Destination, Safeguard Applied (SCC, BCR, consent, adequacy), Risk Rating, Review Cadence, Last Review Date, Next Review Due. Risk rating drives review cadence: low annual, medium quarterly, high monthly.

Structure

• Transfer ID
• Source Jurisdiction
• Destination Jurisdiction
• Data Categories Transferred
• Volume Estimate
• Frequency
• Recipient
• Legal Basis Source
• Legal Basis Destination
• Safeguard Applied (SCC, BCR, consent, adequacy)
• Risk Rating
• Review Cadence
• Last Review Date
• Next Review Due

AI INCIDENT SEVERITY CLASSIFICATION GUIDE

Document Reference: AIR-SEV-001 Version: 1.0 Owner: Head of AI Incident Response Approver: AI Governance Committee Used by: On-call AI Incident Commander, Head of AI Incident Response, AI Governance Committee Chair (override authority)

Section 1: How to Use This Guide

The on-call AI Incident Commander uses this guide at incident intake to assign a provisional severity classification within fifteen minutes of detection. The provisional classification triggers the response cadence specified in Section 4 and the escalation chain specified in Section 5. The Head of AI Incident Response confirms or revises the classification within the first hour. The AI Governance Committee Chair holds override authority on any disputed classification. Severity classification is conservative. When in doubt between two severity levels, classify at the higher severity. Downgrade only with documented justification.

Section 2: Severity Definitions

P0: Critical Emergency

Definition: An AI incident producing or reasonably expected to produce material harm to a significant population of customers, material financial loss to the Institution exceeding [USD threshold], or material regulatory exposure with statutory notification clock active. Examples:

• Confirmed data breach exposing personal data of more than 1,000 customers
• Production model producing customer-facing decisions outside validated performance envelope affecting more than 500 customers in any 24-hour window
• Bias incident with regulatory exposure where disparate outcomes are statistically significant and causally attributable to the model
• Hallucination in customer-facing generative AI producing materially false information distributed to customers
• Prompt injection compromise of agentic AI resulting in unauthorized actions taken on customer accounts
• Vendor compromise affecting institutional data with confirmed exfiltration
• Model decision affecting essential customer service (account access, payment processing, fraud determination) producing systematic incorrect outcomes

Response Profile: Immediate. All-hands.

P1: High Severity

Definition: An AI incident producing or reasonably expected to produce significant harm to a contained customer population, significant institutional risk, or significant regulatory attention without statutory notification clock yet active. Examples:

• Confirmed data breach exposing personal data of 100 to 1,000 customers
• Production model performance degradation exceeding institutional tolerance affecting 100 to 500 customers in any 24-hour window
• Bias indication requiring formal audit and likely committee escalation
• Hallucination in customer-facing generative AI producing materially incorrect information delivered to fewer than 50 customers
• Vendor service disruption exceeding SLA threshold affecting tier-one or tier-two services
• Drift detection at red threshold for tier-one model
• Model approval condition breach discovered post-deployment

Response Profile: Within one hour. Senior leadership engaged.

P2: Medium Severity

Definition: An AI incident producing limited harm or institutional risk, requiring structured response but not immediate executive attention. Examples:

• Confirmed data breach exposing personal data of fewer than 100 customers without sensitive data categories
• Production model performance degradation affecting fewer than 100 customers
• Drift detection at amber threshold for tier-one or red threshold for tier-two model
• Vendor service disruption within SLA tolerance but recurring pattern
• Documentation deficiency discovered in routine audit
• Sharia recertification gap discovered (Islamic finance institutions)
• Validation finding remediation overdue by more than 30 days

Response Profile: Within four hours. AI Governance Office leads.

P3: Low Severity

Definition: An AI incident with minimal customer or institutional impact, addressable through standard operational response. Examples:

• Single-customer model decision producing incorrect outcome with available recourse
• Documentation update required from upstream policy change
• Drift detection at amber threshold for tier-two or red threshold for tier-three model
• Vendor performance issue isolated to single incident
• KRI in amber state without trend deterioration

Response Profile: Within one business day. Operational team leads.

P4: Observation

Definition: An event of governance interest that does not yet meet incident criteria but warrants documentation. Examples:

• KRI trend approaching amber threshold
• Vendor performance trend warranting attention without breach
• Regulatory horizon item warranting future action
• Lessons-learned observation from external incident at peer institution
• Operator question revealing potential training gap

Response Profile: Next governance forum review.

Section 3: Severity Classification Matrix

Use the matrix below when severity is not obvious from the examples in Section 2. Assess each dimension and take the highest severity that any dimension triggers.

Maximum-Dimension Rule: Classify at the severity of the highest-rated dimension.

Section 4: Response Cadence by Severity

Section 5: Escalation Chain

P0 Escalation (Immediate)

1. On-call AI Incident Commander confirms classification
2. Head of AI Incident Response notified within 15 minutes
3. Head of AI Governance Office notified within 30 minutes
4. Chief Risk Officer notified within 1 hour
5. Chief Executive Officer notified within 4 hours
6. Board Risk Committee Chair notified within 24 hours
7. Regulatory notification triggered per Template 37 within statutory deadline

P1 Escalation

1. On-call AI Incident Commander classifies
2. Head of AI Incident Response notified within 30 minutes
3. Head of AI Governance Office notified within 1 hour
4. Chief Risk Officer notified within 4 hours
5. Executive Committee notified at next scheduled meeting

P2 Escalation

1. On-call AI Incident Commander classifies
2. Head of AI Incident Response notified within 2 hours
3. Head of AI Governance Office notified within 1 business day
4. AI Governance Committee notified at next meeting

P3 Escalation

1. Operational team handles
2. AI Incident Response Office notified within 1 business day
3. Aggregated reporting at next monthly review

P4 Escalation

1. Documented in observation register
2. Reviewed at next governance forum

Section 6: Classification Override Authority

Override Discipline: Downgrades are scrutinized at post-incident review. A pattern of downgrades that prove premature triggers Committee review of classification training.

Section 7: Special Cases

7.1 Sharia Compliance Incidents (Islamic Finance Institutions)

Sharia compliance incidents are classified using the matrix above with a Sharia Advisor consultation within the first response window. Material Sharia breaches default to P0.

7.2 Cross-Jurisdictional Incidents

Incidents triggering notification obligations in multiple jurisdictions are managed at the most stringent jurisdiction's requirements, with parallel notification streams coordinated by the Head of Legal.

7.3 Vendor-Originated Incidents

Vendor-originated incidents are classified by their impact on the Institution. Vendor incidents without institutional impact are tracked separately but do not enter the institutional incident severity register.

7.4 Discovered Latent Incidents

Incidents discovered to have been occurring for an extended period before detection are classified by their aggregate impact, not by the impact at the moment of detection. End of Incident Severity Classification Guide. Usage Notes: Severity classification is the single most consequential decision in the first hour of an incident. The classification drives notification clocks, escalation paths, and resource mobilization. The discipline is to classify conservatively in the first fifteen minutes and refine within the first hour, rather than under-classify and discover the misclassification at the regulatory deadline.

RUNBOOK: BIAS DETECTED IN PRODUCTION

Document Reference: AIR-RBK-BIAS-001 Version: 1.0 Owner: Head of AI Incident Response Approver: AI Governance Committee Exercise Cadence: Quarterly simulation

Phase 0: Detection Triage (First 30 Minutes)

Step 0.1: On-call AI Incident Commander confirms the alert source:

• Monitoring system alert (drift detector, bias monitor)
• Internal audit finding
• Customer complaint pattern
• External research publication
• Regulatory inquiry
• Vendor notification

Step 0.2: Confirm the alert is not a known false positive. Cross-reference with the false-positive register. Step 0.3: Identify the affected model. Reference model card (Template 11) and model inventory (Template 14). Step 0.4: Provisional severity classification using Template 29. Bias incidents with regulatory exposure default to P1 minimum. Step 0.5: Open incident record. Assign incident ID. Start decision log. Step 0.6: Notify Head of AI Incident Response within 30 minutes.

Phase 1: First Hour Actions

Step 1.1: Independent calculation of the disparity. Do not rely solely on the alert source. The on-call validator runs an independent calculation against the most recent production sample. Step 1.2: Confirm the disparity is statistically significant. Use the institutional fairness metric thresholds from Template 13. If the disparity is within natural variation, downgrade severity per Template 29 override protocol. Step 1.3: Identify the protected attribute affected and its jurisdictional basis. Cite the specific PDPL article, AAOIFI standard, or sectoral regulation. Step 1.4: Assess immediate scope:

• How many customers affected in the prior 24 hours?
• How many customers affected since last bias audit?
• Is the model still producing decisions?
• Is the disparity present in the most recent decisions?

Step 1.5: Notify Head of AI Governance Office, Chief Risk Officer, Ethics Committee Chair (for tier-one models). Step 1.6: Document the first hour in the decision log.

Phase 2: First Four Hours, Containment Decision

Step 2.1: Convene the containment decision meeting. Required attendees:

• AI Incident Commander
• Head of AI Incident Response
• Head of Model Validation
• Model Owner
• General Counsel
• Ethics Committee Chair (tier-one models)
• Sharia Advisor (Islamic finance institutions, if relevant)

Step 2.2: Evaluate containment options:

Step 2.3: Document the containment decision with rationale, decision-makers present, and dissent if any. Tier-one model containment decisions to continue operation require unanimous attendee approval. Step 2.4: Execute the containment action. Verify execution. Step 2.5: Notify affected business unit head and Chief Customer Officer.

Phase 3: First 24 Hours, Investigation

Step 3.1: Convene the investigation team. The team excludes the model's original developer. Step 3.2: Determine investigation scope:

• Is the disparity causally attributable to the model, or is it the underlying population reality reflected accurately?
• Did the disparity exist at validation, or did it emerge in production?
• What changed (data, model, deployment) before the disparity appeared?
• What is the customer harm pattern?

Step 3.3: Preserve evidence:

• Inference logs for the affected period
• Model artifacts as deployed
• Training data snapshot
• Validation report and bias audit report
• Drift monitoring history
• Deployment configuration history

Step 3.4: Initial root cause hypothesis within 12 hours. Step 3.5: Customer impact assessment:

• Identified affected customers from inference log query
• Categorize impact severity per customer
• Determine recourse pathway availability

Phase 4: First 48 Hours, Decision Point

Step 4.1: AI Governance Committee Chair convenes decision meeting. Required pre-read:

• Incident summary
• Independent disparity calculation
• Containment status
• Investigation status
• Customer impact assessment
• Containment options evaluation update

Step 4.2: Committee Chair decides:

• Continue containment posture
• Adjust containment posture
• Escalate to extraordinary Committee meeting
• Escalate to Board Risk Committee Chair

Step 4.3: Ethics Committee Chair review for tier-one model bias incidents. The Ethics Committee Chair may recommend additional actions. Step 4.4: Document the decision with rationale.

Phase 5: Communications

5.1 Internal Communications

Per Template 36 (Internal Communications Template).

5.2 Regulatory Notification

Bias incidents with regulatory exposure trigger notification obligations under multiple regimes. Head of Legal coordinates:

• PDPL notification where personal data processing is implicated
• Sectoral regulator notification (CBUAE, SAMA) where customer protection expectations apply
• AAOIFI governance reporting (Islamic finance institutions) where Sharia compliance is affected

Use Template 37 (Regulatory Notification Template).

5.3 Customer Communications

Affected customers receive proactive notification within 72 hours of containment. Customer communication includes:

• Statement of fact about the situation
• What this means for the affected customer
• Specific action taken on the customer's account or decision
• Recourse pathway (human review, decision override request)
• Direct contact for questions
• Commitment to follow-up

Use Template 38 (Customer Communications Template), adapted for the specific protected attribute and decision affected.

5.4 Media Statement

Prepared statement held in readiness. Released only if media inquiry begins or proactive disclosure is required per General Counsel and Chief Communications Officer judgment. Use Template 39.

Phase 6: Remediation

Step 6.1: Remediation plan development:

• Model remediation (retraining, mitigation method change, threshold adjustment)
• Data remediation (if data issue identified)
• Process remediation (if process gap identified)
• Policy remediation (if policy gap identified)

Step 6.2: Remediation plan approval:

• Model Validation Forum approves model remediation
• Data Governance Officer approves data remediation
• AI Governance Committee approves process and policy remediation

Step 6.3: Remediation execution with timeline:

• Quick wins within 7 days
• Substantive remediation within 30 days
• Structural remediation within 90 days

Step 6.4: Pre-restoration validation: independent re-validation of the remediated model, including focused bias audit, before any restoration to full operation.

Phase 7: Recovery

Step 7.1: Return-to-service criteria:

• Disparity below institutional threshold confirmed in independent re-validation
• Bias audit refreshed and approved
• Model card updated (Template 11)
• Validation report updated (Template 12)
• Drift monitoring configuration enhanced (Template 16)
• Customer communications complete
• Regulatory notifications complete

Step 7.2: Phased restoration:

• Stage 1: Internal users only, 24 hours, manual review of all decisions
• Stage 2: 10% of customer traffic, 48 hours, enhanced monitoring
• Stage 3: 50% of customer traffic, 72 hours, enhanced monitoring
• Stage 4: Full traffic, sustained enhanced monitoring for 30 days

Step 7.3: Sign-off:

• Head of Model Validation confirms re-validation
• Head of AI Incident Response confirms incident closure conditions
• AI Governance Committee acknowledges return to service

Phase 8: Post-Incident Review

Step 8.1: Post-Incident Review scheduled within 30 days. Use Template 31. Step 8.2: Findings cascade:

• Policy revisions
• Runbook revisions (including this runbook)
• Training revisions
• Bias audit methodology revisions if methodology gap identified

Step 8.3: Update institutional lessons-learned register. Step 8.4: Update Bias Audit Report Template (Template 13) if a methodology gap was identified.

Roles and Responsibilities

Quick Reference Card

End of Bias Detection Runbook. Usage Notes: This runbook is exercised quarterly through tabletop simulation. The simulation surfaces gaps the runbook did not anticipate. Each simulation produces revisions to the runbook before the next quarterly exercise. A runbook that does not change over time is a runbook that is not being exercised against new realities.

Seven-section structure: Incident Summary (detection, containment, resolution timelines, severity classification), Root Cause Analysis (triggering event, contributing factors, systemic factors), Response Assessment (what worked, what did not, runbook adherence), Impact Assessment (customer, financial, reputational, regulatory), Findings (numbered with severity, recommendation, owner, due date), Policy and Runbook Revisions, Sign-Off. The discipline is to ensure findings produce documented changes to policy, runbook, or training.

Structure

• Incident Summary (detection, containment, resolution timelines, severity classification)
• Root Cause Analysis (triggering event, contributing factors, systemic factors)
• Response Assessment (what worked, what did not, runbook adherence)
• Impact Assessment (customer, financial, reputational, regulatory)
• Findings (numbered with severity, recommendation, owner, due date)
• Policy and Runbook Revisions
• Sign-Off

Eight-section structure: Scope, Permitted Uses, Conditional Uses (requiring elevated approval), Prohibited Uses (institutional registry maintained by Ethics Committee), Approval Pathway, Compliance Obligations, Enforcement, Review Cadence. Sample prohibited uses include: AI making consequential employment decisions without human in the loop; generative AI producing content represented as human-authored in regulatory submissions without disclosure; AI inferring protected attributes for decision-making; AI for automated denial of essential services without human review; AI synthetic media impersonating real persons.

Structure

• Scope
• Permitted Uses
• Conditional Uses (requiring elevated approval)
• Prohibited Uses (institutional registry maintained by Ethics Committee)
• Approval Pathway
• Compliance Obligations
• Enforcement
• Review Cadence

Eight-section structure: Scope, Development Standards, Validation Standards (independence, methodology, documentation), Deployment Standards (Gate requirements), Monitoring Standards, Retirement Standards, Sharia Standards (Islamic finance institutions), Roles and Authorities. Sample policy statements: Every production model is registered before activation; tier-one production approval requires unanimous voting member approval; model developers cannot validate their own models; bias audits mandatory for tier-one and tier-two; drift monitoring mandatory and reviewed quarterly.

Structure

• Scope
• Development Standards
• Validation Standards (independence, methodology, documentation)
• Deployment Standards (Gate requirements)
• Monitoring Standards
• Retirement Standards
• Sharia Standards (Islamic finance institutions)
• Roles and Authorities

Eight-section structure: Scope, Tier Definitions, Selection Standards (referenced to Template 24), Contracting Standards (referenced to Template 26), Monitoring Standards (referenced to Template 27), Exit Standards (drill cadence), Sharia Standards (Islamic finance institutions), Roles and Authorities. Sample policy statements: All AI vendor procurements routed through AI Vendor Risk before contract execution; tier-one vendor selections require AI Governance Committee approval; required AI-specific clauses non-negotiable; vendor scorecards refreshed quarterly; exit drills exercised annually for tier-one vendors.

Structure

• Scope
• Tier Definitions
• Selection Standards (referenced to Template 24)
• Contracting Standards (referenced to Template 26)
• Monitoring Standards (referenced to Template 27)
• Exit Standards (drill cadence)
• Sharia Standards (Islamic finance institutions)
• Roles and Authorities

Ten-section structure: Scope, Classification Schema (Template 18), Sourcing Standards, Lineage Standards (Template 19), Quality Standards (six-dimension assessment), Retention Standards (Template 20), Anonymization Standards (Template 21), Transfer Standards (Template 28), Halal Standards (Template 22, Islamic finance), Roles and Authorities. Sample policy statements: All AI data classified before use; lineage documented for tier-one and tier-two models; retention enforced through automated disposal; cross-border transfers recorded before initiation; halal data certification refreshed annually.

Structure

• Scope
• Classification Schema (Template 18)
• Sourcing Standards
• Lineage Standards (Template 19)
• Quality Standards (six-dimension assessment)
• Retention Standards (Template 20)
• Anonymization Standards (Template 21)
• Transfer Standards (Template 28)
• Halal Standards (Template 22, Islamic finance)
• Roles and Authorities

Per-communication structure with eight fields: Subject Line (severity, system, time), Recipient List, Time of Communication, Current Situation (factual, no speculation), Actions in Progress, Actions Completed, Decisions Made and By Whom, Next Update Time. Cadence: every 30 minutes during first 4 hours, hourly for next 12, every 4 hours thereafter until resolution. The discipline is rhythm so stakeholders stop consuming the incident commander's cognitive load with status requests.

Structure

• Subject Line (severity, system, time)
• Recipient List
• Time of Communication
• Current Situation (factual, no speculation)
• Actions in Progress
• Actions Completed
• Decisions Made and By Whom
• Next Update Time

PERSONAL DATA BREACH NOTIFICATION

[TO REGULATORY AUTHORITY]

Confidential: Regulatory Communication

[Institution Letterhead] [Date] To: [Regulatory Authority Name] [Authority Address] Attention: [Data Protection Authority Officer / SDAIA Officer / UAE Data Office Officer] Reference: [Institutional Reference Number] Subject: Personal Data Breach Notification under [the Saudi PDPL and its Implementing Regulations / UAE Federal PDPL Article 9]

1. Institution Identification

Institution Name: [Full legal name] License Number: [Regulatory license reference] Address: [Registered address] Data Protection Officer: [Name, Title, Direct Phone, Email] Incident Single Point of Contact: [Name, Title, Direct Phone, Email available 24/7 during incident]

2. Notification Timing and Statutory Basis

This notification is provided under [cite specific PDPL Article and Implementing Regulation Article triggering the obligation]. Where information is incomplete, the Institution commits to providing updates as investigation progresses per Section 9 of this notification.

3. Nature of the Personal Data Breach

Description of the Breach (factual, three to five paragraphs): On [date], the Institution discovered [describe the discovery mechanism: monitoring alert, audit finding, customer report, third-party notification]. Initial investigation confirmed that [factual statement of what occurred, what was accessed, by whom if known, through what mechanism]. The breach involves [type of breach: confidentiality breach, integrity breach, availability breach, or combination] affecting personal data processed by the Institution's [system or service name]. Categories of Personal Data Affected:

• [Category 1, e.g., Identification data: full name, national ID number, date of birth]
• [Category 2, e.g., Contact data: phone number, email address, residential address]
• [Category 3, e.g., Financial data: account numbers, transaction history]
• [Category N as applicable]

Sensitive Personal Data Affected (if applicable per the PDPL definitions, UAE Article 1):

• [Category, e.g., Health data, biometric data, religious affiliation]

Approximate Number of Data Subjects Affected: [Number, broken down by jurisdiction if relevant] Approximate Number of Personal Data Records Affected: [Number]

4. Cause of the Breach

Root Cause (where determined; where not yet determined, state "Under investigation"): [Describe the root cause: technical vulnerability exploited, process gap, human error, vendor compromise, malicious external action, malicious internal action, accidental disclosure]. Contributing Factors (where identified):

• [Factor 1]
• [Factor 2]
• [Factor N]

AI System Involvement (where applicable): The breach [does / does not] involve an AI system. The AI system affected is [system name, model card reference]. The AI involvement is [training data exposure, inference log exposure, model artifact exposure, prediction output exposure].

5. Likely Consequences of the Breach

Risk to Data Subjects:

Aggregate Risk Assessment: [Statement of aggregate risk to data subjects] Mitigating Factors: [Factors reducing the risk, such as encryption status of affected data, limited scope of access, prompt containment]

6. Containment Status

Containment Actions Completed:

• [Date Time]: [Action, e.g., Affected system isolated from network]
• [Date Time]: [Action, e.g., Compromised credentials revoked]
• [Date Time]: [Action, e.g., Affected access pathway disabled]
• [Date Time]: [Action, e.g., Forensic evidence preservation initiated]

Current Containment Status: [Contained / Containment in progress / Active threat] Confirmation that Active Breach Has Stopped: [Confirmed at date/time / Not yet confirmed]

7. Remediation Plan

Immediate Remediation (completed or in progress):

• [Action, owner, status]

Short-Term Remediation (within 30 days):

• [Action, owner, target date]

Structural Remediation (within 90 days):

• [Action, owner, target date]

Independent Validation of Remediation: The Institution will engage [internal audit / external assessor] to validate the effectiveness of remediation and provide a validation report to the Authority within [90 days] of remediation completion.

8. Communication to Data Subjects

Decision on Data Subject Notification: [Notifying affected data subjects / Not notifying because risk is low / Notifying selected affected data subjects] Rationale for the Decision: [Three to five sentences explaining the decision, with reference to PDPL Article governing the decision] Notification Mechanism: [SMS / Email / Registered post / In-app notification / Telephone / Other] Notification Content Summary: [Brief description of what affected data subjects are being told] Notification Timeline: [When notifications began, when they will complete] Sample Data Subject Notification: [Attached as Annex A] Recourse Mechanism for Affected Data Subjects:

• Dedicated incident hotline: [Number, hours of availability]
• Dedicated incident email: [Email address]
• In-person recourse: [Branch availability if applicable]
• Credit monitoring or identity protection offered (where applicable): [Description]

9. Cooperation Commitment

The Institution commits to:

• Providing updates on this incident at intervals not exceeding [seven days] until incident closure
• Responding to Authority requests for additional information within [two business days] of request
• Making available the Data Protection Officer and Incident Single Point of Contact for Authority interaction throughout the incident
• Preserving all evidence relevant to this incident for the period the Authority directs
• Implementing remediation in coordination with Authority guidance

Dedicated Authority Liaison: [Named individual with full authority to coordinate with the Authority, with direct contact details]

10. Next Update

The next update on this incident will be provided no later than [Date Time]. Earlier updates will be provided if material developments occur.

11. Annexes

• Annex A: Sample Data Subject Notification
• Annex B: Affected Population Detail (by category and jurisdiction)
• Annex C: Containment and Remediation Timeline
• Annex D: Technical Forensic Summary (where appropriate to share at this stage)
• Annex E: Affected AI System Documentation (model card excerpt, where AI system involved)

12. Signature

This notification is submitted by the undersigned with the full authority of the Institution. Signature: ____________________ Name: [Full Name] Title: [Title, typically Data Protection Officer or Chief Compliance Officer] Date: [DD/MM/YYYY] Place: [City, Country] Acknowledgment Requested: We respectfully request acknowledgment of receipt of this notification with the Authority reference number assigned, to enable our incident documentation and subsequent updates.

End of Regulatory Notification Template. Usage Notes: Regulators receive better treatment from institutions that communicate within the deadline than from institutions that communicate complete information after the deadline. Notify within the deadline with what is known, with explicit commitment to update as investigation progresses. The discipline is to populate the notification template within the first 24 hours of incident discovery so the institution is positioned to notify within the statutory deadline (typically 72 hours under PDPL) even if investigation is incomplete. The template adapts to other regulatory frameworks (CBUAE sectoral notifications, SAMA notifications, AAOIFI Sharia incident notifications) by substituting jurisdictional citations and adjusting Section 2 statutory basis references. The core structure remains constant because the regulatory expectation across frameworks remains constant: notify promptly, factually, with named contact and committed update cadence.

Eight-section structure: Greeting (appropriate to relationship), Statement of Fact (customer-comprehensible language), Impact Statement (what this means for the customer), Institutional Action (what the institution is doing), Customer Action (specific, actionable), Recourse (how customer accesses recourse), Contact (how customer reaches the institution), Commitment (when customer will hear next). Language variants: Arabic, English, others per customer base. Discipline is plain language and specific action. Vague reassurance increases customer anxiety; specific guidance reduces it.

Structure

• Greeting (appropriate to relationship)
• Statement of Fact (customer-comprehensible language)
• Impact Statement (what this means for the customer)
• Institutional Action (what the institution is doing)
• Customer Action (specific, actionable)
• Recourse (how customer accesses recourse)
• Contact (how customer reaches the institution)
• Commitment (when customer will hear next)

Six-section structure: Acknowledgment (institution is aware), Statement of Action (specific actions taken), Statement of Customer Commitment, Statement of Regulatory Cooperation, Source of Authoritative Information, Spokesperson (named role authorized to comment). Discipline is to include at least three specific institutional actions in the statement so it is operational rather than rhetorical.

Structure

• Acknowledgment (institution is aware)
• Statement of Action (specific actions taken)
• Statement of Customer Commitment
• Statement of Regulatory Cooperation
• Source of Authoritative Information
• Spokesperson (named role authorized to comment)