Create Policy Shell

Summary

Create an empty Policy Shell that acts as the container for roles, data elements, rules, and deployment configuration.

Description

A Policy Shell is the foundational policy object that holds all components of a complete policy but initially contains no rules or assignments. It defines the policy’s identity, which is its name, description, and purpose, and prepares the environment for adding data elements, roles, permissions, and datastores. Creating a Policy Shell is the administrative starting point for constructing a full policy.

Purpose

To establish a dedicated policy container that will later be populated with rules governing how sensitive data is protected and who may access it. The Policy Shell provides organizational structure and acts as the anchor for all subsequent policy configuration steps.

Prerequisites

• Policy Management must be initialized. For more information about the initialization step, refer to section Initialize Policy Management.
• Any Data Elements, Roles, or Member Sources you plan to use may optionally be created beforehand, but are not required at this step.

Inputs

Typical inputs for this step include:

• Policy name.
• Policy description.
• Optional metadata or tags for categorization.

At this stage, no data elements, roles, or permissions are defined.Only the policy container itself is defined.

Outcome

A new, empty policy is created and ready to be configured. You can now begin attaching Data Elements, assigning Roles, defining permissions, and associating Datastores.

Conceptual Examples

• Example 1: Credit Card Protection Policy
  • An administrator creates a new policy shell named policy_credit_card intended to govern how credit card numbers are tokenized and which users can unprotect them.
• Example 2: Customer Support Access Policy
  • A policy shell named policy_support_data is created to organize rules that provide masked data to customer service roles while restricting access to full values.

Tips

• Choose clear and descriptive names so the purpose of the policy is immediately recognizable.
• Create separate policies for distinct business domains to simplify auditing and updates. For example payments, HR, or analytics.
• Avoid overloading one policy with too many unrelated Data Elements. Smaller policies are easier to manage and review.
• Think of the Policy Shell as the project folder for everything that will follow.