Data protection complaints log template
Your complaints log is the evidence that you met section 164A. Record one row per complaint, always with the date received and the date acknowledged, and keep it in a form you can count.
Why the log is the compliance artefact
Section 164A does not require a log in terms. In practice it is the only way to show you complied. Every duty in the section is time-based, and time can only be evidenced by a dated record. If the ICO asks what happened with a complaint from last October, the log is your answer.
The fields to record
| Field | Why it matters |
|---|---|
| Reference | Lets both sides track the complaint without using names in subject lines |
| Date received | Starts the 30-day clock under section 164A(3). Use the date it reached the organisation |
| Channel received | Shows which routes are live and where the gaps are |
| Complainant name and contact | Needed to acknowledge, update and inform the outcome |
| Relationship | Customer, employee, applicant, supplier, other. Shapes the investigation |
| Summary in the complainant's words | Prevents drift between what they said and what you investigated |
| Category | Marketing, retention, accuracy, access, security, sharing. Makes patterns and future counts possible |
| Date acknowledged | Proves compliance with section 164A(3) |
| How acknowledged | Automated or manual, and by which channel |
| Handler | One named person, so the file never sits unowned |
| Enquiries made and dates | Evidence of appropriate steps under section 164A(5) |
| Updates sent and dates | Evidence of keeping the complainant informed |
| Target response date | Your own internal target, and any revision to it |
| Outcome | Upheld, partly upheld, not upheld, withdrawn |
| Date outcome sent | Evidence you informed the complainant under section 164A(4) |
| Action taken | Deletion, correction, retraining, process change, apology |
| Escalated to ICO | Yes or no, and the date, so you can see escalation patterns |
| Closed date and retention date | Keeps the log clean and defensible |
Spreadsheet column headings
Ref | Date received | Channel | Complainant name | Contact | Relationship | Summary (their words) | Category | Date acknowledged | How acknowledged | Handler | Enquiries made (with dates) | Updates sent (with dates) | Target response date | Outcome | Date outcome sent | Action taken | Escalated to ICO | Closed date | Delete by
Counting, and section 164B
Section 164B lets the Secretary of State require controllers to report how many complaints they receive. No regulations are in force, so there is no return to file today. Consistent categories and one row per complaint mean that if a return is ever required it is a filter and a total rather than a hunt through inboxes. See section 164B reporting.
Keeping the log lawfully
- The log is itself personal data. Restrict access to the people who need it.
- Set a retention period, state it in your policy, and delete on schedule.
- Keep special category detail out of the summary field unless it is essential to the complaint.
- Do not store the log where departing staff take it with them.
If keeping this by hand looks fragile, that is because it is. A purpose-built system that timestamps receipt, sends the acknowledgement and keeps a section 164A complaints log removes the failure modes above.
Prove you met the duty, not just that you meant to
The work in section 164A is operational: spotting the complaint, dating it, acknowledging it within 30 days, keeping the person informed and recording the outcome. PrivacyComplaints does that part for small organisations.