Policy As Code Engine Pace

Activate and build data collectors to add to a policy.

After testing the activated data collectors, add them to a policy in the Policy Builder.

Add existing policies to a policy's conditions to define the order a policy's execution and the conditions is executed.

Add or create policy tags on-the-fly for any PaCE policy, including currently Active policies. Tags enable you to manage policies more efficiently.

You can define and manage your PaCE policies in a single management console.

Use PaCE to manage the life cycle of a policy and create, update, review, and execute policies.

Use the Categories option to group your PaCE policies more efficiently. As the policy administrator, you can create and edit any number of categories.

You can compare two versions of a PaCE policy, whatever their state. Any differences between the two selected versions are highlighted for quick analysis.

Create PaCE policy categories to assign to a policy when creating or updating a policy. Categories enable you to categorize and manage policies more efficiently.

You can create a copy of an existing policy version. All the settings and mappings from the existing version are copied over to the new one.

Create a data collector for a policy version in the Define Variables section of the Policy Builder.

You can map a policy to any number of objects. When you map a policy, validate the inputs, and execute the policy, a compliant, non-compliant, or compliant-exception decision is returned.

Create PaCE templates for the PaCE policy forms that you use frequently.

Create a policy version using low-code for any of your existing PaCE policies.

Create a version from scratch at any time for any of your existing PaCE policies.

Create a PaCE policy to determine if changes to a software service or application comply with a set of pre-defined rules.

Create an API Variable, Config Parameter, or Record Reference for the policy version in the Define Variables section of the Policy Builder.

You can create new versions for any of your existing policies.

This section describes the structure of a PaCE data collector.

The following is a list of the most common data types for creating a variable.

You can activate or deactivate any PaCE policy. Only activated policies can validate object (tables and document IDs) changes. Deactivated policies are not executed, even if the policy is mapped. Deactivating a policy enables you to place the policy into a maintenance-like mode.

You can delete a policy version at any time. However, only versions that have never been published can be deleted. Published versions are stored for auditing purposes.

You can delete a PaCE policy at any time. All related versions for that policy are also deleted. However, for auditing reasons you cannot delete policies that were or are currently in use.

Update categories for a PaCE policy as required. You can also update categories for Active policies.

To edit a Current (published) or Archived PaCE policy version, you must create a copy of that version, which can then be updated as required.

You can edit a Draft PaCE policy version at any time. The Draft version can be published to become the Current version. You can also create multiple different Draft versions from different Archived versions.

You can edit the mapping settings that map a policy to an object.

Edit the PaCE policy script to apply any changes to the policy logic.

Edit and remove tags from a PaCE policy as required. When editing a tag, you can also define who can view the tag.

By integrating Policy as Code Engine with Integrated Risk Management and Policy and Compliance Management workspace, the Compliance administrator can manage an organization's overall compliance posture and provide a business and regulatory context for codified policies.

You can disable exceptions for a policy for which exceptions have been granted. When this option is selected, you can no longer request exceptions and control objectives can no longer be associated with the policy.

Enable exceptions for a PaCE policy and associate it with a control objective in GRC.

Execute a policy to determine if the policy is compliant or non-compliant. Executions can be run as part of your policy evaluation process, or in real time when mapped to an object (table or document ID).I presume we should also mention invoking with the API? Do we want to tell the user how to do that exactly?

Install PaCE.

Extend the capabilities of Policy as Code Engine (PaCE) by creating policies with other applications.

The following is a sample invocation request when the PaCE API is executed.

This table describes the properties that can be configured when the PaCE API is invoked. These properties can be set whenever the API is invoked or when you test a policy in the Test Playground.

This checklist lists the tasks involved in administering PaCE policies.

Use categories and tags to manage and group your PaCE policies more efficiently. As the policy administrator, you can create and edit any number of categories and tags.

You can administrate the full life cycle of policies using PaCE in applications by searching, reviewing, and updating existing policies, and creating policies as required. Policies in the applications are powered by PaCE.

For a policy to be invoked correctly, it must be mapped to an object (table or document ID). The defined mapping settings are automatically verified when the policy is invoked.

Parameters can be passed to a PaCE policy to validate updates to an object (tables and document IDs). These variables apply to authoring in both low-code or JavaScript. Policy versions include three types of parameter inputs: API Variables, Config Parameters, and Record References.

Create a duplicate of an existing policy.

Policy logic is a set of conditions that is used for determining whether a policy is compliant or non-compliant. You can use the condition builder to specify conditions for the policy.

Static Mapping enables you to map a set of policies to a record or object such as an incident or deployable. Dynamic Mapping enables you to map a set of policies on a dynamic set of records or objects such as a set of incidents or a set of deployables.

This section describes the structure of a PaCE policy script.

You can create a duplicate policy from a policy version or multiple versions from two or more policy versions. If you want to use a locked policy, you must first create a duplicate version and then modify the policy version as required.

A PaCE policy version can be in one of four states: Draft, Current, Archived, and Now-Content. The policy version state also defines the version numbering.

PaCE policy versions contain the actual policy script, as well as API Variable and Config Parameter definitions used for validating policies. Each policy can have many versions, each of which can be easily managed.

You can publish a policy version at any time. When the policy is published, a compliant, non-compliant, or compliant-exception decision is made for objects (tables or document IDs) mapped to the policy.

Request an exception on policies that are dynamically mapped to conditions.

When a PaCE policy is invoked, the calling service passes the relevant object (tables and document IDs) that is being validated by providing the documentRecord object. A calling service is a service or product that uses the PaCE API. PaCE determines which policies must be executed by using the mapping table and the documentRecord.

You can review the execution activity of any policy at any time. Recorded execution activity includes the time taken to execute, decisions of compliance, execution types, and the outcome of the execution.

After evaluating any changes made to the PaCE policy script, you can review the execution log generated.

After evaluating any changes made to the PaCE policy script, you can review the execution output and compliance decision reached. You can review this output immediately after evaluating any policy script changes.

This section describes different user personas and roles in PaCE. These personas are defined with the application where PaCE is being used.

Use tags to manage your PaCE policies more efficiently. As the policy administrator, you can create and edit any number of tags.

Test a data collector for a policy version in the Test Playground.

Use the Test Playground to test updates to a PaCE policy script. You can evaluate changes to the policy script in real time, enabling you to determine if the changes that are applied render the policy compliant or non-compliant.

PaCE enables you to manage, administer, and audit policies from a centralized location.

You can update any existing PaCE policies, whether they are activated or deactivated.

The Test Playground enables you to test updates to a PaCE policy at any time, without the need to test or evaluate them in a Production environment.

Use Dynamic Mapping to map multiple PaCE policies against specified conditions.

Use Static Mapping to map multiple PaCE policies against a record such as a change request.

You can view the PaCE policies that have been assigned to a specific category. All the categories created, together with their associated policies, can be viewed in the All Categories table.

You can view a list of all PaCE policies created by you and other policy administrators. The PaCE management console is your gateway to viewing and updating policies, and managing policy versions.

You can view the PaCE policies that have been assigned to a specific tag. All tags together with their associated policies can be viewed in the All Tags table.

If an exception is no longer required, you can withdraw a granted exception request for a policy.

This section provides guidelines on how to write and test PaCE policies.

After a policy has been enabled and configured for exceptions, you can map a policy to a deployable and request an exception.