Author Data Policies
Select classified data, assign supported protection permissions, and save a reviewable Data draft.
Use the Data journey to configure protection for discovered data.
Classification scope selects data categories and their applicable discovered locations.
Principal scope identifies who receives the configured target permissions.
The current authoring lane enables Encryption.
Standalone Masking and Filtering choices remain Coming Soon.
Before starting, prepare access and catalog inputs.
Use your deployment’s supported principals and native integration.
Do not create a policy against invented catalog identities.
To author and verify a Data policy, follow these steps:
- Configure scope, principals, and protection.
- Save and inspect validation.
- Submit the exact saved draft.
- Hand off to an authorized reviewer and approver.
- Verify Data delivery.
Saving incomplete work does not make it eligible for submission.
The current governed revision, which records approved intent, remains unchanged until approval.
Draft edits do not replace that revision or prove a change in target protection.
Refer to states and revisions.
For a complete worked handoff, follow your first policy.
1 - Configure a Data Policy
Choose discovered classifications, supported principals, Encryption, and explicit Data permissions.
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:
- Open Policy Library.
- Select Data Protection Policy from the creation choices.
The authoring form opens. Navigation alone does not save a policy.
- Select the classification that identifies your prepared data.
The selected classification defines the data scope for this draft.
- 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.
To choose the protection method and permissions, follow these steps:
- Select Encryption.
The current Data lane does not enable standalone Masking or Filtering.
- Inspect the recommended protection settings for each classification.
Recommendations depend on current discovery and integration context.
- Choose the supported settings that match your organization’s protection requirements.
- Assign the required permissions for each selected principal.
- Review the generated title.
- 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.
2 - Save and Validate a Data Draft
Persist proposed work, inspect saved findings, and separate Save from submission and approval.
Save retains authoring work without replacing the current governed revision.
The governed revision records approved intent. The draft records proposed changes.
Compilation checks authored inputs and derives target-specific rules and validation findings.
It does not publish those rules.
Before You Begin
Complete these prerequisites before saving the draft:
Save Proposed Work
To save the proposed policy work, follow these steps:
- Review the title, classifications, principals, and protection permissions.
- Select Save Draft.
Policy compiles the current inputs before saving.
- Inspect the returned notice.
A successful Save returns you to the Library.
- Reopen the policy in Policy Library.
- Confirm the saved scope and draft status.
Record the policy identifier for later review and support.
A successful Save can retain compiler findings or incomplete semantic work.
It does not prove submission readiness, approval, or target delivery.
Repeated saves retain snapshots within the same proposed revision.
A snapshot records saved content and its validation evidence at that point.
The latest snapshot is the draft head. Another Save advances that head, not the governed revision.
Inspect Findings
To review the saved validation findings, follow these steps:
- Inspect outstanding exceptions and validation feedback for the saved draft.
- Correct missing permissions, invalid scope, or unsupported selections.
- Save the corrected work.
- Reopen the saved draft to confirm the correction.
Do not assume that an unavailable or stale validation count means zero findings.
Submission and approval revalidate current dependencies.
Only explicitly reviewable conflicts permit acknowledgement with reasoning.
Hard failures require correction. Acknowledgement cannot bypass them.
An authorized reviewer can refresh the exact saved head through
GET /policies/{policy_id}/validation in the
application programming interface (API) reference.
That operation requires policy:review.
An author without that capability must not use it as a diagnostic shortcut.
Recover Without Losing Intent
If Save fails, retain your edits and read the reported finding.
For a connection or directory error, ask the administrator of the named integration to restore access before retrying Save.
If you changed the form during compilation, save again using the latest edits.
If Policy reports that the draft changed, reload it and compare its content with your unsaved edits.
In an API client, obtain a new Draft-ETag only after that comparison.
For an uncertain response, inspect the Library before creating another policy.
If the saved result remains unclear, preserve the policy identifier and support reference.
Send those details to your Policy administrator instead of repeatedly selecting Save or creating another policy.
Next, submit the saved draft.
For artificial intelligence (AI) preview, use AI preview and Save.