Import your existing policy checks

A single checks settings file can be uploaded as it is. A checks package file, or a settings file that links other files or custom Python scripts, is bundled first so the linked files come with it. Either way you end up in the same Import dialog.

Run checks export against the file your pipeline uses today.

It writes liquibase-checks-export.zip in the working directory, holding the package file, every settings file it links, and a manifest that lists them. Use --format=tar or --format=targz for a different archive type, and --export-file=<path> to name the output. A plain settings file exports too, if you would rather upload an archive than the file itself.

Note: Python scripts are left out of the archive by default. The check's configuration, including the script path, still imports, and a run from the assignment executes the check as long as the machine running checks run can reach the script at that path and has custom scripts enabled.

1. In the web application, go to Govern > Policies to open Manage All Catalogs.

2. Select Import… and drop in your .conf, .yaml, or .yml file, or the archive from step 2. Files up to 20 MB are accepted.

3. Select Import File.

The import runs while the dialog is open and finishes with a message such as Imported 59 checks in 7 packages into a new catalog. Warnings that did not stop the import, such as a rule ID that appears twice in a file, show with that message.

If the file is not a valid checks settings file, nothing is created and the dialog says so. Fix the file and try again.

The new catalog is named after your file and stamped with the import time. Importing liquibase.checks-settings.conf gives you checks-settings import 2026-09-17 16:27:02.809, with the liquibase. prefix and the extension dropped.

Inside it, the checks are grouped into one package per category. A settings file you dropped in directly gives you the same package names as the Liquibase Default Catalog, so a full file yields Data Protection, Scripting Standards, Metadata Content, and the rest. An archive from checks export prefixes each package with the file it came from, so checks from two files never merge: CSF for the default liquibase.checks-settings.conf, otherwise the file name without its liquibase. prefix and extension, for example CSF-data-protection or security-checks-authorization-and-access. A check the server does not recognize keeps its configuration and lands in an Uncategorized Checks package.

Every check arrives with the parameters, severity, and enabled or disabled state it had in the file. A check you customized in the CLI keeps its link to the built-in check it was derived from.

1. Go to Govern > Policies, which lists every catalog.

2. Open the imported catalog's actions menu, choose Edit Catalog, give it a name your team will recognize, and choose Save. Assignments that already reference the catalog keep working under the new name.

1. Decide which checks you want. Your checks arrived exactly as your file had them, so if the file already reflects what your team enforces, there is nothing to change. Every check starts at the severity it had in the file, and the default catalog's checks start at the lowest severity, so first runs report and never block.

The Liquibase Default Catalog is where to look for checks you have not used yet. Its packages come with the same checks enabled as a new checks settings file, which is a set chosen to flag risky statements without configuration. The table shows what each package starts with and what to turn on when it fits your team.

Enable or disable a policy check covers toggling one check or a whole package, and Browse the policy catalog covers copying a check into your package.

Select the package, choose Assign, then + New Assignment, and create an assignment covering the projects, pipelines, connections, or changelogs it governs. The save dialog lists everything the change affects before you choose Confirm & Save. Assigning a single check adds its whole package, with the other checks disabled for that assignment.

Put the assignment ID in your pipeline next to the server URL and API key, as Run checks with a policy assignment shows.

Note: When both an assignment ID and a checks settings file are present, the assignment wins and the file is ignored. Your pipeline keeps working on the file until you add the ID, and nothing breaks if you leave the file in place afterwards. Remove the file once every pipeline uses the assignment.