India · DPDP Act · Detection evidence, not legal advice

The Digital Personal Data Protection Act is a legal question. Whether your customers' data is already public is not.

This page describes one narrow, factual thing external monitoring can establish: which personal data belonging to your organisation, your customers or your staff has already left your control and is reachable from outside it, and what evidence you are handed when it has.

Request an exposure snapshot DPDP advisory at Security Brigade

Scope of this page

Where this page stops

The boundary changes what you should do with everything below it.

Read this first

What monitoring detects, and who owns the legal call

What it describes: Personal data that has already left your organisation’s control and is now reachable from outside it: leaked credentials tied to customer or staff identities, storage that answers without authentication, documents a search engine has indexed, and source repositories carrying customer records. Each of those is an observable fact about a system on the public internet.
Where it stops: This is not legal advice, and it is not a reading of the Digital Personal Data Protection Act, 2023. Nothing here tells you whether a given exposure is a personal data breach under the Act, whether a notification duty arises, who would have to be told, or on what timeline. ShadowMap does not make an organisation DPDP-compliant.
Where the statutory question belongs: With your legal counsel and whoever owns data protection in your organisation, with the evidence in front of them. What monitoring contributes is that evidence: specific, attributable and repeatable. Where the readiness work itself needs doing (applicability, consent, rights workflow, processor due-diligence), that is an advisory engagement, and Security Brigade runs it on a separate site under a separate scope.

What is detectable

Four kinds of personal-data exposure that are visible from outside

Every row is an observation about something publicly reachable. The third column says what monitoring establishes about it, and stops there.

External personal-data exposure: what is observed, and what it does and does not establish
What is exposed	Where it surfaces	What monitoring can establish	Covered by
Credentials tied to identities	Stealer logs and breach corpora	Which account the credential belongs to, whether the identity is corporate, customer or partner, and, where it is safe and authorised to test, whether it still authenticates.	Dark Web Monitoring
A credential is evidence about an account, and usually about the machine it was taken from. Whether anybody else has reached the personal data behind that account is not something monitoring can tell you.
Storage readable without authentication	Object storage, buckets and containers	That the container responds to an unauthenticated request from the public internet, and which of your domains, brands or suppliers it attributes to.	Data Exposure Monitoring
Attribution is the load-bearing half. An open container is only your problem once it has been established as yours, your customer's or your vendor's. Before that it is somebody else's finding.
Documents indexed by search engines	Public search indexes and the open web	That a document is retrievable by anyone who searches for it, and which of your properties published or linked it.	Data Exposure Monitoring
People assume this category is private, because nobody chose to publish it. A link, a default setting or a directory listing made it public.
Records inside public repositories	Public code repositories and their history	That the repository is public, that it carries records or credentials belonging to your systems, and whether it maps to an application you are actually running.	Data Exposure Monitoring
The correlation is what makes this actionable: a repository is compared against your live attack-surface endpoints to establish whether the leaked code belongs to a running production application.

External personal-data exposure: what is observed, and what it does and does not establish

Credentials tied to identities

Where it surfaces: Stealer logs and breach corpora
What monitoring can establish: Which account the credential belongs to, whether the identity is corporate, customer or partner, and, where it is safe and authorised to test, whether it still authenticates.
Covered by: Dark Web Monitoring

A credential is evidence about an account, and usually about the machine it was taken from. Whether anybody else has reached the personal data behind that account is not something monitoring can tell you.

Storage readable without authentication

Where it surfaces: Object storage, buckets and containers
What monitoring can establish: That the container responds to an unauthenticated request from the public internet, and which of your domains, brands or suppliers it attributes to.
Covered by: Data Exposure Monitoring

Attribution is the load-bearing half. An open container is only your problem once it has been established as yours, your customer's or your vendor's. Before that it is somebody else's finding.

Documents indexed by search engines

Where it surfaces: Public search indexes and the open web
What monitoring can establish: That a document is retrievable by anyone who searches for it, and which of your properties published or linked it.
Covered by: Data Exposure Monitoring

People assume this category is private, because nobody chose to publish it. A link, a default setting or a directory listing made it public.

Records inside public repositories

Where it surfaces: Public code repositories and their history
What monitoring can establish: That the repository is public, that it carries records or credentials belonging to your systems, and whether it maps to an application you are actually running.
Covered by: Data Exposure Monitoring

The correlation is what makes this actionable: a repository is compared against your live attack-surface endpoints to establish whether the leaked code belongs to a running production application.

From detection to evidence

What you are actually handed when personal data is found outside

The order is the argument. Each step narrows what the next one is permitted to say, and that keeps a finding usable by somebody who has to make a legal decision on top of it.

Detected

An artefact is found outside your perimeter

A credential in a stealer log, a container that answers without authentication, an indexed document, a public repository. At this point it is an observation about a system on the public internet.
Attributed

Established as yours, your customer's or your supplier's

Exposure is split by whose it is (corporate, customer or partner) and tied back to the domain, brand or supplier it belongs to. An unattributed finding says nothing about your organisation.
Tested

Probed, where it is safe and authorised

Continuous Automated Red-Teaming establishes whether a leaked credential or key still opens something. Not everything is testable, and anything that was not tested is labelled as not tested.
Routed

Into the system your privacy and security work already runs in

Findings route to Slack, Jira, ServiceNow or your SIEM with the case attached, so the record of what was found sits somewhere you already keep records.

The state a credential carries

"Leaked" is not one condition

Where a leaked credential is tied to a customer or staff identity, the useful question is not whether it exists but whether it still opens the account behind it. Every credential carries one of four published states, including one for credentials nobody tested.

Credential states, read as a question about whether personal data behind an account is currently reachable
State	What it means	What follows
Confirmed Working	Probed, and it authenticated. The account, and whatever personal data sits behind it, is reachable with this credential now.	Rotate, check for session persistence, and put it in front of whoever owns the legal decision.
Maybe Working	Probing was inconclusive: rate limiting, an MFA interstitial, or a response that could be read either way.	Treat it as live until somebody on your side has checked it.
Not Working	Probed and rejected. The credential is stale against this service.	Still evidence that a device was compromised. The endpoint is the finding now, not the password.
Not Tested	Outside authorised scope, or no safe probe exists for the service in question.	Nothing is implied about it in either direction. Verify it internally.

Key

Reachable now
Assume reachable
Not reachable with this credential
Unknown, and yours to check

Boundaries of the evidence

What a finding here does not settle

How to read a finding on this pageCaution As of August 2026

Detection establishes that an artefact is reachable from outside your organisation. It does not establish that anybody other than us reached it.
Attribution establishes which domain, brand or supplier a finding belongs to. Whether the individuals behind those records are data principals under the Act, and what follows if they are, is a legal determination.
Where a credential was tested, its state says what was tested and what came back. Where it was not tested, it says that.
Regulatory Intelligence tracks advisories and directives as programme context for your team, not as a reading of the law on your behalf.

Deliberately excluded

Any statement about whether a given exposure is reportable, to whom, or on what timeline.
Any assertion that using ShadowMap makes an organisation compliant with the Digital Personal Data Protection Act, 2023. No monitoring product can do that. The readiness assessment is Security Brigade's work, on a separate site, priced separately.
Personal data held correctly inside your own systems. Everything described here is observed from outside; internal data discovery and classification is a different exercise with different tooling.

Where this evidence comes from

Three parts of the platform, one correlated exposure model

Data Exposure Monitoring Public repositories, storage that is readable without authentication, and documents a search engine has indexed. Each is attributed to an owner, and tested for whether what is inside still opens anything. Dark Web Monitoring Stealer-log and breach material we collect first-hand, not resold, so a credential tied to a customer or staff identity arrives carrying a state, not just a row. Regulatory Intelligence Advisory and directive tracking across regulators and jurisdictions, supplied as programme context for your own team. It is not a reading of the law on your behalf.

ShadowMap's own position under the Act, covering Data Fiduciary and Data Processor roles, residency and grievance redressal, sits on the DPDP compliance page. That page covers our processing, not yours. The readiness work itself (applicability, consent, rights workflow, processor due-diligence) is DPDP advisory at Security Brigade, a separate engagement from anything described here.

Questions this page gets asked

Before you take this to counsel

Does ShadowMap make my organisation DPDP-compliant?

No, and no monitoring product does. A position under the Digital Personal Data Protection Act, 2023 depends on how you collect, process, store, retain and account for personal data across your whole estate, most of which sits inside your perimeter, where external monitoring does not look. What we contribute is narrower and factual: evidence about personal data that has already left your control and is reachable from outside. That evidence is useful to the people making the compliance determination.

Can you tell me whether a given exposure is a reportable breach?

No. That determination belongs with your legal counsel and whoever owns data protection in your organisation. What we can hand them is the fact pattern underneath it: what is exposed, which of your domains, brands or suppliers it attributes to, whether a leaked credential still authenticates where it was safe and authorised to check, and when it became visible to us. The reporting decision is made on top of that, by people qualified to make it. If you have no one holding that brief yet, Security Brigade runs DPDP readiness as an advisory engagement.

What kinds of personal data can you actually see?

Only what is observable from outside your organisation. In practice that means credentials tied to corporate, customer or partner identities; storage that answers an unauthenticated request; documents a search engine has indexed; and records carried inside public source repositories. Personal data sitting correctly inside your own systems is invisible to external monitoring by design. Discovering and classifying it is a separate exercise with separate tooling.

Our privacy counsel already advises us. What does this add?

Counsel advises on a fact pattern, and assembling it is usually the slow part: what is out there, whose it is, and whether it still works. Continuous external monitoring means that question is already partly answered before anybody has to ask it under time pressure, and answered the same way each time. Nobody has to reconstruct it by hand during an incident.

How is this different from your DPDP compliance page?

Our DPDP compliance page sets out ShadowMap's own position under the Act: our Data Fiduciary and Data Processor roles, residency, grievance redressal and the rest. This page is about your estate, and it describes what monitoring detects. Neither page is an assessment of you; that work sits with Security Brigade.

Find out what of your estate is already readable from outside

One apex domain, two business days, a written snapshot of the assets, credentials, leaked code and impersonating domains already visible. No call required.

Request an exposure snapshot See Data Exposure Monitoring