Data discovery · DPDP s.8(4), s.8(5)

Know what you hold.

You cannot give notice for data you do not know you have, or erase it, or report a breach of it. Nyvika reads the systems a business actually runs, finds Indian personal data, and keeps an inventory your other obligations depend on.

s.8(4) Accuracy & completenesss.8(5) Safeguards13 identifier types
The inventory: each data store with its findings, risk score and connection status
The challenge

The spreadsheet of systems is always out of date.

Every obligation starts with knowing where personal data is. Most organisations know roughly; the Act asks for enough precision to erase it and to say what was breached.

Unknown copies
The export someone kept
A CSV in a shared drive, a backup table, a test database restored from production. The data that gets breached is usually the data nobody listed.
Indian identifiers
Aadhaar, PAN, UPI, voter ID
Generic scanners know credit cards and emails. Indian identifiers have their own formats and checksums, and they are what the Board will ask about.
Minimisation
Data no purpose needs
Section 8(4) and the principle of purpose limitation mean data held without a purpose is a liability. You can only find it if you can see it.
What Nyvika does

Read-only, bounded, real.

Connectors sample, they do not copy. Limits on tables, rows, objects and document size keep a scan quick and safe.

Ten sources

Databases, object stores, drives, warehouses and your connected CRM.

  • PostgreSQL, MySQL, MongoDB
  • S3 and S3-compatible, Azure Blob, Google Drive, SharePoint
  • BigQuery, Snowflake, CRM objects

Indian identifiers

Thirteen types with format and checksum validation and context scoring to cut false positives.

  • Aadhaar, PAN, passport, voter ID, UPI
  • Bank account, card, phone, email, date of birth
  • Address, name, IP address

Inventory and map

Each store with its findings, risk score and the purposes it serves; a data-flow map from purposes to stores to processors.

  • Record of processing generated from the registers
  • Minimisation flags where a store holds data no purpose needs
  • Feeds breach impact and impact assessments

Import

Already run a discovery or data-security tool? Import its inventory as CSV or JSON and keep using it.

  • Findings marked as imported with their source
  • Same inventory, same reports
  • No second scanner to pay for
Credentials

Sealed per store.

Connection credentials are encrypted in the vault and bound to the asset they belong to. Scans run in the background and sample under fixed limits.

  • Bounded sampling

    At most 200 tables, 20 rows per table, 500 objects and 64 KB per document in a scan.

  • On demand

    Scan one store or all of them from the console; findings keep their first-seen and last-seen dates.

  • Honest limits

    Text and column names are read; images, scans and audio are not. Continuous scanning is on the roadmap.

The data-flow map: purposes on the left, data stores in the middle, processors on the right
One ledger

How it connects.

Every module writes to the same registers and the same hash-chained evidence, so nothing is re-keyed and nothing is lost between teams.

Questions

Asked about discovery.

Does Nyvika copy our data?

No. A scan reads a bounded sample, classifies it, and stores the finding (which identifier types, how many, where), not the values. Credentials are encrypted and used only for scans you start.

Can it scan on a schedule?

Scans are started from the console or the API in this release. A per-store schedule is on the roadmap; most customers scan monthly and after any new system goes live.

We use a data-security platform already.

Keep it. Export its inventory and import it into Nyvika, so breach response, assessments and the record of processing use what it found.

Still have a question? Write to us.

Scan one real database in the demo.

Bring read-only credentials for a test copy of a database or a bucket; you will see findings in minutes.