The Compliance Problem Is Actually an Access Problem
Most organizations treat compliance as a reporting challenge: pull the logs, chase the approvals, reconstruct who had access to what and why. But by the time you’re doing that reconstruction, the real problem already happened weeks, months, or years earlier.
We sat down with Samantha Hamernick to talk about why audit time is so painful for so many organizations, and what it actually takes to build compliance into the access model itself — so that proving it becomes a byproduct, not a fire drill.
An over-provisioning problem, not a reporting one
When compliance teams scramble at audit time, the instinct is to blame the tooling — better dashboards, better logs, better reports. Hamernick sees it differently.
“It’s more of an over-provisioning problem,” she said. “Not knowing who has access to what because of the amount of over-provisioning that’s happening.”
Scale makes this worse, not better. As Hamernick put it, if a company has 20,000 users and a million data sources, proving compliance is a lot easier when that population of users has access to less data. The traditional group-based, rule-based model works against that. Every new permutation of access tends to spawn a new group or role — and when that feels like too much overhead, the shortcut is to drop someone into a group that already exists, even if it grants more than they need. “And then at compliance time,” Hamernick said, “suddenly this person has access to half of the data in your platform.”
The PII exercise nobody trusts
Ask a large enterprise a simple question — who has access to our PII? — and you’d expect a simple answer. In practice, Hamernick has seen that exercise take a team of analysts five full days just to begin to determine the answer. And even then, the results aren’t trusted, partly because the process took so long that something has likely already changed by the time it’s done.
Much of this traces back to the recertification process most large companies rely on: an email every six to twelve months listing Active Directory groups, asking someone to confirm whether access is still needed. The problem, Hamernick explained, is that this is often the entire mechanism for determining PII access — and it doesn’t actually work. An AD group doesn’t tell you what it grants access to on its own; someone has to trace it back through the platform to find out. One group might have nothing to do with PII; another might have everything to do with it. “It’s like an impossible process to actually do,” she said. Which means most organizations don’t actually know whether they’re in compliance — they’re just hoping the recertification email caught everything.
Why stale access never gets cleaned up
Standing access piles up quietly. Hamernick described the common scenario: someone is removed from a group that appears to grant access to a given table, but they still have access afterward — because some other group is also granting it, and nobody realized. Teams often don’t even check whether access was actually revoked; they assume the job is done and move on.
This is compounded by tenure. Employees who’ve been at a company for ten or fifteen years, and changed roles multiple times, often still carry access that mapped to a job they had seven years ago. Nobody set out to create that risk. It’s simply what happens when access is granted manually, in pieces, over years, with no single source of truth for why someone has what they have.
Recertification: Mass approval, mass error
There’s a real difference between access that was granted correctly at the time and access that’s still appropriate today. Most organizations handle that gap through the same recertification email process — and, in Hamernick’s experience, it doesn’t hold up well. People approve requests en masse because they don’t want to be the one who takes something away and upsets a colleague. “I would say eighty percent of that is probably error,” she said, describing the mass approval of AD group access as the direct reason people still have access they were granted years earlier.
Her prescription has two parts. First, reduce how often recertification has to happen at all by putting some of the burden on time itself: give access an expiration date that arrives before the recertification cycle would — ideally, one that’s tied to when the access is actually still needed, not an arbitrary calendar date. Second, look at usage. If someone hasn’t queried a dataset in a month, that’s a strong signal their access can be pulled — ideally automatically — so that by the time a recertification review happens, it’s a short list of people who’ve demonstrated they actually need the data, rather than a long list nobody has the appetite to challenge.
Multiple platforms, multiplied risk
Data rarely lives in one place, and that reality changes the shape of the compliance problem entirely. Without a consistent approach across platforms, organizations end up writing different policies platform by platform. The request and approval process looks different everywhere too — a ticket in one system, a role in another, a Slack message and a manual grant somewhere else. And often, the people who understand the audit records in each of those platforms aren’t the same people, and don’t report to the same person. “This siloed part,” Hamernick said, “means that you are compounding the amount of recertifications and compliance and audit efforts.” It’s not additive — it’s exponential.
AI widens who’s asking for access
Traditionally, access to a platform like Snowflake was granted to a well-defined, technical group of people doing a well-defined job. AI changes that population. As Hamernick described it, the moment access extends beyond technical users to people who are simply asking questions of an AI agent — “pull all the data that I have access to and give me a summary of it” — the profile of who’s requesting access, and how much, expands well beyond what compliance teams have historically had to plan for. A non-technical user isn’t running a careful, scoped query; they’re asking broadly and letting the system figure out what it can reach. That’s a materially different — and larger — access surface for already-stretched compliance teams to reason about.
Where continuous compliance starts
Asked where organizations should start if they want to move from reactive compliance to something continuous, Hamernick’s answer began with visibility: get to a place where you can know, at any point in time, who has access to what — not just when an audit forces you to find out. That starting point tends to be uncomfortable. Once teams actually see the current state of their access landscape, the natural reaction is concern, followed quickly by a push to reduce it — masking sensitive data as a first, immediate step while a longer-term fix takes shape.
The pattern Hamernick has heard repeatedly from multi-platform teams is a desire for something that sits above the individual platforms and governs access consistently across all of them — separating policy from any single platform, and layering in automation, rather than solving compliance one system at a time. As she put it, most organizations using one modern platform are also using another, and what they’re asking for isn’t a better report generator. It’s a way to know what’s happening before the audit ever begins.
The takeaway
Every one of these problems — the five-day PII exercise, the rubber-stamped recertifications, the standing access nobody remembers granting, the compliance question that has a different answer on every platform — traces back to the same root cause: access that isn’t policy-driven, time-bound, or consistently tracked. Better reporting can’t fix that. It can only tell you, after the fact, how bad it already is.
The organizations that get ahead of this aren’t the ones with the best audit dashboards. They’re the ones that stopped treating access as a one-time grant and started treating it as something that has to continuously earn its place — proven not because someone reconstructed it under deadline, but because the system was built to prove it all along.
FAQ
Why do organizations struggle at audit time if they already have reporting tools?
Because the problem doesn’t start with reporting — it starts with over-provisioning. If people have access to more data than they need, no report can make that easy to explain. Better logs and dashboards can only describe a messy access model in more detail; they can’t clean it up.
What does a “who has access to PII?” exercise typically reveal?
At many large enterprises, this exercise can take a team of analysts several days just to begin to answer, and the results still aren’t fully trusted once delivered. It usually reveals that access recertification — the periodic review most companies rely on — isn’t actually capable of confirming PII access, because reviewers are approving abstract group names without visibility into what those groups actually grant.
Why is stale or standing access so hard to clean up?
Because it’s often granted through multiple, overlapping paths — group memberships, roles, one-off manual grants — and removing one path doesn’t guarantee access is actually revoked. Without a clear record of how access was granted, teams can’t confidently confirm it’s been removed. That’s part of why employees who’ve changed roles multiple times over many years often still carry access tied to jobs they no longer hold.
How does having data across multiple platforms affect compliance?
It compounds the problem rather than adding to it. Different platforms tend to have different policies, different request-and-approval processes, and different people managing the audit records — often without a shared owner. That fragmentation multiplies the effort required to answer even basic compliance questions.
How is AI changing compliance and access requirements?
AI is expanding who requests access, not just how much is requested. Historically, access to a given platform went to a well-defined technical group. Now, non-technical users can prompt an AI agent to pull and summarize everything they have access to — broadening the population that compliance teams need to account for, well beyond what recertification processes were designed to handle.
What’s the first step in moving from reactive to continuous compliance?
Visibility. Organizations need to be able to see who has access to what at any given time — not only when an audit forces the question. From there, most teams find they’re over-provisioned and need to reduce access and apply protections like masking, ideally through an approach that applies policy consistently across platforms rather than one system at a time.
