Configure a Data Policy

Configure a narrowly scoped Data policy before saving its first draft. Scope means the selected classifications, applicable discovered data, and intended principals. Act as an authorized author, not as the eventual reviewer.

Before You Begin

Refer to access requirements and complete example preparation.

Complete these prerequisites before configuring Data protection:

• Identify one discovered classification and one supported principal.
• Use nonproduction inputs that your organization permits you to protect.
• Ask the Traverse administrator to confirm the classification’s tables or columns if its meaning is unclear.

Select Classifications and Principals

To configure the Data policy scope, follow these steps:

1. Open Policy Library.
2. Select Data Protection Policy from the creation choices. The authoring form opens. Navigation alone does not save a policy.
3. Select the classification that identifies your prepared data. The selected classification defines the data scope for this draft.
4. Select the supported principal that should receive access. Use its catalog identity, not a similarly named replacement.

The principal receives permissions at the protection target. It need not be the signed-in Policy author. Policy edit authority does not grant that author access to protected data.

Choose all principals only when your intended scope explicitly requires it. Switching between explicit identities and wildcard scope changes policy meaning. Reinspect permissions after changing that selection. Do not use wildcard scope to work around an unsupported principal.

If classifications or principals cannot load, stop before submission. Send the error to the Traverse integration administrator to investigate missing discovery or identity data. Never replace missing identities with guessed values.

Configure Protection and Permissions

To choose the protection method and permissions, follow these steps:

1. Select Encryption. The current Data lane does not enable standalone Masking or Filtering.
2. Inspect the recommended protection settings for each classification. Recommendations depend on current discovery and integration context.
3. Choose the supported settings that match your organization’s protection requirements.
4. Assign the required permissions for each selected principal.
5. Review the generated title.
6. Enter a meaningful title if your workflow requires a clearer name.

For each principal, choose at most one read mode: cleartext, protected, or null. Cleartext returns readable data. Protected returns a token or ciphertext rather than cleartext. Null returns a null value instead of the protected value. Protection and reprotection permissions remain independent of the read mode. A principal selection alone does not supply an action permission. Turning off every read mode does not imply a cleartext grant.

Avoid wildcard scope for the first Data exercise. Do not infer a principal-specific permission from an absent matrix row. Inspect compiler findings and the saved policy before relying on any grant.

Check Scope Before Saving

Confirm the classification, principal identities, method, and permissions together. If you change scope, revisit the permission rows and title. A title does not prove that the underlying selections remain complete.

Stop when recommendations, schema checks, or principal compatibility fail. Do not substitute a Coming Soon method or a different identity. If the finding describes discovery or Policy Integration Manager (PIM) configuration rather than a form field, send it to the administrator of that integration.

Next, save and inspect the draft. Refer to authoring choices for shared concepts.