UK ICO AI Compliance Checklist: 11 Tests Tied to Current Guidance

The ICO organises its AI guidance by data protection principles and operating questions. A deployed system still needs a testable record beneath those chapters: who approved the purpose, what data crossed the request boundary, which model received it, how a person can challenge the result and what happened when a control failed.

The ICO's Guidance on AI and data protection says it is under review following the Data (Use and Access) Act and identifies 15 March 2023 as the current page update. This UK ICO AI guidance compliance checklist treats the material as guidance under review and checks operative duties against the latest revised UK GDPR and Data Protection Act 2018.

1. Record the guidance and legislation versions

A compliance file should show which source informed each decision. The ICO review warning means a reviewer needs the retrieval date and a plan for later changes.

Owner: privacy owns the source register and change review.

Pass when: the AI governance register names the ICO chapter used, retrieval date, current warning, legislation version and next review owner. A source update creates an assessment ticket rather than overwriting the historical entry.

Keep: source register, archived page reference, review calendar and change ticket.

2. Assign accountability and system roles

The ICO's accountability and governance chapter addresses senior management responsibility, data protection by design and default, and controller and processor relationships. Article 5 makes the controller responsible for demonstrating compliance with the principles.

Owner: executive sponsor and privacy.

Pass when: each deployed AI use has a business owner, technical owner, privacy owner, controller and processor analysis, approved purpose, system identifier and escalation route.

Keep: role register, responsibility matrix, approval and architecture diagram.

3. Complete the DPIA threshold test before deployment

Article 35 requires a DPIA before processing likely to result in high risk, considering its nature, scope, context and purposes. The ICO accountability chapter treats the DPIA as a central mechanism for assessing AI processing.

Owner: privacy, the DPO and business decision owner.

Pass when: every use has a dated threshold decision before go-live. A qualifying system has an approved DPIA covering processing, necessity and proportionality, risks, measures, advice and review triggers.

Keep: threshold screen, DPIA, DPO advice, risk register and approval date.

4. State the purpose and lawful basis at feature level

The ICO's AI lawfulness chapter addresses identifying purposes and a lawful basis. Article 6 supplies the lawful-basis framework, with additional conditions under Articles 9 and 10 for particular data.

Owner: legal, privacy and product.

Pass when: each AI feature links to one precise purpose, a lawful-basis decision and any applicable additional condition. The statement separates support summarisation from employee evaluation rather than grouping both under “service improvement.”

Keep: purpose register, legal assessment, data-category analysis and approval.

5. Test transparency in the actual user flow

The ICO's AI transparency guidance addresses information about AI processing and directs organisations to explanation resources where decisions affect people.

Owner: product and privacy share the user-flow test.

Pass when: a synthetic user encounters the current notice at the right point in the flow. The notice identifies the purpose, relevant data use, retention information and rights route at a level appropriate to the audience.

Keep: rendered screen, notice version, readability or usability review and release record.

6. Define and test fairness criteria

The ICO's AI fairness chapter distinguishes data protection fairness from technical measures of bias and discusses sources of unfairness across the AI lifecycle.

Owner: the business decision owner with privacy and model risk.

Pass when: the use case has documented affected groups, foreseeable harms, outcome tests, acceptable thresholds, human review and remediation. One test set includes edge cases relevant to the population rather than only an aggregate score.

Keep: fairness assessment, test dataset description, results, reviewer decision and remediation record.

7. Separate personal-data accuracy from model performance

The ICO's accuracy and statistical accuracy chapter addresses the UK GDPR accuracy principle alongside the statistical performance of AI systems. Those are related evidence families with different tests.

Owner: data governance and model risk, with the business decision owner.

Pass when: personal data used by the feature has a correction path, while model outputs have documented validation, limits and review rules. A synthetic false account fact is stopped before the authoritative customer record changes.

Keep: source-quality controls, evaluation result, reviewer action and correction ticket.

8. Minimise data before the model call

The ICO's security and data minimisation chapter applies those principles to AI development and deployment. Article 5 limits personal data to what is necessary for the purpose.

Owner: product, data governance and AI platform engineering.

Pass when: the approved prompt schema lists necessary fields. A test adds a visible purple synthetic identifier in an excess field, and the request boundary applies the configured redaction or refusal before transmission.

Keep: schema, minimisation decision, test payload, classifier result and policy record.

9. Test security failures at the HTTP boundary

Article 32 requires measures appropriate to risk and includes regular testing and evaluation where appropriate. Normal-path evidence leaves the failure posture unanswered.

Owner: security engineering owns the failure tests and retests.

Pass when: tests cover an unknown model endpoint, missing originating identity and policy-evaluator timeout. Each event produces the approved restrictive outcome, alert and independently retrievable record.

Keep: test plan, console capture with the red denial row, alert ticket, signed event and clean retest.

10. Make individual rights work across AI stores

The ICO's individual rights chapter addresses rights handling in AI systems. Retrieval needs stable references across source systems, model traffic, provider stores and generated outputs.

Owner: privacy operations and data governance.

Pass when: a synthetic subject request locates relevant personal data and disclosure history, records the decision and routes correction, erasure or restriction to each applicable store. Use a subject reference distinct from caller identity where needed.

Keep: request, identity check, search query, export, decision, execution proof and response.

11. Reconcile approved providers with observed traffic

Governance documents describe the intended processors and destinations. Runtime evidence tests which endpoint received a request. Article 28 covers processor selection and required contract terms.

Owner: procurement, privacy and AI platform engineering.

Pass when: every observed HTTP model endpoint maps to an approved provider file, region and allowed data classes. An unapproved route is refused, investigated and closed with a named owner.

Keep: contract, subprocessor list, endpoint inventory, route export, denial and discrepancy decision.

Review register

Use one row per test with these fields:

• Control: the checklist number and ICO chapter.
• Owner: one accountable function and named delegate.
• State: Pass, Gap or Not applicable with a reason.
• Evidence: stable links to the test and approval artifacts.
• Review: test date, source version and next trigger.
• Remediation: due date, owner and clean retest.

My view is that item 11 should sit near the top of the review meeting. A processor register can be immaculate while a white console row shows the production agent calling a hostname absent from it. The register expresses the approved permission for that provider. The route record settles what happened.

DeepInspect

DeepInspect supports items 8, 9 and 11 directly and supplies operating evidence to items 2, 3 and 10. It sits inline between authenticated users or agents and HTTP-based LLM endpoints, evaluates application-supplied identity and purpose context, role, data classification, destination and policy, then applies a permit, redaction or denial before transmission.

Each decision creates a signed, tamper-evident record outside the calling application's write path. DeepInspect supplies payload-classification tests, restrictive failure evidence, observed route inventories and subject-linked disclosure history where the application provides the reference. Governance, legal analysis, transparency, fairness, accuracy, rights decisions and offline systems remain with their named owners. Book a technical deep dive at deepinspect.ai.