mentation. The gap between what the policy intended and what the system actually does is not a failure of either the policy writers or the engineers. It is a structural feature of governance programs that treat policy approval as implementation evidence.
How the Gap Forms
A data retention policy is written specifying that personal data must be deleted after three years. The policy is approved by the DPO, reviewed by legal, and communicated to the engineering teams responsible for the systems that hold personal data. Each engineering team receives the policy and assesses how to implement it in their system. Some implement automated deletion. Some implement a manual review process for deletion that runs when someone remembers to run it. Some note the policy requirement in their backlog and prioritize it below operational features for the next eight quarters. Some discover that their system cannot selectively delete records by age without rebuilding the data model and defer indefinitely.
Three years after the policy was approved, four different systems have four different retention implementations, ranging from automated compliance to documented non-compliance to undocumented partial implementation to a belief that the policy does not apply to this system because the data is technically log data rather than personal data. The policy is the same across all four. The system behaviors are different. The governance program has documented the policy. It has not measured the implementation.
Policy approval is the beginning of governance, not the evidence of it. The evidence of governance is the measured state of the systems the policy was designed to govern.
The Systems That Diverge Most
Legacy Systems That Predate the Policy
Policies written for current operational requirements are applied to systems built under different requirements. A legacy system whose data model was not designed for selective deletion cannot implement a granular retention policy without architectural change. A legacy authentication system whose access control model does not support the granularity required by a least-privilege policy cannot implement the policy without replacement. The policy is valid. The system cannot meet it. The gap persists until the system is modernized or replaced, which may be years away.
Third-Party Systems Governed by Vendor Implementation
SaaS applications implement data handling according to their own architecture, not according to the customer's policy. A retention policy that specifies three-year deletion does not cause a SaaS vendor to delete data after three years unless the vendor's platform has a mechanism for customer-configurable retention and the customer has configured it correctly. The policy's requirement flows to the vendor through the DPA. Whether the DPA's requirements are implemented in the vendor's system is a verification question that most organizations have not answered.
AI Systems Whose Behavior Emerges From Training
AI systems do not behave according to policy documents. They behave according to what they learned from training data and how they were fine-tuned. A data minimization policy that specifies collection of only necessary personal data does not cause an AI model to decline to process personal data it encounters in inputs. A purpose limitation policy does not cause an AI model to refuse to use personal data for purposes beyond the original collection purpose. The policy governs the decision to deploy the AI system and the constraints placed on its use. It does not govern the model's internal behavior.
Closing the Gap
The governance investment that closes the policy-to-system gap is verification: measuring the actual behavior of systems against the policy's requirements and producing evidence that confirms compliance or identifies deviation. This requires technical assessment capability — the ability to query systems about their actual configuration and behavior, not about their documented intended configuration and behavior.
For retention policies, verification means confirming that the deletion or anonymization process actually runs on the specified schedule and actually removes the specified data categories. For access control policies, verification means confirming that the access controls actually enforce the specified permissions and that no undocumented access paths exist. For data minimization policies, verification means confirming that the forms and APIs that collect data actually enforce the specified field limits.
The organizations that have closed this gap have built technical verification into their governance cycles alongside policy review. Policy review confirms that the policy remains appropriate. Technical verification confirms that the policy is being followed. Both are necessary. Most programs have only the first.
Measure the system against the policy. The policy describes the intent. The system's behavior is the evidence.
Approve the policy. Then verify the system. The distance between them is the governance gap that matters.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.