During an infrastructure review, an engineer is reminded that customer-document storage must not be public. The setting is fixed and the check passes. A month later, someone enables public access directly in the cloud console. The rule exists, the test exists, and the documents are exposed anyway.
Policy as Code expresses a requirement in a form software can evaluate. Its value depends on where evaluation happens. Reviewing a file before deployment, preventing a live change and finding an existing violation are different capabilities. One should not be presented as evidence of all three.
Agree on what the rule means
“Do not allow insecure storage” is a reasonable intention, but an imprecise test. Which resources hold customer documents? What access is forbidden? Which exceptions are acceptable? People need to agree on permitted outcomes as well as violations.
Suppose the rule applies to resources labelled “customer data”. Who supplies that label, and what happens when it is missing? If authors can remove the label to escape evaluation, the control depends on voluntary participation. Perfect policy code can still examine the wrong resources.
Someone must own the requirement. Engineers can implement the check, but should not have to invent the company's rules for storing particular documents. Record those decisions separately and automate the conditions that can actually be expressed and observed.
Who acts on a denial?
A policy engine evaluates supplied information. Another component must enforce the result by rejecting a request, stopping deployment or merely displaying a warning. Open Policy Agent explicitly separates decision-making from enforcement. Installing the engine without connecting its decisions to an action protects nothing.
A build check provides early feedback. Enforcement at the production platform can cover changes outside that build path. Periodic inspection finds drift after it occurs. Each has different coverage and timing. Map the actual routes for change, including administrative consoles and emergency access.
Nor does a new prohibition necessarily repair existing resources. Kubernetes admission checks evaluate matching requests; they do not automatically correct older objects. Existing violations need discovery, review and separate changes. Disabling them indiscriminately can disrupt dependencies nobody checked.
Test the rules as well as the infrastructure
A test proving that an unsafe setting is rejected is necessary but insufficient. Test permitted work too. A policy that blocks every release admits no bad releases, but the team will soon look for an off switch.
For document storage, try private access, public access, missing classification, an unapproved exception and modification of a protective label. Include a changed input format after a platform upgrade. The OPA testing guide shows how policy behaviour can be covered by repeatable tests.
A particularly dangerous failure is a rule that stops finding its expected field and silently appears to pass. Missing information, an explicit permission and an evaluation failure must remain distinct. OPA's operations guidance discusses undefined decisions: a responsive HTTP server is not proof that the necessary policy is loaded and has answered the question.
Observation and enforcement are different rollout stages
Before a broad prohibition, establish who it would affect. An observation period can reveal disagreement with expected behaviour without stopping work. Call it observation, though: if the change still goes through, there is not yet an enforced constraint.
After reviewing the results, enable enforcement for a limited scope. Test an ordinary release, an emergency repair and an unavailable policy source. Define failure behaviour in advance. A sensitive change should not become permitted merely because verification failed. Emergency exceptions need a narrow scope, an accountable owner and subsequent review.
Check which policy version is actually active. In a distributed deployment, some evaluators may still use older rules. OPA's bundle mechanism distributes and activates policy sets. Publishing a bundle is not simultaneous enforcement everywhere. Signing establishes provenance, not correctness of the underlying requirement.
An exception needs an end
A temporary business exception should name the resource, reason, approver and expiry. Permission to approve it must be separate from the ability to add a convenient label. When it expires, either fix the deviation or make another explicit decision. Otherwise temporary permission becomes permanent policy by neglect.
Rolling back a policy is not automatically safe either. It can restore access that a newer version deliberately removed. Investigate the difference in permissions rather than reverting every recent restriction. Sometimes correcting one condition is safer than restoring the entire previous policy.
Useful evidence includes the resource identifier, policy version, decision and applied exception. Explaining a denial rarely requires copying the complete customer document into a log. The people investigating need access to that evidence, while the team being checked should not be able to rewrite it arbitrarily.
What counts as a result?
For the first rule, demonstrate that the recurring violation is caught on the relevant change paths, ordinary releases still work and the denial tells an engineer how to fix the problem. Then inspect existing resources. Green new builds should not hide an old public document store.
Policies reduce coordination only while people can understand and maintain them. Weekly exceptions for ordinary work suggest a faulty requirement or implementation. The number of rules is not a useful measure of control quality. The company should be able to identify the risk addressed, the coverage achieved and the routes still outside enforcement.