How to answer
How do you handle data subject access, deletion and portability requests?
Usually answered from the wrong seat. As a processor you are not meeting these requests, you are helping the controller meet theirs, and saying which one you are is most of the answer.
As a processor we do not respond to data subject requests directly. We assist the controller in meeting them within the statutory period, providing export, correction and deletion of a named individual's personal data across production and backups on request. The commitment is in clause [n] of our DPA.
Square brackets are yours to fill in. FillTrust grades an answer like this confirmed in your documents when your documents support it.
- Answered from
- Your DPA and your privacy notice, which should already commit to this. The operational half comes from whatever runbook the person who handles the request actually follows.
- Evidence to attach
- The clause in the DPA, and the documented process if a reviewer presses.
- Where it is asked
- CAIQ v4.0 · DSP-11SIG LiteBespoke vendor questionnaires
The question is asked in one line and contains a distinction that decides the whole answer: whether you are the controller or the processor. Get that wrong and every sentence afterwards is confidently answering somebody else's obligation.
Establish which seat you are in, in the first sentence. For most B2B SaaS, the customer is the controller and you are the processor. Their end users' requests go to them. Your commitment is to assist: to find, export, correct or delete a named individual's data when the controller asks, quickly enough for them to meet the deadline running against them. That is a smaller promise than "we handle data subject requests" and it is the true one, so it is also the one you can keep.
Say what the assistance concretely is. Whether it is self-service in the product or a support request, what identifiers you need to locate a person, and what comes back. A reviewer is trying to work out whether honouring an erasure request against your system takes them ten minutes or a fortnight of email, because that answer becomes their problem the moment they sign.
Backups are where honest answers separate from tidy ones. Personal data in an immutable backup usually cannot be surgically erased, and pretending otherwise is worse than explaining it. The accepted approach is to state that production data is deleted immediately, that backups age out on a stated retention cycle, and that restored data is re-processed against outstanding erasures. Say the retention window. A reviewer who works in privacy is specifically checking whether you have thought about this, and "deleted everywhere immediately" from a company that keeps thirty-five days of backups tells them you have not.
Keep the deletion answer aligned with the retention one. The data retention row, the DPA and this answer all state how long data survives, and they are frequently three different numbers written by three different people. That contradiction is easy for a reviewer to spot and hard for you to explain.
If you have never received one, say that, and describe the process you would follow rather than implying volume you do not have. "No requests to date; the process is documented at [x] and the commitment is in our DPA" is complete, and it is better than a vague claim of routine handling.
How this one goes wrong
Specific to this question, not general advice.
- Answering as though you were the controller. If you process on a customer's behalf, the request comes to them and your obligation is to assist, which is a different and much more answerable commitment.
- Promising deletion you cannot perform in backups. Restoring a backup that predates an erasure quietly reinstates the record, and this is the detail a reviewer with privacy experience asks about.
- Committing to a turnaround you have never tested. The statutory clock runs against the controller, so your assistance has to be fast enough for them to meet it, not merely fast enough to feel reasonable.