What are the default policy check packages?
Last updated: June 9, 2026
When you run init project, Liquibase generates eight policy check package files in a checks-packages/ subdirectory of your project. Six are themed packages targeting specific governance areas and two are composite packages that bundle multiple themed packages together. Packages save you the time of identifying and enabling each check one by one. You can enable a single package to get a curated set of related checks at once, then customize the package to fine-tune which default checks within the package are enabled.
Use a default package
Use --checks-packages with checks run or checks show to target a specific package by name:
liquibase checks run --checks-settings-file=liquibase.checks-package.yaml --checks-packages=data-protection
Customize individual packages
Enabled by default vs. opt-in
The tables below show whether each check in a package is enabled by default or opt-in. Default-enabled checks run automatically when you target that package. Opt-in checks must be explicitly enabled, usually because they require configuration specific to your environment, such as regex patterns for PII detection or naming conventions.
To enable an opt-in check in a package:
liquibase checks enable --check-name=<CheckName> --checks-settings-file=<package-file>
Adjust what runs in a package
You can turn individual checks on or off in any package using checks enable or checks disable with that package's settings file:
liquibase checks enable --check-name=<CheckName> --checks-settings-file=<package-file>
liquibase checks disable --check-name=<CheckName> --checks-settings-file=<package-file>
Changes apply only to that package file and do not affect your other packages.
Default packages and when to run them
Choose the package that matches the type of changes you are reviewing:
auth-and-access- Detects SQL that grants or revokes database privileges, helping you catch unauthorized access changes before they reach production.data-protection- Guards against destructive operations and flags risky structural changes like drops, truncates, and data type modifications.database-compatibility- Flags SQL that uses reserved keywords for your target database platform, preventing deployment failures caused by keyword conflicts.metadata-content- Enforces documentation standards for changesets, including required comments, contexts, labels, and table-level metadata.scripting-standards- Enforces scripting hygiene including transaction settings, one change per changeset, and rollback presence.sensitive-data-pii- Detects personally identifiable information (PII) and sensitive data patterns in changelog SQL. All checks are opt-in.
Package details
auth-and-access
Detects SQL that grants or revokes database privileges, helping you catch unauthorized access changes before they reach production.
Check | Description | Status |
|---|---|---|
Use the check to warn when changelogs contain WITH ADMIN OPTION statements. | Enabled by default | |
Use the check to warn when changelogs contain WITH GRANT OPTION statements. | Enabled by default | |
Use the check to warn when changelogs contain WITH GRANT statements. | Enabled by default | |
Use SQLRevokeWarn to warn when changelogs contain REVOKE statements so that you do not have security issues due to the wrong privileges being removed, which can lead to failing jobs and even downtime. | Enabled by default | |
Use the check to warn when changelogs contain Grants with specific privileges statements. | Opt-in |
data-protection
Guards against destructive operations, enforces row-limit thresholds on data manipulation statements, and flags risky structural changes.
Check | Description | Status |
|---|---|---|
Use the check to warn when a column is being dropped. | Enabled by default | |
Use the check to warn when a table is being dropped. | Enabled by default | |
Use the check to warn when a table is being truncated, which is a significant database change which can destroy your organization’s most essential resource: critical data. | Enabled by default | |
Use the check to enhance deployment control by checking for an associated index that your target URL database tables uses. | Enabled by default | |
Use the check to enhance deployment control of specific changesets by warning you if a forbidden Change Type is present. | Enabled by default | |
Use this check to prevent statements from being deleted from your database if more than a specified number of rows are affected by that statement. | Enabled by default | |
Use this check to prevent statements from being inserted into your database if more than a specified number of rows are affected by that statement. | Enabled by default | |
Use this check to prevent statements from being inserted into your database if more than a specified number of rows are affected by that statement. | Enabled by default | |
Use the ModifyDataTypeWarn check to warn when changelogs contain a data type modification, such as a change which might lead to unintended changes or permanent loss of essential data. | Enabled by default | |
Use the check to warn when a changeset which creates a table does not include the creation of a primary key. | Enabled by default | |
Use SqlSelectStarWarn to warn when generated or raw SQL contains 'SELECT *' statements so that you do not have unsafe or unnecessarily broad queries selected which can lead to failing jobs and even do | Enabled by default | |
Use the check to validate that the target tables do not contain more than the allowed number of columns. | Enabled by default | |
You can use the check to ensure a specific table contains specific elements, such as a primary key, default values, or other constraints. | Opt-in | |
Use this check to enforce naming conventions, security standards, or deployment rules by validating specific fields in DynamoDB change types. | Opt-in | |
Use this check to enforce the use of the Dynamo-specific deleteDynamoTable change type. | Opt-in | |
Use this check to enforce the use of the Dynamo-specific DynamoDeleteGlobalSecondaryIndexCheck changetype. | Opt-in | |
Use this check to enforce naming conventions, security standards, or deployment rules by validating specific fields in MongoDB change types. | Opt-in |
database-compatibility
Flags SQL that uses reserved keywords for your target database platform, preventing deployment failures caused by keyword conflicts.
Check | Description | Status |
|---|---|---|
Use the check to warn when changeset's generated or raw SQL contain 'USE DATABASE' directive. | Enabled by default | |
Use the check to ensure that no Oracle reserved words are used to name database objects. | Opt-in | |
Use the check to ensure that no Postgres non-reserved keywords are used to name database objects. | Opt-in | |
Use the check to ensure that no Postgres reserved keywords are used to name database objects. | Opt-in | |
Use the check to ensure that no SQL Server's future reserved keywords are used to name database objects. | Opt-in | |
Use the check to ensure that no SQL Server ODBC reserved keywords are used to name database objects. | Opt-in | |
Use the check to ensure that no SQL Server reserved words are used to name database objects. | Opt-in |
metadata-content
Enforces documentation standards for changesets, including required comments, contexts, labels, and table-level metadata.
Check | Description | Status |
|---|---|---|
Use the check to warn when a changeset comment has not been added to a changeset. | Enabled by default | |
Use the check to enhance deployment control of specific changesets by requiring one or more contexts be assigned to every changeset in a changelog. | Enabled by default | |
Use the check to enhance deployment control of specific changesets by requiring labels be assigned to every changeset in a changelog. | Enabled by default | |
All . | Enabled by default | |
This policy check allows you to easily check whether the attributes in your changesets each match a particular string or regular expression. | Opt-in | |
This policy check allows you to easily check whether the attributes in your changesets each match true or false. | Opt-in | |
Use the check to notify you when the 8-4-4-4-12 pattern of UUID or GUID is not followed when creating a changeset ID. | Opt-in | |
You can use the check to check for the presence of a comment within a table described in a changelog. | Opt-in | |
You can use the check to look for the presence of specific patterns in their table comments. | Opt-in | |
Use the check to confirm when a specific context or a context that matches a specific pattern is present on all changesets. | Opt-in | |
Use the check to confirm when a specific label or a label that matches a specific pattern is present on all changesets. | Opt-in |
scripting-standards
Enforces scripting hygiene: transaction settings, one change per changeset, rollback presence, and delimiter and pattern requirements.
Check | Description | Status |
|---|---|---|
This check verifies whether your changesets contain runInTransaction=true or runInTransaction=false. | Enabled by default | |
Use the check to enhance deployment control of changesets by limiting a changeset to a single change. | Enabled by default | |
Use the check to warn when a changeset does not contain a rollback, which can hamper efforts to restore to a previous database schema if problems are encountered either during or after deployments. | Enabled by default | |
Certain changesets need an end delimiter specifically set, while others do not need the end delimiter. | Opt-in | |
Use the check to validate that object naming conventions adhered to and that object names match the supplied pattern. | Opt-in | |
Use the check to validate that your object names do not fit naming conventions and that object names match the supplied pattern. | Opt-in | |
The PatternAFollowedByPatternB check can be used to confirm conditions within the changelog. | Opt-in | |
The PatternANotFollowedByPatternB check can be used to confirm conditions within the changelog. | Opt-in | |
The PatternANotPrecededByPatternB check can be used to confirm conditions within the changelog. | Opt-in | |
The PatternAPrecededByPatternB check can be used to confirm conditions within the changelog. | Opt-in | |
Use the check to notify you when your custom specific patterns in the changelog are found. | Opt-in |
sensitive-data-pii
Detects personally identifiable information (PII) and sensitive data patterns in changelog SQL. All checks are opt-in.
Check | Description | Status |
|---|---|---|
Helps you identify and prevent sensitive personal identifiable information (PII) from being deployed through your database changes. | Opt-in | |
Identifies highly-sensitive financial and bank information in your database changelogs, helping prevent PII data exposure. | Opt-in | |
Identifies highly-sensitive person-centered information in your database changelogs, helping prevent PII data exposure. | Opt-in | |
Identifies highly-sensitive health, hospital, and physician information in your database changelogs, helping prevent PHI data exposure. | Opt-in | |
Identifies highly-sensitive US geographic location information in your database changelogs, helping prevent PII data exposure. | Opt-in | |
Identifies highly-sensitive computer-related and date information in your database changelogs, helping prevent PII data exposure. | Opt-in |
Composite packages
Composite packages bundle themed packages together for common use cases.
Package | Includes |
|---|---|
|
|
|
|