Every company that commissions or builds software processes personal data somewhere: customer records, employee data, access logs. Brazil's General Data Protection Law (LGPD) does not come with a technical checklist. It requires protection to be considered from the design of the product or service through to its operation (Art. 46, § 2). In practice, privacy requirements have to be part of the project scope, not an adjustment made after the system goes live.
This piece is technical guidance from people who build systems, not a legal opinion. Decisions about legal basis, contracts and regulatory risk should go through a lawyer.
Before the code: knowing what data the system will process
No technical requirement makes sense without a data inventory. The law calls it the record of processing operations (Art. 37). In a software project, that survey belongs in the scope document and should answer, for each set of personal data:
- What data is collected (name, tax ID, phone, purchase history);
- What for: the specific purpose, not "to improve customer service";
- Where it lives: which system, database, integration or file;
- Who accesses it: which user roles and which vendors;
- For how long, and what happens afterwards;
- On what legal basis: for example, consent, performance of a contract, legal obligation or legitimate interest.
That survey usually uncovers bigger risks than any legal question: a copy of the production database used in a test environment, an old backup with no access control, an integration that sends more fields than the target system needs.
Consent is not the default legal basis
The most common mistake is assuming everything needs consent. The LGPD provides ten legal bases for personal data (Art. 7), and consent is often the worst choice: the data subject can withdraw it at any time, and then the processing that relies on it has to stop.
For customer data needed to deliver the service, the natural basis is performance of a contract. For issuing invoices and keeping tax records, it is legal obligation. Consent makes sense for what is genuinely optional, such as marketing communications. The choice of basis defines system requirements: processing that relies on consent requires recording when and how it was given and allowing it to be withdrawn.
The technical requirements that belong in the scope
From the perspective of people who build systems, five measures deliver most of the protection. They should appear in the scope as requirements, with acceptance criteria:
- Role-based access. Each user sees only the data they need for their role. It is the most effective measure and the most neglected: everyone having administrator access "because it is more practical" is common;
- Individual authentication and a second factor. A shared login makes any traceability impossible: without knowing who did it, you cannot respond to an incident;
- Access logging. A log of who looked at or changed personal data, with a timestamp. It is what lets you answer "was my data accessed improperly?";
- Encryption in transit and at rest. HTTPS is the baseline; the database and backups must be encrypted as well;
- Tested backups. The LGPD requires protecting data against accidental loss and destruction (Art. 46), and a backup that has never been restored in a test guarantees nothing.
Retention: deletion is a requirement too
It is the part almost every project leaves out. The law requires deleting data once its purpose has ended: keeping everything forever is non-compliance, and it also increases the damage in the event of a breach.
In practice: set a retention period per type of data, respecting statutory record-keeping (tax and employment law have their own periods), and treat deletion or anonymization as a feature of the system. A scheduled purge routine solves what a written policy does not.
Data subject rights: the system has to respond
Data subjects can request confirmation of processing, access, correction, portability and deletion. The system does not need a self-service portal, but it must make it possible to find, export and correct a person's data without querying the database by hand. The full statement must be provided within 15 days (Art. 19), a deadline that is hard to meet when data is scattered across systems that do not talk to each other. Small processing agents have simplified rules under CD/ANPD Resolution No. 2/2022, but a channel for data subjects remains mandatory.
Incidents: the logging comes before the problem
When a security incident may cause relevant risk or harm to data subjects, the company must report it to the ANPD, Brazil's data protection authority, and to the affected data subjects (Art. 48). Without access logs and without knowing what data sits in each system, there is no way to say what was exposed, and the report cannot be made with the precision the law requires.
Vendors: what to require in the contract
Whoever builds or hosts a system holding your customers' data acts as a processor, and your company remains accountable to the data subject. The processor must follow the controller's instructions (Art. 39) and is jointly liable when it breaches the law or those instructions (Art. 42). That is why development and hosting contracts should state clearly where the data is hosted, which security measures are mandatory, how and how quickly an incident is reported, and what happens to the data when the contract ends.
Reviewing these points before signing usually prevents more risk than a code audit carried out afterwards.