Section 164A — Data protection complaints: full annotated text

Reading

"Facilitate" is an active obligation — stronger than "accept" or "not obstruct." The controller must make it possible for a data subject to submit a complaint, which means providing a named, accessible mechanism for doing so. A generic contact form, or a page that says "email us if you have any concerns," does not satisfy this provision. The facility must be identifiable as a data-protection complaints channel. [4]

The "where requested" framing is important: the duty is demand-triggered. It activates when a data subject presents a data-protection complaint to the controller — it does not require the controller to proactively invite complaints. But once activated, it imposes a complete handling obligation, not merely a duty to accept the complaint.

Practical implication

Every UK data controller must operate a functioning, publicly accessible data-protection complaints process. This means a dedicated intake mechanism — a hosted form, a widget, or an email address specifically designated for data-protection complaints — communicated to data subjects. The ICO's guidance [4] is explicit that the mechanism must be easy to find: buried in a privacy policy is not sufficient.

Reading

The statute says "one month" — not 30 days. One calendar month runs from the date of receipt to the same date in the following month. A complaint received on 15 March must be acknowledged by 15 April (31 days). A complaint received on 28 January must be acknowledged by 28 February (31 or 29 days depending on the year). In practice, treating the deadline as 30 days provides a conservative working margin that is shorter than the statutory period for most months.

"Acknowledge receipt" means more than an auto-responder. The ICO's guidance [4] treats an acknowledgement as a substantive communication confirming that a data-protection complaint has been received and is being handled — not a generic "thank you for contacting us" message.

The clock starts from receipt by the organisation, not from when the complaint reaches the data protection team. If a customer emails a support address complaining about data handling, the one-month period begins on the date of that email.

Practical implication

Controllers need a system that timestamps complaints at intake and tracks the acknowledgement deadline automatically. Manual diary entries are not sufficient — they depend on someone noticing, counting, and chasing. Without a tamper-proof timestamp at intake, controllers cannot prove to the ICO when the complaint was received, and therefore cannot prove the acknowledgement was timely.

Reading

Unlike the acknowledgement, the outcome communication is governed by a "reasonable time" standard — not a fixed deadline. "Reasonable" is context-dependent: the complexity of the complaint, the number of systems involved, and the nature of the alleged infringement all bear on what is reasonable. The ICO's guidance [4] indicates that most complaints should be resolved within a few weeks of acknowledgement; anything approaching three to six months should be the outer boundary for complex cases.

"Outcome" means a substantive conclusion — not a promise to investigate. The controller must communicate what it found, and what, if anything, it is doing in response. A complaint that a controller has informally resolved without a written outcome is still a compliance gap. The outcome must be documented and communicated.

Practical implication

Every complaint must be formally closed with a written outcome. Controllers should build an outcome-communication step into their complaint-handling workflow, not treat it as optional. Any complaint that has been acknowledged but not formally closed is an open liability — both because it has not met the s.164A(2)(b) obligation and because open complaints are highly visible in an ICO investigation.

Reading

Data subjects cannot be charged for submitting a complaint, for the investigation of that complaint, or for receipt of the outcome. This applies regardless of volume or frequency: even where a data subject is a serial complainant, the controller cannot impose a per-complaint charge. This mirrors the broader GDPR principle (UK GDPR Art.12(5)) that the exercise of data-subject rights must generally be free of charge.

The only narrow exception in the broader GDPR framework — charging for manifestly unfounded or excessive requests — applies to DSAR requests under Art.15, not to complaints under s.164A. The complaint-handling duty in s.164A(3) is absolute on fees.

Practical implication

Any terms and conditions, policies, or onboarding documents that purport to charge for handling personal-data complaints must be removed. Charging for complaint handling is not a defence against a poorly resourced compliance function — it is itself a breach of s.164A(3).