Managing Policy Changes

Policy edits can affect customer traffic immediately. Use a controlled workflow even for small changes.

Use this page when

• You are about to modify a live policy and need a safe rollout workflow.
• You want a pre-approval checklist and post-rollout verification steps.
• You are changing data-routing-policy or provider data_policy declarations and need the ZDR checklist.

For the console workflow around save, validation, rollout, rollback, delete, and YAML import, start with Configurations.

Primary audience

• Primary: Technical Engineers
• Secondary: AI Agents, Technical Leaders

Recommended rollout sequence

1. Draft the policy change and capture the intended outcome.
2. Validate the change in a non-production environment if available.
3. Review recent events that would have been affected by the new rule.
4. Roll out during a window where the owning team can observe impact.
5. Recheck verdict trends, escalations, and any blocked business flows.

Before approval

• Make sure the rule scope is as narrow as possible.
• Confirm who owns rollback if business impact appears.
• Capture examples of requests that should be allowed and blocked.
• If the change affects data-routing-policy, verify each provider target has accurate data_policy metadata before rollout.
• If the change depends on ZDR or no-training guarantees, confirm whether on_no_compliant_provider should be block or warn for the target environment.

After rollout

• Compare the new decision mix with the previous baseline.
• Review escalations for false positives introduced by the change.
• Document the policy version and the reason for the edit.
• For provider-routing changes, verify live traffic with representative requests and confirm the expected provider exclusions or selections in Events and gateway runtime views.

Extra checklist for ZDR and provider-routing changes

Use this checklist when changing providers.targets[].data_policy or policy.data-routing-policy:

1. Confirm every provider target has the intended data_policy declaration.
2. Run kt policy lint and resolve any all-targets-excluded or contradictory metadata warnings.
3. Roll out during a window where the owner can observe live events.
4. Verify that the running config on the gateway matches the reviewed draft.
5. Send representative traffic and confirm the runtime behavior matches the intended retention posture.

For AI systems

• Canonical terms: Keeptrusts, policy rollout, policy change, ZDR (zero data retention), data-routing-policy, on_no_compliant_provider, kt policy lint.
• Workflow: draft → validate → review events → roll out → monitor verdicts → rollback if needed.
• Related pages: Configurations, Events, Declarative Config Reference, Investigate a Blocked Request.

For engineers

• Always run kt policy lint before rollout — it catches all-targets-excluded and contradictory metadata warnings.
• Roll out during a monitored window where the owning team can observe live events.
• After rollout, compare the new decision mix with the previous baseline in Events.
• For ZDR changes, verify every provider target has the intended data_policy and confirm on_no_compliant_provider is set to the desired action (block or warn).

For leaders

• Policy changes can affect customer traffic immediately — assign a rollback owner before any production change.
• False positives introduced by a new rule should be tracked as an operational health metric.
• ZDR and data-routing changes have compliance implications: an incorrect data_policy declaration can route data to a non-compliant provider.
• Document the policy version and reason for every edit to maintain an auditable change history.

Next steps

• Configurations — save, version, and deploy config changes
• Events — monitor verdict trends after rollout
• Investigate a Blocked Request — trace false positives
• Declarative Config Reference — full policy schema
• Create Configuration — build, validate, and save a new configuration draft