UK Data-Protection Complaints Under DUAA: From Intake to Outcome

Acknowledge within 30 days, investigate without undue delay, and keep the response connected to its evidence

Published

Yellow and white envelope, evidence folder, and response bubble illustrate complaint intake, investigation, and outcome, with the FormKiQ wordmark.

A customer tells support that a statement was sent to an old address. The message is logged as a service issue, forwarded to privacy, and discussed with a processor. Unless someone connects those steps, the organization may struggle to show when it received the complaint, what it investigated, and what it told the customer.

Treat a data-protection complaint as an accountable case with an owner, a timeline, supporting evidence, and an outcome. The process can use an existing support or case system; what matters is that the work and response remain connected.

Start with the actual obligation

The complaints-handling duty introduced by the Data (Use and Access) Act 2025 took effect on June 19, 2026. The regulator’s commencement guidance identifies the change. For controllers handling complaints under UK data-protection law, the complaints guidance sets out four duties:

  • Provide a way for people to make data-protection complaints.
  • Acknowledge receipt within 30 days.
  • Investigate appropriately and keep the person informed without undue delay.
  • Communicate the outcome without undue delay.

Scope reviewed: November 10, 2026. The stages below are an implementation pattern. Keep legal requirements distinct from the organization’s internal service targets.

1. Recognize and register the complaint

Train receiving teams to recognize concerns about personal information, even when the person uses ordinary language or raises several issues together. Offer an accessible complaints route and capture complaints received through support, email, post, forms, or conversations. A preferred form should help intake rather than hide concerns arriving elsewhere.

Record the original received time, channel, sender, concern, requested outcome, case reference, and accountable owner. Preserve the message and attachments. Handing work from support to privacy should retain the same receipt date and history.

A complaint may also contain a request for access, correction, or deletion, or indicate a possible security incident. Create linked work with its own applicable rules and owner. Closing the complaint should not silently close a rights request or replace an incident-reporting decision.

2. Acknowledge promptly and start work

Confirm receipt and explain that the concern will be considered. Give the person a reference and suitable contact route, and retain the acknowledgment record. Use an earlier internal target where practical rather than treating day 30 as the preferred response date.

The guidance on receiving complaints makes an important distinction: investigation starts when the complaint arrives, not after the acknowledgment period. There is no blanket 30-day investigation allowance. Plan proportionate enquiries and progress updates from the outset.

Calculate the acknowledgment date correctly

The 30-day period starts the day after receipt. If the last day falls on a weekend or public holiday, the guidance allows acknowledgment by the next working day.

Store the received date, deadline calculation, and applicable calendar. If routing or verification is still pending, keep the original receipt date visible. Changing an internal task target should not silently reset the acknowledgment deadline or the investigation’s elapsed time.

3. Investigate with proportionate access

Clarify the issue and desired outcome, then identify the records and people needed to establish what happened. Assign requests for evidence with an owner and follow-up date. If a processor or another team holds relevant material, track that dependency rather than leaving it in an unanswered email thread.

Before disclosing personal information, establish appropriate confidence in the person’s identity and any representative’s authority. Use existing authenticated relationships where suitable and request only the additional evidence needed. Store verification results separately from broadly shared case notes and apply appropriate retention to supporting copies.

Keep the evidence needed to explain a complaint decision.
RecordWhat it should establish
Original complaint and acknowledgmentWhat was raised, when it arrived, and how receipt was confirmed.
Relevant notice or procedureThe version in effect for the activity being investigated.
System or processor evidenceSource, time, record references, and the facts supported by the material.
Decision and responseFindings, rationale, approved reply, recipient, and dispatch result.
Remedy and follow-upAction owner, commitment, due date, and evidence that the action was completed.

Keep raw evidence, working analysis, and the approved decision distinguishable. Give contributing teams access to the material they need; avoid exposing an entire complaint file through search, exports, or investigation spreadsheets.

4. Explain and record the outcome

Use a clear response that addresses the concern, explains the findings, and describes any remedy or remaining action. Follow the regulator’s outcome guidance, including information about raising unresolved concerns with the regulator. Keep the approved response and the evidence supporting it together.

Track dispatch and failures through the chosen channel. A task marked complete is not proof that a reply was sent, and an email open is not reliable proof that it was read. Keep unresolved delivery problems and promised remedies visible after the decision is issued.

5. Follow through and learn from the case

Assign each corrective action an owner and completion record. Preserve later correspondence and reopen disputed work without overwriting the original outcome. Apply the complaint record’s retention rule, with holds where applicable, rather than keeping every identity document or investigation copy indefinitely.

Report on acknowledgment timeliness, investigation age, stalled dependencies, failed responses, reopened complaints, and recurring causes. Use aggregate reporting with limited personal information. A dashboard should help teams resolve work, not simply reward closing cases quickly.

Example: a statement went to an old address

  1. Keep one timeline

    Support receives the concern and forwards it to privacy. The case retains the first received time, records the acknowledgment, and assigns an investigator. An address-correction request is linked to the complaint rather than lost inside it.

  2. Establish the facts

    The investigator connects the address-change request, account history, statement version, and dispatch-provider response. Any possible personal-data breach is referred for its own assessment while the complaint investigation continues.

  3. Answer and complete the remedy

    The approved reply explains the findings and next steps. The case links dispatch evidence and the verified address correction. An overdue processor response or failed delivery remains an open follow-up, with an owner.

Test the handoffs before relying on them

  • Transfer a complaint between teams. Confirm that receipt time, ownership, and acknowledgment tracking remain intact.
  • Test a weekend deadline, public holiday, absent owner, and failed notification. Confirm a visible fallback and escalation.
  • Request evidence from a processor and restrict a sensitive attachment. Confirm that work progresses without broadening access.
  • Fail the final-response delivery and reopen the case. Confirm preserved decisions and accountable follow-up.

Close the complaint with an explained outcome

Keep the original receipt time, responsible owner, investigation evidence, approved reply, and remedy connected through the complaint's lifecycle. Failed delivery and unfinished actions need accountable follow-up so closure reflects the work completed and the response the organisation can explain.

Talk to FormKiQ about an intake-to-outcome workflow that fits the systems and responsibilities already in place.

    Start with FormKiQ Core

    The open-source foundation — API-first, deployable into your own AWS account, and free to use. Right for architecture validation and early implementation.

    Get Started Free

    Deploy FormKiQ Essentials or Advanced

    Production-ready editions for departments and complex workflows. Start with a Proof-of-Value deployment or go straight to production.

    Explore Options

    Plan an Enterprise Rollout

    For governance-heavy environments with residency, sovereignty, assurance, and multi-jurisdiction requirements. Talk to us about the right deployment model.

    Book a Call