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 is not an interpretation of the Act and not an assessment of your compliance position. It 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

What this is, and what it is not

Said here rather than at the bottom, because the distinction changes what you should do with everything below it.

Read this first

A detection capability, described. Not an opinion on your obligations.

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.
What it is not: It 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, and no finding should be read as saying that it does.
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. None of them is a conclusion about your compliance position, and the third column is deliberately the narrowest claim we can make rather than the widest.

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 the personal data behind that account has been reached by anyone else is a separate question, and monitoring on its own does not answer it.
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
This is the category people most often assume is private, because nobody chose to publish it. It became public through a link, a default setting or a directory listing rather than a decision.
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 the personal data behind that account has been reached by anyone else is a separate question, and monitoring on its own does not answer it.

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

This is the category people most often assume is private, because nobody chose to publish it. It became public through a link, a default setting or a directory listing rather than a decision.

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, which is what 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 and nothing more than that.
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 and should not be treated as though it did.
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 rather than presented as though it had been.
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 rather than in an inbox.

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, and the one that says nothing was tested says exactly that.

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 — your 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 and not a monitoring output.
Where a credential was tested, its state says what was tested and what came back. Where it was not tested, it says that instead of implying a result.
Regulatory Intelligence tracks advisories and directives as programme context for your team. It is context, never 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. That is the determination this page deliberately does not make.
Any assertion that using ShadowMap makes an organisation compliant with the Digital Personal Data Protection Act, 2023. No monitoring product can do that, and one that claims it is offering a legal opinion it is not qualified to give. 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 attributed to an owner, and tested for whether what is inside still opens anything. Dark Web Monitoring Stealer-log and breach material collected first-hand rather than resold, so a credential tied to a customer or staff identity arrives carrying a state instead of arriving as a row. Regulatory Intelligence Advisory and directive tracking across regulators and jurisdictions, supplied as programme context for your own team — never as a reading of the law on your behalf.

Looking for ShadowMap's own position under the Act — Data Fiduciary and Data Processor roles, residency, grievance redressal? That is the DPDP compliance page, and it is about our processing rather than yours. Looking for the readiness work itself — applicability, consent, rights workflow, processor due-diligence? That is DPDP advisory at Security Brigade, and it is a different 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. It is not the determination.

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

No. That is the determination this page deliberately does not make, and it 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 that is a separate exercise with separate tooling, and we would rather say so than imply coverage we do not have.

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

Counsel advises on a fact pattern, and assembling the fact pattern 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 rather than reconstructed by hand during an incident.

How is this different from your DPDP compliance page?

They answer opposite questions. 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, not ours, and it describes a detection capability rather than a legal posture. Neither 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 — and to be clear, it is a detection snapshot, not a compliance assessment.

Request an exposure snapshot See Data Exposure Monitoring