ICO Statutory AI + ADM Code of Practice — Customer Guide

Last updated: 2026-05-15 (Plan 138 v1)

What is the ICO AI + ADM Code, and why does it matter to you?

The ICO Code of Practice on AI and Automated Decision-Making is the UK Information Commissioner's Office statement of how data-protection law applies when your firm uses AI to make decisions about individuals. It is statutory under sections 121 to 129 of the Data Protection Act 2018: non-compliance is admissible evidence against you in ICO enforcement action and in court, and a judge can rely on the Code to decide whether you complied with UK GDPR. The ICO is enforcing right now — fines, public-register entries and mandatory remediation orders have landed on retailers and recruitment firms running automated decision-making. Every UK firm running AI that makes decisions about people (banks credit-scoring, HR-tech screening, fintech onboarding, healthcare triage, retailers personalising offers) is in scope. The quickest way to take pressure off your team is to keep a current evidence pack mapped to the Code so you can answer ICO questions before they become enforcement letters.

What ICO AI + ADM Code-specific features does Secruna ship?

End-to-end (Plan 138) — every item below is wired in the deployed system:

• Rule book v1 — 22 IGP YAMLs at rule_book/ico_ai_adm_code/v1/ covering the seven themes: Lawful basis and accountability (LB), Transparency (TR), Article 22 ADM specifics (ADM), DPIA for AI (DPIA), Fairness and bias (F), Data subject rights for AI (DSR), Children and high-risk processing (CH). Loader picks it up via KNOWN_FRAMEWORKS["ico_ai_adm_code"] in packages/rekognise-core/src/rekognise/agent/rule_book/registry.py.
• Evidence pack export — PDF / CSV / HTML at /exports/ico-ai-adm-code-evidence-pack. Backend renderer in packages/rekognise-core/src/rekognise/cp/export/regulation_evidence_pack.py (shared with NCSC CAF / NIS2 / DORA / Cyber Essentials Plus); API at GET /export/ico-ai-adm-code-evidence-pack?format={pdf,csv,html} mounted by apps/cp-api/src/cp_api/main.py.
• Tenant subscription — platform admins enable ico_ai_adm_code per tenant via enabled_frameworks (the same Plan 103 path used for every other framework). The evidence-pack endpoint gates on require_framework_subscription(db, tenant.id, "ico_ai_adm_code").
• Sidebar entry — /exports/ico-ai-adm-code-evidence-pack is registered in the framework feature manifest (packages/rekognise-core/src/rekognise/cp/framework_features/manifest.py) as the ico_ai_adm_code_evidence_pack feature. The Plan 109 dynamic sidebar surfaces the entry automatically when a tenant has ico_ai_adm_code enabled.
• Counsel review (Plan 97) — every rule YAML carries pending_counsel_review: true so verdicts route through the same counsel pipeline as DS 05-138 / NCSC CAF / NIS2 / DORA / Cyber Essentials Plus rules.
• Cross-framework signal share — ICO Code Theme 1 (lawful basis + ROPA) and Theme 3 (Article 22 ADM identification) reuse the universal Secruna AI systems inventory. Themes 4-6 reuse the tenant_cyber_posture artifact-metadata kind for tenant attestations.
• Verdict taxonomy — Non-Compliant / Requires Attention / Compliant / Not Applicable. See FRAMEWORK_CATEGORY_TAXONOMY["ico_ai_adm_code"] in packages/rekognise-core/src/rekognise/agent/rule_book/loader.py.
• Operator surface — /admin/regulations lists the ICO Code under shipped frameworks; /admin/tenants/{id}/framework-subscriptions accepts ico_ai_adm_code as a subscription target.
• Audit event — successful exports emit evidence_pack.ico_ai_adm_code.exported for the audit log.

Limitations (v1)

• DPIA template is from Plan 90; full DPIA-versus-AI-system linking is a Plan 90 follow-up. Secruna ships the AI-system DPIA template per Plan 90. Wiring every AI-system row to its DPIA record + DPO sign-off ticket is a Plan 90 follow-up; v1 reads the DPIA state from the tenant attestation and surfaces it on the evidence pack.
• Bias testing (F.01) is tenant-attested. Secruna does NOT run statistical fairness tests on customer models. The F.01 IGP captures a tenant attestation that bias testing has been performed; the analysis itself is the customer's responsibility. The bias-testing surface (capture of test results, methodology and thresholds) is scaffolded as Plan 140.
• Article 22 meaningful human intervention uses the existing HITL queue. The ICO Code ADM.03 obligation (meaningful human intervention available on request) reuses the Plan 75 HITL queue. There is no specialised ADM-contest endpoint yet — appropriate for v1 because most enterprise customer flows already route ADM contests through a single review queue.
• Article 22 right to contest is native (Plan 141). ADM.04 (data-subject right to contest under Article 22(3)) ships under Plan 141: a public-facing intake form at /contest-an-ai-decision/{tenant_slug} on the marketing site backed by an internal queue at /adm-contests in the dashboard. Each contest carries a 30-day notification deadline (UK GDPR baseline), an auto-emailed acknowledgement, and an outcome record that is emailed back to the data subject. The Plan 75 HITL queue stays in place for upstream ADM.03 meaningful-human-intervention. Per-tenant CAPTCHA on the public form, configurable per-tenant deadlines, and automated decision-explanation drafting are deferred to a future plan.
• The Code itself is being formalised. The ICO Code on AI and Automated Decision-Making is being consolidated. This rule book reflects the current published ICO guidance at https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/ and the related consultation pages. The rule book will be refreshed when the final statutory version of the Code lands; until then pending_counsel_review: true is set on every YAML and the TODO(plan-138-source-refinement) comment points at the canonical ICO source.

What the ICO AI + ADM Code is

The ICO Code on AI and Automated Decision-Making is the statutory Code of Practice issued by the UK Information Commissioner's Office under sections 121-129 of the Data Protection Act 2018. It translates UK GDPR obligations (particularly Article 22 — the right not to be subject to solely automated decision-making with legal or similarly significant effect) into operational expectations for organisations running AI systems.

Statutory status means:

• The Code is admissible evidence in court and in ICO enforcement action.
• A judge or ICO investigator can rely on the Code to decide whether your organisation complied with UK GDPR.
• The standards in the Code carry the same legal weight as the underlying GDPR obligation.

The Code covers seven themes Secruna mirrors as IGPs:

1. Lawful basis and accountability — Article 6 / 9 / 30 + DPO oversight.
2. Transparency and right to be informed — Article 13 / 14 + ADM logic + significance disclosure.
3. Article 22 ADM specifics — identification + exception basis + meaningful human intervention + right to contest.
4. DPIA for AI — before deployment + on material change + bias / discrimination / accuracy risk coverage.
5. Fairness and bias — bias testing on training data + model outputs; adverse-impact review.
6. Data subject rights for AI — Article 15 / 16 / 17 applied to AI decisions and training data.
7. Children and high-risk processing — Age-Appropriate Design Code alignment + parental consent.

Recent ICO enforcement has targeted retailers and recruitment firms running ADM, combining financial fines with public-register entries and mandatory remediation orders.

What Secruna covers

Secruna ships the ICO Code as a live rule book — rule_book/ico_ai_adm_code/v1/. Each Code theme becomes one or more Secruna rules with an ICO citation, a connector signal match (or a tenant-attestation marker), and a customer_description body explaining what the obligation means and what evidence the ICO expects.

The v1 rule book covers:

• Theme 1 — Lawful basis and accountability (4 IGPs): lawful basis per AI system, special-category data condition, DPO oversight, ROPA updated to include AI.
• Theme 2 — Transparency (3 IGPs): privacy notice describes AI use, ADM logic disclosed, significance + consequences disclosed.
• Theme 3 — Article 22 ADM specifics (4 IGPs): solely automated decisions identified, Article 22(2) exception basis, meaningful human intervention, right to contest.
• Theme 4 — DPIA for AI (3 IGPs): DPIA before deployment, bias / discrimination / accuracy risk coverage, DPIA review on material change.
• Theme 5 — Fairness and bias (3 IGPs): bias testing on training data + outputs, special-category attributes handled per ICO guidance, adverse-impact review.
• Theme 6 — Data subject rights for AI (3 IGPs): right of access (AI decision explanation), right to rectification of AI inputs, right to erasure of AI training data.
• Theme 7 — Children and high-risk processing (2 IGPs): special protections for children's data, Age-Appropriate Design Code alignment.

How verdicts map to ICO Code outcomes

Secruna verdict	ICO Code outcome	What it means
non_compliant	Control not evidenced	Highest severity — the absence of a documented control is the most direct evidence path to a statutory-Code breach in ICO enforcement.
requires_attention	Control partially evidenced	A weakness with documented remediation owed at the next internal review.
compliant	Control fully evidenced	Informational.
not_applicable	Control out of scope for the tenant	Residual fallback (e.g. Theme 7 children's-data protections at a B2B-only fintech with no consumer-facing service).

Severity ordering (highest first): non_compliant > requires_attention > compliant > not_applicable.

Using the evidence pack when the ICO asks

The ICO AI + ADM Code Evidence Pack is generated from the dashboard under Exports → ICO AI + ADM Code Evidence Pack (org_admin role required). The file is a tenant-level PDF / CSV bundle:

• Cover — tenant name, framework metadata, generation timestamp, document ID.
• §1. Assessment summary — counts of IGPs at each verdict.
• §2. Per-IGP evidence by theme — one section per theme (LB / TR / ADM / DPIA / F / DSR / CH), one row per IGP with the verdict and a short evidence summary.
• §3. Gaps surfaced for assessment — non-compliant + requires-attention IGPs surfaced separately so the DPO or ICO investigator sees the remediation list at a glance.
• §4. Audit trail — last 90 days of platform activity material to the evidence pack.

Filename: secruna-ico-ai-adm-code-evidence-{tenant_slug}-{date}.pdf (or .csv).

Responding to an ICO enforcement letter

The ICO opens enforcement by writing to the controller — typically with a list of specific questions about an AI system or an automated decision. The evidence pack is the answer:

1. ICO letter cites the AI system + the specific obligation (e.g. "evidence of meaningful human intervention under Article 22(3)").
2. Secruna evidence pack §2 has one row per IGP — find the ADM.03 row.
3. Cross-reference the evidence summary back to the underlying AI inventory row + tenant attestation.
4. Generate a fresh evidence pack (PDF + CSV) and attach to the ICO response.

Re-running after remediation

Verdicts re-evaluate on every discovery run. Refresh the evidence pack:

1. Trigger a discovery run (Connections → Run discovery now) or wait for the scheduled run.
2. Confirm the verdict has flipped to compliant under the IGP detail page.
3. Generate a fresh evidence pack — the new gap count appears on the cover.

What Secruna does NOT cover

• Statistical fairness testing. Bias testing (F.01) is tenant-attested in v1; the analysis is the customer's. Plan 140 will land the bias-testing surface.
• Meaningful human intervention (ADM.03) reuses the existing HITL queue. The Plan 75 HITL queue is the surface compliance officers use to review individual decisions before they go out. The specialised data-subject-facing contest workflow shipped under Plan 141 is now native — see Limitations (v1) above for what is + is not covered.
• DPIA-versus-AI-system linking automation. v1 surfaces the tenant-attested DPIA state per AI system; full DPIA workflow linking is a Plan 90 follow-up.
• Filing on the ICO public register. The ICO maintains a public register of enforcement notices and undertakings; this is an ICO surface, not a tenant surface.
• DPO services. Secruna provides the evidence pack to support the DPO's work; we do not provide DPO services.

Frequently asked

Q. We run AI to score customers but we don't make the final decision by automation alone — is Article 22 relevant? Article 22 applies to solely automated decisions. If a human meaningfully reviews each decision (not a rubber-stamp), Article 22 does not bite directly. But the wider ICO Code (lawful basis, transparency, DPIA, fairness, data subject rights) still applies; AI processing of personal data is in scope regardless of whether the decision is solely automated.

Q. We're a UK firm running AI in the EU. Does the ICO Code apply or does the EU AI Act apply? Both can apply. UK data-protection law (and therefore the ICO Code) applies to processing in the UK or affecting UK individuals; the EU AI Act applies to AI systems placed on the EU market or used by EU-established providers / deployers. Many groups subscribe to both: ICO Code for the UK entity, EU AI Act for the EU subsidiary.

Q. We have a DPO already. Do we need a separate ICO-Code accountability person? No — the DPO is the right person. Theme 1 of the Code expects DPO (or equivalent accountable person) oversight; the DPO sign-off cycle should incorporate AI system go-live gates.

Q. The Code is "being formalised" — what happens when the final statutory version lands? Secruna will refresh the rule book to match the final statutory text. The pending_counsel_review: true flag on every YAML guarantees that verdicts route through counsel review before they affect any procurement-decision surface. We will email subscribed tenants when the refresh ships.