Connect SQL Server, PostgreSQL or MySQL. Consiva introspects every non-system schema, classifies personal data at column level, and maps what it finds to your declared processing purposes. Credentials are encrypted at rest and write-only — never returned by any API response.
Most organisations can name the two databases that matter. It is the third one — the reporting replica, the legacy application nobody has migrated, the analytics warehouse a team stood up in 2021 — where the surprises live.
This is not a documentation failure so much as a structural one. Schemas accumulate columns. An email_alt field gets added for one integration and never removed. A support tool writes phone numbers into a free-text notes column. A data science team copies a production table into a sandbox to test something and the copy stays. None of this appears in a data inventory built by asking people.
It matters concretely, not abstractly. When a Section 12 erasure request arrives, you have to erase her personal data — and you cannot erase what you have not found. When your notice has to give an itemised description of the personal data being processed, that itemisation has to be real.
Stated first, and plainly, because a connector list discovered halfway through a demo is worse than a limit stated up front.
Supported today:
| Source | Coverage |
|---|---|
| Microsoft SQL Server | Enterprise, Express, Azure SQL. Full table introspection. |
| PostgreSQL | v12+, including managed PostgreSQL on Supabase, AWS RDS and self-hosted. All schemas, tables and views. |
| MySQL / MariaDB | MySQL 5.7+, MariaDB, Aurora. SSL/TLS supported. Compatible with WooCommerce and Magento schemas. |
From a connection string to a column-level inventory — shown here as a workflow before the detail below.
This is a connected source and its classification results. The source list shows each connected database with its engine and when it was last scanned. The findings table is what the scan actually returned — schema.table.column, the SQL data type, the classified category with a risk score, how many matching values were found, and one masked sample so you can sanity-check the finding without exposing real data. A row like “Unclassified” with no category is a column the pattern classifier could not confidently place — worth a look, since a column nobody can name is usually a column nobody is still actively using on purpose.
The most common objection, answered directly.
Non-system schemas only. Consiva scans application schemas and skips system catalogues.
Read-only introspection. Discovery reads schema structure and samples for classification. It does not write, alter or drop.
Credentials encrypted at rest and write-only. Once supplied, a credential is never returned by any API response. Nobody — including Consiva support — retrieves it through the interface.
SSL/TLS supported on MySQL-compatible connections.
Scheduled off-peak. Scan windows are configurable so introspection does not coincide with your load peaks.
Per scan run: timestamp · sources covered · schemas, tables and columns examined · findings by data type · the incremental difference report against the previous run.
Per finding: schema, table and column · detected data type and confidence · suggested purpose · confirmation state, with the reviewer and the time of confirmation.
For erasure requests: the target list — the specific columns and tables holding a given individual's personal data — which is what turns an erasure request from a guessing exercise into an executable one.
Coverage statement. Every export names which sources were in scope and which classes of system are outside Consiva's discovery entirely.
A SaaS company runs a primary PostgreSQL database, a reporting replica and a legacy MySQL instance behind an application scheduled for retirement two years ago. The privacy team's inventory lists the primary only.
The first discovery run across all three returns 214 columns classified as personal data. Nineteen are in the legacy MySQL instance, including a table of customer phone numbers from a product line discontinued in 2022. Four columns in the reporting replica hold email addresses that had been assumed to be hashed and are not.
The discontinued-product table is a retention decision rather than a technical one, and it goes to legal with a question about which retention duty, if any, applies. The replica finding is fixed in a sprint. Neither would have surfaced from an interview-based inventory, because in both cases the people who would have been asked believed something different.
Illustrative. Not based on a named Consiva customer.
Discovery is the capability most likely to need help, because the hard part is not the scan but the review — deciding what a classified column is actually for, and what to do about the ones nobody can account for.
Discovery engagement — Consiva connects the sources, runs the initial scans, and works through the classification queue with your systems owners.
Managed Privacy Officer — ongoing review of each cycle's difference report, and chasing owners for newly appeared columns.
Your team retains all decisions on classification and purpose. Consiva does not determine the lawful basis for your processing.
Software that connects to your data stores and finds where personal data actually lives, rather than relying on a documented inventory. It introspects schemas, classifies columns against known patterns for personal data types, and produces an inventory you can act on. Under DPDP it matters most for two obligations: itemising personal data in your notice, and locating everything that has to be erased when a Section 12 request arrives.
You supply connection details for a database. The tool reads the schema structure across non-system schemas, examines column names and sampled values against patterns for personal data types, and returns each finding with a confidence level and a suggested processing purpose. Your team confirms or rejects each classification. Repeat scans produce a difference report so schema changes surface without anyone having to notice them manually.
The same category, named for personally identifiable information. Under DPDP the operative term is personal data — defined in Section 2(t) as any data about an individual who is identifiable by or in relation to such data — which is broader than the narrow "PII" framing common in US practice. Consiva classifies against personal data types including email, phone, name and Aadhaar-format identifiers.
Microsoft SQL Server including Azure SQL, PostgreSQL v12 and above including managed instances on Supabase and AWS RDS, and MySQL 5.7 or above including MariaDB and Aurora. Not currently supported: Oracle, MongoDB, Elasticsearch, unstructured file stores, data lakes, SaaS applications without a direct integration, and endpoint scanning. If your personal data is mostly in those, this is not the right tool for you and it is better to know that early.
Discovery is read-only schema introspection with sampling for classification — it does not write, alter or drop. It scans non-system schemas only, supports SSL/TLS on MySQL-compatible connections, and scan windows are configurable to avoid load peaks. Credentials are encrypted at rest and write-only, never returned by any API response. That said, we suggest pointing the first scan at a replica: it makes the internal approval conversation easier and lets your DBA see what the scan does at no risk.
Because two obligations are unsatisfiable without it. Rule 3(b)(i) requires your notice to give an itemised description of the personal data you process, which you cannot do accurately from an inventory built by asking people. And Section 12(3) requires erasure of her personal data on request — you cannot erase what you have not found.
Connect a database, get a column-level classification back — Enterprise plan, safe against production.