An access request catches many SMEs unprepared: an email lands in support, nobody knows who is responsible, the deadline runs and the data sits in a dozen systems. Yet handling can be organised reliably with a simple process. This article describes it for companies subject to the Swiss FADP, the GDPR or both.
The rights involved
Data subjects can request access to their data, have incorrect data rectified, under certain conditions request erasure or restriction, object to processing and obtain their data in a common electronic format. The rights are structured similarly in the revised FADP and the GDPR but differ in detail; the glossary entry on data subject rights gives an overview.
The deadlines
Under the GDPR the response is due within one month; for complex or numerous requests the deadline can be extended by two months if the person is informed within the first month. Under Swiss law access must in principle be provided within 30 days; where that is not possible, the person is told by when it will be provided. Both frameworks provide that access is usually free of charge.
The workflow
- Centralise intake: a fixed address or form for data protection requests, and a rule that requests arriving through other channels are forwarded immediately.
- Record: date received, type of request, deadline and owner in a simple register.
- Verify identity: appropriately and proportionately — someone writing from the known email address usually needs no ID; sensitive data or doubts require more.
- Search for data: in every system named in the record of processing activities, including email, support tools, backups and processors.
- Check exceptions: statutory retention duties, third-party rights, business secrets.
- Respond: clearly, completely and in the form the law requires.
- Document: what was requested, what was delivered, what was refused and why.
What an access response must contain
Besides the data itself, it includes the information the privacy notice contains, applied to the specific person: purpose of processing, recipients, retention period, source of the data where not collected from the person, and where applicable the existence of automated individual decisions. Those deriving their privacy notice from the record of processing already have this information.
Erasure and its limits
An erasure request does not mean everything must be deleted. Data that must be retained by law, such as accounting records, stays stored but is blocked for other purposes. What matters is explaining to the person what was deleted, what was not and why. In SaaS products, deletion across all systems — database, storage, analytics tools, email delivery — belongs in the architecture from the start.
Data portability
The right to data portability requires the data in a common electronic format. For SaaS providers, a clean export that customers can trigger themselves is the most efficient solution: it meets the request without manual work and is also a trust signal for business customers.
As a processor
SaaS providers processing data on behalf of their customers usually do not answer end-user requests themselves but forward them to the customer and support the response. That belongs in the data processing agreement and in a clear internal process.
Common mistakes
- Requests get lost in the support inbox until the deadline has passed.
- The search is limited to the main database and misses email, support tools and processors.
- Identity checks demand disproportionate documentation.
- Refusals are neither reasoned nor documented.
We support building such processes through our revised FADP implementation for SMEs; for the emergency of a data breach there is the data breach playbook.