What Is Data Discovery and Why Every DPDP-Regulated Business Needs It

Data DiscoveryDPDP Act 2023PII ScanningROPASection 12Data MappingPrivacy Compliance

What Is Data Discovery?

Data discovery is the step where teams look for personal data across their systems. It is often done with automation that scans and flags data, then lists it in a catalog. This covers places like databases, file servers, cloud drives, APIs, and tools from outside vendors. So the main goal is simple to say. You want to know where the personal data lives, in real terms.

The idea can sound easy. But it can turn into a mess quickly. Take a medium sized company in India. It might see roughly ten thousand customer orders each month. That work can leave personal data scattered in all sorts of places. There could be a MySQL database still running. There may be an older SQL Server setup. Staff might rely on an Excel sheet saved in a shared Google Drive. Some details can also sit inside a helpdesk ticket tool. Then there is the marketing automation platform too. Without systematic discovery, none of that is visible — and invisible data cannot be protected, deleted, or reported to the Data Protection Board of India.

Data discovery is not a one-time audit exercise. The most effective programmes treat it as a continuous, automated process that runs on a schedule — flagging new personal data stores as they appear, tracking changes to existing ones, and maintaining a living inventory that reflects the reality of your systems rather than a snapshot from six months ago.

Active vs Passive Data Discovery

There are two main ways to locate personal data. Knowing how they differ can change how you plan your DPDP work. Active scanning gives ground-truth inventory; passive analysis maps how data flows. The best programmes use both.

Active discovery is a method where you reach out to the places where data lives. You use read-only database logins or storage access keys. Then you run set queries or you move through folders in the file system. During this step, the tool looks at field or column names. It also checks a few sample values. Then it applies match rules to tag the text. These rules may use regular expressions for Aadhaar IDs, PAN card numbers, email addresses, and phone numbers. Active scanning produces high-confidence, precise results because it examines actual data rather than traffic metadata.

Passive discovery analyses network traffic, database audit logs, or application access logs to infer what personal data exists and how it flows between systems — without accessing data stores directly. It is useful for discovering shadow data paths and understanding data flow diagrams, but it cannot replace active scanning for classification accuracy. The best compliance programmes use both: active scanning for ground-truth inventory, passive analysis for data flow mapping.

Modern automated data discovery platforms — including Consiva's built-in scanner — combine active database interrogation with passive log analysis, giving you a complete picture of your data landscape within hours rather than the weeks a manual spreadsheet audit would require.

Why Data Discovery Is the Foundation of DPDP Compliance

The Digital Personal Data Protection Act 2023 (DPDP Act) introduced India's most comprehensive data privacy framework. It places a broad set of obligations on Data Fiduciaries — any organisation that determines the purpose and means of processing personal digital data. Every one of those obligations traces back to a single precondition: you must know what personal data you hold and where it is.

DPDP Act Provisions That Require Data Discovery

Section 4: Processing only for lawful purpose with consent — impossible to audit without a comprehensive data inventory.
Section 6: Purpose limitation — data retained beyond its stated purpose cannot be identified without a discovery index.
Section 8(4): Reasonable security safeguards — you cannot secure data you do not know exists.
Section 8(5): Data Fiduciaries must ensure personal data is complete, accurate, and consistent — requires a master inventory.
Section 8(6): Breach notification to the Board — you cannot notify on a breach of data that was never inventoried.
Section 8(7): Erasure of data after purpose fulfilment or consent withdrawal — demands knowing every storage location.
Section 9: Children's data protections — requires identifying whether child data is stored and where.
Section 12: Data principal rights including access, correction, and erasure — all responses require a precise data map.

Think of data discovery as the geological survey you commission before constructing a building. Without knowing what lies beneath — soil composition, buried utilities, drainage channels — every subsequent construction step is guesswork. DPDP compliance built without a data discovery foundation will eventually fail when the Data Protection Board sends an inquiry notice and your team cannot account for where a data principal's information resides.

The DPDP Act's emphasis on purpose limitation under Section 6 means that data should not be retained beyond what is necessary for the stated purpose. But you cannot enforce purpose limitation on data you do not know exists. Orphaned records in decommissioned databases, test environments seeded with production data, and forgotten analytics pipelines are all common sources of undiscovered personal data — and all represent potential regulatory liabilities.

How PII Scanning Works Across SQL Server, MySQL, and PostgreSQL

Personally Identifiable Information (PII) scanning — the technical core of automated data discovery — works differently depending on the database platform. Here is how a production-grade scanner handles the three most common relational databases in Indian enterprise environments.

Microsoft SQL Server

Consiva talks to SQL Server through a special user account that only reads data — a read-only service account to be exact. Before starting the scan, the software first takes a look at every database on the instance, and maps out all the tables and columns in it by querying the INFORMATION_SCHEMA.COLUMNS view. Then it runs a two-stage analysis: first, it looks through the column names for certain patterns — things like 'email', 'mobile number', 'aadhaar number', 'pan card', 'date of birth', and loads of others like that. If it finds one, it labels that column as likely sensitive. After that, it grabs a smaller batch, usually around 500 to 1,000 rows. It picks records from the fields that are likely to hold PII. Then it applies a regular expression to the sample. This step is meant to verify whether any sensitive values are present.

-- Consiva column heuristic discovery query (simplified)
SELECT
  TABLE_SCHEMA,
  TABLE_NAME,
  COLUMN_NAME,
  DATA_TYPE,
  CHARACTER_MAXIMUM_LENGTH
FROM INFORMATION_SCHEMA.COLUMNS
WHERE COLUMN_NAME LIKE '%email%'
   OR COLUMN_NAME LIKE '%mobile%'
   OR COLUMN_NAME LIKE '%aadhaar%'
   OR COLUMN_NAME LIKE '%pan_card%'
   OR COLUMN_NAME LIKE '%passport%'
   OR COLUMN_NAME LIKE '%dob%'
   OR COLUMN_NAME LIKE '%address%'
   OR COLUMN_NAME LIKE '%pincode%'
ORDER BY TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME;

MySQL and MariaDB

MySQL scanning follows the same column-heuristic approach but additionally inspects table comments and column comments — metadata fields often populated by developers with plain-language notes such as "stores customer PAN number for tax processing". The scanner checks what comes from SHOW CREATE TABLE. It looks at CHECK constraints and uses them to see how values are stored. This can help confirm if a column holds structured PII, like Aadhaar, which is a 12 digit number, or email addresses. Consiva's MySQL connector can work with both MyISAM and InnoDB. It also allows encrypted links using TLS.

PostgreSQL

PostgreSQL introduces two additional discovery vectors that make it particularly interesting: custom types and JSONB columns. A column of a custom type named user_gender defined as an ENUM is clearly sensitive personal data even if the column name itself is an opaque abbreviation. Consiva's PostgreSQL connector queries pg_type and pg_enum to surface these custom types and flag them for human review. It also scans JSONB columns — an increasingly common storage pattern in modern applications — by extracting a sample of JSON objects and analysing their key names against the PII heuristic dictionary.

A 2025 survey of Indian SaaS companies found that 63% of discovered personal data resided in tables whose names gave no indication of containing PII — order history tables holding delivery addresses, event log tables capturing IP addresses, and analytics tables storing device fingerprints. Column name heuristics alone are insufficient; data value sampling is essential for high-confidence classification.

Structured vs Unstructured Data Discovery

The distinction between structured and unstructured data is one of the most consequential in data discovery, because the two require entirely different scanning approaches and present different compliance risk profiles under the DPDP Act.

Structured data lives in relational databases, data warehouses, and spreadsheets with defined schemas. SQL Server, MySQL, PostgreSQL, Amazon Redshift, Google BigQuery — all are structured sources that yield to the column-heuristic and data-sampling approach described above. They are the easiest to scan because they have predictable column names and typed values.

Unstructured data is harder to manage for compliance. You can find it in many places, like PDF files with signed contracts or KYC papers in cloud storage. There are also Word and Excel files with customer lists or staff records. Some teams keep email attachments in shared inbox archives. Identity documents may show up as images, then get run through OCR. Chat histories and support tickets can be saved as plain text in NoSQL tables. Web server logs are another issue, since they may store personal info inside URLs or in request data.

Characteristic	Structured Data	Unstructured Data
Scanning approach	Schema traversal + data sampling	OCR, NLP, and regex on file content
Scan speed	Fast	Moderate
Classification confidence	High	Medium
DPDP regulatory risk	Medium	High
Common sources	MySQL, SQL Server, PostgreSQL, Redshift	S3 buckets, SharePoint, email archives, PDF stores
Erasure complexity	Row-level DELETE statements	File deletion or content redaction

For DPDP compliance, unstructured data presents the greatest regulatory risk precisely because it is the hardest to inventory and control. A scanned Aadhaar card stored in an Amazon S3 bucket without proper access controls is a serious data breach waiting to happen — and without unstructured data discovery, your privacy team will never know it exists. Consiva scans both structured and unstructured sources in the same unified workflow, surfacing a single data map across your entire technology estate.

How Data Discovery Feeds into ROPA Generation

The Record of Processing Activities (ROPA) is the cornerstone compliance document for any Data Fiduciary operating under the DPDP Act. While the Act itself does not use the specific term ROPA, Section 28 empowers the Data Protection Board of India to requisition records detailing how personal data is being processed — making a well-maintained ROPA the obvious evidence to produce in response to any Board inquiry.

A ROPA entry for any given processing activity must capture: the category of personal data processed, the purpose of processing, the legal basis (consent under Section 6, legitimate use under Section 7, or a specific exemption under Section 17), the data retention period, the technical and organisational security measures in place, and — critically — the systems and locations where the data is stored. Without data discovery, this last field is filled by guesswork or incomplete self-reporting from application owners who may not know the full scope of what their systems store.

With automated discovery, your ROPA's storage location field is populated from verified scan results rather than developer recollections. When the Board asks "where do you store customer email addresses?", your answer is backed by evidence — not memory. This distinction is the difference between a convincing compliance demonstration and an uncomfortable audit conversation.

In practice, Consiva's data discovery scanner runs an active scan across your connected data sources and produces a classified inventory — listing every storage location, the category of personal data found there (contact details, financial data, biometric data, health data, and so on), and the confidence level of the classification. This inventory is ingested by Consiva's ROPA module, which maps each storage location to the relevant processing activity and auto-populates the Systems and Storage field.

The result is a living ROPA that updates whenever a new scan detects a change — a new table added to your database, a new S3 prefix created by an ETL pipeline, or a new SaaS connector introduced by your sales team. You no longer rely on developers self-reporting data structures to the privacy function. For a deeper look at the full ROPA workflow, see our guide to automating ROPA for DPDP compliance.

Know Exactly Where Your Personal Data Lives

Consiva's automated discovery scanner maps your databases, cloud storage, and file systems in hours — not weeks. No manual spreadsheets. No guesswork. Results feed directly into your ROPA and rights fulfilment engine.

Start Free on Consiva.ai — No Credit Card Required

How Data Discovery Enables Section 12 Erasure Request Fulfilment

Section 12 of the DPDP Act, 2023 gives data principals a right to ask for deletion of their personal data. This covers your customers, your workers, and also any other person whose data you handle. In Section 12(b), the Act is clear about when erasure can be sought. It applies when the personal data is no longer needed for the reason it was gathered. It also applies when the person withdraws consent. The Data Protection Board, once fully operational, is expected to formalise a fulfilment deadline; international best practice and draft rules suggest a window of 30 days from receipt of the request.

Consider what happens when an erasure request arrives in your privacy team's inbox without a data discovery system in place. The team manually contacts each application owner, asking them to search their respective systems. The marketing manager checks the CRM. The engineering lead queries the production database. Nobody checks the data warehouse, the email marketing platform, the CSV export generated for a now-cancelled campaign, or the backup snapshots retained in cloud storage. The individual's personal data persists in at least three locations. If the Board audits this deletion, you have a demonstrable compliance failure — one that could attract a penalty of up to ₹50 crore under Schedule I of the Act.

With Consiva's discovery-backed data map, the erasure workflow is entirely different and reliably complete:

Erasure request received and logged

A data principal submits an erasure request via your Consiva-powered rights management portal or by email. Consiva creates a timestamped ticket with the request date, the individual's identifiers (email address, customer ID, or phone number), and the calculated fulfilment deadline — 30 days from the date of receipt.

Automated data location lookup

Consiva queries its discovery index — the continuously updated inventory of all personal data across your connected systems — and retrieves every storage location associated with the individual's identifiers. This runs in seconds and produces a complete deletion checklist.

Assisted or automated deletion execution

Depending on your configuration, Consiva either generates deletion scripts for your engineering team to execute with one-click approval (maintaining human oversight), or for connected SaaS systems triggers deletion directly via the system's API. Each deletion action is logged with a UTC timestamp, the identity of the approver, and the specific records deleted.

Verification scan and formal closure

A targeted re-scan of the identified locations confirms that the data no longer exists in any of the flagged stores. Consiva closes the ticket and generates a fulfilment certificate — a PDF audit trail including all deletion logs, timestamps, and approver identities — which you can produce to the Board or to the data principal upon request. The entire process is documented end-to-end, well within the 30-day window.

Without the discovery foundation, step 2 is simply absent. That absence makes the remaining steps unreliable and almost certainly incomplete — a risk no Data Fiduciary under the DPDP Act should be prepared to accept given the Board's enforcement powers.

Running Your First Data Discovery Scan: Step by Step

Getting started with data discovery on Consiva is a structured process designed to minimise disruption to your production systems while maximising coverage. Here is a practical walkthrough of the full first-scan cycle.

Inventory your data sources before connecting anything

Set aside 30 minutes to jot down every system that might store personal data. Think about the production database first. Then check staging and development setups. Don't forget data warehouses, too. Also include third-party SaaS tools that move or store personal data, shared drive folders, and email archives. Look for outside APIs as well. Even if your list is not finished, you still get a clearer sense of what is in scope.

Create dedicated read-only service accounts

For each database, create a read-only user account exclusively for Consiva. In MySQL: GRANT SELECT ON *.* TO 'consiva_scan'@'%' IDENTIFIED BY 'strongpassword';. In PostgreSQL: GRANT CONNECT ON DATABASE mydb TO consiva_scan; GRANT USAGE ON SCHEMA public TO consiva_scan; GRANT SELECT ON ALL TABLES IN SCHEMA public TO consiva_scan;. Never use an admin or application credential for scanning. Least-privilege access is both a security best practice and a requirement under DPDP Section 8(4).

Connect data sources in the Consiva dashboard

Head over to Settings → Data Sources → Add New. Choose the type of database you're working with and enter the host, port, database name and the read-only credentials you created at setup. Consiva tests the connection and confirms it works before it saves it. If you are linking cloud storage, supply an IAM role ARN (AWS) or a service account JSON (Google Cloud) to give Consiva read-only access to your bucket.

Configure scan parameters and PII categories

First, choose the scan depth you want: Schema-only (fastest results, lowest confidence), the full-on scan (all rows, slowest, highest confidence), or a simple Schema plus Sample (a 500-row data sample — the recommended starting point). Then decide which PII categories you want Consiva to flag — contact details, financial identifiers, government IDs (like Aadhaar & PAN), biometric references, health data, and location data. Set the initial scan to run right away, and schedule the subsequent incremental scans to run daily or weekly.

Review, validate, and act on results

The initial scan spits out a classified inventory with confidence scores — if the score is high enough, you can let Consiva auto-approve the findings. But if the score is only medium, you'll have to verify whether it's, say, an Aadhaar number or just an internal reference number (that ref_no column with 12-digit numbers in it). Plan for about an hour or so of review time per 100 findings on the first run; subsequent scans only flag what's changed.

Classification, Tagging and Remediation of Discovery Results

Your job is to now take these findings and turn them into something useful. A completed data discovery scan is not itself a compliance deliverable — it is the raw material from which compliance is built. Raw scan results must be processed through three subsequent steps before they translate into materially reduced regulatory risk.

Classification: Assign Sensitivity Categories

Assign each discovered data element to a sensitivity category aligned with the DPDP Act's distinctions. Consiva fills in a set of categories ahead of time. It includes Basic Contact Data such as name, email, and phone number. It also includes Government Identifiers like Aadhaar, PAN, Passport, and Voter ID. There is Financial Data too — bank account numbers, card numbers, UPI IDs, and GSTIN. Health and Medical Data are listed as well — conditions, prescriptions, and diagnostic results. Biometric Data is another category, meaning fingerprints, face templates, and retina scans. Minors' Data is also included — any data for people under 18 years old — which must follow extra safeguards under Section 9, including a need for parental consent that can be checked.

Next, classification is used to decide the legal basis for processing. It also helps set the right limits for how long data is kept. Classification points to the security controls that must be used. It also helps decide if the Data Fiduciary counts as a Significant Data Fiduciary under Section 10. If it does, more duties apply, including a Data Protection Impact Assessment.

Tagging and Ownership Assignment

Once classified, each data store should be tagged with a designated data owner — typically the business unit responsible for the system — and linked to the relevant processing activity in your ROPA. This ownership model ensures accountability: when a data principal submits a rights request or when a retention period expires, there is a named individual responsible for acting. Consiva's tagging interface allows bulk ownership assignment across all tables within a database, or granular column-level tagging for particularly sensitive fields.

Remediation: Act on What You Find

Many first-time discovery scans surface data that should not exist in its current form. Common findings include:

Personal data in non-production environments: Replace with anonymised synthetic data using Consiva's masking templates. Production data seeded into staging or development environments is one of the most frequent causes of inadvertent data exposure.
Data retained beyond its stated purpose: Trigger a deletion workflow immediately. Set up auto rules for data age so records are removed right when they hit their expiry date.
Unencrypted PII in file exports stored in shared drives: Either encrypt those exports or remove the files, lock down access to the folder so only the right people can open it, and turn on encryption in the export process that created those files.
Cloud storage buckets with overly permissive access containing personal data: Immediately restrict access permissions and initiate a security review to determine whether unauthorised access occurred.
Orphaned accounts and test data: Delete records associated with test users or decommissioned accounts that have no active data principal relationship and no legitimate retention basis.

For e-commerce businesses where personal data volumes grow rapidly with each transaction cycle, discovery scans should run weekly with daily incremental checks on high-velocity tables. See our DPDP compliance checklist for e-commerce for a sector-specific operational framework that builds on data discovery as its foundation.

How Consiva's Data Discovery Module Works

Consiva is purpose-built for DPDP compliance in Indian businesses, and the data discovery module sits at the centre of the platform's architecture. Unlike generic data governance tools designed primarily for GDPR or CCPA, Consiva's scanner is pre-loaded with India-specific PII patterns covering all formats of Aadhaar numbers (with and without spaces or hyphens), PAN card formats for all categories of taxpayers, GSTIN formats for all states and union territories, Indian mobile number prefixes (both pre- and post-number portability), Indian postal PIN codes, all Passport number formats in use, and Voter ID formats used across all 28 states and 8 union territories.

Consiva Data Discovery: Technical Specification

Database connectors: Microsoft SQL Server 2014+, MySQL 5.7+, PostgreSQL 12+, Oracle Database 12c+, Amazon Aurora, Amazon RDS, Azure SQL Database, and Google Cloud SQL.
Cloud storage connectors: Amazon S3, Azure Blob Storage, Google Cloud Storage, with support for encrypted buckets via KMS/CMK.
PII detection engine: 340+ built-in regex patterns covering Indian government IDs, financial info, contact details, and health data fields; a custom pattern builder for your own proprietary identifiers.
Scan modes: just the schema for a super quick look, a sample of 500 rows for more depth, or a full statistical analysis — customisable per data source.
Incremental scanning: After the initial full scan, Consiva compares table checksums and schema hashes to figure out only what's changed, cutting re-scan times by up to 94% on a stable database.
ROPA integration: Classified findings are automatically pushed to the ROPA module as candidate processing activity entries for a data steward to review and confirm.
Rights request integration: The discovery index feeds the fulfilment engine for Section 12 erasure and access, making a per-person data location report fast, often within seconds.
Security: Database keys and secrets are locked when stored, using AES-256, and data moves over TLS 1.3. Consiva does not keep a copy of your personal data — only metadata such as table name, column name, PII type, and a confidence score.
On-premises agent: For organisations that cannot expose database connections to the internet, a lightweight scanner agent deploys within your network perimeter, scans locally, and sends only metadata to the Consiva cloud for analysis.

The on-premises scanner agent is particularly relevant for banking, insurance, healthcare, and government-adjacent organisations operating under sector-specific data localisation requirements. The agent is distributed as a Docker container or a system service installer for Windows Server and Linux. See pricing plans including the on-premises agent tier, or contact our team for enterprise deployments requiring custom network topology or air-gapped installation.

The Cost of NOT Doing Data Discovery

The DPDP Act 2023 is unambiguous about the financial consequences of non-compliance. Schedule I of the Act sets out a tiered penalty structure with the maximum financial penalty of ₹250 crore per non-compliance event imposable by the Data Protection Board of India. These are not hypothetical maximums — the Board has statutory authority to impose them in proportion to the nature, gravity, and duration of the non-compliance, without requiring proof of harm to any individual data principal.

Non-Compliance Type	Maximum Penalty	Discovery Gap That Triggers It
Failure to implement reasonable security safeguards (Section 8(4))	₹250 crore	Unencrypted PII in unknown or unmonitored storage locations
Failure to notify the Board and data principals of a breach (Section 8(6))	₹200 crore	Cannot notify on a breach of data that was never inventoried
Non-compliance with obligations related to children's data (Section 9)	₹200 crore	Failure to identify and govern minors' data scattered across systems
Failure to fulfil a rights request within the required period (Section 12)	₹50 crore	Incomplete erasure because not all data locations were known
Other obligations including ROPA accuracy and purpose limitation (Section 6)	₹50 crore	Inaccurate ROPA due to undiscovered processing activities

Beyond the direct financial penalties, consider the compounding costs: legal representation before the Board (typically ₹5 to 15 crore for complex defended cases), reputational damage from public Board orders (all adjudication orders are required to be published under Section 27(8)), customer attrition following a publicised breach or enforcement action, and the engineering cost of reactive remediation undertaken under regulatory pressure — which is consistently estimated at three to five times the cost of proactive prevention.

A complete initial data discovery scan on Consiva costs a fraction of a single day's legal representation before the Data Protection Board. The return on investment calculation for proactive discovery is not an abstract compliance exercise — it is straightforward financial risk management. Start your free scan today and understand your data landscape before the Board asks you to account for it.

The Indian data protection enforcement landscape is moving quickly. The Data Protection Board of India is actively being constituted, the DPDP Rules are approaching finalisation, and enforcement against early non-compliant organisations will serve as precedent for the Board's adjudication approach. The businesses that build their compliance programmes on a solid data discovery foundation now — knowing exactly what personal data they hold, where it lives, who is responsible for it, and how to delete it on demand — will be positioned to respond to any Board inquiry with confidence and evidence. Those that defer discovery until enforcement begins will be scrambling under time pressure, spending far more, and demonstrating exactly the kind of negligence the Board is designed to penalise.

Ready to Map Your Personal Data?

Consiva's automated data discovery scans your databases and cloud storage in hours, feeds your ROPA automatically, and powers instant Section 12 erasure fulfilment. Start free — no credit card, no lengthy procurement process, results the same day.

Get Started Free — Scan Your First Database Today

Need guided onboarding for your enterprise? Talk to our team →

Frequently Asked Questions

Data discovery is the process of searching through your entire organisation to track down and understand where all personal data is stored — basically tracing the digital footprint of your organisation to figure out where all this personal info is living. It's the key to answering the fundamental question: 'where exactly does personal data hide in our organisation?' Without that knowledge you're left struggling to build a reliable Records of Processing Activities, deal with erasure requests under Section 12 on time, or even keep the Data Protection Board of India off your back.

The DPDP Act 2023 does not use the phrase "data discovery", but several obligations make it a practical necessity. Section 8(5) requires Data Fiduciaries to maintain accuracy and completeness of personal data. Section 8(7) mandates erasure upon withdrawal of consent or fulfilment of purpose — both of which are impossible without knowing where data resides. The ROPA requirement further demands comprehensive records of all processing activities, which only a systematic discovery scan can reliably produce.

Consiva's data discovery module scans the likes of Microsoft SQL Server, MySQL, PostgreSQL, Oracle Database, and Amazon Aurora, and also checks cloud storage such as AWS S3, Azure Blob and Google Cloud Storage. Plus it looks at shared file systems and API endpoints spewing out JSON, as well as unstructured data within connected systems — that's anything from CSV exports and Excel files to PDFs buried away in your databases.

DPDP Act Section 12(b) grants data principals the right to erasure of personal data when it is no longer necessary for the purpose it was collected, or when consent is withdrawn. Consiva maintains a continuously updated data map — a record of every table, column, and file that holds a given individual's data. When an erasure request arrives, the platform generates a deletion checklist covering all locations in seconds, enabling your team to execute and document the deletion well within the 30-day window expected under the Act.

The Digital Personal Data Protection Act 2023 threatens to hit organisations with massive fines up to ₹250 crore if they get it wrong, and the Data Protection Board of India has the power to really make an example of people who aren't playing ball — with graduated sanctions that only get worse depending on how bad things are. But data discovery makes a big difference here because it shows the Board that your organisation has got the "reasonable security safeguards" nailed under Section 8(4), that you know where all your data is, and that you can get on top of data principal requests before they blow up in your face — all of which are big tick boxes for the Board when it comes to making their decisions.

Both active and passive data discovery try to track down personal data within an organisation, but they go about it in very different ways. Active data discovery involves directly connecting to data sources via credentials and running structured queries or file-system traversals to identify personal data in real time. Passive discovery analyses network traffic, query logs, or audit trails to infer what data exists and how it flows between systems — without touching the data stores directly. Consiva primarily uses active discovery for accuracy, supplemented by passive log analysis to identify data that moves through APIs and microservices.

For a typical mid-market organisation with 10 to 50 database schemas and under 500 GB of structured data, Consiva's initial scan completes in 2 to 6 hours. Larger enterprises with multiple data warehouses and unstructured file stores may require 24 to 48 hours for the first full scan. Subsequent incremental scans run on a configurable schedule and typically complete within 15 to 30 minutes as they only re-examine changed tables and newly created files.