DUAA: The "Keep Calm and Build a Workflow" Act
Practical solutions for UK SMBs navigating data subject access requests, complaints, analytics, and automation after February 5, 2026
Why DUAA Sounds Scarier Than It Is
If you run a small or mid-sized business in the UK and you're only just hearing about the Data (Use and Access) Act 2025, you're not alone. The main provisions came into force on February 5, 2026, and the commencement regulations were published just two days earlier. That's not a lot of notice.
Here's the good news: DUAA doesn't replace UK GDPR. It doesn't replace the Data Protection Act 2018. It doesn't replace PECR (the Privacy and Electronic Communications Regulations). It amends all three. That means if you are already handling personal data responsibly, you're not starting from scratch. You're adjusting.
The changes are also phased, which gives you time to prepare. The February 5 provisions cover DSARs (data subject access requests), cookies, automated decision-making, and a new "recognized legitimate interests" lawful basis. The mandatory complaints handling procedure doesn't kick in until June 19, 2026. The ICO (Information Commissioner's Office) is rolling out updated guidance throughout the year.
This article walks through the four areas that matter most for SMBs and gives you a concrete workflow for each one. No legal theory, no jargon walls. Just the processes you can put in place starting this week.
This article is for informational purposes only and does not constitute legal advice.
The Real Problem DUAA Is Solving
Most SMBs want to do the right thing with personal data. The issue is rarely intent. It's structure. A subject access request lands in someone's inbox and nobody is sure who handles it. A customer complains about how their data was used and the response depends on whoever happens to see the email first. Cookie banners were copy-pasted from a template two years ago and nobody has checked what scripts are running since.
DUAA isn't inventing new obligations so much as it's codifying what responsible data handling already looks like. Searches in response to DSARs should be reasonable and proportionate. Complaints should have a clear channel and a timeline. Automated decisions should be transparent. Cookies should reflect what your site does.
The common thread across all these changes is the same: replace ad hoc responses with repeatable, documented workflows. That's what the rest of this article helps you build.
Workflow 1: DSARs
From Fire Drill to Intake Process
The problem
Data subject access requests have a way of catching SMBs off guard. They arrive via email, phone, social media, or in person. Staff aren't sure where personal data lives across the company's tools. The one-month response deadline creates pressure that leads to over-collection, wasted effort, and a lot of internal stress.
What changed on February 5
Two important clarifications are now in statute. Searches in response to DSARs must be "reasonable and proportionate," which was already established in case law but now gives SMBs much more confidence to scope searches sensibly. And the "stop-the-clock" mechanism is now explicit: if you need to verify a requester's identity or clarify what they're asking for, you can pause the response timeline until you get the information you need. You just must show the clarification was genuinely required.
The ICO's updated DSAR guidance from December 2025 adds a practical note: even if a requester refuses to clarify, you should still make reasonable searches based on your own judgement. And whether you hold a "large amount of information" is now assessed relative to your own size and resources, which is a meaningful shift for smaller organizations.
The workflow
Step 1: Single intake channel. Create one place where all DSARs go, regardless of how they arrive. A shared inbox or a simple form works. The point is that nothing gets lost because it landed in someone's personal email.
Step 2: Identity and scope. Before searching for anything, verify who's making the request and what they're asking for. If you need clarification, send the stop-the-clock request and document the date you sent it.
Step 3: Reasonable search. Use a pre-defined search map (see diagram below) to decide which systems to check based on the type of request. A customer DSAR hits your CRM and support tools. An employee DSAR hits HR and payroll. You don't need to search everything every time. Document why you included or excluded specific systems.
Step 4: Respond and log. Send the response within the deadline, and log the request, the actions you took, any stop-the-clock periods, and the response date.
Workflow 2: Complaints
Build It Now, the Mandate Hits June
The problem
Data protection complaints tend to arrive informally. They're buried in support tickets, mentioned in social media replies, or squeezed into an email about something else entirely. When there's no clear intake channel, no assigned owner, and no timeline, complaints drift. And complaints that drift tend to escalate to the ICO.
What's coming on June 19
Section 103 of DUAA introduces a new statutory right to complain. Controllers will need to provide an accessible complaints mechanism, such as an electronic form. You'll need to acknowledge complaints within 30 days and respond with an outcome "without undue delay." It's worth noting that some individuals are already citing Section 103 in their DSARs and complaints, even though it isn't in force yet. Getting ahead of this is smart.
The workflow
Step 1: Receive. Publish a clear, easy-to-find complaints channel on your privacy page. A dedicated email address or a simple form works. Make it obvious.
Step 2: Acknowledge. Confirm receipt within 30 days. Aim for faster. An automated acknowledgement template makes this effortless.
Step 3: Investigate. Assign a named owner. Review what happened. Talk to the people involved.
Step 4: Respond. Communicate the outcome to the complainant. Be clear about what you found and what, if anything, you're doing about it.
Step 5: Log and remediate. Record the complaint, the investigation, and the resolution. If a process failure caused the complaint, fix the process. Complaints are a feedback loop, not just a compliance obligation.
Workflow 3: Cookies and Analytics
Cleanup, Not Overhaul
The problem
Cookie banners on most SMB websites were set up once and never revisited. They often don't reflect what the site is doing. Analytics quality suffers because blanket consent mechanisms create friction. And many business owners have no idea what third-party scripts are running in the background.
What changed on February 5
DUAA introduces new, narrow exemptions to cookie consent requirements. Cookies that are strictly necessary for service delivery, device security, fraud prevention, or user authentication can be set without explicit consent. Cookies used solely for analytics or solely for storing visual and functional preferences also fall under a new exemption.
But here's the important nuance that a lot of summaries are getting wrong: the analytics exemption doesn't mean "no consent banner needed." It replaces the consent requirement with a requirement to offer an informed, simple, and free opt-out at the point of first use. That's a different mechanism, and potentially a simpler one, but it's not a free pass. If your business also serves EU users, you'll probably want to maintain your existing consent approach for consistency.
The workflow
Step 1: Audit. Run a full cookie and tracker inventory across your web properties. Find out what's running, not what you think is running.
Step 2: Classify. Sort cookies into categories: strictly necessary, analytics and statistics, functional preferences, and advertising or behavioral.
Step 3: Decide. For analytics cookies, evaluate whether the new opt-out exemption works for your setup. If you serve both UK and EU users, weigh the cost of maintaining two approaches against keeping a single consent model.
Step 4: Clean. Remove trackers and scripts you aren't using. If you don't know what a script does, that's a good sign it should go.
Step 5: Document. Update your cookie notice so the language matches what's actually deployed. Align your banner with reality.
Workflow 4: Automated Decisions
Register What You Already Use
The problem
Automation is woven into the SaaS tools that SMBs use every day, often without anyone thinking of it as "automated decision-making." If your CRM scores lead and your sales team only calls the top-scoring ones, that's an automated decision. If your recruitment platform filters out applicants before a human sees their CV, that's an automated decision. If your support tool routes tickets by priority without a person reviewing each one, same thing. When nobody makes the decision, nobody can explain it, and that's where the risk sits.
What changed on February 5
DUAA rewrites Article 22 of UK GDPR entirely, replacing it with four new articles (22A through 22D). "Solely automated" decisions are now defined as those with "no meaningful human involvement." These decisions are more broadly permissible than before, but they come with mandatory safeguards: you must tell people about significant automated decisions made about them, let them challenge those decisions, and give them a path to human intervention. One notable restriction: solely automated decisions can't be made based on the new "recognized legitimate interests" lawful ground, so if you're relying on that basis, a human needs to be meaningfully involved.
The workflow
Step 1: Inventory. Build a simple register of the tools in your business that make automated decisions. For each one, note the tool name and vendor, what decision it makes, what data it uses, and whether meaningful human review exists in the process.
Step 2: Assess. Flag any tool that makes decisions with legal or similarly significant effects on individuals. These are the ones that need the full safeguard package.
Step 3: Document the challenge path. Write a clear, accessible explanation of how someone can request a review or an explanation of an automated decision that affected them.
Step 4: Assign ownership. Name a specific person who's responsible for each tool's compliance. If nobody owns it, nobody maintains it.
How It All Connects
If you look at these four workflows side by side, you'll notice they all follow the same pattern: intake, ownership, response, logging. That's not a coincidence. DUAA compliance isn't four separate projects. It's one operational pattern applied four different ways.
Every workflow starts with a defined entry point, so nothing slips through the cracks. Every workflow has a named owner so there's no ambiguity about who's responsible. Every workflow has a documented response timeline, so people know what to expect. And every workflow creates a record so you can demonstrate what you did and why.
That shared spine is what makes this manageable. You're not building four new systems. You're building one system and using it four times. And once it's in place, it works as an operational asset that improves efficiency well beyond compliance.
For MSPs: these workflows are a natural service package for your SMB clients. The pattern is repeatable, the deliverables are clear, and the value extends beyond data protection into general operational maturity. The 60-day readiness plan below works as a client onboarding template.
Your 60-Day Readiness Plan
Here's a practical timeline for getting these workflows in place. Weeks 1 and 2 focus on the provisions that are already live. Weeks 3 through 5 prepare you for the June 19 complaints deadline. Weeks 6 through 8 are about documenting and publishing everything so it sticks.
The most important thing about this plan is what it doesn't include: expensive software purchases. Everything here can be built with the tools you already have. Shared inboxes, simple forms, spreadsheet registers, and clearly written procedures. Structure and ownership are the differentiators, not technology.
Workflows Scale. Panic Doesn't.
DUAA isn't asking for perfection. It's asking for documented, repeatable processes. The businesses that treat this as a reason to get organized will be better run six months from now, not just more complaint. Faster DSAR responses, fewer complaints reaching the ICO, cleaner analytics, and clearer accountability around automation. Those are operational wins, not just regulatory checkboxes.
The phased timeline is a feature, not a threat. Use it. Build incrementally. Start with the February 5 provisions that are already live and use the runway until June 19 to get your complaints handled in place.
And remember: the pattern is the same every time. Intake. Ownership. Response. Logging. Get that spine right, and the rest follows.