How the exposure happens
Very little of this is adversarial. A developer needs an image served to a browser and makes the container public because that works immediately. A data team shares an export with a partner and grants broad read because scoping it properly takes a ticket. A legacy static site is migrated with its permissions intact. A backup lands in a bucket whose policy was written for something else.
In each case the exposure is created once, satisfies an immediate need, and is never revisited, because nothing breaks and nothing alerts. Discovery is trivial for anyone looking — storage endpoints are predictable and continuously enumerated by third parties.
Finding it across an estate
Every major platform exposes the information needed to answer "what is publicly readable" through its own API, and the native configuration-compliance services will report it continuously. The work is less technical than organisational: enumerate the accounts, subscriptions and projects that actually exist, including the ones created for a proof of concept and never decommissioned.
Shadow accounts are the common gap. An inventory built from the billing relationship rather than from memory is the only reliable starting point, and it frequently surfaces environments nobody currently owns.
- Enumerate all accounts, subscriptions and projects from the billing root, not from documentation.
- Enable the platform’s configuration-compliance service in every region in use, not only the primary one.
- Alert on the transition to public, rather than reporting the state monthly.
- Record an owner for every storage container; unowned containers are the ones that stay exposed.
Preventing recurrence structurally
Turn on the account-level public-access block. On the major platforms this is a single setting that prevents individual containers from being made public regardless of their own policy, and it is the highest-value control available here. Where a genuine public-serving use case exists, isolate it in its own account with an explicit exception, so the default stays safe everywhere else.
For the legitimate need that drove most of these decisions — serving a file to a specific person for a limited time — use pre-signed or time-limited URLs, or a content delivery network with an origin that is not itself public. This covers the overwhelming majority of cases and removes the incentive to loosen the policy.
Finally, put the check in the pipeline. Infrastructure-as-code policy scanning catches a public bucket at pull-request time, which is an order of magnitude cheaper than catching it in production and immeasurably cheaper than catching it in a disclosure.
If data was exposed
Close the exposure, then establish scope before anything else: what objects were present, for how long, and what access logs exist. Server access logging is often not enabled, which makes it impossible to say whether anything was retrieved — an answer that is itself material to the notification assessment and should be stated honestly rather than assumed either way.
If personal data was involved, the Data Protection Act’s notification duties engage, with the seventy-two-hour clock running from awareness. Document the timeline carefully: when the exposure began, when it was detected, when it was closed, and what the logs do and do not show. That record is what a regulator will ask for.
Take this with you
The PDF edition carries the same content, formatted for printing and circulation inside your organisation.
