UK Data Protection for Software Teams 2026: An Engineering Guide to the DUAA

UK data protection law changed materially this year, and almost everything written about it is addressed to compliance teams.

That is a problem, because most of what changed is engineering work. A new complaints obligation is a workflow, an SLA timer and an audit trail. The revised automated decision-making regime is model governance, human-review routing and explanation surfaces. The cookie exemptions are a consent management rebuild. The DSAR changes are a search implementation and a clock that can now pause.

Here is the sequence. The Data (Use and Access) Act 2025 received Royal Assent on 19 June 2025. Commencement regulations brought the principal data protection provisions into force on 5 February 2026. The final tranche — the requirement for controllers to acknowledge data protection complaints — took effect on 19 June 2026, a matter of weeks ago.

If your last data protection review predates February, your architecture is running against a framework that has since changed underneath it.

This guide covers what changed, what each change means in code rather than in policy, and a checklist you can run against an existing system.

This is an engineering guide, not legal advice. Every position here should be confirmed with a data protection specialist or qualified counsel before it drives a build decision. ICO guidance on several of these areas is still being published.

What changed, and when

The DUAA amends rather than replaces the UK GDPR, the Data Protection Act 2018 and PECR. The core framework — principles, lawful bases, rights, fine structure — remains substantially aligned with the EU GDPR. The divergences are specific and they are concentrated in areas that touch product engineering.

Two of these are genuinely significant for anyone building software: the automated decision-making reform and the complaints obligation. The rest are meaningful but tractable.

The complaints obligation

The most recent change, and the one most likely to be sitting unbuilt right now.

New section 164A of the Data Protection Act 2018 requires controllers to acknowledge data protection complaints within 30 days, effective 19 June 2026. Organisations are required to have a procedure in place for dealing with data protection complaints, and to make a clear submission mechanism available and publicised.

What this means to build:

A submission route that is discoverable and unambiguous. Not a general contact form that a support agent may or may not classify correctly. A route a data subject can find and use, which produces an identifiable data protection complaint record.

An SLA timer with a hard 30-day acknowledgement. Instrumented, monitored, and alerting before breach rather than after. This is the same engineering pattern as any regulatory clock — the failure mode is a complaint sitting in a shared inbox with nobody owning the countdown.

Classification at intake. Support queues receive thousands of messages. Some of them are data protection complaints and do not announce themselves as such. Whether you solve that with routing rules, agent training, or classification tooling, it needs solving — a complaint you failed to recognise is still a complaint you failed to acknowledge.

An audit trail. When it arrived, when it was acknowledged, by whom, what was done. The ICO's supervisory posture across UK regulation has moved consistently toward demonstrable outcomes rather than stated intentions.

If you build nothing else from this article, build this. The obligation is live now, the deadline is short, and unlike most compliance work it has a bright-line test you either pass or fail.

DSARs: proportionate search and a pausable clock

Two changes, both helpful, both requiring implementation.

Reasonable and proportionate search. Organisations are now only required to carry out reasonable and proportionate searches in response to a subject access request. This provision was backdated to 1 January 2024 and applies retroactively to requests made before the Act passed.

The pausable clock. New Article 12A changes how the one-month response period is calculated. Where a controller needs further information from the requester — to verify identity, or to clarify scope — the response period can be paused while awaiting it.

What this means to build:

A DSAR search that is bounded and documented. "Proportionate" is only defensible if you can describe what you searched and why that was proportionate. Systems that scatter personal data across services with no canonical index cannot make that argument. The engineering answer is a data map maintained as code rather than as a spreadsheet that goes stale.

A clock that can genuinely pause. Not a spreadsheet with a manually adjusted date. A state machine with defined transitions — received, awaiting clarification, resumed, responded — where each transition is timestamped and the elapsed calculation excludes paused periods automatically. Manual clock management is where the errors are.

Identity verification as a first-class step. The pause is only available if you actually requested clarification. Build the request, log it, and start the pause from it.

Recognised legitimate interests

The DUAA introduces a new lawful basis — recognised legitimate interests, at Article 6(1)(ea) — covering five specified categories where the balancing exercise is no longer required. The categories broadly cover national security and defence, emergencies, crime prevention and detection, safeguarding vulnerable individuals, and responding to requests from public bodies.

Two constraints that get lost in the summaries:

The list is narrow. Direct marketing, intra-group data sharing and network security are not on it. A legitimate interests assessment is still required for those. Firms reading "no more LIAs" and applying it broadly are misreading the provision.

Everything else still applies. Controllers relying on a recognised legitimate interest remain bound by purpose limitation, data minimisation and every other UK GDPR principle. The change removes one step, not the framework.

Engineering impact is modest, but there is one real consequence: your lawful basis needs to be recorded per processing purpose in a way that survives audit. Systems that record a single lawful basis at the account level cannot express "recognised legitimate interest for fraud prevention, consent for marketing, contract for service delivery." That granularity is now more consequential than it was.

Financial services firms benefit most here, particularly around fraud prevention and customer due diligence — which connects directly to the engineering requirements we cover in our London fintech development guide.

Automated decision-making: the big one

This is the change that matters most if you build anything with a model in it.

Section 80 and Schedule 6 replaced Article 22 of the UK GDPR with new Articles 22A to 22D, effective 5 February 2026.

The old position: prohibition by default. Solely automated decisions with legal or similarly significant effects were banned unless a specific exception applied — consent, contract necessity, or statutory authorisation.

The new position: permission with safeguards. The default flips. Solely automated significant decisions become permissible provided the required safeguards are in place, which include informing individuals about automated decisions affecting them, allowing them to challenge those decisions, and providing access to meaningful human review.

Special category data remains more protected, and the stricter regime continues to apply there.

Why this matters commercially. This is a genuine liberalisation and one of the clearest UK-EU divergences the DUAA creates. It makes a range of automated decisioning products materially easier to deploy in the UK than in the EU. If you have been avoiding automated decisioning on legal grounds, that calculation has changed.

What this means to build — and this is the part nobody is specifying:

A human review path that is real. "Meaningful human review" means a human who can actually access the decision, understand the inputs, and overturn it. A review queue where an operator sees an outcome and a confidence score and has no capacity to reverse anything does not satisfy this. Build the reversal path, not just the review screen.

Notification surfaces. Individuals must be informed about automated decisions affecting them. That is a product surface — in-app, email, or both — that fires from the decision event rather than being assembled later.

A challenge mechanism. Distinct from your complaints route, though it may share infrastructure. A data subject must be able to contest a specific decision, and that contest needs a workflow with an outcome.

Decision reconstruction. To provide meaningful review of a decision made four months ago, you need the model version, the feature values, the configuration and the thresholds as they were at the time. This is the same versioning discipline that regulated fraud systems require, and it is the thing most machine learning deployments do not have.

Special category detection. If your feature set can include special category data — health, biometrics, and the other protected categories — the stricter regime applies. Knowing whether it does is a data lineage problem.

Most teams deploying models have the model and lack the governance layer around it. That layer is now a legal requirement rather than good practice, and it is where our AI and machine learning practice spends a substantial share of engagement time — because a model you cannot explain, version or reverse is a liability regardless of how well it performs.

The ICO has consulted on draft guidance covering automated decision-making and profiling. Watch for the final version before locking your design.

Cookies and tracking technologies

Section 112 exempts certain analytics and functionality cookies from the PECR consent requirement, effective 5 February 2026. From that date a set of cookie categories — broadly those used for statistical purposes and to improve site functionality — no longer require prior consent.

What this means to build:

A consent management rebuild, not a banner edit. Your CMP needs to distinguish exempt categories from non-exempt ones and stop blocking the exempt ones. Most implementations bundle analytics with marketing in a single "accept" — that is now leaving measurement data on the table unnecessarily.

A tracker inventory. You cannot categorise what you have not enumerated. Most sites are carrying tags nobody can account for. Audit first.

Care with behavioural biometrics. Requirements around behavioural biometrics and analytics data following consent rules similar to cookies mean that if your product does behavioural profiling — typing cadence, interaction patterns, device fingerprinting for anything beyond security — that is not obviously in the exempt category. Treat it conservatively.

Do not apply this to EU traffic. The exemption is UK-specific. If you serve both jurisdictions, your CMP now needs to behave differently by user location. That is a real divergence and a real implementation task.

The ICO has published updated guidance on storage and access technologies. Read it before you ship the change.

International transfers and the data protection test

The DUAA introduces a "data protection test" for third-country transfers, offering more flexibility than the previous "essentially equivalent" standard.

The practical effect for most engineering teams is modest but worth knowing: transfer assessments have a somewhat more workable standard than before. The mechanisms — adequacy regulations, the UK IDTA, the UK Addendum to the EU SCCs — continue to operate.

What this means to build: a data flow map you can actually produce. Most transfer assessment pain comes from organisations not knowing where their data goes. Every sub-processor, every region, every backup destination, every logging and observability endpoint. That last category catches people out constantly — error tracking and APM tools routinely ship personal data to regions nobody assessed.

Adequacy and what it means architecturally

Resolved, and better than many expected.

On 19 December 2025 the European Commission renewed the UK adequacy decisions — one under the GDPR, one under the Law Enforcement Directive — reaffirming that personal data can continue to flow freely from the EEA to the UK. This followed an interim extension in June 2025 and an EDPB opinion adopted in October 2025.

The renewal carries a sunset clause running to 27 December 2031, with the possibility of extension. The Commission continues to monitor divergence and can raise concerns before that point.

What this means architecturally: EU-to-UK transfers require no additional safeguards for the next five years. You can site UK infrastructure, use UK processors, and route EU personal data to the UK without SCCs.

The caveat worth designing for: UK adequacy remains the only time-limited adequacy decision, precisely because the Commission wants to monitor alignment. The DUAA divergences described in this article — particularly on automated decision-making and cookies — are the areas under scrutiny. That is not a prediction of withdrawal; it is a reason not to build an architecture that would be catastrophic to unwind. Keep data residency configurable rather than hard-coded. That is good practice regardless.

The engineering checklist

Run this against an existing system.

Complaints — do this first, it is already live

• Discoverable, publicised data protection complaint submission route

• Complaints identifiable as such at intake, including from general support queues

• 30-day acknowledgement SLA instrumented with pre-breach alerting

• Full audit trail: received, acknowledged, actioned, by whom

DSARs

• Search scope bounded, documented, and defensible as proportionate

• Data map maintained as code, not as a stale document

• Response clock implemented as a state machine with automatic pause handling

• Identity verification and clarification requests logged as clock-pausing events

Automated decision-making

• Inventory of all solely automated decisions with legal or similarly significant effects

• Notification surface firing from the decision event

• Challenge mechanism with a defined workflow and outcome

• Human review path with genuine reversal capability, not review-only

• Model, feature, configuration and threshold versioning enabling point-in-time reconstruction

• Special category data lineage established

Cookies and tracking

• Complete tracker inventory

• CMP distinguishes exempt from non-exempt categories

• Behavioural biometrics treated conservatively

• UK and EU consent behaviour differentiated by user location

Lawful basis and transfers

• Lawful basis recorded per processing purpose, not per account

• Recognised legitimate interests applied only to the five specified categories

• Complete data flow map including logging, observability and backup destinations

• Data residency configurable rather than hard-coded

Frequently asked questions

What is the Data (Use and Access) Act 2025? UK legislation amending the UK GDPR, Data Protection Act 2018 and PECR. It received Royal Assent on 19 June 2025 and has been phased into force, with the principal data protection provisions commencing on 5 February 2026 and the complaints requirement on 19 June 2026. It amends rather than replaces the existing framework.

When did the DUAA come into force? In stages. Some provisions on Royal Assent in June 2025, further provisions in August 2025, the principal data protection provisions on 5 February 2026 under commencement regulations, and the complaints procedure requirement on 19 June 2026.

What is the new data protection complaints requirement? New section 164A of the Data Protection Act 2018 requires controllers to acknowledge data protection complaints within 30 days, effective 19 June 2026. Organisations must have a procedure in place and a clear, publicised submission mechanism.

Does the UK still have EU adequacy? Yes. The European Commission renewed the UK adequacy decisions on 19 December 2025, under both the GDPR and the Law Enforcement Directive. The renewal carries a sunset clause running to 27 December 2031, with the possibility of extension, and the Commission continues to monitor divergence.

What changed for automated decision-making under the DUAA? Articles 22A to 22D replaced the previous Article 22 with effect from 5 February 2026. The old default prohibited solely automated decisions with legal or similarly significant effects unless an exception applied. The new default permits them subject to safeguards, including informing individuals, allowing them to challenge decisions, and providing meaningful human review. Special category data remains more protected.

Do I still need cookie consent in the UK? For some categories, no. Section 112 exempts certain analytics and functionality cookies from the PECR consent requirement from 5 February 2026. Other categories, including marketing, still require consent. The exemption is UK-specific and does not apply to EU users.

What are recognised legitimate interests? A new lawful basis at Article 6(1)(ea) covering five specified categories where the balancing test is not required — broadly national security and defence, emergencies, crime prevention, safeguarding, and responding to public body requests. Direct marketing, intra-group sharing and network security are not included and still require a legitimate interests assessment.

How have subject access request rules changed? Searches need only be reasonable and proportionate, a provision backdated to 1 January 2024. New Article 12A allows the one-month response period to be paused where the controller requires further information from the requester, such as identity verification or scope clarification.

Does UK data protection law still align with the EU GDPR? Substantially, in core principles, lawful bases, rights and fine structure. The DUAA introduces specific divergences in cookies, automated decision-making, subject access requests, international transfers and ICO governance. Organisations operating in both jurisdictions need their systems to behave differently by user location in those areas.

The short version

Three things are worth doing this month.

Build the complaints route. The obligation is live, the 30-day clock is a bright-line test, and it is the change most likely to be sitting unbuilt.

Inventory your automated decisions. The regime got more permissive and more demanding at the same time. More things are now allowed, and each of them needs notification, challenge, human review and version history. That is a build, and most teams have the models without the governance layer around them.

Split your consent behaviour by jurisdiction. The UK cookie exemptions do not apply to EU users. A single CMP configuration serving both is now either over-blocking in the UK or under-consenting in the EU.

Everything else on the checklist is worth doing and less urgent.

About Akoode Technologies

Akoode Technologies is an AI and software development company headquartered in Gurugram, India, with a US office in Oklahoma, working with clients across the UK, USA and India. We build custom software, AI and machine learning systems, mobile applications and eCommerce platforms for startups, SMEs and enterprises across 15+ industries, with 180+ projects delivered globally and clients across the UK, including London and Manchester.

Verified ratings: 4.9 out of 5 on Google across 110 client reviews, and 5.0 out of 5 on GoodFirms.

If you are assessing an existing platform against the 2026 changes, book a call and we will walk the checklist against your architecture.

This article is an engineering guide, not legal advice. Legislative references reflect published analysis as of August 2026; several DUAA provisions are being implemented through secondary legislation and ICO guidance on automated decision-making and storage technologies remains in development. Confirm all positions with a data protection specialist or qualified counsel before they drive build or compliance decisions.