Data Governance: The Gap Between What Your Policy Says and What's Actually Happening

An auditor asks to see your data retention policy. You pull it up. It's clean. It's dated. It has a version number and a signature block.

Then the auditor asks a second question: who follows it?

The room gets quiet.

Someone mentions that sales still exports customer lists to personal spreadsheets for quarterly reviews. Someone else remembers that a contractor from two projects ago still has access to the shared drive. Nobody deleted the files the policy says should have been deleted eighteen months ago.

The policy was never wrong. The business just kept moving after it was written, and the policy didn't move with it.

Why a Policy Feels Like Enough

Most leadership teams believe that having a documented policy means they are governed. The document exists. It was reviewed. It sits in a folder everyone can point to.

It's an easy belief to hold. Writing a policy is a project with a finish line. You can schedule it, complete it, and check it off. Governing the daily behavior of every system, vendor, and employee never finishes.

A policy nobody follows is a description, not a control.

Documentation also feels like progress because you can show it to someone. A board, a customer, an insurer. It answers "do you have one of these" with a confident yes. What it can't answer is what's happening right now, in the tools your team uses, under the deadlines they're working against.

How the Gap Opens

The business kept adding tools after the policy was written. A new SaaS platform here. A file-sharing shortcut there. An exception granted during a busy quarter that was supposed to be temporary and never got revoked.

None of it shows up as a violation on paper, because nobody updated the paper. Each department builds its own workaround for the parts of the policy that slow it down, and the workarounds don't wait for permission.

By the time anyone notices, the written policy and the actual practice are describing two different companies.

AI Agents Are the Newest Version
of This Gap

AI agents didn't create this problem. They inherited it and sped it up.

An agent connected to your systems gets whatever access it's given at setup. That decision gets real scrutiny once. Then the agent's role expands, or someone connects one more tool to save a step, and nobody goes back to ask whether the original grant still fits.

It's the same drift as the retention policy nobody enforces. It just moves at agent speed instead of headcount speed.

The UK AI Security Institute, a government body that tests frontier AI models, published an incident report this summer that shows the shape of the problem. During a testing exercise, researchers deliberately gave AI agents open internet access to see what the models could do under loose conditions. That access decision was documented and intentional. What lagged behind was oversight built to watch what the agents did with the access while they were doing it. General security monitoring caught the unusual activity after it started, and the team shut it down within about an hour. But nothing was watching the evaluation as it ran.

These were test conditions, far looser than how these models ship to the public. That should make the lesson land harder, not softer. If a government evaluator with a documented, deliberate access decision didn't have eyes on what happened next, what are the odds your business does?

Granting access is a decision. Watching what happens with it is a different decision, and it has to be made continuously.

The same discipline that governs a data policy applies to every agent you connect to a system: know what it's authorized to touch, watch continuously that it isn't touching more, and revisit that authorization on a schedule instead of assuming the first grant still holds.

The Real Cost of the Gap

The cost shows up at the worst moment: during an incident, an audit, or a customer's security questionnaire.

A breach investigation doesn't ask what your policy says. It asks who had access, why, and for how long. If the policy says three roles should have access and the real answer is twelve people, and nobody's sure why, you haven't just failed a technical control. You've shown a regulator or an insurer that your documented control was never operational.

Under FTC rules, stating a control you don't follow can itself be the violation. The promise creates the liability. Companies have paid nine-figure penalties for the gap between what the policy said and what the systems did.

Vendor and customer due diligence works the same way. A prospect's security team wants evidence the policy is practiced, not just the document. A mismatch there costs deals, not just audit points.

A Better Way

Governing the practice matters more than governing the document. Every policy needs a second, quieter question attached to it: how do we know this is happening?

Three things make that answer real instead of assumed:

  • Written control. The policy exists, is current, and reflects how the business operates today, not how it operated when the policy was drafted.
  • Practiced control. The behavior in the systems matches the words on the page. Access matches the roles that are supposed to have it. Retention schedules actually delete what they say they'll delete.
  • Verified control. Someone checks, on a schedule, that written and practiced still match. Not once a year before an audit. On a cadence that catches drift before it becomes a finding.

Most organizations have the first. Few have the third. The third is the one that protects you.

How InsITe Approaches It

We treat a governance policy as a living operational document, not a compliance artifact. That means building the verification step in from the start instead of bolting it on after an audit finding forces the question. We look at what's actually happening in the environment before we prescribe a policy to fix it. A policy built on the real workflow survives contact with the business.

Where This Leaves You

The policy on the shelf was never the problem. The distance between it and the Tuesday afternoon reality of how your team handles data is the problem.

Before your next audit finds that distance for you, ask two questions. When did anyone last check whether practice still matches policy? And if an investigator asked for the evidence instead of the document, what would they find?

 

ABOUT INSITE BUSINESS SOLUTIONS:

Most West Michigan manufacturers know they need to connect their shop floor systems with their business systems. But figuring out how to bridge that gap is like playing vendor roulette. They often end up picking either an IT shop or an automation house, or a combination of both. 

InsITe has IT and OT engineers on staff. One call, one team, one point of accountability across the full tech stack. Before we recommend anything, we walk your shop floor and then design the solution, execute the implementation, and own the outcome through managed services, security, and ongoing support. 

If you're looking for IT or OT help from people who understand the ins and outs of manufacturing, we can help. 

Talk to an Advisor Today →

Back to Blog