## Overview

The **Governance & LGPD** module gathers, inside the account Settings, everything the operation
needs to serve LGPD/GDPR day to day: the contacts' **consent registry**, **data subject requests**
(export or anonymize/erase a contact's data), **central message retention**, the **DPO data**
(Data Protection Officer) and the **native audit trail**. It also hosts
[Presentation Mode](/hc/ajuda/articles/administration-modo-apresentacao-en), which blurs sensitive
data for demos and screen recordings.

## Prerequisites

- **Administrator** profile (or a custom role holding the governance permissions — governance
  management, data export, data erasure and audit viewing).
- The **Governance & LGPD** feature enabled on the account. The **Audit** tab additionally requires
  the **Audit Trail (Native)** feature. If the area is missing, talk to the account owner.

## Step by step

1. Open **Settings → Governance & LGPD**.
2. On the **LGPD** tab, fill in the **DPO name and email** and, if desired, enable
   **automatically request and register inbound consent**. Configure the global message, per-channel
   overrides, privacy-policy URL, and accepted affirmative/negative replies.
3. Set the **message retention (days)**: messages of **resolved** conversations older than the
   limit are redacted automatically every day (0 disables it).
   **Conversation retention (days)** removes resolved, inactive conversations in small batches; linked
   contracts and active legal holds always suspend removal. The canonical audit ledger is preserved.
   **Commerce payload retention (days)** removes buyer-identifying data from old events while preserving
   aggregate revenue values.
4. Set the **audit trail retention (days)** — older events are pruned.
5. To serve a data subject: search the contact in the **Data subject requests** section and choose
   **Export data** (generates a JSON bundle with the contact's profile — including masked tax ID,
   country, address and billing address —, company memberships and relationships, consent history,
   conversations, messages and attachment manifest, and emails a notification; it does not include CRM
   deals, payments, tasks, contracts or bookings) or
   **Anonymize** (scrubs the identifying data — name, email, phone, identifier, attributes, fiscal
   document, address and the company memberships/relationships — preserving the conversation
   history).
6. Track progress in the **Request history** list, which refreshes automatically while requests are pending
   or processing. If loading fails, use **Try again**. When the bundle is ready, use **Download bundle**:
   the platform checks your permission again and issues a temporary link.
   For anonymization and erasure, the request stays **Processing** until the WhatsApp gateway confirms that the
   subject was removed from the groups they took part in. The local part is already done at that point, and the
   notice under the status explains the wait. The platform retries automatically every day, with no action needed
   from you, and the request only shows **Completed** after that confirmation.

## Settings & options

- **Manual/API consent**: from the contact panel, read the history and append a declaration — purpose (data
  processing, marketing, cookies, custom), channel, granted or denied, and a note. The API also accepts structured
  evidence. History is immutable. A global (`all`) declaration is the current default; only channel declarations
  newer by event time/id are also current overrides. Older channel declarations remain visible but not current.
- **Automatic inbound consent**: on the first inbound interaction for a contact/channel with no applicable
  `data_processing` declaration, the platform persists and sends the prompt through that channel's normal pipeline.
  The prompt is processed in the background, alongside bots, listeners, and automations — the inbound message never
  waits on it. A configured affirmative or
  negative reply appends a declaration with channel, response message, prompt message, and evidence. Automatic
  evidence stores technical IDs, the normalized matched token, and a SHA-256 digest — never the raw reply text.
- **Consent prompt wording, per language**: the automatic prompt ships with built-in text, but you can write
  your own — and now **per language**. The text is chosen by the **contact's** language (falling back to the
  account language and finally to the wording you already had). A single text configured earlier keeps
  applying to every language: there is nothing to migrate. There is also a per-**channel** text, which wins
  over the general one. An `{x}` picker inserts the five accepted placeholders — `{{contact_name}}`,
  `{{privacy_policy_url}}`, `{{dpo_email}}`, `{{affirmative_token}}` and `{{negative_token}}`; anything else is
  **stripped** on send, and the platform refuses the save telling you which placeholder does not exist (in any
  of the languages). An empty field shows the built-in text that really goes out, and **Restore default**
  deletes your version of that language for real (the removal reaches the server, it does not just vanish
  from the screen).
- **Prompt preview and test**: the preview renders the text **per channel**, with a real contact's name and the
  tokens the matcher accepts; the **test** really sends it to a conversation you pick. You validate the
  wording without waiting for the next inbound.
- **Legal holds**: the **Legal holds** tab lists the conversations retention must never remove — not by
  age, not by inactivity. Search the conversation by contact, number or inbox, give the reason (a court
  order, say) and place it.
  A hold is **released, never deleted**: the record keeps who placed it, who released it and when, because
  that is precisely the evidence a legal hold exists to produce. Only administrators and roles with
  **manage data governance** place or release holds; export/erase holders can read the list to understand
  why a conversation survived a sweep.
- **Consent badge**: the contact panel shows the state in force — **Granted**, **Denied**, or **Pending**. With more
  than one channel the badge shows the worst state, so a refusal can never hide behind a grant on another channel;
  hover it for the channel-by-channel reading. A channel the contact never declared on simply does not appear —
  absence is not pendency.
- **Unrecognized reply**: if the contact answers with something that cannot be read as a decision, the platform
  **stops asking** and flags the conversation with **Consent pending**. Settle it with the contact and record the
  declaration by hand from the panel.
- **Campaigns**: contacts who explicitly refused are removed from the audience. The preview reports how many were
  excluded, and the note appears only when a refusal actually shrank the list. Someone who was never asked, or whose
  grant expired, still receives it — asking for consent is the prompt's job, not the campaign's.
- **Deliberate boundary**: this mode requests and records; it **does not quarantine the inbound message, pause
  automations until a decision, or ever block outbound**. The UI therefore makes no technical-blocking promise.
  If the operation's legal policy requires all processing to stop, enforce that restriction in the operational flow
  in addition to this registry.
- **Safe customization**: the prompt can be global or channel-specific and supports only `contact_name`,
  `privacy_policy_url`, `dpo_email`, `affirmative_token`, and `negative_token`, each wrapped in double braces.
  Replies are matched case-insensitively and ignore accents and edge punctuation. An affirmative token cannot also
  be negative; the API rejects ambiguous configurations and legacy ambiguity never records a decision. Unsupported
  placeholders and Liquid tags are rejected; legacy values are stripped before sending so they cannot expose data.
- **Anonymize with message redaction**: optionally the anonymization also redacts the contact's
  inbound message content and purges attachments.
- **Mandatory confirmation**: anonymization/erasure requires typing the **contact id** — a guard
  against accidental destructive actions.

## Use cases

- Serve a formal data-subject request (LGPD art. 18) with an auditable receipt.
- Periodically sanitize the base with central message retention.
- Prove the marketing legal basis with the per-contact consent history.

## Tips, limits & best practices

- The export runs in the background; the requester receives an email that returns them to the
  authenticated Governance area. Only Administrators and roles with **data export** can issue the
  temporary bundle link; governance management or data erasure alone do not grant file access.
- Anonymization does **not** delete the conversation — it deletes the identity. For full removal,
  use erasure (contact deletion), aware that the conversation history is removed with it.
- Every governance action leaves an event in the audit trail (when enabled).
- Prompt, grant, and denial have distinct audit actions; retries are idempotent and the contact row lock prevents
  two concurrent prompts.
- **Companies in DSR**: a contact's export and anonymization **already include** their **Companies**
  memberships and relationships (names, roles, dates and notes). What stays separate is fiscal-document
  masking (Presentation Mode/RBAC) and the governance of the Company as an entity — see the Companies
  & relationships article.

## Troubleshooting

- **The area is missing**: the feature is not enabled on the account or your profile lacks the permission.
- **A request stays "Processing" with a waiting notice**: the local part is done and the removal from the WhatsApp
  groups still has to be confirmed. The platform retries automatically every day; do not create a new request for
  the same subject.
- **A request shows "Failed"**: read the notice under the status. For an export, create a new request. If the
  removal from the groups was refused, contact support, because that request cannot be reprocessed from the screen
  yet. The failure event is also recorded in the audit trail.
- **The prompt was not sent**: check the Governance & LGPD feature, inbound consent control, and whether a global
  or channel declaration already exists. Any prior state (granted or denied) prevents another prompt. A prompt marked
  failed by the delivery provider is retried on the next inbound message, once per contact/channel.
- **A reply was not recognized**: check the configured tokens; the message must match one complete token. Add
  required variants as comma-separated values.

## See also

- [Presentation Mode](/hc/ajuda/articles/administration-modo-apresentacao-en)
- [Audit logs](/hc/ajuda/articles/administration-auditoria-en)
- [Custom roles and governance (RBAC)](/hc/ajuda/articles/administration-custom-roles-governanca-rbac-en)
- [Companies and relationships](/hc/ajuda/articles/contacts-crm-empresas-e-relacionamentos-en)