What a data protection complaints register should contain

The register is an index, not the whole case file

The law and ICO guidance require a record of complaints and actions, but they do not prescribe one universal spreadsheet layout. The register should act as a controlled index to the fuller case file rather than copying every sensitive detail into one workbook.

Use a stable case reference and link or point to correspondence, evidence and decision records stored in the organisation’s approved system. Avoid putting unnecessary special category data or lengthy allegations into a widely accessible tracker.

Core intake and ownership fields

The register should preserve the first receipt date and make ownership visible. It should also record the route selected at triage and whether the same message contains a separate data rights request.

• Case reference and current status
• Date and channel of first receipt
• Complainant or representative reference, with authority status where relevant
• Short neutral summary of each complaint point
• Outcome requested by the person
• Assigned owner and alternate owner
• Linked rights-request reference, if applicable
• Communication or accessibility needs

Clock and communication fields

Keep the calculation inputs as well as the result. That makes the deadline reproducible and prevents a later user from seeing only an unexplained date.

• Day one and the 30th calendar day
• UK region and public-holiday data version
• Adjusted acknowledgement deadline and adjustment reason
• Actual acknowledgement date and method
• Dates of material progress updates
• Date and method of the outcome communication

Investigation and decision fields

The record should show the scope of the investigation without turning the register into an unsupported legal conclusion. Use evidence references and a separate decision log for detailed analysis.

• Issues investigated and any issues routed elsewhere
• Evidence references and people consulted
• Material findings and unresolved uncertainty
• Outcome for each complaint point
• Corrective, preventative or follow-up actions
• Action owner, target date and completion evidence
• Reviewer, approval date and closure date

Control access, retention and reporting

Limit register access to people who need it. Define a retention rule that reflects the organisation’s legal, regulatory and operational needs, and record deletion or archive actions where the system requires them.

Aggregate reporting can help identify repeated causes, delayed acknowledgements and overdue corrective actions. Reports should use the minimum information needed and should not expose case narratives or identities unnecessarily.

Keep a blank template and the current case

If a tool promises that facts are entered once, the generated register should include the current case row. A separate blank template sheet can be included for future cases. Delivering only an empty register after collecting the case facts breaks that promise.

The exported register, chronology, correspondence and sources record should use the same case reference and dates. Run a simple cross-file check before the pack is finalised.