Define Rule with Data Element and Role

Summary

Define a rule that specifies how a Role may interact with a Data Element by assigning permissions such as protect, unprotect, mask, or view.

Description

A Rule establishes the relationship between a Data Element and a Role within a policy. It defines which operations members of that Role are allowed to perform on the Data Element. For example, protecting the data using tokenization, viewing masked values, or unprotecting the data if permitted. Rules are the core of policy logic. They determine the behavior of the system when a user or application attempts to access or process sensitive data.

Purpose

To define who, the Role; can do what, permission; to which data, the Data Element. Rules translate business intent into enforceable policy logic and ensure consistent application of protection standards across all datastores.

Prerequisites

• A Policy Shell must exist. For more information about creating a policy shell, refer to the section Create Policy Shell.
• A Data Element must be created. For more information about creating a data element, refer to the section Prepare Data Element.
• A Role must be created and associated with a Member Source. For more information about creating a member source, creating a role, and assigning member source to the role, refer to the following sections:
  • Create Member Source
  • Create Role
  • Assign Member Source to Role

Inputs

Typical inputs for this step include:

• Role to which the rule applies.
• Data Element being controlled.
• Permissions. For example, protect, unprotect, mask, and view.
• Optional output behavior. For example, allow masked return only.
• Optional masking configuration if applicable.

Outcome

A rule is added to the policy, granting or restricting specific interactions between the designated Role and Data Element. The policy now contains enforceable access logic that dictates how protected data will behave for different types of users or applications.

Conceptual Examples

• Example 1: Protect‑Only Rule
  • A rule is created to allow the r_cc_protect role to protect credit card numbers using tokenization but not unprotect them. Applications using this role can store sensitive data safely, but cannot retrieve clear values.
• Example 2: Masked‑View Rule
  • A rule is created for the r_support_masked role, allowing customer support teams to view masked data but not access clear text or perform protection operations.

Tips

• Define rules with the principle of least privilege. Only grant operations that are required for the role’s function.
• Avoid giving unprotect permissions unless absolutely necessary. Restricting this keeps sensitive data safe.
• Use naming conventions to help visually match roles to rule types. For example, r_<domain>_protect and r_<domain>_viewmasked.
• For complex policies, document why each rule exists to simplify future audits or updates.