What is Policy Checks?
Definition
A policy check runs against a ChangeSet before deployment, comparing it to a rule the organization has defined, and either allows the deployment to proceed or blocks it, depending on the result. Common examples include requiring a rollback script for any destructive change, blocking changes outside an approved maintenance window, or requiring a second approver for changes to a production database. The alternative is a manual checklist that someone is supposed to run through before every deployment, which works until volume increases or someone forgets a step under time pressure. A policy check applies the same standard every time, to every change, regardless of who wrote it or how busy the reviewer is, which is what makes it possible to enforce governance at a scale manual review can't reach.
Why policy checks matter
As the number of databases, environments, and people making changes grows, a standard that depends on someone remembering to check it stops holding. A rule that's enforced manually in one environment and skipped in another isn't really a standard, it's a suggestion. Policy checks turn a written standard into something that's actually enforced the same way everywhere, every time, which is usually the difference between a governance policy that exists on paper and one that actually shapes what gets deployed. It also changes what a human reviewer is actually reviewing: instead of manually confirming a change follows every rule, a reviewer can trust that the check already did, and focus their attention on judgment calls the check isn't built to make.
How policy checks work
A policy check is defined once, typically as a rule referencing something structural about a change, such as its change type, the object it affects, or whether it includes a rollback. When a ChangeSet is proposed for deployment, the check evaluates it against that rule and returns a pass, a warning, or a block, depending on how strict the policy is configured to be. Checks can run at different points, during code review, right before deployment, or both, so a violation can be caught as early as possible rather than only at the last gate. Checks can also vary by environment, so a rule that blocks a change outright in production might only produce a warning in a development environment, giving teams room to experiment without weakening the standard where it matters most.
How Liquibase helps
Liquibase Secure runs policy checks as part of its governance layer, evaluating ChangeSets against organization-defined rules before they reach a database and giving approvers a pass or fail result instead of a list of things to manually verify. That shifts review from checking whether a change follows the rules to focusing on whether the change itself makes sense, since the rule-following part is already handled automatically, and it produces the same policy evidence auditors ask for without someone assembling it after the fact.
