Somewhere in the estate is a bucket named something like customer-data-migration-temp-2023. The migration finished years ago. The bucket did not. Whether it is a non-event or a genuine problem comes down to two questions: what is in it, and what can reach it.

A useful S3 review begins with inventory and scope. List the buckets that matter, identify owners, separate production data from exports and test data, and decide whether you need broad automated discovery, targeted discovery jobs, or both.

Macie's automated or targeted discovery will find likely sensitive data. Treat the results as a decision aid, not a verdict. Sensitive data discovery becomes security work only when it changes access, retention, ownership, or remediation decisions.

Check coverage before trusting completeness. Unsupported objects, content that cannot be analyzed, excluded buckets, sampling limits, and stale inventories all create blind spots. A clean report is not proof that no sensitive data exists.

Then combine sensitivity with exposure. Block Public Access settings, bucket policies, access points, cross-account access, broad roles, external principals, replication paths — the point is not to audit each in isolation, but to find where they touch the buckets the discovery flagged.

Encryption counts only when key access is understood. Review key policies, grants, and administrative access, and ask whether broad identities can decrypt the same data the bucket review just flagged as sensitive.

Ownership and retention close the loop. A bucket of old exports and forgotten logs often has no application owner — and if nobody owns the data, nobody is making the risk decision about access, retention, deletion, or masking.

The risky bucket is the one where sensitive content and reachable access overlap. Likely PII plus broad roles plus unclear retention plus no owner should move ahead of a well-owned bucket with narrow access and documented retention.

Remediation should be specific: narrow the policy, remove stale principals, fix key access, verify Block Public Access, delete data that should not exist, move exports to controlled locations, and assign an owner for recurring review.

What to check now: for every bucket where PII and reachable access overlap — owner, classification, public and cross-account paths, key policy, retention rules, and an open remediation ticket.

S3 is not the whole PII problem, but it is the right place to start. It is where exports, logs, analytics, backups, and forgotten copies of sensitive data tend to land.