UK DPA AI Controls Mapping: Objective, Owner, Test and Evidence

A controls map becomes useful when every legal objective has an owner, an implementation point, a test and an artifact. For hosted AI, the map also needs a boundary verdict. A policy gateway can govern authenticated HTTP traffic to a model. It cannot choose the lawful basis, approve a DPIA or correct a customer record.

This UK DPA AI controls mapping uses the latest revised UK GDPR, with the Data Protection Act 2018 supplementing the regime. The ICO currently warns that its AI guidance is under review following the Data (Use and Access) Act. Full below means enforceable on the routed request path. Partial means the path supplies one component or evidence. Outside assigns the operative control elsewhere.

Accountability and processing records

Source objective: Article 5 makes the controller responsible for the data protection principles and able to demonstrate compliance. Article 30 specifies records of processing activities for controllers and processors.

Owner: privacy, with executive approval and system-owner input.

Implementation: maintain one AI inventory tied to purposes, data categories, recipients, transfers, erasure expectations and security measures. Add model endpoint, provider, policy version and go-live date as operating detail.

Test and evidence: select inventory row UK-AI-042, retrieve its Article 30 record and reconcile the approved endpoints against observed HTTP destinations. Keep the row, approval, route export and discrepancy decisions.

Coverage verdict: This row receives Partial coverage. Runtime routes and policy versions support demonstration. Governance approval and the statutory record remain organisational controls.

Lawfulness and purpose limitation

Source objective: Articles 5 and 6 require lawful processing for specified purposes, with personal data limited to what is necessary. Articles 9 and 10 add conditions for special category and criminal-offence data.

Owner: legal and privacy define the basis and purpose. Product and AI platform engineering implement the approved scope.

Implementation: bind each purpose identifier to allowed roles, personal-data classes and model destinations. Require the application to supply that purpose value with every routed request.

Test and evidence: send a synthetic support record under the approved purpose, then attempt the same payload with a recruitment purpose and an unapproved endpoint. Retain the legal decision, purpose register, permit and denial.

Coverage verdict: Full for evaluating purpose-scoped destinations when trustworthy purpose context reaches the gateway. The lawful-basis decision and necessity analysis are Outside.

Transparency

Source objective: Article 5 requires transparent processing. The ICO's current AI transparency guidance addresses how organisations explain AI processing and direct people to relevant rights information.

Owner: product and privacy share this control and its review.

Implementation: version notices by feature and connect each version to the purpose, provider categories, retention rule and deployed policy. Include a user-facing explanation path appropriate to the context.

Test and evidence: run a synthetic user flow and capture the notice presented before processing. Compare the provider category in that notice with the observed destination for the resulting request.

Coverage verdict: This row receives Partial coverage. Route records can test consistency between declared and actual destinations. Notice drafting, timing, accessibility and explanation stay Outside.

Data minimisation

Source objective: Article 5 requires personal data to be adequate, relevant and limited to what is necessary for the processing purpose.

Owner: product and data governance define the minimum fields. AI platform engineering enforces the approved request schema.

Implementation: classify prompt content before transmission, redact excess fields where the use permits it, and refuse payloads whose risk or ambiguity crosses policy.

Test and evidence: place a visible purple synthetic identifier in an unnecessary account-history field. The permitted support fields continue to the approved model while the excess value receives the configured action. Preserve the schema, test payload and signed decision.

Coverage verdict: Full for classification and policy action on routed HTTP payloads. Data selection in source stores and minimisation during offline training are Outside.

Security of processing

Source objective: Article 32 requires controllers and processors to implement measures appropriate to risk. The provision covers confidentiality, integrity, availability, resilience, restoration, and regular testing and evaluation where appropriate.

Owner: security engineering with AI platform engineering.

Implementation: validate identity context, authorise destination by role and data class, use restrictive failure behaviour, protect the event write path and operate an integrity-verification procedure.

Test and evidence: trigger three cases under ticket SEC-1241: an unknown endpoint, missing principal and evaluator timeout. Each test should produce the approved restrictive outcome, alert and independently retrievable record.

Coverage verdict: Full for the configured controls on authenticated HTTP AI traffic. Storage security, endpoint protection, local execution and model-development security are Outside.

Processor governance

Source objective: Article 28 covers processor selection and contract terms, including documented instructions, confidentiality, security, assistance, deletion or return, audit information and subprocessor conditions.

Owner: procurement, legal and privacy.

Implementation: map every hosted model endpoint to an approved processor file, configured region, allowed data classes and review date. Enforce only the approved routes at runtime.

Test and evidence: compare the endpoint and region observed for one production sample with the signed arrangement and current subprocessor list. Change the SDK base URL to an unapproved route and retain the denial.

Coverage verdict: Full for route enforcement and Partial for processor governance. Due diligence, contract sufficiency and audit rights remain Outside.

DPIA and change control

Source objective: Article 35 requires a DPIA before processing likely to result in high risk. The assessment describes processing, necessity and proportionality, risks to people and measures addressing them.

Owner: privacy, the DPO and business decision owner, with security input.

Implementation: give each DPIA risk a stable identifier and translate technical treatments into policy tests. Trigger review when the purpose, data classes, provider, model, affected population or decision effect changes.

Test and evidence: risk DPIA-22 covers disclosure of health details to an unapproved provider. Send a synthetic marked record to that route and attach the denial, policy version and reviewer sign-off to the risk.

Coverage verdict: This row receives Partial coverage. Runtime controls test selected treatments. Threshold assessment, consultation, approval and broader risk analysis are Outside.

Retention and individual rights

Source objective: Article 5 includes storage limitation. UK GDPR rights provisions cover access, rectification, erasure and restriction subject to their conditions.

Owner: privacy operations and data governance.

Implementation: set retention for decision records, prompts, responses and provider-held data. Add a stable subject reference when the person described in a payload can differ from the caller.

Test and evidence: retrieve all routed disclosures for a synthetic subject and date range, then follow a correction into the authoritative source system. Keep the query, export, rights decision, correction ticket and disposal result.

Coverage verdict: This row receives Partial coverage. Request records can supply disclosure history and apply retention to their own store. Identity verification, exemptions, source correction, provider deletion and response delivery stay Outside.

Coverage register

Record the map in a scannable control register:

• Accountability and Article 30: privacy owner; inventory reconciliation; Partial.
• Lawfulness and purpose: legal and product owners; purpose-to-route test; Full at request boundary, Outside for legal analysis.
• Transparency: product and privacy owners; notice-to-destination comparison; Partial.
• Minimisation: data governance and platform owners; marked-field test; Full on routed payloads.
• Security: security owner; route, identity and timeout tests; Full on authenticated HTTP traffic.
• Processor governance: procurement and legal owners; contract-to-route comparison; Full for routing, Partial overall.
• DPIA: privacy and DPO owners; treatment test joined to risk; Partial.
• Retention and rights: privacy operations owner; subject-range retrieval and disposal; Partial.

My candid view is that processor governance is the row most likely to look green in a board pack and turn amber on the wire. A contract may name one service and region while a changed base URL sends the prompt elsewhere. Procurement establishes the approved arrangement. The request record establishes the destination used.

DeepInspect

DeepInspect is the enforcement point behind the Full request-boundary verdicts and an evidence source for several Partial rows. 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 produces a signed, tamper-evident record outside the calling application's write path. That record supports endpoint reconciliation, minimisation tests, Article 32 operating evidence, processor-route comparison, DPIA treatment tests and disclosure retrieval. DeepInspect leaves legal analysis, notices, approvals, contracts, rights decisions and offline systems with the owners named in the map. Book a technical deep dive at deepinspect.ai.