Global supply chain & logistics · Across 112 AWS accounts
A global supply chain and logistics company had a problem that is more common than most leaders admit: no one could say exactly where the company's most sensitive data was kept, or who could open it. Over the years, customer records, carrier and supplier financials, and regulated shipping documents had spread across many places — S3 storage buckets, RDS and Aurora databases, and a long list of other data services. There was no single map of any of it.
That gap was already causing harm. When a major customer asked the company to prove its data was encrypted and kept separate from other clients' data, it took nearly two weeks to put together a shaky answer — long enough for the renewal talks to cool off. Auditors kept finding the same contradiction: data marked highly sensitive in one system sat openly readable in another, mostly because no one had agreed what “sensitive” even meant.
Four things were driving this, all about the data rather than the tools. There was no way to label data by how sensitive it was, so ordinary and highly sensitive information were protected the same way. Storage settings had drifted, so encryption, public-access controls, and backups were applied differently from place to place. Access was too broad — permissions (managed through AWS IAM) often gave far more reach than anyone could justify. And the company only looked for exposed data at audit time, so problems were always caught late.
We began with the data itself — using Wiz CNAPP plus hands-on review to build the first end-to-end inventory of sensitive data across all 112 accounts: what existed, where it sat, how it was stored, and who could reach it. That surfaced ~50 issues, ~25 Critical: sensitive data in public S3 buckets, databases without encryption at rest, plaintext secrets, and IAM roles with sweeping access.
On that map we put four data controls in place: a four-tier classification scheme (public / internal / confidential / restricted) tied to regulatory category; storage governance with KMS encryption at rest by default and enforced public-access blocks; least-privilege access validation across IAM and bucket policies; and continuous discovery rather than annual. Every finding was scored by data sensitivity and exposure together.
With the data foundation in place, we extended the same discipline to AI. Because classification already existed, AI guardrails plugged straight into it — acceptable-use keyed to data tiers (restricted data never leaves approved endpoints), prompt scrubbing for sensitive fields, and authentication for AI endpoints that had been sitting open. AI governance became an extension of data governance, not a separate exercise.
First complete map of sensitive data across the estate — 112 accounts, ~50 issues, ~25 Critical, each with a classification and owner
Established the enterprise's first data classification scheme, adopted across six business units
Brought storage to a consistent baseline (encryption at rest, public-access blocks) and cut exposed plaintext secrets by ~85% within 90 days
Tightened access to restricted data via least-privilege IAM and bucket-policy reviews
Defined the AI usage guardrail policy that became the AI acceptable-use standard
Leadership dashboards by data type, business unit, and regulatory category — turning a two-week scramble into a same-day answer
You cannot govern AI before you can govern data. Because classification, storage, and access came first, “what can this model touch?” had an answer grounded in a real data map — and the AI controls became a natural next layer rather than a separate fire to fight.