Privacy policies are the first documentary failure most digital businesses run into. Either they don't have one, or the one they have was copied from a competitor in 2018 and never reviewed. Both are non-compliant under the LGPD, and both create exposure that surfaces at exactly the wrong moments — when a payment processor audits, when an investor's diligence reaches the data section, when a brand partner asks for compliance evidence.
This article covers what the LGPD actually requires, what generic internet templates miss, and how to scope the document to the operation.
What the LGPD requires
Brazil's General Data Protection Law (LGPD, Law No. 13,709/2018) does not literally require a "privacy policy" by name. What it requires is that the data subject have facilitated, clear, and adequate access to specific information about how their data is being processed.
Article 9 lists the elements:
- Specific purpose of the processing
- Form and duration of the processing
- Identification of the controller
- Contact information of the controller and, where applicable, the Data Protection Officer (DPO)
- Information about shared use of data and the purposes of such sharing
- Responsibilities of the agents that will perform the processing
- The data subject's rights (Art. 18)
In practice, this list is delivered via a privacy policy published on the website and made accessible from any data collection point (sign-up forms, checkout, contact pages).
A website without a privacy policy, or with a policy that omits any of these elements, is non-compliant. The exposure has three dimensions:
- Regulatory — ANPD has authority to apply sanctions under LGPD Art. 52, ranging from warnings to fines
- Contractual — payment processors, advertising platforms, partner brands, and B2B clients increasingly require evidence of compliance
- Reputational — privacy failures attract negative attention and erode trust
What generic templates miss
Most templates copied from the internet have three structural problems:
Problem 1 — declaring what the operation does not do
Templates often include language like "we may share data with affiliated companies" or "we may use your data for product research." If the operation does not, in fact, share data with affiliates and does not run product research, declaring that it might creates an unnecessary disclosure footprint. Less problematic than the next one, but still poor practice.
Problem 2 — omitting what the operation actually does
Far more dangerous. A typical infoprodutor stack involves:
- Email platform (Kit, Mailchimp, ActiveCampaign) processing names, emails, behavior
- Payment gateway (Stripe, Pagar.me, MercadoPago) processing names, CPFs, payment data
- Course platform (Hotmart, Kajabi, Eduzz) processing access logs, completion data
- Analytics (Google Analytics, Meta Pixel) processing IPs, behavioral data
- Customer support (WhatsApp Business, intercom) processing conversation history
Each of these is a processor receiving data on behalf of the controller. Each requires a Data Processing Agreement (DPA), and each must be disclosed in the privacy policy with the purpose of the sharing. Templates rarely list any of them specifically.
Problem 3 — boilerplate retention language
Templates often say "we retain data as long as necessary" without specifying. The LGPD requires a defined retention period per processing purpose. For an infoprodutor:
- Tax data: retention by the period set by Brazilian tax/accounting legislation (multi-year)
- Active customer data: retention while the customer relationship is active
- Marketing data: retention while consent is valid; deleted on revocation
- Analytics data: retention based on the purpose; consider anonymization after a defined period
Listing the retention period per data type makes the policy concrete and defensible.
What a working privacy policy looks like
A privacy policy that holds up under scrutiny has the following structure:
- Identification — full controller name, CNPJ (or CPF for individual operations), address, official contact email, DPO contact (or simplified regime declaration if applicable)
- What data is collected — itemized by collection point (form, checkout, browser tracking, etc.)
- How data is used — by purpose, with the corresponding legal basis (Art. 7 or Art. 11 of the LGPD)
- Who receives the data — list of processors with the purpose of each sharing, jurisdiction, and applicable safeguards for international transfers
- Retention — per data type, with reference to the rule that justifies the period
- Data subject rights — the rights of Art. 18 with practical instructions on how to exercise each
- Cookies and trackers — list of trackers with category (essential, analytics, marketing) and the consent mechanism
- Security — general description of the technical and organizational measures, without exposing specifics that themselves create vulnerability
- Updates — how changes to the policy are communicated and the version date
- Effective date and version history — this matters for evidentiary continuity
When to update
The policy should be reviewed:
- When a new processor is added to the stack (new email platform, new analytics tool)
- When a new processing purpose is added (e.g., adding a referral program with new data flows)
- When the operation expands geographically (cross-border data transfers)
- At a defined cadence (annually is reasonable for stable operations)
Updates should preserve the version history. If a question arises about how data was being processed at a specific moment, the prior version of the policy in effect at that moment is part of the answer.
Document hygiene
A privacy policy is not a marketing asset. It is a legal document with operational consequences. Two practices reduce risk:
Reflect actual practice. The single most important rule. A policy that promises more privacy than the operation actually delivers creates exposure at every audit, every incident, every diligence. A policy that matches the actual practice — even if the practice is data-intensive — is defensible.
Get review by someone who has read the LGPD. Generic legal review without LGPD-specific attention misses the elements of Art. 9, the legal bases of Art. 7 and 11, and the international transfer rules of Chapter V. LGPD-specific review catches structural gaps that generic review will miss.
Privacy policy is one of the few legal documents that operates continuously, in front of every visitor, every customer, every regulator, every auditor. Treating it as a serious operational document — not a copy-paste afterthought — pays for itself the first time it matters.
FAQ
Yes. Email is personal data under the LGPD (Art. 5, I). Collecting for newsletter involves defining purpose, legal basis, retention period, ways to revoke — all information that Art. 9 requires be made available to the data subject. The policy does not need to be lengthy: it needs to cover Art. 9 elements clearly. Simple site = simple policy; but mandatory.
Under LGPD Art. 9, at minimum: specific purpose of processing; form and duration; controller identification; contact information (controller and DPO, where applicable); responsibilities of processing agents; data subject rights (Art. 18); sharing with third parties and respective purposes; international transfers and applicable safeguards. A policy that omits any of these elements is non-compliant. Generic internet templates often cover only a fraction.
As a starting point, yes — provided it is reviewed and adjusted to the actual operation. AI-generated policy tends to be generic: it declares sharing that does not happen, omits processing that does happen, and does not reflect the concrete tech stack (payment gateway, email platform, analytics, remarketing pixel). The bigger risk is not the generated document, but the gap between the document and reality — that gap is what becomes a regulatory or contractual problem.
Under the LGPD (Art. 15), processing ends with the end of the purpose — but there are important exceptions (Art. 16): compliance with legal or regulatory obligations, research by accredited bodies, transfer to a third party with legal basis, controller's exclusive use (anonymization). For digital sellers: tax data (invoices, receipts) must be retained for the periods set by the Brazilian Tax Code and accounting legislation; non-essential data should be deleted or anonymized. The policy must indicate retention periods by data type.
The privacy policy describes practices and responsibilities — it does not need to be "updated because of the incident". What needs to happen in the incident is separate: notice to affected subjects, notice to ANPD under Resolution CD/ANPD No. 15/2024 (where there is relevant risk or damage), evidence preservation, activation of the response plan. Subsequently, if the incident reveals a gap in the policy (e.g., actual practice diverges from the document), correct the document as a remediation measure — not as a reaction.
