Quick Answer: What is an LGPD data map?
An LGPD data map is a practical inventory and flow model showing which personal data a business processes, whose data it is, where it comes from, which systems hold it, why it is used, which legal basis supports each purpose, who receives it, where it goes internationally, how long it is kept, how it is protected and how data-subject rights can be executed. The LGPD does not expressly require a document literally named “data map.” However, Article 37 requires controllers and operators to maintain records of the processing operations they perform, especially when based on legitimate interest. A strong data map is the operational foundation for those records and for many other LGPD duties.
Key Takeaways
- The LGPD requires processing records, not a specific diagram called a “data map.” Article 37 is the statutory anchor.
- Data mapping is discovery; ROPA is structured documentation. A data map should feed the processing record rather than be confused with it.
- Start with business processes and systems, not only databases. Personal data can exist in SaaS tools, spreadsheets, email, exports, logs, backups and vendor environments.
- Map purposes before legal bases. A legal basis cannot be selected intelligently until the specific processing purpose is understood.
- Map recipients and countries. Vendors, subprocessors, remote access and foreign hosting can create separate transfer obligations.
- Map rights and retention. If you cannot locate a person's data or explain why it is still retained, the inventory is incomplete.
- The map is a living governance asset. New vendors, products, AI features, countries and purposes should trigger updates.
Why Data Mapping Is the Foundation of LGPD Compliance
The LGPD is built around processing operations. Article 5 defines “processing” broadly—collection, production, reception, classification, use, access, reproduction, transmission, distribution, processing, archiving, storage, deletion, evaluation or control, modification, communication, transfer, dissemination and extraction can all be processing.
That means the compliance question is not simply “what customer database do we have?” It is “what happens to personal data throughout its lifecycle?”
The lifecycle you are trying to discover
Collect → Receive → Validate → Store → Use → Analyze → Share → Transfer → Archive → Retrieve → Correct → Delete / Anonymize
A company that skips this discovery stage will usually struggle later with legal bases, privacy notices, vendor contracts, incident response, rights requests, retention and international transfers.
Article 6 reinforces the reason. The LGPD principles include purpose, adequacy, necessity, transparency, security, prevention and accountability. A company cannot demonstrate those principles for processing it has never identified.
Article 37 says controllers and operators must maintain records of the personal-data processing operations they carry out, especially when processing is based on legitimate interest. Article 50 further connects privacy governance with the nature, scope, purpose, risks, internal supervision, incident response, continuous monitoring and periodic assessment of processing.
LGPD Data Map vs ROPA: Are They the Same Thing?
They are closely related, but treating them as identical can create confusion.
Finds systems, flows, fields, people, vendors, countries, hidden copies and actual operational behavior.
Structures the processing operations into an accountable register aligned to Article 37.
Uses the map and ROPA to drive legal bases, notices, vendors, retention, rights, security, incidents and assessments.
Think of the data map as the investigation and the ROPA as one of the formal outputs. A company can have an attractive spreadsheet called “ROPA” and still miss critical processing if the discovery process was weak.
What Should an LGPD Data Map Contain?
A practical map should capture enough information to answer downstream compliance questions without becoming unusably complex.
| Field | What to record | Why it matters |
|---|---|---|
| Business process | Sales, recruiting, payroll, support, marketing, fraud, product analytics, etc. | Connects data to the real operation. |
| System / asset | CRM, ERP, SaaS, app, database, spreadsheet, email inbox, log store, cloud bucket. | Shows where data actually exists. |
| Data subjects | Customers, leads, users, employees, applicants, children, suppliers, visitors. | Supports rights, risk and transparency. |
| Data categories | Contact, account, financial, device, behavioral, sensitive, biometric, health, location. | Drives risk and legal-basis analysis. |
| Source | Direct from person, customer organization, public source, partner, vendor, device, inference. | Supports expectations and transparency. |
| Purpose | Specific operational reason for processing. | The purpose is the center of the legal analysis. |
| Legal basis | Applicable Article 7 or Article 11 basis after analysis. | Shows why the processing is legally permitted. |
| Role | Controller, operator or different roles by purpose. | Determines instructions and responsibilities. |
| Recipients / vendors | Internal teams, processors, controllers, agencies, platforms, subprocessors. | Supports sharing and vendor governance. |
| Location | Brazil and foreign hosting/support/access locations. | Feeds international-transfer analysis. |
| Transfer mechanism | Applicable Article 33 route where relevant. | Documents cross-border legality. |
| Retention | Duration, trigger and deletion/anonymization rule. | Supports Articles 15–16 and necessity. |
| Security | Access controls, encryption, logging, backups and other relevant safeguards. | Feeds Article 46 and risk review. |
| Rights search key | Email, account ID, employee ID, ticket ID or other identifier used to find a person's records. | Makes Article 18 requests executable. |
| Automated decisions / profiling | Scoring, recommendation, fraud, credit, eligibility, segmentation. | Flags Article 20 and higher-risk processing. |
| Owner | Business and technical owner. | Creates accountability for updates. |
| Risk / notes | High-volume, sensitive data, children, new tech, monitoring, unresolved gaps. | Feeds RIPD and remediation priorities. |
How to Build an LGPD Data Map: 12-Step Method
Define the Scope
Decide whether the first mapping exercise covers the whole organization, one product, one country flow or one high-risk process. Smaller companies can often map the whole business. Larger organizations may need to map in waves.
Define entities, products, business units and systems that are in scope. For a global company, identify which Brazilian-facing products or operations are relevant under Article 3.
Build the System Inventory
Start with systems because people often forget abstract “processing activities” but can name the tools they use every day.
Inventory production databases, CRM, ERP, HR, payroll, ecommerce, analytics, support, marketing automation, spreadsheets, shared drives, cloud storage, data warehouses, mobile apps, websites, AI tools, log systems and third-party SaaS.
Interview the People Who Operate the Process
Policies describe intended behavior. Interviews reveal actual behavior. Talk to sales, marketing, support, HR, finance, product, engineering, security, legal/privacy and procurement.
Ask practical questions: What data do you receive? From whom? Where do you put it? Who can access it? What do you export? Which vendors receive it? When do you delete it?
Identify Data Subjects and Data Categories
Do not record only “customer data.” Break it down enough to understand risk and purpose: contact information, credentials, purchase history, device identifiers, behavioral events, employment data, financial information, sensitive data, health data, biometrics and children-related data where applicable.
Article 5 defines sensitive data separately, so the distinction between ordinary and sensitive personal data matters.
Trace the Data From Source to Deletion
Follow the data through the entire lifecycle rather than documenting one system at a time. A lead may begin in a web form, enter CRM, move into email automation, reach a sales spreadsheet, be synced to an ad platform and then remain in backups after the CRM record is deleted.
Define the Purpose Before the Legal Basis
“Customer management” is usually too broad. Split the purpose into specific activities: fulfill an order, provide support, send a renewal notice, prevent fraud, measure product performance, send promotional offers or maintain tax records.
Only after the purpose is clear should the company assign an Article 7 or Article 11 legal basis.
Map Controllers, Operators, Vendors and Subprocessors
For every external party, record what it receives, why it receives it and what role it performs. ANPD guidance emphasizes that controller/operator status depends on the real processing operation, not merely the contract label.
Include cloud providers, analytics, CRM, payroll, payment, email, agencies, AI tools, support platforms, security vendors and downstream subprocessors where relevant.
Map International Transfers
Identify destination countries, exporters/importers, foreign hosting, overseas support access and downstream vendors. Resolution 19/2024 states that an international transfer within its scope must be supported by both an applicable LGPD legal basis and a valid transfer mechanism.
Attach Retention and Deletion Rules
Articles 15 and 16 connect the end of processing with purpose, necessity, expiration, withdrawal and legal retention exceptions. Your data map should therefore show more than “we keep data as long as necessary.”
Record the actual trigger: seven years after invoice date, 90 days after account closure, active employment plus statutory retention, or another defined rule supported by a legal or business rationale.
Map Data-Subject Rights Execution
Article 18 gives individuals rights including confirmation, access, correction and several forms of deletion, blocking or anonymization. A data map should show how the company can actually find a person's records.
Record the identifiers needed to search each system and which vendor or team must act when a request arrives.
Connect Security and Privacy Risk
Article 46 requires technical and administrative security measures, and Article 50 encourages governance proportionate to the nature, scope, scale, sensitivity and risks of processing.
Add a lightweight risk field to the map: sensitive data, children, large scale, monitoring, credentials, financial data, profiling, AI, international access, critical vendor or unresolved security issue.
Validate, Normalize and Convert the Map Into Governance Records
Remove duplicates, standardize data categories and system names, challenge vague purposes, assign owners and resolve obvious contradictions.
Then use the cleaned data map to populate the Article 37 processing record, privacy notice, vendor register, transfer register, retention schedule, rights procedures and remediation backlog.
Example: Data Map for a U.S. SaaS Company Serving Brazil
| Processing | Data & system | Purpose / basis | Recipients / transfer | Retention / rights |
|---|---|---|---|---|
| Create account | Name, business email, account ID in app database. | Provide requested SaaS service; contract analysis. | Cloud infrastructure; foreign processing mapped under Article 33. | Account lifecycle + documented post-closure rule; searchable by email/account ID. |
| Security logs | IP, login events, device/session data in SIEM/log platform. | Security/fraud; legitimate-interest assessment for ordinary data where appropriate. | Security vendor and cloud/log subprocessors. | Short risk-based retention; access restricted to security team. |
| Support | Ticket, customer messages, attachments in helpdesk SaaS. | Provide support; contract/service purpose. | Helpdesk vendor and its subprocessors. | Ticket retention + ability to export/correct/delete where applicable. |
| Newsletter | Email, preference and campaign history in marketing platform. | Consent or documented legitimate-interest analysis depending on context. | Email/marketing vendor outside Brazil. | Preference and suppression controls; search by email. |
| Product analytics | Account/user event data in analytics platform. | Product measurement; legal-basis and minimization analysis. | Analytics vendor; potential international transfer. | Defined event retention; deletion linkage where technically applicable. |
Notice that the map does not say only “we use AWS, HubSpot and Zendesk.” It connects each system to a purpose, subject, legal basis, recipient, transfer, retention rule and rights workflow.
Why the Data Map Matters for Rights and Retention
Article 18 allows individuals to request confirmation, access, correction and several other actions. Article 19 says personal data should be stored in a format that favors the exercise of access rights.
That creates a very practical mapping question: if a Brazilian customer gives you their email address, can you find every relevant record across CRM, support, marketing, product, billing and vendors?
The same is true for retention. Articles 15–16 say processing ends in circumstances including fulfillment of the purpose, loss of necessity, expiration of the processing period, withdrawal where applicable or an ANPD determination; retention is permitted only for specified purposes after termination.
Why International Transfers Belong in the Map
A company cannot review Article 33 from a vendor list alone. It needs to understand the actual path of the data.
Resolution 19/2024 says international transfers covered by the regulation must comply with the LGPD and be supported by an applicable legal basis and a valid transfer mechanism. The regulation also requires the controller to publish accessible information about international transfers, including purpose, destination country, controller identification, shared use, responsibilities, security measures and data-subject rights.
Your map should therefore identify:
- where the data originates;
- which entity exports it;
- which entity or system receives it abroad;
- the destination country;
- the business purpose;
- the Article 7/11 legal basis;
- the Article 33 transfer mechanism; and
- downstream transfers or remote access that materially change the chain.
See LGPD International Data Transfers.
Use the Data Map to Prioritize Security and RIPD Work
Article 46 requires agents to adopt technical and administrative measures capable of protecting personal data, and says security should be considered from the design stage of the product or service through execution.
A map can become a security prioritization tool by flagging systems that combine higher-risk characteristics:
- sensitive personal data;
- children or vulnerable groups;
- large volumes;
- credentials or authentication data;
- financial information;
- continuous monitoring;
- profiling or automated decisions;
- international exposure;
- many subprocessors; or
- high business criticality.
Article 38 allows ANPD to require a Data Protection Impact Report, and Article 10 specifically allows ANPD to request one for processing based on legitimate interest. A well-built map makes that deeper assessment much easier because the organization already understands the processing inputs, purposes, systems, recipients and risks.
Common Data-Mapping Mistakes
“We mapped our databases.”
Databases are only one storage layer. Email inboxes, cloud SaaS, exports, logs, shared drives, backup systems and vendor platforms can all contain personal data.
“We asked IT to do the map.”
IT understands systems, but business teams define many purposes and workflows. Good mapping requires business, technical and privacy/legal input.
“Every field in the CRM has the same purpose.”
One system can support contract fulfillment, marketing, fraud, support and legal retention at the same time. Map purposes at the processing-operation level.
“Vendor country = server country.”
A vendor headquartered in one country can host, support or subprocess data in several others. Map the actual processing chain.
“Retention = indefinite because we may need it someday.”
That conflicts with purpose and necessity logic. Define actual retention triggers and lawful reasons for preservation.
“The map is finished once.”
Products, vendors, AI tools, countries and purposes change. A static data map becomes inaccurate quickly.
How to Keep the Data Map Current
The LGPD does not prescribe one universal interval for refreshing a document called a data map. Article 50, however, points privacy governance toward continuous monitoring and periodic assessment.
A practical change-trigger model updates the map when:
A Practical Data-Mapping Workshop Agenda
For a small or mid-size business, a focused workshop can accelerate the first map. Invite representatives from business, IT/security, privacy/legal and operations.
| Session | Goal | Output |
|---|---|---|
| 1. Scope & systems | Agree entities, products, processes and tools. | System inventory. |
| 2. Data & subjects | Identify who and what data flows through each process. | Data taxonomy. |
| 3. Purpose & basis | Separate processing purposes and start legal-basis decisions. | Purpose/basis matrix. |
| 4. Vendors & transfers | Map third parties, countries and remote access. | Recipient/transfer map. |
| 5. Retention & rights | Define lifecycle and search/action paths. | Retention and rights workflow. |
| 6. Risk & actions | Flag high-risk processing and missing evidence. | Remediation backlog. |
Build the Map With a Structured Worksheet
The Brazil LGPD Compliance Playbook — 2026 Edition includes a dedicated Data Mapping Worksheet and Processing Inventory / ROPA, plus a Legal-Basis Decision Record, Vendor Privacy and Security Review, International Transfer Review, Retention Schedule, Data-Subject Request tools, Security Incident Assessment, 100-point compliance audit and 30-day implementation roadmap.
Frequently Asked Questions
Does the LGPD require a data map?
The LGPD does not expressly require a document literally named “data map.” Article 37 requires controllers and operators to maintain records of processing operations, especially when based on legitimate interest. A data map is a practical discovery and governance tool that helps create and maintain those records.
What should an LGPD data map contain?
A useful map can include business process, system, data subjects, data categories, source, purpose, legal basis, role, recipients, vendors, subprocessors, locations, international transfers, retention, security, rights-search paths, profiling/automated decisions, risk and owner.
Is a data map the same as a ROPA?
Not necessarily. Data mapping is the discovery and tracing process. The Article 37 processing record or ROPA is a structured register of processing operations. The map should feed the ROPA, but the two should not be automatically treated as identical.
Should vendors be included in the data map?
Yes. Record which vendors receive or access personal data, what they do, their role, subprocessors where relevant, security dependencies and any international-processing locations.
Should international transfers be included?
Yes. Map exporter, importer, destination, purpose, underlying Article 7/11 legal basis and the applicable Article 33 transfer mechanism.
Should retention periods be part of the map?
Yes. A useful map records the retention duration or trigger and connects it to the processing purpose, legal obligations and deletion/anonymization process.
Can we build an LGPD data map in a spreadsheet?
Yes. The LGPD does not prescribe one technology for a data map. A well-designed spreadsheet can work for many organizations if it is controlled, consistent, owned and updated. Larger organizations may later move to dedicated privacy-management tooling.
Who should own the data map?
Privacy or the encarregado can coordinate it, but operational ownership should be distributed. Business and technical owners should validate the processing they control because no single privacy team sees every operational detail.
How often should the map be updated?
There is no universal statutory update interval for a document called a data map. Update it when material changes occur and perform periodic reviews. Article 50 supports privacy governance based on continuous monitoring and periodic assessment.
Can a data map help with data-subject requests?
Yes. Mapping systems, identifiers, vendors and owners makes it much easier to locate, export, correct, block or delete relevant records when a valid request is received.
Official Sources Used for This Guide
- Law No. 13,709/2018 — LGPD, current compiled text Primary source for definitions, Article 6 principles, Articles 15–20 rights/lifecycle, Articles 33–37 transfers and processing records, Articles 38–39 accountability, Article 46 security and Article 50 governance.
- ANPD — Guide to Controllers, Operators and the Encarregado, Version 2.0 Official guidance used for practical role analysis across processing operations and complex vendor chains.
- ANPD Resolution CD/ANPD No. 19/2024 — International Data Transfers Current regulation used for transfer characterization, underlying legal basis, Article 33 mechanisms and transparency requirements.
- ANPD — Educational Materials and Guidance Current official repository of ANPD guidance on agents, legitimate interest, cookies, security and other implementation topics.