LGPD programs often start with policies, spreadsheets, and legal questionnaires. The most difficult question is technical: where is the personal data, who can reach it, how long does it survive, and what proves that the controls work? A database assessment turns those questions into evidence, priorities, and an implementation plan.
What a database-focused LGPD assessment delivers
The assessment does not replace legal advice or the controller's decisions on legal basis. It provides the technical evidence that a DPO, privacy office, security team, and database owners need to make those decisions and implement them consistently.
- Data map: databases, schemas, tables, columns, file stores, ETL jobs, replicas, analytics copies, and third-party exports that may hold personal or sensitive data.
- Access map: human users, application identities, service accounts, privileged roles, shared credentials, and the paths used to access production data.
- Lifecycle map: collection, replication, backup, retention, archival, deletion, restore testing, and disposal.
- Risk register: findings ranked by likelihood, impact, owner, proposed control, dependencies, and validation evidence.
- Remediation roadmap: quick risk reductions, structural changes, and controls that need product, security, legal, or vendor participation.
Phase 1: establish scope and ownership
We start by identifying the systems that process personal data and the people accountable for them. This includes production databases, read replicas, reporting warehouses, staging copies, developer refreshes, ETL pipelines, exports, object storage, and backup repositories. The database is rarely the only copy of a record.
For each system, the client identifies the business owner, technical owner, environment, data classification, criticality, cloud/vendor boundary, and whether the system participates in a data-subject request. This avoids a common failure mode: securing the primary database while a nightly analytics extract remains broadly accessible elsewhere.
Phase 2: discover and classify data with evidence
Column names are useful signals, not proof. A disciplined discovery process combines schema inspection, approved sampling procedures, application knowledge, database comments, ETL metadata, and reports. We look for direct identifiers such as CPF, email, telephone, address, account identifiers, authentication data, and for attributes that can become identifying when combined.
-- PostgreSQL: inventory likely data-bearing objects before classification
SELECT table_schema, table_name, column_name, data_type
FROM information_schema.columns
WHERE table_schema NOT IN ('pg_catalog', 'information_schema')
ORDER BY table_schema, table_name, ordinal_position;The output is reviewed with system owners. Classification is recorded in a governed inventory rather than inferred forever from a keyword scan. For sensitive personal data, financial data, credentials, and regulated records, the assessment documents the additional access, encryption, logging, and retention expectations.
Phase 3: test controls across the data path
Compliance is not a checkbox on one table. We test controls at rest, in transit, and while data is being operated:
- Role design, least privilege, privileged access, break-glass access, stale accounts, and shared service credentials.
- TLS for client connections and replication paths, secrets storage, certificate rotation, and network segmentation.
- Encryption approach, key ownership, and whether backups, exports, WAL/archive logs, and snapshots receive equivalent protection.
- Auditability of DDL, privileged access, exports, failed logins, and changes to retention or access controls.
- Whether non-production refreshes are masked, minimized, or generated from synthetic data.
Phase 4: prioritize remediation instead of creating a report nobody uses
Findings are converted into actions with owners and evidence criteria. Examples of high-priority technical findings include public network exposure, shared DBA credentials, unencrypted backups, unrestricted production restores into development, disabled audit trails, orphaned users, and replication or ETL paths that bypass established access controls.
Important boundary: the controller and its DPO/legal advisors define legal basis, privacy notices, retention obligations, and response policy. Our consulting translates approved obligations into database controls, validates their implementation, and produces technical evidence.
How João Victor Oliveira can help
João Victor Oliveira is a Senior Database Administrator with 13+ years across mission-critical banking, public-sector, cloud, and enterprise environments. His experience includes PostgreSQL, MySQL/MariaDB, Oracle, SQL Server, AWS RDS, Azure, migrations, high availability, backup/recovery, monitoring, and performance engineering. The engagement combines that operating experience with a practical focus on systems that need to stay available while controls are improved.