What happens when organisations delay updating cookies, automated decision making, and subject access request processes under the DUAA?

Why Delaying DUAA Updates Creates Compliance Drift

When organisations keep legacy cookie, automated decision-making, and subject access request workflows in place after the DUAA changes, the issue is not only legal lag. The practical problem is that notices, internal approvals, data handling steps, and response timelines can become inconsistent with the rules that now govern them. That creates avoidable exposure because staff keep operating to the old model while the organisation is judged against the new one. For a plain-language overview of the wider control environment, NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for understanding how policy, process, and accountability need to line up.

Practitioners often underestimate how quickly this turns into an evidence problem. If the published notice, the consent journey, the SAR workflow, and the actual operational record no longer tell the same story, the organisation may struggle to demonstrate that it has kept pace with the amended requirements. In practice, many teams only discover the mismatch after a regulator, legal reviewer, or customer complaint forces them to reconstruct what changed and when.

How Cookie, ADM, and SAR Processes Need to Change in Practice

The DUAA does not just require a policy edit. Organisations need to check the full processing chain: the wording presented to users, the logic that triggers consent or preference capture, the internal rules that govern automated decisions, and the steps used to answer access requests. Each of those elements can fail independently, so updating one without the others often leaves a compliance gap.

For cookies, the key question is whether the notice and preference model still accurately describes what is collected, why it is collected, and how consent or refusal is recorded. For automated decision making, teams should verify whether the safeguards, human review points, and escalation routes match the amended legal position rather than the older interpretation. For subject access requests, the risk is usually process friction: the request handler, the system owner, and the legal reviewer may each assume someone else has already adjusted the workflow.

• Review the external notice and the internal procedure together, not separately.
• Map each affected rule to the system, owner, and evidence trail that proves it is live.
• Check that change control covers templates, decision logic, and response timing, not only policy text.
• Test whether staff can still explain the current process in a way that matches the actual workflow.

Where organisations rely on multiple platforms or outsourced processors, the update is only real when every downstream copy of the process has been aligned. This guidance breaks down when teams treat DUAA work as a documentation exercise instead of a live operating-model change.

Where the Hardest DUAA Gaps Usually Appear

Tighter privacy controls often increase operational effort, so organisations have to balance clarity and compliance against process speed and user experience. The hardest cases are usually not the obvious ones, but the edge cases where cookies, automated decision-making, and SAR handling intersect with older retained templates or legacy system behaviour.

One common variation is that a policy gets updated while the consent banner, privacy notice, or case-management script remains unchanged. Another is that an automated decision is technically documented, but the review step is informal and leaves no defensible record. A third is that SAR deadlines and exemption handling look correct on paper, yet the operational queue still reflects the old workflow. In guidance terms, this is a recognised governance failure pattern rather than a settled area of consensus: the law may define the obligation, but teams still need to operationalise it consistently across systems and owners.

Where multiple business units or vendors handle the same data activity, the weakest link is usually not the rule itself but the point where responsibility becomes ambiguous. Organisations should treat that ambiguity as a control defect, not an administrative inconvenience.

Practitioner Guidance

What to prioritise: Update the live process before you rely on the rewritten policy. If the notice, workflow, and evidence trail do not change together, the organisation still operates on the old rules even if the document set looks current.

What to verify: Confirm that each affected process has an owner who can show the amended rule in operation, not just approved in a document repository. For this topic, the decisive evidence is usually the combination of user-facing wording, decision records, and request-handling logs.

• Validate the user journey end to end for cookies and consent.
• Check that automated decision safeguards are still executable, not merely described.
• Re-run a sample SAR through the current queue, escalation, and response path.
• Escalate any gap where the business cannot show who changed the process, when it changed, and how it is now enforced.

Practitioner takeaway: The risk is rarely that the organisation has no policy; it is that the policy says one thing while the operational process still does another.

Related resources from NHI Mgmt Group

• How should organisations scope automated decision-making technology for compliance in consequential decision processes?
• How should organisations govern access control when decision-making moves to the edge?
• How should teams govern automated decision-making systems under privacy regulations?
• Why do automated decision-making systems create extra compliance risk under MODPA?