Personal Data Exposure Through Misconfigured Cloud Storage Buckets or Public Links

Teams routinely create cloud storage buckets (AWS S3, Azure Blob, Google Cloud Storage) or shareable file links to move data between internal teams, external vendors, or clients. Buckets are occasionally left with public or overly broad access permissions, and shareable links — once created — are rarely revisited, deactivated, or access-reviewed after their original purpose has passed.

1. Does a misconfigured storage bucket or an unreviewed shareable link containing personal data constitute a DPDP breach even without evidence of unauthorised access?
2. What organisational risks arise from decentralised, ungoverned bucket and link creation across teams?
3. What is the compliant approach to managing cloud storage and shareable-link access to personal data?

Not compliant as a standing practice.

DPDP requires organisations to implement reasonable security safeguards to prevent personal data breaches, which includes preventing avoidable misconfiguration. A bucket or link that is technically accessible to unauthorised parties — even if no exploitation has been confirmed — represents a failure of the security-by-design obligation, and in many cases the fact of exposure itself may constitute a reportable breach depending on what was exposed and for how long.

• Decentralised creation with no central inventory — Individual teams create buckets and links independently, with no central registry of what exists, what it contains, or who can access it — meaning the organisation cannot answer a basic question about its own data footprint if asked by a regulator or affected individual.
• Default-open configurations — Several cloud storage services default to broader access than intended unless actively configured otherwise, and a rushed or unreviewed setup by an engineer under deadline pressure is a common route to accidental public exposure.
• Stale links with no expiry — A shareable link created for a one-time transfer with a client or vendor frequently remains active indefinitely, discoverable by search engines or accessible to anyone who obtains the URL, long after the original recipient's need has passed.
• No detection mechanism — Without automated scanning for public buckets or stale links, exposure can persist for months or years undetected, extending both the duration and scale of the underlying compliance failure.

1. Enforce private-by-default policies at the account/organisation level. Configure cloud provider account-level settings to block public bucket creation by default, requiring an explicit, logged, and justified override for any exception.
2. Implement automated exposure scanning. Deploy continuous monitoring tools that scan for publicly accessible buckets and flag them for immediate remediation, rather than relying on manual review.
3. Mandate expiry on all shareable links. Configure shareable links containing personal data to expire automatically within a short, defined window, with any extension requiring a fresh, deliberate action rather than indefinite persistence by default.
4. Maintain a central data store inventory. IT and the DPO should maintain a registry of all buckets, drives, and shared repositories containing personal data, reviewed periodically, so that the organisation can account for where personal data resides at any point in time.

DPDP Risk Summary