Common Mistakes Organizations Make When Responding to Access Requests

The most frequent mistake is answering a Section 11 request with a raw data export rather than the summary the Act actually calls for - a plain description of the personal data processed, the processing activities involved, and the identities of the fiduciaries and processors the data has been shared with. A spreadsheet of database fields, without that context, technically contains information but does not fulfill the right as framed by the Act.

This mistake usually comes from routing the request straight to an engineering team without a compliance-minded translation step in between. The fix is simple in principle: someone with a clear view of the requirement should review the response before it goes out, checking it against what Section 11 actually asks for, not just whether data was included.

A close second is a response that only reflects the primary internal system, missing the vendors, processors, and other fiduciaries that also touched the same data. This happens when the team responding does not have visibility into the full data flow, which is a symptom of not maintaining a current data inventory or vendor register in the first place.

The underlying fix here is not procedural but structural - the organization needs an accurate, current map of where personal data flows before it can answer this part of an access request correctly, and that map needs to be kept up to date as new vendors and integrations are added, not built once and left stale.

Without a shared internal standard, different people handling similar requests produce noticeably different responses - different levels of detail, different formats, different interpretations of what counts as complete. That inconsistency is itself a risk, since it suggests the process is ad hoc rather than genuinely institutionalized.

A short, concrete internal playbook - what a complete response includes, what template to use, who reviews before sending - removes most of that variance without requiring every response to go through lengthy individual legal review.

Some organizations swing too far toward speed and skip meaningful identity verification, risking a data leak to an impersonator. Others swing too far the other way, demanding excessive identity documentation that itself becomes a new privacy concern. Either extreme is a mistake; the goal is proportionate verification matched to the sensitivity of what is being requested.

And finally, many organizations resolve requests correctly but fail to document the process - no record of when it was received, how it was verified, or why a particular response was given. That gap only becomes visible when it is too late, typically during an audit or an escalation, which is exactly when a clean record would have mattered most.

The Rights Request Generator and Checklist Generator together cover most of these gaps - a consistent response template paired with a checklist that confirms verification, scope, and documentation were all handled correctly before the response goes out.