LGPD for SaaS is one of the topics that raises the most questions among founders and product teams: does the law apply to the software itself, the customer using the software, or both? The answer is both, but in different ways, and understanding this distinction is the starting point for any decision regarding data protection on a cloud platform.
A company that develops and markets a SaaS product occupies a unique position in the data processing chain. Depending on how the product was built and who it serves, it may act as the data controller for the data it collects directly from users, the data processor for the data its customers enter into the platform, or both at the same time in different parts of the system. Each of these roles carries different obligations, and confusing them is one of the most common mistakes that leads technology companies to operate out of compliance without realizing it.
Controller, Processor, or Both?
To understand how LGPD applies to SaaS in practice, it helps to start with a concrete example. A customer management platform for small businesses collects the user’s email address and name during registration. In this case, the SaaS company is the data controller, because it decided to collect that data and defined its purpose. When the platform’s customer begins registering their own contacts, suppliers, and sales history, the SaaS company becomes the data processor of that information, since it is processing data whose purpose was defined by the customer, not by the SaaS company.
This distinction matters because the legal obligations of each role are different. The controller is responsible for the legal basis for data collection, the privacy policy, responding to data subject requests, and notifying authorities of incidents. The processor, in turn, must follow the controller’s instructions and adopt appropriate security measures for the data it processes on the controller’s behalf, as detailed in the article about LGPD compliance and the roles of controllers and processors.
The problem is that many SaaS products have never formally mapped which parts of the system correspond to each role, and therefore do not know exactly which obligations they must fulfill at each layer.
What Changes as the Product Grows
Cloud platforms have a characteristic that makes regulatory compliance more complex over time: they grow. New features are added, third-party integrations are enabled, the volume of stored data increases, and each of these changes can alter the platform’s data processing profile without anyone reviewing the legal implications.
For example, an integration with an analytics tool may begin transferring user data to a third party without this being disclosed in the privacy policy. A reporting feature may begin consolidating information from different customers in ways that were not anticipated when users originally signed up. A notification system may start using behavioral data to personalize messages, creating a new processing purpose with no defined legal basis.
Each of these situations represents regulatory exposure that accumulates silently and only becomes visible when someone asks the right questions. Knowing which questions to ask about the company’s data environment before approving new features or integrations is part of what distinguishes a technology company with mature governance from one that discovers problems at the worst possible time.
What the Platform Needs to Have in Place
Regardless of the product’s stage of development, certain elements must be in place for LGPD compliance in a SaaS environment to remain sustainable over time.
Data mapping by feature. Every part of the product that collects, processes, or stores personal data should be documented: what data is processed, for what purpose, under which legal basis, and for how long it is retained. This mapping makes it possible to answer any question from a customer, data subject, or regulator without relying on the memory of whoever built the system.
Data Processing Agreements (DPAs) with customers. When the SaaS company acts as the processor of its customers’ data, it must have a contract formalizing that relationship, establishing security obligations, processing limitations, and incident response procedures. This document, known as a Data Processing Agreement (DPA), is required by corporate customers and by regulations such as Brazil’s LGPD and the European GDPR.
A privacy policy that reflects the actual product. One of the most frequently overlooked issues in technology companies is having a privacy policy that no longer matches the current product. If the platform has evolved but the document has not, the company is telling users that it processes data in a way that no longer reflects reality, which constitutes a violation regardless of any other factor.
Access controls for customer data. Who within the company can access the data customers store on the platform? For what purpose, and with what level of accountability? SaaS environments often give support and engineering teams broad access to databases to troubleshoot issues, but that access must be controlled, auditable, and limited to what is necessary. An information security policy specifically covering access to production data is what formally establishes these rules internally.
A procedure for handling data subject requests. End users of the platform have the right to request access to their own data, corrections, portability, and deletion. Whether acting as a controller or processor, the SaaS company must have a defined process for receiving and responding to these requests within the legal deadlines. This includes knowing how to technically export a specific user’s data, anonymize it, and completely delete it from all environments, including backups.
What Corporate Customers Are Beginning to Require
As mid-sized and large companies mature their privacy practices, they increasingly include compliance requirements in their technology vendor procurement processes. A SaaS platform that cannot answer basic questions about how it handles user data, does not have a DPA available, or has never undergone a security audit begins losing business to competitors that have already addressed these issues.
In this context, LGPD compliance for SaaS becomes more than just a legal obligation—it also becomes a commercial qualification criterion. While the penalties established by law represent regulatory risk, losing contracts with customers that require mature privacy practices is the immediate cost that most technology companies experience long before any regulatory enforcement action.
Where to Start
For products that do not yet have this process in place, the most productive starting point is data mapping: reviewing every product feature and documenting what is collected, where it is stored, who has access to it, and for what purpose. This exercise often reveals unnecessary data collection, undocumented integrations, and broader-than-necessary access permissions, and each of these issues has a well-known technical solution when identified early.
What does not have a simple solution is discovering these problems after a corporate customer has asked the questions, after a user has filed a complaint with the ANPD, or after an incident has exposed what was improperly configured.
STWBrasil supports technology companies in achieving LGPD compliance, from initial data mapping to the development of contracts, policies, and technical controls that maintain compliance as the product continues to grow.
