Company data in a public storage bucket

Usually a misconfiguration rather than an intrusion, which makes the first question not how they got in but who else read it. Only access logs answer that, and they are off by default on most platforms, so find out at once whether they were on.

Trigger. A researcher, a journalist or a scanner reports a storage bucket, blob container or shared link that anybody on the internet can read.

The first 90 minutes1 of 5 expire

01 02 03 04 05

045 min90

01
Remove public access, and only that
by 10 minexpires
Block public access at the bucket or account level and revoke anonymous or shared links. Leave the objects and their versions where they are.
02
Find out whether access logging was on
by 20 min
For S3, server access logging or CloudTrail data events. For Azure, storage diagnostic logs. For Google Cloud, data access audit logs. If none was on, write that down now, because it changes what you can say later.

Tell somebody

Legal and the data protection lead, with the contents inventory
The researcher, with thanks and a timeline: how they are treated decides whether the next one tells you first
The owning team, on why it was public: a share set up for a partner that outlived its purpose is common

Drawn from

The documents these steps come from, so you can check one rather than take it on trust.

The evidence

What each source proves, and what it does not.

cloudtrail

Collect it in one go

A read-only script that gathers most of the above in volatility order, with a hash manifest.

Triage collection

Make it yours

Replace the escalation list with real names, and the timings with what your change process actually allows. A playbook that assumes an authority you do not have will stall at the step that needed it.

Remove public access, and only that

Find out whether access logging was on