Bias Monitoring Protocol
Project: Sable AI Ltd — AI Governance Framework Stage: Stage 4 — Monitoring & Operational 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 protocol defines the methods Sable AI Ltd uses to detect, measure, and respond to algorithmic bias in Scout's CV screening and candidate shortlisting outputs. It is the most novel document in this framework: unlike breach response or GDPR compliance mapping, bias monitoring for AI recruitment tools is an emerging practice with limited established precedent, and the legal framework governing how demographic data may be collected for monitoring purposes is unsettled.
This document must be read alongside L3-4.1-Monitoring-Framework-v1.md, which defines the monitoring metrics (M-13–M-15) that this protocol operationalises, and L2-3.2-Equality-Act-2010-Compliance-Map-v1.md, which sets out the underlying Equality Act 2010 discrimination risk.
[LEGAL REVIEW REQUIRED] — The entire approach to demographic data collection and use for bias monitoring described in this protocol requires review by a qualified data protection and employment lawyer before implementation. The legal constraints identified in Section 3 are significant, and the operational choices in Sections 4–8 must be validated against the actual Sable AI Ltd product architecture, customer contracts, and current applicable law.
Scope: This protocol covers all bias monitoring activity related to Scout's shortlisting outputs. It applies to Sable AI Ltd's internal monitoring obligations and to the monitoring expectations Sable AI Ltd should impose on its customers through contractual requirements.
2. Why Bias Monitoring Matters
2.1 Regulatory obligation
The ICO has confirmed through live audit findings that AI providers processing candidate CVs are expected to proactively monitor for bias. The ICO's AI in Recruitment Outcomes Report (November 2024) states that AI providers assessed during the ICO's audit "had considered the potential for bias in their AI tools, usually by measuring potential bias using an adverse impact analysis methodology." This is not aspirational guidance — it reflects what the ICO found and expects during actual enforcement reviews.
UK GDPR Articles 5(1)(a)–(e) (lawfulness, fairness, accuracy, data minimisation, storage limitation) and Article 25 (data protection by design and default) together require that Scout's processing does not produce systematically unfair outcomes for protected groups throughout the processing lifecycle. A failure to monitor for bias is itself a failure of the accountability principle (UK GDPR Art. 5(2)).
2.2 Equality Act 2010 risk
Scout's shortlisting outputs may cause or amplify indirect discrimination against candidates with protected characteristics, including race or ethnic origin, sex, disability, age, and pregnancy or maternity. Where a candidate can demonstrate that Scout's operation put them at a particular disadvantage compared to candidates without that characteristic — and where Sable AI Ltd or its customer cannot objectively justify the practice — this constitutes indirect discrimination under Equality Act 2010 s.19. Regular bias monitoring is the primary operational control for detecting and preventing this outcome before it causes harm and before it becomes visible to the ICO or EHRC.
See L2-3.2-Equality-Act-2010-Compliance-Map-v1.md for the full protected characteristic risk analysis.
2.3 What the ICO audit found
The ICO's November 2024 audit of AI recruitment providers found:
- The majority monitored for bias using adverse impact analysis, commonly applying the four-fifths (80%) rule as a minimum threshold
- Several providers used inferred or estimated demographic data — predicting gender or ethnicity from candidate names or CV content — to measure bias; the ICO found this approach to be both methodologically unreliable and in most cases unlawful under UK GDPR Art. 9
- Providers who identified bias took remediation actions including reducing the weightings of identified data points, excluding proxy features, and re-testing after changes
- Some providers used rollback as a remediation mechanism when bias was introduced by a system update
- AI providers were expected to retain test results and evidence of actions taken, and to report KPIs to senior management regularly
This protocol is designed to position Scout at or above the standard observed in the ICO's audit.
3. The Legal Constraint: Demographic Data for Bias Monitoring
This section addresses the most legally complex aspect of bias monitoring for recruitment AI directly, rather than deferring it to a legal review note.
3.1 Why demographic data is required
Bias monitoring that does not use demographic data — for example, monitoring only aggregate shortlisting rates without segmenting by protected characteristic — cannot reliably detect discriminatory impact. The four-fifths rule requires comparing shortlisting rates between demographic groups. Detecting whether a screening criterion acts as a proxy for a protected characteristic requires knowing which candidates belong to which group. Without demographic data, bias monitoring produces incomplete results.
3.2 Why demographic data is legally constrained
Data about race or ethnic origin, disability, health, and sex (and inferences drawn to estimate these characteristics) constitutes special category personal data under UK GDPR Article 9. Processing such data requires:
- A lawful basis under UK GDPR Art. 6(1)
- An additional condition under UK GDPR Art. 9(2)
- In many cases, an appropriate policy document under DPA 2018 Schedule 1 Part 4
The ICO has stated explicitly that inferred or estimated demographic data — for example, ethnicity or gender inferred from a candidate's name or CV content — is still special category data and must be treated as such. The ICO AI in Recruitment Outcomes Report (November 2024) found that providers using inferred data "did not always treat inferred information as special category data or identify an additional condition for processing" and that "processing special category data without a lawful basis and additional condition is unlikely to be lawful under the UK GDPR."
The ICO further found that inferred demographic data is methodologically unreliable: AI providers using it "were generally unable to demonstrate that it was reliable and accurate enough to mitigate bias effectively in their AI tools."
Conclusion: Sable AI Ltd must not use inferred or estimated demographic data for bias monitoring purposes. [LEGAL REVIEW REQUIRED]
3.3 The purpose limitation problem
The ICO's November 2024 report notes that some providers considered repurposing demographic data collected from successful candidates for equality monitoring of new hires — reusing this data to assess bias in the AI's selection outcomes. The ICO states that "repurposing information in this way is unlikely to comply with the UK GDPR purpose limitation principle and you will need an appropriate lawful basis for this purpose." [LEGAL REVIEW REQUIRED]
3.4 Permitted approaches to demographic data
The following approaches are considered in order of legal robustness:
| Approach | Legal basis route | Key conditions | Assessment |
|---|---|---|---|
| Option A — Voluntary equality monitoring by candidates | Art. 6(1)(a) + Art. 9(2)(a) explicit consent | Must be genuinely voluntary; no detriment if not provided; purpose clearly explained; separate from any other consent or application process | Legally permissible if conditions strictly met — preferred approach where operationally feasible [LEGAL REVIEW REQUIRED] |
| Option B — Aggregate statistical testing without individual demographic data | No personal data processing involved | Use statistical methods comparing overall shortlisting patterns over time — cannot test individual-level protected characteristic impact but can detect systemic anomalies | Methodologically limited but avoids Art. 9 risk — appropriate as floor-level monitoring where Option A is unavailable |
| Option C — Inferred demographic data (e.g., name-origin classification) | Art. 9 condition required; data accuracy obligations apply | ICO has stated this is unreliable and in most cases unlawful without Art. 9 condition — not a viable shortcut | Not recommended [LEGAL REVIEW REQUIRED] |
| Option D — Repurposed equality monitoring data | New Art. 6 basis required; purpose limitation constraint | Very high legal risk without specific legal advice; purpose limitation issue is ICO-identified | Not recommended without specific legal sign-off [LEGAL REVIEW REQUIRED] |
Recommended approach for Sable AI Ltd [ASSUMPTION A-022]: Implement Option A (voluntary equality monitoring) for customers who can operationalise it within their candidate-facing processes, supplemented by Option B (aggregate statistical testing) as a baseline monitoring approach where voluntary data is unavailable or insufficient in volume. Options C and D are not to be implemented without explicit legal advice confirming a compliant lawful basis and condition. [LEGAL REVIEW REQUIRED]
4. Demographic Parity Testing Methodology
Regulatory basis: ICO AI in Recruitment Outcomes Report (November 2024) — the majority of audited AI providers used adverse impact analysis; UK GDPR Art. 5(1)(a) (fairness); Equality Act 2010 s.19 (indirect discrimination); DSIT Responsible AI in Recruitment Guide (March 2024) — bias audit methodology.
4.1 Concept
Demographic parity testing assesses whether Scout's shortlisting rate is consistent across demographic groups — i.e., that the probability of being shortlisted does not differ significantly by protected characteristic. A material disparity in shortlisting rates between groups is a bias signal requiring investigation, not an automatic finding of discrimination.
Demographic parity is a necessary but not sufficient condition for fairness. Scout could achieve demographic parity while being inaccurate for all groups equally, or could be biased in ways not captured by aggregate shortlisting rates. It is used here as a minimum monitoring baseline, not as a complete fairness standard.
4.2 Procedure
-
Data pre-condition: Confirm that candidate demographic data has been collected under a legally compliant mechanism — Option A (voluntary equality monitoring) with appropriate Art. 6 + Art. 9 documentation in place. Do not proceed with individual-level demographic analysis without this confirmation. [LEGAL REVIEW REQUIRED]
-
Group definition: Monitor for the following protected characteristic groups, consistent with ICO AI in Recruitment Outcomes Report (November 2024) and DSIT guidance:
- Sex (male / female / non-binary where data is provided by the candidate)
- Racial or ethnic origin (using categories provided by the candidate in voluntary monitoring — do not impose external classification schemes)
- Disability status (whether the candidate has declared a disability)
- Age group (recommended: 10-year bands — under 30, 30–39, 40–49, 50–59, 60+ [ASSUMPTION])
-
Other characteristics listed in Equality Act 2010 s.4 as data collection permits
-
Shortlisting rate calculation: For each monitored group G across a defined time period:
-
Shortlisting rate(G) = candidates from group G shortlisted ÷ total candidates from group G submitted to Scout in the period
-
Adverse impact ratio calculation: See Section 5 below.
-
Minimum sample size: Statistical testing requires sufficient sample sizes to be meaningful. Demographic parity analysis should not be conducted on fewer than 50 candidates per group per reporting period. Where sample sizes are insufficient, record this limitation, apply Option B aggregate methods only, and note the constraint in the monthly monitoring report. [ASSUMPTION]
-
Documentation: All test parameters, sample sizes, group-level shortlisting rates, and adverse impact ratios must be recorded and retained per Section 12 of this protocol.
5. Adverse Impact Ratio Calculation
Regulatory basis: ICO AI in Recruitment Outcomes Report (November 2024) — "In many cases they used the 'four fifths rule' as a minimum threshold. This means the selection rate for any group must be at least four fifths or 80% of the selection rate of the group with the highest rate."
5.1 The four-fifths rule
The four-fifths (or 80%) rule is the standard adverse impact threshold referenced by the ICO in its 2024 recruitment AI audit. It defines an adverse impact signal as:
Adverse Impact Ratio (AIR) = Shortlisting rate of group G ÷ Shortlisting rate of the highest-performing group
Where AIR < 0.80 for any group G, this constitutes a potential adverse impact finding requiring investigation and response per Section 9.
Worked example:
| Group | Candidates submitted | Shortlisted | Shortlisting rate | AIR | Status |
|---|---|---|---|---|---|
| Group A | 100 | 60 | 60% | 1.00 (reference) | — |
| Group B | 80 | 34 | 42.5% | 0.71 | RED — below threshold |
| Group C | 60 | 30 | 50% | 0.83 | GREEN — within tolerance |
| Group D | 45 | 36 | 80% | — | Sample size may be too small to be meaningful — note limitation |
In this example, Group B's shortlisting rate triggers an investigation. Group A is the reference group (highest rate). Group C is within tolerance. Group D's result should be noted with a sample size caveat.
5.2 Limitations of the four-fifths rule
The four-fifths rule is a minimum threshold indicator, not a definitive finding of unlawful discrimination. An AIR below 0.80 does not automatically mean Scout is operating unlawfully — it requires investigation to determine whether there is a non-discriminatory explanation (e.g., legitimate differences in qualifications, self-selection patterns, role-specific requirements). Similarly, an AIR above 0.80 does not guarantee the absence of discrimination at individual level or in relation to characteristics where monitoring data is unavailable.
The ICO expects AI providers to investigate the cause of adverse impact findings and to act on them — not simply to record the threshold breach and move on.
5.3 Alert thresholds
| AIR value | Alert level | Required action |
|---|---|---|
| < 0.80 for any monitored group | RED | Immediate escalation to CTO; bias investigation per Section 9; remediation within 30 days [ASSUMPTION] |
| 0.80–0.85 for any monitored group | AMBER | Increase monitoring frequency; document reason; review within 30 days |
| ≥ 0.85 for all monitored groups | GREEN | Continue scheduled monitoring; note in monthly report |
6. Keyword and Language Bias Flags
Regulatory basis: DSIT Responsible AI in Recruitment Guide (March 2024) — bias monitoring should address proxy features for demographic characteristics; ICO AI in Recruitment Outcomes Report (November 2024) — proxy feature monitoring and remediation; Equality Act 2010 s.19 (indirect discrimination through neutral criteria with differential impact).
6.1 Proxy feature risk
Scout processes raw CV text, which may contain terms or features that act as statistical proxies for protected characteristics. If Scout's underlying model weights any of these features in a way that correlates with protected characteristic group membership, it may produce discriminatory shortlisting outcomes without explicitly processing any demographic data. Examples of proxy features relevant to recruitment AI:
| Proxy feature | Protected characteristic at risk |
|---|---|
| Employment gaps (>12 months) | Pregnancy/maternity; disability; caring responsibilities |
| Name-based patterns (name origin, cultural naming conventions) | Race or ethnic origin |
| Educational institution prestige or type | Socioeconomic background; indirect ethnicity/geography proxy |
| Sports or activities with demographic correlations | Age; sex |
| Language style, vocabulary register | Socioeconomic background; first-language status |
| Degree subject or field | Sex (historically gendered subject distributions) |
The ICO audit (November 2024) specifically noted that inferred demographic proxies in CV text can cause discriminatory impacts even when no protected characteristic data is explicitly processed [ASSUMPTION A-017].
6.2 Keyword monitoring procedure
-
Proxy feature audit (annual and post-change): Conduct a structured review of Scout's system prompt(s) and any scoring criteria or instructions passed to the Anthropic Claude API, to identify whether any terms or criteria could act as demographic proxies. This audit should be conducted by the CTO with external expert input where available [ASSUMPTION A-023]. Findings documented in the proxy feature audit register.
-
Rejection output sampling (quarterly): Draw a random sample of minimum 50 candidate rejection decisions per quarter. Review the CVs of rejected candidates for common themes: employment gaps, institution types, name origin patterns, activity keywords. Assess whether any theme correlates with a protected characteristic group. This review is conducted manually by the CTO or a designated reviewer.
-
Job description review (per submission): Where Sable AI Ltd has access to the job descriptions submitted by customers, review each job description for gendered or otherwise biased language (e.g., "rockstar", "aggressive", "nurturing", "young and dynamic") before or shortly after Scout processes it. Notify the customer of any problematic language identified. [ASSUMPTION]
-
Prompt review (pre-deployment): Following any update to Scout's system prompt or job description processing template, conduct a dedicated proxy-feature bias review before the update is deployed to production. Any prompt language that could introduce proxy feature weighting must be revised before go-live.
6.3 Alert threshold
Any proxy feature audit or rejection sampling exercise that identifies a feature in Scout's scoring logic correlating with a protected characteristic → RED alert → Immediate escalation to CTO → Remediation per Section 10.
7. A/B Outcome Tracking
Regulatory basis: DSIT Responsible AI in Recruitment Guide (March 2024) — example of rollback when a system update caused a drop in shortlisting rate for female applicants; ICO AI in Recruitment Outcomes Report (November 2024) — "sampling checks on changes to AI algorithms, to prevent introducing errors or bias into AI unintentionally."
7.1 Purpose
A/B outcome tracking compares Scout's shortlisting outcomes before and after a model or prompt change. It is the primary mechanism for detecting bias introduced by a system update. The DSIT Guide provides a direct operational precedent: following a new update, a supplier "conducts the bias audit which identifies a drop in the number of female applicants for positions... The supplier informs the organisation and rolls back the update until the issue can be identified and resolved."
7.2 Pre-change baseline capture
Before any material change to Scout's model version, system prompt, scoring criteria, or input/output format [ASSUMPTION]:
- Run Scout's canary test suite (M-11 in
L3-4.1-Monitoring-Framework-v1.md) against a test CV set covering demographic proxy profiles: CVs with employment gaps; CVs with names drawn from different cultural origins; CVs from different educational institution types; CVs with varying language register - Record baseline shortlisting rates and confidence score distributions for the test set
- Record the current adverse impact ratio from the most recent live monitoring period (where available)
7.3 Staging environment validation
- Deploy the proposed change to a staging environment before production
- Run the identical canary test suite in staging
- Compare staging results against baseline:
- Overall shortlisting rate: should remain within ±10% of baseline [ASSUMPTION]
- Adverse impact ratio by proxy group: should remain above 0.80 for all groups
- Confidence score distribution: should remain consistent
- If staging tests pass all checks: proceed to production deployment
- If any staging test fails: do not deploy; escalate to Engineering Lead and CTO; investigate root cause; roll back or revise
7.4 Post-deployment confirmation
Following production deployment: 1. Run abbreviated canary test on production immediately post-deploy 2. Monitor M-10 (shortlisting rate stability) and M-13 (adverse impact ratio) for the first 30 days post-deployment at increased frequency
7.5 Alert thresholds
| Signal | Threshold | Alert level | Action |
|---|---|---|---|
| Staging shortlisting rate shift vs. baseline | >10% | AMBER | Investigation before deployment; document justification if proceeding |
| Staging adverse impact ratio vs. baseline | AIR <0.80 (new finding not present in baseline) | RED | Do not deploy — escalation; root cause investigation; rollback or redesign |
| Post-deployment shortlisting rate shift | >15 percentage points from 3-month baseline | AMBER | Elevated monitoring; investigation within 5 business days |
8. Alert Thresholds Summary
| Signal | Threshold | Alert Level | Action |
|---|---|---|---|
| Adverse impact ratio — live monitoring | <0.80 for any group | RED | Immediate escalation → bias investigation → remediation within 30 days |
| Adverse impact ratio — live monitoring | 0.80–0.85 for any group | AMBER | Increase monitoring frequency; review within 30 days; document |
| A/B staging test: shortlisting rate shift | >10% vs. baseline | AMBER | Investigate before deployment; document justification if proceeding |
| A/B staging test: adverse impact ratio | <0.80 (new finding) | RED | Do not deploy; rollback; escalation |
| Keyword/proxy audit: confirmed proxy feature in scoring logic | Any confirmation | RED | Immediate escalation; prompt/model review; interim human override |
| Candidate complaint citing bias | Any | AMBER minimum | Trigger reviewer investigation; log in incident register; monthly aggregate escalation |
| Reviewer challenge rate | Non-zero | AMBER | Investigation per L3-4.1-Monitoring-Framework-v1.md M-06 |
9. Escalation Path
-
Detection: Monitoring system, Engineering Lead, or reviewer detects a threshold breach or bias signal → immediately logs in Scout incident register with metric, date, value, and threshold breached
-
Notification: Engineering Lead or monitoring owner notifies CTO within 1 business day of detection
-
Initial assessment (CTO, within 3 business days): Reviews output data, sampling methodology, adverse impact ratio calculation, and any available proxy feature audit results → determines root cause hypothesis and interim response
-
Bias investigation (CTO, within 5 business days [ASSUMPTION]):
- If root cause is identified: proceed directly to remediation per Section 10
- If root cause is unclear: commission targeted sampling review or external review as appropriate
-
Implement interim human override injection (Section 10.1) while investigation continues
-
Where discrimination impact is confirmed or strongly indicated:
- Invoke full remediation process (Section 10)
- Notify Founder/CEO
- Update DPIA record per
L2-3.4-DPIA-Template-v1.md - Assess whether an ICO breach notification or voluntary report is required per
L3-4.3-Incident-Response-Plan-v1.md -
Assess whether EHRC engagement is warranted [NOTE: EHRC notification trigger not confirmed in reviewed source documents — this should be verified against EHRC enforcement guidance before inclusion in operational policy] [LEGAL REVIEW REQUIRED]
-
Customer notification: Where a confirmed or suspected bias event affects a specific customer's shortlisting run, notify that customer within 5 business days of confirmation [ASSUMPTION]
10. Remediation Process
Regulatory basis: ICO AI in Recruitment Outcomes Report (November 2024) — providers took remediation actions "reducing the weightings of data points or excluding data points... typically repeated bias tests periodically at the least, or before launching changes"; DSIT Responsible AI in Recruitment Guide (March 2024) — rollback example; ICO extract on "swiftly addressed issues throughout the AI lifecycle."
10.1 Remediation options
The following remediation options are available in order of ascending disruption:
| Option | Description | When to use |
|---|---|---|
| Prompt adjustment | Revise Scout's system prompt to remove or reduce the weight of an identified proxy feature; re-test immediately post-change | When proxy feature is identifiable in prompt logic; change is low-risk and reversible |
| Exclusion or de-weighting | Add identified proxy terms or features to an explicit exclusion list or reduce their weight in Scout's scoring instructions | When prompt adjustment alone is insufficient; proxy feature clearly isolated |
| Human override injection | Require mandatory human review for all candidates meeting the profile of the affected group until root cause is resolved; override replaces automated shortlisting outcome | Immediate interim measure when adverse impact is confirmed and root cause is unknown or cannot be immediately resolved |
| Model rollback | Revert to the previous stable model version or prompt version | When bias was introduced by a specific update and the change cannot be safely remediated forward |
| Shortlisting suspension | Suspend Scout's shortlisting function for the affected role, customer, or customer segment while investigation continues | Last resort where no interim remediation can be applied and the risk of continued discriminatory output is high |
10.2 Post-remediation testing
Following any remediation action, regardless of which option was applied:
- Run the full canary test suite to confirm the adverse impact has been resolved in testing
- Monitor the adverse impact ratio for the next live shortlisting batch at elevated frequency (weekly for the first month post-remediation [ASSUMPTION])
- Document: cause identified, remediation applied, canary test results, residual risk assessment, monitoring plan
- If adverse impact ratio remains below 0.80 after remediation: escalate to CTO for model redesign consideration and commission external audit
- If adverse impact ratio returns to or above 0.85 after remediation: revert to standard monitoring frequency; document resolution; retain all remediation records
11. External Audit Cadence
Regulatory basis: ICO AI in Recruitment Outcomes Report (November 2024) — "Engage cognitive behavioural and psychometric experts to regularly test and review AI logic, scoring, and outputs for potential accuracy or bias issues"; DSIT Responsible AI in Recruitment Guide (March 2024) — "The organisation asks their supplier to run repeated bias audits every six months, and/or when major updates to the system are released."
11.1 Recommended cadence
[ASSUMPTION A-023] Sable AI Ltd has not yet commissioned an external bias audit. The following cadence is the recommended minimum:
| Trigger | External audit scope |
|---|---|
| Annual minimum | Full bias audit of Scout's shortlisting outputs across all live customers; adverse impact analysis; proxy feature review; assessment of internal monitoring adequacy |
| Following any RED-level bias finding | Targeted audit of the affected component or workflow; independent assessment of root cause and remediation |
| Before any major model update (version change; significant prompt restructure) | Pre-deployment audit to validate that the change does not introduce new bias |
| Before any significant customer or market expansion (new sector; new geographic market) | Assessment of current bias controls for fitness in the new context |
11.2 Audit scope
External auditors should be provided access to: - Scout's system prompt(s) and scoring logic documentation - Sample CV and job description datasets (pseudonymised where possible and where permissible) - Bias monitoring reports from the preceding 12 months - Human reviewer override logs - Adverse impact ratio calculations from the preceding period - Canary test suite and results
11.3 Audit output requirements
External audit reports must include: - Adverse impact analysis for each monitored protected characteristic dimension - Assessment of proxy feature risk in Scout's processing logic - Comparison of Scout's methodology against current ICO and DSIT guidance - Remediation recommendations with prioritisation - Independent assessment of whether Sable AI Ltd's internal monitoring is adequate to detect the bias risks identified
External audit reports must be retained for a minimum of 3 years [ASSUMPTION] and must be made available to the ICO on request.
12. Evidence Retention
Regulatory basis: ICO AI in Recruitment Outcomes Report (November 2024) — retain "test results or reports and evidence of actions you've taken to address issues"; UK GDPR Art. 5(2) — accountability; UK GDPR Art. 33(5) — breach documentation; ICO Guide to Accountability and Governance — linked evidence architecture.
| Record type | Minimum retention period | Notes |
|---|---|---|
| Monthly bias monitoring reports | 3 years [ASSUMPTION] | Secure internal controlled-access store |
| Adverse impact ratio calculations (per period) | 3 years | Include sample sizes, group definitions, methodology notes |
| Canary test results | 3 years | Version-controlled; linked to associated model/prompt version |
| A/B test results (pre/post deployment) | 3 years | Linked to associated deployment record |
| Keyword/proxy feature audit reports | 3 years | Include date, scope, findings, and action taken |
| Bias incident escalation and investigation records | 3 years | Linked to incident register per L3-4.3-Incident-Response-Plan-v1.md |
| Remediation action records | 3 years | Include cause, remediation applied, post-remediation test results |
| External audit reports | 3 years minimum; longer where findings remain active | Treated as accountability evidence under UK GDPR Art. 5(2) |
| Demographic data used for Option A voluntary monitoring | Retain only as long as needed for the monitoring purpose; delete when no longer required | Requires Art. 9-compliant access controls and a separate retention policy [LEGAL REVIEW REQUIRED] |
13. Cross-References
| Document | Relevance |
|---|---|
L3-4.1-Monitoring-Framework-v1.md |
Metrics M-13–M-15 that this protocol operationalises; monitoring governance, dashboard design, review cadence |
L3-4.3-Incident-Response-Plan-v1.md |
Escalation path when bias finding meets incident threshold; ICO notification decision tree |
L2-3.2-Equality-Act-2010-Compliance-Map-v1.md |
Protected characteristics at risk; EHRC enforcement context; EA 2010 indirect discrimination analysis |
L2-3.1-UK-GDPR-Mapping-Matrix-v1.md |
Art. 9 lawful basis for demographic monitoring data; purpose limitation constraints; Arts. 22A–22C safeguards |
L2-3.4-DPIA-Template-v1.md |
DPIA update required on confirmation of bias finding; living-DPIA obligations |
L1-2.5-Roles-and-Responsibilities-v1.md |
RACI for bias monitoring responsibilities |
14. Regulatory Sources
| Source | Relevant provisions |
|---|---|
| UK GDPR | Art. 5(1)(a)–(e), Art. 5(2), Art. 9(2), Arts. 22A–22D, Art. 25; Recital 71 (profiling and fairness) |
| DPA 2018 | Schedule 1 — conditions for processing special category data; Part 4 (appropriate policy document requirement) |
| Equality Act 2010 | s.4 (protected characteristics); s.19 (indirect discrimination); s.20–21 (duty to make reasonable adjustments) |
| ICO AI in Recruitment Outcomes Report (November 2024) | Adverse impact ratio; four-fifths rule; inferred demographics findings; evidence retention; remediation examples |
| DSIT Responsible AI in Recruitment Guide (March 2024) | Bias audit definition and methodology; iterative bias audits; six-month cadence example; rollback precedent; contestability |
| ICO Guide to Accountability and Governance | Documentation obligations; review cycles; linked evidence architecture |