# LGPD in internal systems: what to review

> What to review for Brazil's LGPD in internal systems: screens, permissions, reports, exports and logs, with a ready checklist for IT and privacy leads.

Author: José Carlos Maciel, Founder and developer. Published 2026-10-30, updated 2026-10-30.
Source: https://boosting.tech/en/blog/lgpd-in-internal-systems-what-to-review/

**Quick answer:** Reviewing LGPD in an internal system starts with screens, reports and logs. Check who can see each personal field, what leaves the system as PDF or spreadsheet, what the log stores and how long everything is kept. The checklist in this article walks that review screen by screen, with operations and the privacy lead in the same conversation.

Friday, late afternoon. Legal asks IT for a list: which screens show Brazil's individual taxpayer ID (CPF), who can export the visitor spreadsheet and whether the log records views of uploaded documents. Nobody has a ready answer. The system has been running for years, the gatehouse and the review committee use it every day, and the company privacy policy speaks in general principles. What is missing is a map of what the software actually does with personal data.

This article gives you that map as a review. You will see what Brazil's LGPD asks for when the system is internal, why screens, reports and logs concentrate the risk, what belongs in the technical pass and what does not, a ready checklist and a practical sequence. If you are still deciding whether to keep or replace what you have, start with [legacy system modernization](/en/blog/legacy-system-modernization/). If the earlier question is how to buy software, see [custom software vs off-the-shelf](/en/blog/custom-software-vs-off-the-shelf/).

## What is LGPD applied to internal systems?

LGPD applied to internal systems means reading [Law No. 13,709/2018](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm), Brazil's General Data Protection Law, against the software your company uses to operate: gatehouse, scheduling, inspection, scholarship applications, work orders, emergency command. The system processes personal data when it identifies or can identify a natural person, whether employee, contractor, visitor, applicant, patient or passenger.

The law defines processing broadly: collection, storage, use, access, transmission, deletion and other operations on the data. Think of it as Brazil's counterpart to frameworks such as the GDPR, with its own authority, the ANPD (Autoridade Nacional de Proteção de Dados). The [ANPD LGPD guide](https://www.gov.br/anpd/pt-br/centrais-de-conteudo/materiais-educativos-e-publicacoes/guia_lgpd_final.pdf) organizes the concepts for day-to-day application. For an internal system, that means looking past the public website. The risk usually sits on the gatehouse screen, in the field-report PDF and in the log that records who opened an attachment.

Systems we build and maintain put personal data in predictable places. In [industrial access control](/en/case-studies/industrial-access-control/), visitor and contractor records, badges and entry and exit history. In [scholarship management](/en/case-studies/scholarship-management/), household data, income, documents and the trail of review opinions. In both, the product design has to say who sees what and what gets recorded.

## Why do screens, reports and logs concentrate the risk?

Screens, reports and logs concentrate the risk because that is where personal data appears to real people, leaves the database as a file and leaves traces that are also data. A well-designed database rule is not enough if the export ignores the permission filter or if support can open any record with a broad login.

In practice, the issues we see most often in reviews are these:

- The list screen shows more personal columns than a profile that only needs to confirm presence requires.
- The export button builds a full spreadsheet, including other sites or companies.
- Reports go out by email with government ID, phone or address that the purpose does not need.
- The log stores passwords, tokens or the full document content when an event identifier would do.
- Nobody knows how long backups, downloaded spreadsheets or old logs need to exist.
- When a data subject asks for access or correction, the team does not know which tables and attachments to check.

Among other points, the LGPD asks for purpose, necessity, security and accountability. Article 46 of the law calls for technical and administrative measures to protect data from unauthorized access and improper processing. Article 37 asks for records of processing activities. None of that mandates a specific product. It mandates knowing what the system does and being able to show it.

When processing may create high risk for data subjects, the ANPD advises considering a [Data Protection Impact Report (RIPD)](https://www.gov.br/anpd/pt-br/canais_atendimento/agente-de-tratamento/relatorio-de-impacto-a-protecao-de-dados-pessoais-ripd). The report describes data types, security methods and mitigation measures. A review of screens, reports and logs feeds that document with facts from the system instead of generic statements.

## What belongs in the technical review and what stays out?

The technical review covers what the software exposes, stores and exports. Decisions on legal basis, privacy policy and communication with the data subject stay with the controller (the company) and with the privacy lead or legal team. The table keeps the two sides apart so the meeting does not mix code with legal opinion.

| Topic | In the system review | With legal / privacy lead |
| --- | --- | --- |
| Screens | Who sees each field; masking; restricted search | Whether collecting that field has a legal basis and purpose |
| Reports | Permission to generate; columns; where the file goes | Retention of copies outside the system |
| Logs | Events recorded; who can read the log; technical retention | Audit policy and incident response |
| Attachments | Private storage; view logging | Document classification and deletion rules |
| Multi-company | Isolation by company or site | Contracts and controller vs processor roles |
| Data-subject request | Where to find the data and how to export or correct it | Response deadline and official channel with the person |

What usually stays out of the first cycle is rewriting the whole system, rolling out network DLP tools or building the full privacy governance program. Those topics matter, but a pass through screens, exports and logs already closes concrete gaps. In the scholarship case, for example, files sit in private storage and the system records attachment views. In access control, each company sees only its own records and the history stores who approved or denied. Those product decisions support compliance in daily use.

## Which checklist should you use for screens, reports and logs?

The checklist below collects checks we use when we look at an internal system that holds personal data. It works for a system you own, for a legacy product under [support and modernization](/en/services/support-and-modernization/) and for specifying what a new system needs from day one.

### LGPD review checklist for an internal system

Use it with IT, the people who run the system every day and the data protection officer or privacy lead. The checklist is a technical starting point. It does not replace legal advice or the organization's privacy policy. Mark what already exists and note what is missing before you ask for code changes.


**Screens and permissions**

- [ ] Every screen that shows a name, ID document, contact, photo or health data has a defined access profile
- [ ] A user from one company or site cannot see records from another company or site
- [ ] Sensitive fields (government ID, income, health, biometrics) appear only for people who need that function
- [ ] Search results never return people outside the logged-in user's scope
- [ ] There is a way to hide or mask personal data on support and field-operations screens

**Reports and exports**

- [ ] Every report with personal data requires an explicit permission, not only access to the main screen
- [ ] PDF, spreadsheet and CSV exports inherit the same permission filter as the screen
- [ ] Reports sent by email do not carry personal columns beyond what that purpose needs
- [ ] There is a record of who generated or downloaded a report with personal data
- [ ] Downloaded spreadsheets are not treated as a permanent copy without a disposal rule from the company

**Logs and audit trail**

- [ ] The system records login, record changes, approvals, attachment views and deletions
- [ ] Each audit event stores who did it, when and what changed, without storing passwords or tokens
- [ ] Logs that contain personal data have restricted access (security, audit, privacy lead)
- [ ] The log retention period is written down and aligned with security and audit purposes
- [ ] You can find one data subject's history when the company needs to answer a request

**Retention and data-subject response**

- [ ] The purpose of each personal record is described (site access, scholarship, service job, emergency)
- [ ] There is a rule for how long data stays active after the process ends
- [ ] Attachments with identity documents sit in private storage, not in a public folder
- [ ] The company knows which screens and tables to query for access, correction or deletion requests
- [ ] [object Object]

Tick items with the screen open. Ask a user from each profile to try seeing what they should not see. Generate the most used report and check the columns. Open the log and see whether you can audit without exposing more sensitive content than needed. Note failures with a screenshot and the profile used. That package becomes a clear scope for the development team or the vendor.

## How do you put the review into practice?

The review works best in short cycles, starting with the module that holds the most personal data and has the most users.

1. List the modules and the people. Note gatehouse, HR, HSE, review committees, field operations and support. For each, write which personal records they open.
2. Classify the data on the screen. Name and badge are one thing. Government ID (such as CPF), income, identity documents, health data or biometrics need tighter care. Mark what is sensitive under the LGPD and under company policy.
3. Test permissions for real. Sign in as contractor, tenant company, analyst and administrator. Try searching someone from another site. Try exporting.
4. Check reports and automatic emails. Look at the generated PDF, the spreadsheet and any scheduled send. Cut columns that do not serve that report's purpose.
5. Define what the log needs to store. Login, change, approval, attachment view and deletion usually cover audit needs. Avoid storing authentication secrets.
6. Write retention periods with the privacy lead. Separate active process data, historical archives and security logs. Without a written period, nobody deletes safely.
7. Build the data-subject response playbook. Which screens to query, who runs a correction or deletion, how to record the request. The [ANPD FAQ](https://www.gov.br/anpd/pt-br/acesso-a-informacao/perguntas-frequentes) helps align language with what a data subject can ask for.
8. Prioritize code fixes. Isolation between companies, export permissions and attachment-view logging usually come first because they block leaks in normal use.

In field operations, the same criteria apply to the app or the offline form. The report that moves from the field to the office carries the worker's name and sometimes a witness. Treat that flow as part of the system, not as an exception. The article on [automatic service reports](/en/blog/automatic-service-report/) shows the path from field record to PDF; in an LGPD review, the question is which columns and attachments that PDF truly needs.

## What if the system is legacy, multi-company or full of attachments?

The default path changes in three common situations.

When the system is legacy, the review still starts with screens and exports, even if the code is hard to change. Often you can tighten a profile, turn off an export button or drop a report column without rewriting the core. If isolation between companies does not exist in the data model, that becomes an item for modernization in parts, in the same spirit as our [legacy system](/en/blog/legacy-system-modernization/) article.

When several companies share the same database, as in an industrial complex with tenant companies and contractors, isolation by company is a product requirement. Each requester sees only their own visitors and requests. Without that, a shared spreadsheet or a broad login becomes the weak point. The design of [third-party access control](/en/blog/third-party-access-control/) and the [industrial gatehouse case](/en/case-studies/industrial-access-control/) start from that isolation.

When the system stores many attachments (ID cards, proofs, reports, photos), private storage and a record of who opened the file matter as much as the screen. In [scholarship management](/en/case-studies/scholarship-management/), applicants upload household documents and the committee reviews them with a recorded opinion. Protecting the file and logging who viewed the attachment are part of the process, not an infrastructure extra.

Offline areas, parallel spreadsheets and personal email attachments also break the default path. If operations still download the daily list and send it by chat, the system review has to include the process. Otherwise the software looks fine and the leak continues on someone's phone.

## When is this not enough?

A review of screens, reports and logs covers what the system shows and records. It does not replace a formal processing inventory, a legal-basis opinion, contracts with processors, an incident response plan or, when applicable, a RIPD. It also does not fix, on its own, a legacy product with no real access control or a habit of sharing spreadsheets.

At those points, involve the company's privacy lead and legal team. If the system needs isolation between sites, an audit trail or module-by-module modernization, a [custom software company](/en/services/custom-web-systems/) that already maintains systems with personal data can support the technical diagnosis. In [support and modernization](/en/services/support-and-modernization/), the work often starts exactly with permissions, exports and logs.

If you want to talk about the system your operation uses today, we offer a free diagnostic conversation to map where personal data appears and what can be adjusted without inventing legal promises. The talk is technical and fits an IT agenda with the privacy lead in the room.

## Frequently asked questions about LGPD in internal systems

### Does an internal system used only by the company still need to follow the LGPD?

Yes. The LGPD applies to personal-data processing in Brazil, including systems used only by internal staff, when there is data on employees, contractors, visitors, applicants or individual customers. The fact that the system is not a public website does not remove the duty. What changes is the design of the measures: permission, retention, security and records become the core of compliance.

### Do I need a RIPD for every internal system?

Not automatically. The ANPD recommends a RIPD when processing may create high risk for data subjects, and the LGPD sets cases where the authority may require the report. Criteria such as large scale, sensitive data, monitoring of publicly accessible areas or solely automated decisions raise the chance of high risk. A review of screens and logs helps describe the processing accurately for that assessment.

### What should a log store to help with LGPD?

A useful audit and security log usually stores who took the action, when, on which record and whether it succeeded, without storing passwords or the full content of sensitive documents. Attachment views, record changes, approvals and deletions are common events in operations systems. The log retention period should be written and aligned with the security purpose, not endless by omission.

### Does exporting a spreadsheet with CPF to leadership violate the LGPD?

It depends on purpose, necessity and who receives it. If leadership only needs totals, a spreadsheet with every visitor's CPF is excess. If the send is occasional, permissioned, limited to needed columns and paired with a disposal rule for the copy, the risk drops. In the review, the practical point is: the export requires its own permission and leaves a trail of who generated the file.

### How do we answer an access or deletion request when data sits in several modules?

Map beforehand where the data subject appears: records, attachments, generated reports, tickets and backups. The response combines the controller's decision (what can be deleted, what law or contract requires keeping) with technical work in the system. Having the map of screens and tables ready avoids improvising under a deadline. This article's checklist already asks for that playbook as an explicit item.

### Does a team cloud spreadsheet count as an internal system for the review?

For risk, yes. If operations process personal data in a shared spreadsheet, the same questions apply: who accesses it, what gets exported and how long it stays. Many companies start remediation by replacing that spreadsheet with a [custom web system](/en/services/custom-web-systems/) that has login, permission and history. The review works in both scenarios: it shows the gap before you choose the tool.

## References

- [Law No. 13,709/2018: Brazilian General Data Protection Law (LGPD)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm)
- [ANPD: Data Protection Impact Report (RIPD)](https://www.gov.br/anpd/pt-br/canais_atendimento/agente-de-tratamento/relatorio-de-impacto-a-protecao-de-dados-pessoais-ripd)
- [ANPD: Guide to Brazil's General Data Protection Law (LGPD)](https://www.gov.br/anpd/pt-br/centrais-de-conteudo/materiais-educativos-e-publicacoes/guia_lgpd_final.pdf)
- [ANPD: Frequently asked questions about the LGPD](https://www.gov.br/anpd/pt-br/acesso-a-informacao/perguntas-frequentes)