Incident Response Plan
Project: Sable AI Ltd — AI Governance Framework Stage: Stage 4 — Monitoring & Controls Status: Draft Version: v1 Date: 2026-03-01 Assumptions: Built on outline assumptions — not verified against real Sable AI Ltd data
1. Purpose and Scope
This plan governs the detection, classification, response, notification, documentation, and remediation of incidents arising from Sable AI Ltd's Scout system — an AI-powered CV screening and candidate shortlisting tool [ASSUMPTION: A-002].
This plan applies to: - All personal data breaches involving candidate data processed by Scout - Discriminatory or biased shortlisting outputs - Model hallucination or accuracy failures affecting candidate assessments - Third-party service incidents (Anthropic API outage or data breach) affecting Scout operations [ASSUMPTION: A-005] - UK GDPR Arts. 22A–22C safeguard failures (automated decisions without mandatory human review) [ASSUMPTION: A-007]
Related documents:
- L1-2.5-Roles-and-Responsibilities-v1.md — RACI and accountability structure
- L3-4.1-Monitoring-Framework-v1.md — detection metrics and alert thresholds
- L3-4.2-Bias-Monitoring-Protocol-v1.md — bias monitoring and bias incident escalation
- L2-3.4-DPIA-Template-v1.md — residual risk assessment for Scout processing
- L4-5.1-Data-Processing-Agreement-Template-v1.md — contractual notification obligations by customer type
- L4-5.2-Candidate-Transparency-Notice-v1.md — candidate communication templates
[LEGAL REVIEW REQUIRED]: Sable AI Ltd's notification obligations under UK GDPR Arts. 33 and 34 differ depending on whether it acts as a joint controller or processor in each customer relationship (see Section 6). This plan requires legal review before operational use.
2. Incident Definition
An incident is any event that has affected, or has the potential to affect, the confidentiality, integrity, or availability of personal data processed by Scout; or that has resulted in, or may result in, discriminatory outcomes, accuracy failures, or harm to candidates' rights, freedoms, or legitimate interests.
UK GDPR Art. 4(12) defines a personal data breach as:
"a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed"
ICO guidance confirms this extends to any security incident affecting the "confidentiality, integrity or availability of personal data" — including, expressly, events causing discrimination, damage to reputation, or "any other significant economic or social disadvantage to the natural person concerned" (ICO, Personal Data Breaches).
For Scout specifically, discrimination risk is treated as a first-class incident category, not a secondary concern to a data breach. Both must be managed and documented.
Near-misses — events that could have caused an incident but did not — must also be logged (Section 10). ICO guidance states: "you should ensure that you record all breaches, regardless of whether or not they need to be reported to the ICO." Near-misses do not require ICO notification but must be documented to satisfy the UK GDPR Art. 5(2) accountability principle.
3. Incident Types
| Type | Name | Description | Primary Regulatory Hook |
|---|---|---|---|
| A | Personal Data Breach | Unauthorised access to, disclosure of, alteration of, or loss of candidate personal data (CVs, assessments, shortlisting scores, contact details) — whether caused by Sable AI Ltd or by Anthropic as sub-processor [ASSUMPTION: A-005] | UK GDPR Arts. 32–34; ICO breach guidance |
| B | Discriminatory Shortlisting Output | Scout produces shortlisting results that systematically disadvantage candidates on the basis of a protected characteristic under the Equality Act 2010 (race/ethnicity, disability, age, sex, pregnancy/maternity, or others) | Equality Act 2010; UK GDPR Art. 5(1)(a) lawfulness/fairness; ICO AI in Recruitment Outcomes Report (Nov 2024) |
| C | Model Hallucination / Accuracy Failure | Scout produces materially false candidate assessments — e.g., attributes qualifications, skills, or characteristics not present in the source CV; or produces outputs with significant accuracy degradation from baseline | UK GDPR Art. 5(1)(d) accuracy principle; ICO AI in Recruitment findings |
| D | Arts. 22A–22C Safeguard Failure | A candidate is progressed or rejected on the basis of Scout's output without mandatory human review [ASSUMPTION: A-007], in potential breach of UK GDPR Arts. 22A–22C safeguards | UK GDPR Arts. 22A–22C; ICO AI in Recruitment: "Prevent using AI outputs to make automated recruitment decisions" |
| E | Third-Party Service Incident | Anthropic API outage, data breach at Anthropic, or suspension of service affecting Scout's availability or the security of candidate data processed by Anthropic [ASSUMPTION: A-005] | UK GDPR Art. 33(2) (processor-to-controller notification); DPA sub-processor obligations |
4. Severity Levels
P1 — Critical
Definition: Incident has caused, or is likely to cause, significant harm to a material number of candidates; involves a large-scale personal data breach; constitutes a confirmed pattern of discriminatory shortlisting; or triggers an immediate UK GDPR Art. 33 ICO notification obligation.
P1 criteria — any one sufficient: - Personal data breach affecting 50 or more candidate records [ASSUMPTION: A-008 — threshold not confirmed against DPIA risk assessment; verify before operational use] - Confirmed discriminatory shortlisting affecting a protected characteristic group across multiple roles or customers - Complete Anthropic service outage persisting more than four hours, preventing Scout from operating [ASSUMPTION: A-005] - ICO investigation, enforcement action, or formal request for information received - Evidence of systematic Arts. 22A–22C safeguard failure (not an isolated single instance) [ASSUMPTION: A-007] - Candidate personal data exposure in a public-facing or widely accessible context
Detection-to-escalation timeline: | Step | Action | Deadline | |---|---|---| | 1 | Detecting party notifies CTO/AI Lead [ASSUMPTION: A-001] | Within 1 hour of detection | | 2 | CTO/AI Lead notifies Founder/CEO | Within 2 hours of detection | | 3 | Founder/CEO + CTO assess ICO notification obligation | Within 4 hours of detection | | 4 | If ICO notification required: submit initial notification | Within 72 hours of becoming aware (UK GDPR Art. 33(1)) | | 5 | If Anthropic-side breach: notify customer-controller after receiving Anthropic's notification | Without undue delay (UK GDPR Art. 33(2)) | | 6 | Notify affected customer(s) | Within 24 hours of confirmed incident |
External notification requirements:
ICO (UK GDPR Art. 33): Where the breach is likely to result in a risk to the rights and freedoms of natural persons, Sable AI Ltd must notify the ICO without undue delay and no later than 72 hours after becoming aware (Art. 33(1)). Notification must contain at minimum (Art. 33(3)): - (a) Nature of the breach; categories and approximate number of data subjects and records - (b) DPO/contact point name and contact details - (c) Likely consequences of the breach - (d) Measures taken or proposed, including mitigation
Where full investigation is incomplete within 72 hours, phased reporting is permitted (UK GDPR Art. 33(4); ICO guidance: "provide whatever relevant information you have" and update "without undue delay"). Use template at Section 7.
Candidate notification (UK GDPR Art. 34): Where the breach is likely to result in a high risk to the rights and freedoms of candidates, notification to affected individuals is required "without undue delay" (Art. 34(1)). Notification must be in plain language and include the Art. 33(3)(b)(c)(d) information (Art. 34(2)). Where individual notification involves disproportionate effort (large-scale breach), a public communication is required instead (Art. 34(3)(c)). Exemptions: (i) encryption renders data unintelligible to unauthorised persons (Art. 34(3)(a)); (ii) subsequent measures neutralise the high risk (Art. 34(3)(b)).
EHRC: See Section 8. Seek legal advice before taking any action. Do not assume proactive EHRC notification is required.
Required actions: 1. Contain: disable the affected feature, revoke access, or isolate the affected data 2. Preserve evidence: logs, API call records, model outputs, reviewer actions 3. Open a P1 incident ticket and record the exact time of detection 4. Notify legal counsel [ASSUMPTION: A-001 — legal counsel arrangement not confirmed] 5. Assess ICO notification within 4 hours; document the decision and reasoning 6. Prepare ICO notification (Section 7) 7. Notify affected customers; co-ordinate candidate communication through customer 8. Assess candidate notification requirement; document the decision 9. Begin root cause analysis within 24 hours (template: Section 9) 10. Document all actions and decisions with timestamps (UK GDPR Art. 33(5))
P2 — High
Definition: Incident has caused, or may cause, harm to a limited number of candidates; involves a personal data breach affecting a small number of records; constitutes a single confirmed discriminatory output; or involves a Scout accuracy failure affecting specific shortlisting decisions.
P2 criteria — any one sufficient:
- Personal data breach affecting 1–49 candidate records [ASSUMPTION: A-008 — threshold not confirmed]
- Single confirmed discriminatory shortlisting output for a candidate with a protected characteristic
- Model hallucination or materially false assessment identified for one or more specific candidates (Type C incident)
- Arts. 22A–22C safeguard failure for an individual candidate (single instance) [ASSUMPTION: A-007]
- Scout accuracy degradation above the threshold defined in L3-4.1-Monitoring-Framework-v1.md
- Partial Anthropic API outage causing intermittent Scout failures [ASSUMPTION: A-005]
Detection-to-escalation timeline: | Step | Action | Deadline | |---|---|---| | 1 | Detecting party notifies Engineering Lead | Within 2 hours of detection | | 2 | Engineering Lead and CTO confirm P2 classification | Within 4 hours of detection | | 3 | If personal data breach confirmed: notify Founder/CEO | Within 4 hours of detection | | 4 | Notify affected customer(s) if their data is affected | Within 48 hours |
External notification requirements:
ICO: Assess whether the breach is "unlikely to result in a risk to the rights and freedoms of natural persons" — if so, ICO notification is not required, but the decision and reasoning must be documented (ICO guidance). If risk is assessed as likely: 72-hour notification applies as for P1. Where a single candidate's data is affected and appropriate mitigations are in place (e.g., pseudonymisation or encryption), risk may be assessed as low — but this assessment must be recorded.
Candidate notification: Assess whether the high-risk threshold under Art. 34(1) is met. For a small-scale breach where data is encrypted or pseudonymised, notification may not be required (Art. 34(3)(a)). Document the decision in the incident register.
EHRC: See Section 8. Seek legal advice if a confirmed discriminatory output suggests a systemic or recurring issue.
Required actions:
1. Investigate and contain the issue; suspend the affected output if needed
2. Determine the scope: how many candidates are affected?
3. Assess ICO notification requirement; document the decision with reasoning
4. For discriminatory outputs (Type B): withdraw the affected shortlist; notify the customer; flag the affected candidate(s) for fair reconsideration
5. For accuracy failures (Type C): correct the record where possible; notify the affected candidate(s) via the customer
6. Begin RCA within 48 hours (template: Section 9)
7. Cross-reference L3-4.2-Bias-Monitoring-Protocol-v1.md for activated bias incident thresholds
P3 — Medium
Definition: Potential issue requiring investigation; no confirmed harm to any candidate; near-miss event; individual candidate complaint about a Scout output; minor data quality or availability issue.
P3 criteria — any one sufficient: - Suspected but unconfirmed bias signal from monitoring (below alert threshold; requires investigation) - Individual candidate complaint or challenge to a Scout shortlisting outcome - Minor API error rate above baseline (within operational recovery tolerance) - Single data quality issue identified in Scout outputs - Near-miss: an event that would have caused a P1 or P2 incident if not caught
Detection-to-escalation timeline: | Step | Action | Deadline | |---|---|---| | 1 | Detecting party logs the event in the incident register | Within 24 hours | | 2 | Engineering Lead investigates | Within 72 hours | | 3 | If investigation reveals P2 or P1 criteria are met: re-classify immediately | On identification |
External notification requirements: No immediate ICO or external notification required. Document the event and investigation outcome. If re-classified to P2 or P1: notification obligations apply from the point of re-classification.
Required actions:
1. Log the event in the incident register (Section 10)
2. Investigate within 72 hours
3. If candidate complaint: acknowledge receipt within five business days [ASSUMPTION: A-009 — acknowledgement SLA not confirmed]; investigate and respond
4. If bias signal: initiate bias investigation per L3-4.2-Bias-Monitoring-Protocol-v1.md
5. Document findings; escalate or close
5. Severity Summary Table
| Severity | Recruitment AI Examples | Detection-to-Escalation | ICO Notification | Candidate Notification |
|---|---|---|---|---|
| P1 — Critical | Large-scale CV data breach; confirmed discriminatory shortlisting pattern across roles; systematic Arts. 22A–22C safeguard failure; complete Scout outage >4 hrs | 1 hr to CTO; 2 hrs to CEO | Required within 72 hrs where risk to rights and freedoms (Art. 33(1)) | Required without undue delay where high risk to individuals (Art. 34(1)) |
| P2 — High | Small-scale breach (1–49 records); single confirmed discriminatory output; model hallucination affecting individual candidate(s); isolated Arts. 22A–22C safeguard failure | 2 hrs to Engineering Lead; 4 hrs to CTO | Assess and document decision; notify if risk likely | Assess high-risk threshold; document decision |
| P3 — Medium | Suspected bias signal (unconfirmed); candidate complaint; near-miss; minor data quality issue; minor API errors | 24 hrs to Engineering Lead | Not required — log and document | Not required — address through complaints process |
6. Controller vs. Processor — Notification Paths
Sable AI Ltd's notification obligations under UK GDPR Arts. 33–34 depend on its role in each customer relationship. [LEGAL REVIEW REQUIRED] Refer to L4-5.1-Data-Processing-Agreement-Template-v1.md for contractual notification obligations by customer type.
6.1 — Agency Customer (Potential Joint Controller Arrangement)
Where a recruitment agency uses Scout to screen candidates on behalf of employer clients, Sable AI Ltd may be a joint controller rather than a processor [ASSUMPTION: A-003]. Joint controller arrangements are governed by UK GDPR Art. 26.
Under this arrangement: - Both Sable AI Ltd and the agency customer may have independent ICO notification obligations - Sable AI Ltd's Art. 33 clock runs from when Sable AI Ltd becomes aware of the breach - The DPA with agency customers must specify which party leads ICO notification and candidate communication - Both parties must be notified and co-ordinate on the response
6.2 — In-House HR Customer (Controller-Processor Arrangement)
Where a corporate HR team uses Scout as a tool, the customer is the sole controller and Sable AI Ltd is the processor.
Under UK GDPR Art. 33(2), Sable AI Ltd must notify the customer-controller without undue delay after becoming aware of a personal data breach — regardless of whether the 72-hour ICO notification threshold is met. The customer-controller then assesses whether to notify the ICO. Sable AI Ltd must provide sufficient information for the controller to comply with its Art. 33 obligation.
6.3 — Anthropic Sub-Processor Path
Anthropic is a sub-processor of Sable AI Ltd [ASSUMPTION: A-005]. In the event of an incident affecting candidate data processed by Anthropic: - Anthropic must notify Sable AI Ltd without undue delay under the terms of the Data Processing Agreement [ASSUMPTION: A-005 — a valid DPA with Anthropic is in place] - Sable AI Ltd's 72-hour Art. 33 clock starts from receipt of Anthropic's notification (or from any other point at which Sable AI Ltd becomes aware) - Sable AI Ltd must then notify the relevant customer-controller (or co-ordinate with a joint controller) and assess ICO notification
7. ICO Notification Template
Use for all P1 incidents and applicable P2 incidents where the risk-to-rights threshold is met. Submit via the ICO self-service reporting portal.
INCIDENT REFERENCE: [Internal ticket number]
DATE/TIME INCIDENT DETECTED: [DD/MM/YYYY HH:MM]
DATE/TIME INCIDENT OCCURRED: [DD/MM/YYYY HH:MM — if known; otherwise state unknown]
DATE/TIME ICO NOTIFIED: [DD/MM/YYYY HH:MM]
PHASED REPORT: [ ] Initial notification — further details to follow
[ ] Full notification
── ORGANISATION ────────────────────────────────────────
Name: Sable AI Ltd
ICO registration no.: [ASSUMPTION: A-001 — not verified; confirm before use]
DPO / Contact point: [Name, email, direct telephone]
── NATURE OF BREACH (Art. 33(3)(a)) ────────────────────
Breach type(s): [ ] Confidentiality [ ] Integrity [ ] Availability
Description:
Categories of personal data involved:
Approx. no. of data subjects affected:
Approx. no. of personal data records affected:
── LIKELY CONSEQUENCES (Art. 33(3)(c)) ─────────────────
[Describe the likely consequences for affected candidates and any discrimination,
financial, or reputational harm.]
── MEASURES TAKEN OR PROPOSED (Art. 33(3)(d)) ──────────
Containment measures taken:
Mitigation measures taken or proposed:
Remediation actions planned:
── PHASED REPORTING NOTE ────────────────────────────────
If initial notification: reason full information not yet available:
Expected date of follow-up notification:
── ADDITIONAL NOTES ─────────────────────────────────────
[Any other information relevant to the ICO's assessment]
Note on phased reporting: UK GDPR Art. 33(4) permits phased notification where full investigation is ongoing. ICO guidance confirms: "provide whatever relevant information you have" and update "without undue further delay." Always notify within 72 hours even with incomplete information, then follow up.
8. Discrimination Incidents and the EHRC
[LEGAL REVIEW REQUIRED]
The Equality and Human Rights Commission (EHRC) is the statutory body responsible for enforcing equality legislation in Great Britain, including the Equality Act 2010.
Important caveat on notification obligation: The source materials reviewed for this framework — UK GDPR, ICO Personal Data Breaches guidance, ICO AI in Recruitment Outcomes Report (November 2024), and DSIT Responsible AI in Recruitment guidance — do not establish an express statutory obligation to proactively notify the EHRC upon confirming a discrimination incident. This position must be verified against the Equality Act 2010 enforcement provisions and any EHRC guidance on reporting obligations before this plan is used operationally. Do not treat EHRC notification as a confirmed mandatory requirement without independent legal advice.
What is established: - The EHRC has statutory enforcement powers under the Equality Act 2006, including formal investigations, unlawful act notices, and applications for court injunctions - Where a confirmed discriminatory shortlisting pattern affects a protected group, the EHRC may investigate or take action following a complaint from an affected candidate or an enforcement referral - Voluntary proactive engagement with the EHRC may be advisable in serious P1 discrimination incidents as a demonstration of accountability and good faith
Recommended approach for P1 Type B incidents:
1. Seek legal advice on EHRC notification or voluntary engagement before taking any step
2. Do not make representations to the EHRC without legal counsel
3. Document the incident and remediation actions taken as evidence of good faith compliance
4. Cross-reference L3-4.2-Bias-Monitoring-Protocol-v1.md for the remediation process following a confirmed discriminatory output
9. Root Cause Analysis Template
Complete for all P1 incidents within seven days of containment. Complete for all P2 incidents within fourteen days.
INCIDENT REFERENCE: [Internal ticket number]
INCIDENT TYPE: [ ] A — Data Breach [ ] B — Discriminatory Output
[ ] C — Accuracy Failure [ ] D — Arts. 22A–22C Safeguard Failure
[ ] E — Third-Party Incident
SEVERITY: [ ] P1 [ ] P2 [ ] P3
DATE INCIDENT OCCURRED: [DD/MM/YYYY]
DATE RCA COMPLETED: [DD/MM/YYYY]
RCA LEAD: [Name and role]
── 1. INCIDENT DESCRIPTION ──────────────────────────────
What happened?
When was it detected?
How was it detected?
[ ] Monitoring alert (source: __________________)
[ ] Human reviewer flag
[ ] Candidate complaint
[ ] Customer report
[ ] Anthropic notification [ASSUMPTION: A-005]
[ ] Other
Who was affected (categories and approximate number of candidates)?
── 2. TIMELINE ──────────────────────────────────────────
[DD/MM/YYYY HH:MM] — [Event]
[DD/MM/YYYY HH:MM] — [Event]
[DD/MM/YYYY HH:MM] — ICO notified (if applicable)
[DD/MM/YYYY HH:MM] — Candidate(s) notified (if applicable)
── 3. ROOT CAUSE ANALYSIS ───────────────────────────────
Immediate cause:
Root cause:
Contributing factors:
System / technical:
Process / operational:
Human:
Third-party / vendor [ASSUMPTION: A-005]:
── 4. IMPACT ASSESSMENT ─────────────────────────────────
Personal data affected:
Candidate harm — actual:
Candidate harm — potential:
Discriminatory outcome — actual or potential:
ICO notification triggered?
[ ] Yes — notified on [date] [ ] No — documented reason: ___________
Candidate notification triggered?
[ ] Yes — notified on [date] [ ] No — documented reason: ___________
── 5. ACTIONS TAKEN ─────────────────────────────────────
Containment:
Remediation:
Candidate redress provided (if applicable):
System or process changes made:
── 6. CORRECTIVE ACTIONS ────────────────────────────────
| Action | Owner | Target date | Status |
|---------------------------|-------|-------------|--------|
| | | | |
── 7. LESSONS LEARNED ───────────────────────────────────
What detection or response worked well?
What failed or was slower than required?
What change would prevent recurrence?
── 8. SIGN-OFF ──────────────────────────────────────────
Completed by: [Name, role]
Reviewed by: [CTO / Founder]
Date: [DD/MM/YYYY]
10. Incident and Near-Miss Register
All incidents and near-misses must be logged and retained. UK GDPR Art. 33(5) requires documentation of "the facts relating to the personal data breach, its effects and the remedial action taken." ICO guidance confirms this requirement extends to all breaches regardless of whether ICO notification is required.
ICO documentation guidance further states: "it is useful to mark any breaches against your record of processing activities, while also linking to the full breach documentation. This can help you monitor which processing activities the breaches relate to and identify any patterns or potential areas of concern."
Minimum register fields:
| Field | Content |
|---|---|
| Incident ID | Sequential reference — [YEAR]-[NNN] |
| Date detected | DD/MM/YYYY |
| Date of incident | DD/MM/YYYY (if different from detection) |
| Incident type | A / B / C / D / E (see Section 3) |
| Severity | P1 / P2 / P3 / Near-miss |
| Description | Brief description of what occurred |
| Data subjects affected | Approximate number |
| ICO notification | Yes — date / No — reason documented |
| Candidate notification | Yes — date / No — reason documented |
| RCA completed | Yes — reference / No — reason |
| Status | Open / Under investigation / Closed |
| Closed date | DD/MM/YYYY |
The incident register must be retained for a minimum period sufficient to demonstrate accountability under UK GDPR Art. 5(2) [ASSUMPTION: A-010 — minimum three years is recommended practice; verify with legal adviser before confirming retention period].
11. Candidate Redress
Where a candidate has been adversely affected by a Scout incident (Type B discriminatory output, Type C accuracy failure, Type D Arts. 22A–22C safeguard failure), appropriate redress must be provided.
DSIT Responsible AI in Recruitment guidance is explicit: "Where harms are identified through routes to contestability, appropriate redress should be made."
Redress options (select as appropriate for the incident): - Withdrawal of the affected shortlisting decision and rescreening by a human reviewer independent of the original Scout output - Exercise of the candidate's data subject rights: access to their data (UK GDPR Art. 15); rectification of inaccurate data (Art. 16); right to object to processing (Art. 21) - Direct communication to the candidate (delivered through the customer-controller) acknowledging that an issue occurred and explaining the corrective action taken - Referral to the recruiting organisation to ensure the candidate is fairly reconsidered for the role
[LEGAL REVIEW REQUIRED]: The appropriate form of redress and which party (Sable AI Ltd or the customer-controller) is responsible for delivering it to the candidate must be determined in the context of the applicable DPA arrangement. Refer to L4-5.1-Data-Processing-Agreement-Template-v1.md.
12. RACI Reference
For the full RACI matrix governing incident response ownership, see L1-2.5-Roles-and-Responsibilities-v1.md.
Summary of key roles for incident response [ASSUMPTION: A-001]:
| Role | Primary responsibility |
|---|---|
| Founder/CEO | P1 escalation authority; ICO notification decision; legal counsel engagement |
| CTO (likely DPO [ASSUMPTION: A-001]) | P1 and P2 triage lead; technical containment; Art. 33 assessment; ICO notification preparation |
| Engineering Lead | P2 and P3 investigation; monitoring alert response; technical RCA |
| Customer Success Lead | Customer communication; candidate redress co-ordination |
13. Plan Review and Testing
This plan must be reviewed: - Annually as a minimum — ICO accountability guidance confirms that obligations are "ongoing" and that controls must be reviewed at "appropriate intervals" - After any P1 incident — revise within 30 days of RCA completion and sign-off - After significant changes to Scout's architecture, data types processed, or customer base — per ICO documentation guidance that records must "reflect the current situation"
This plan must be tested against a simulated incident scenario at least annually. ICO guidance states: "you need to be able to detect, investigate, report (both internally and externally) and document any breaches. Having robust policies, procedures and reporting structures helps you do this." Test outcomes must be documented and used to improve the plan.
[LEGAL REVIEW REQUIRED throughout. This plan is a draft framework document built on unverified assumptions about Sable AI Ltd — not a legal compliance certification. All thresholds, timelines, escalation paths, and notification obligations must be verified against Sable AI Ltd's actual regulatory position, DPA arrangements, and legal advice before operational use.]