Data subject rights are no longer just a legal topic of the LGPD (Brazilian General Data Protection Law) and have become one of the most sensitive points of data protection governance. This became even more evident when the ANPD (Brazilian Data Protection Authority) defined data subject rights as one of its priority enforcement topics for the 2026-2027 biennium. At the same time, the 2025-2026 Regulatory Agenda itself keeps the topic among the central axes of regulatory development.
In practice, this means that organizations must be prepared to respond, consistently and traceably, to requests for confirmation of processing, access, correction, anonymization, blocking, deletion, portability, information on data sharing, review of automated decisions and transparency about consent and legal bases, as provided for in the LGPD. These rights do not depend merely on goodwill or on a form available on the website. They depend on structure, process, governance and evidence.
The most common mistake: treating data subject rights as an isolated routine
Many companies still see handling data subject requests as a one-off activity, concentrated in a privacy channel or in the legal team. But a request for access, correction or deletion is almost never resolved in isolation. It cuts across systems, departments, suppliers, internal policies, retention rules and, often, earlier decisions that were never documented.
This is the point at which data subject rights stop being a front-end obligation (the service channel) and begin to reveal the real level of maturity of data governance (the back end of privacy).
Where it all begins: there is no consistent response without an up-to-date RoPA
When a data subject exercises the right to know which data the company holds about them and with whom they have been shared (Art. 18 of the LGPD), the professional or the DPO who receives the request needs visibility. If the Data Inventory (RoPA, Record of Processing Activities) is outdated, split across disconnected spreadsheets or filled in as a bureaucratic exercise, the response is already failing from the start.
The RoPA is not a static document to be filed away in a drawer. It is the navigation map for any response to data subject rights.
It is through the RoPA that the team should be able to answer quickly:
- In which processes do the data of this type of data subject usually appear?
- Which systems and departments are involved in these processes?
- What is the applicable legal basis (which determines, for example, whether or not a deletion request can be refused)?
- With which suppliers or partners have these data been shared (so that the request, if granted, is extended to them)?
- What is the regulatory retention period (which may also justify refusing deletion)?
Without a structured, dynamic RoPA integrated into operations, every request becomes an investigative project from scratch. And within the tight timeframes of regulation, improvisation almost always results in a missed deadline or an inconsistent response.
The request flow: validation, sequencing and deadlines
Governance of data subject rights requires a clear process or workflow that removes dependence on an analyst's memory and places request handling in a systematic flow.
A good process should include:
- Data Subject Authentication: How can you ensure that the person requesting the information is, in fact, the data subject, without asking for more data for authentication than the purpose itself requires?
- Triage and Classification: Is this a simple access request, a complex objection based on legitimate interest, or a deletion request that conflicts with the company's legal duty to retain data?
- Internal (and External) Escalation: From whom should the DPO request information or operational action (IT, HR, Marketing, suppliers)? How can you ensure that these departments respond on time?
- Response Validation: Is the legal reasoning for rejecting an erasure request (e.g., retention of medical records, limitation period, defense in legal proceedings) sound and documented? Will the data subject be able to understand the response?
- Decision Record: Is evidence of the request, the analysis and the response sent kept on file?
Responding on time does not exhaust the LGPD: it must be clear why we refused and on what correct grounds (or why we granted the request, if the situation called for it).
The critical point: when deletion (erasure) meets compliance
The right to deletion is perhaps the best example of why there is no proper request handling without mature governance.
If the processing of data is based not on consent but on compliance with a legal or regulatory obligation, credit protection, legitimate interest or performance of a contract, the company will often need to justify the impossibility of erasing that data.
This requires:
- Understanding precisely which legal basis supports that process (which must be recorded in the RoPA).
- Knowing for how long the company has the legal duty (or right) to retain that information, even after the end of the service or the user's objection (Retention Schedules linked to the Inventory).
- The technical capacity to carry out only partial deletion, or definitive purging only at the end of that retention period (effective data lifecycle management).
- Blocking mechanisms, in case the data can be kept (due to a regulatory obligation) but should no longer circulate or be accessed by the business in a disproportionate way.
The level of complexity at this point rises dramatically if the schedules and policies are a “lost PDF” rather than a parameter that supports the decision within the flow.
The relationship with Privacy by Design and Data Protection Impact Assessments (DPIA)
If the company has genuinely embedded privacy by design in its systems pipeline, new systems themselves should include ways to easily deactivate, export or review a profile. When this approach is not used, simple deletion processes take months, as IT has to develop the extraction reactively and under pressure, increasing the company's operating costs.
Likewise, when DPIAs are prepared because the use of legitimate interest or a high degree of risk in systematic processing has been identified, one of the main points documented in the assessment is: how does the company intend, if and when requested, to manage the rights applicable in that specific context? With advance planning and documentation by the DPO and governance (in the DPIA), the response arrives faster in day-to-day request handling.
Enforcement and the yardstick of an effective program
By including rights among the topics selected for active enforcement (alongside incidents, the DPO and the public sector), the ANPD's message is not only that data subjects should know how to complain through ombudsman channels. The message turns back, with technical urgency, to companies: this will be their Achilles' heel if there is an infringement or corporate and regulatory unwillingness.
It is unlikely that enforcement will focus first, disproportionately or exclusively, on mature companies over a trivial mistake on an ordinary day if there are no recurring complaints.
Unfortunately for many teams, however, the real difficulty lies in everyday interactions with the data subject, or a former employee, who files a complaint with the ANPD after never receiving a timely response through the company's official website about unwanted data. If the complaint triggers the authority, and the authority requires the company to respond by immediately proving everything and explaining how it avoided the problem and why it retained the data (or worse, if there was not even a record of the request at the entry point), a proceeding begins.
At that stage, the controller will not need to answer “my submit button works”; instead, it will have to demonstrate all of the governance behind the button.
Software bridges the gap where spreadsheets have collapsed
Managing data subject rights without the practical use of software has become an exhausting, slow task, highly prone to oversights.
Mature governance platforms, such as those developed or integrated in this cycle, for example DPO Privacy's software with a “Data Subject Rights Handling” or “Privacy Ombudsman” module, should provide:
- Clean Authentication (Request Portal): Creation or embedding of a secure portal link for the DPO, with formal and secure receipt of all requests directly into the platform, through controlled cryptographic protocols that can be triaged automatically.
- Secure Channel between the DPO and Users: An isolated internal thread, with guarantees, and exchanges without exposing untracked corporate mailboxes (avoiding the dispersion or use of loose, informal “parallel” emails for critical responses and exchanges with demanding data subjects).
- Multi-Task Communication and Dispatch Integrated with the RoPA: A non-negotiable management differentiator (clearly present in DPO Privacy's software). If a customer says they want information involving their logistics access and benefits system (HR data), on the same screen as the data subject's ticket, the DPO or compliance team selects the person responsible with one click in the integrated Inventory table. From there, Risk Management dispatches a task to the health plan provider, the processor and partner, asking it to provide evidence of deleting, reviewing and closing that individual's record, with no spreadsheets on the desk, under a locked deadline, with the platform reporting when deadlines are due and controlling SLAs.
- Evidence Kept under Regulatory Lock: Rather than relying on mere human control, which could accidentally delete defenses already formally exercised.
Conclusion
Guaranteeing, handling, processing and recording requests made by individuals exercising their rights under the LGPD no longer belongs, in Brazil's current advanced framework, to the commercial realm of the traditional and rigid “Contact Us” or customer service desk.
The ANPD now monitors non-compliance with this indicator, because handling rights is the main way of ensuring that abusive processing models are not exploited illegally, without the necessary limits on use or control by the true owner of the data.
