Protocol for handling data subject requests and complaints

What a data subject can ask for

• To know what data the company holds about them, where it came from and what it is used for.
• To have information updated or corrected where it is incomplete, out of date or wrong.
• To request deletion where no legal or contractual duty to keep the data exists.
• To withdraw the authorisation given, entirely or for particular purposes.
• To be shown proof of the authorisation the company says it holds.
• To complain to the Superintendence of Industry and Commerce if no answer arrives or the answer does not satisfy them.

Queries and complaints are different routes

A query seeks information: what do you hold about me. A complaint seeks a correction: this is wrong, fix it. Each has its own deadline, counted in business days, and its own limited extension, which only works if the person is told before the original period runs out. In practice the problem is rarely legal; it is traceability. The request landed in an inbox nobody checks, or it was answered by phone and no record of anything survived.

That is why the design starts with the channel: a single one, published in the policy and the notice, with acknowledgement of receipt, a fixed date and a named owner. Everything else is built on top of that.

Hard cases are settled beforehand, not mid-deadline

A useful protocol does not restate the statute: it answers in writing the questions that make the team hesitate while the clock is already running.

• Deletion that does not apply. Where a legal retention duty, a live contract or an outstanding obligation exists, and how that is explained without denying the right.
• Partial withdrawal. Opting out of marketing is not the same as erasing a purchase history or terminating the contract.
• Who is asking. Identity verification, requests made by attorneys, by relatives or by third parties without standing.
• How it arrives. Requests coming in through social media, through a salesperson or in a public review, which start the clock all the same.
• Data held by a provider. How correction or deletion is actually executed when the information sits in a third party system.
• Former employees and candidates. Requests about CVs, recruitment processes and personnel files.
• Credit bureau reporting. Governed by its own regime and handled through a separate route that we identify.

How we set it up

1. We review where requests are arriving today and what has been answered so far.
2. We define the single channel, the acknowledgement of receipt and how each request gets a fixed date.
3. We write the decision tree: what kind of request it is, which team must act and what answer is due.
4. We draft response templates for the frequent scenarios, including reasoned refusals.
5. We set the escalation rules: which cases go to a lawyer and which do not.
6. We train the team that will apply it and run a test with the company's own real cases.

What the client receives

• The written procedure for handling queries and complaints, with owners and internal deadlines that fall before the legal ones.
• Drafted response templates, including the cases where the request is refused and the reasons have to be given.
• A traceability log recording each request, its date and its outcome.
• Escalation rules and criteria for deciding when deletion applies and when it does not.
• Training for the customer service or HR team that will run it.

Typical situations we handle

• A company that has already received a complaint before the Superintendence for answering late.
• A business with many customers and no internal route for requests arriving by chat or social media.
• An HR team receiving requests from former employees about their information.
• A company receiving deletion requests from customers with outstanding obligations and unsure what to answer.