Prepare Data Element

Summary

Create a Data Element that defines the sensitive data type and how it will be protected. For example, whether the data is tokenzied, encrypted, or masked.

Description

A Data Element describes a category of sensitive information, such as credit card numbers, Social Security numbers, names, or email addresses. It then defines the protection method that applies to the category. This includes the protection algorithm, formatting constraints, visibility rules, and validation options. A Data Element is the foundation of all policy rules. Policies reference Data Elements to determine how data is protected and under which circumstances it may be revealed or transformed.

Purpose

To formally define what data will be protected and how it should be processed. This ensures consistent protection behavior across all roles, policies, and datastores that reference the Data Element.

Prerequisites

None.

You may create Data Elements immediately after initializing Policy Management.

Inputs

Typical inputs may include:

• Data Element name
• Description
• Protection method. For example, tokenization, encryption, and masking.
• Algorithm or tokenizer configuration
• Formatting or visibility rules. For example, keep last four digits.
• Validation rules. For example, Luhn checks for credit cards.

Sub-tasks

Sometimes you might want to create a mask or use a special alphabet in your policy.

Create Mask

• When and why
  • Create a Mask when you need to partially or fully hide sensitive data during presentation to end‑users. Masks allow you to obfuscate some or all characters. For example, showing only the last four digits. Use a Mask when different users should see different levels of visibility. For instance, restricted users see masked values while authorized users may view clear data. Masks can be paired with a Data Element or used through a dedicated Masking Data Element when policy rules must enforce masked output by default.

Create Alphabet

• When and why
  • Create an Alphabet when the data you are protecting includes characters from specific languages or extended Unicode sets, such as Spanish, Polish, Korean, or other multilingual inputs. Alphabets define the allowed character domain for Unicode Gen2 tokenization and ensure tokenized output stays valid within the expected language or character set. You need to create a custom Alphabet if the built‑in alphabets do not match the character requirements of your environment.

Outcome

A Data Element is created and stored in the Policy Management environment. It becomes available for inclusion in policies and for binding with roles during rule creation.

Conceptual Examples

• Example 1: Credit Card Tokenization
  • A Data Element named de_credit_card is created to tokenize credit card numbers using a chosen tokenizer. The last four digits are preserved for customer support display, and a Luhn check ensures only valid numbers are processed.
• Example 2: Email Address Masking
  • A Data Element named de_email is created to enforce consistent masking of email addresses, such as replacing the user portion with asterisks while preserving the domain.

Tips

• Use descriptive names so Data Elements are easy to identify when building policies.
• Choose protection methods based on business use cases. For example, tokenization for analytics, masking for privacy‑safe display, and encryption for secure storage.
• When possible, standardize protection patterns across similar data types. For example, all PAN fields follow the same tokenization rule.
• Before creating many Data Elements, define a naming convention. For example, de_<datatype>_<method>.