This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Policy Lifecycle and Governance

Hand off saved policy work between authors, reviewers, and approvers without confusing approval with delivery.

1: Submit Saved Work for Review
2: Review and Decide on a Submission
3: Correct Returned Work and Resubmit
4: Restore Policy Intent or Retire a Policy

Authors submit drafts. Reviewers request changes or approve them. Approval creates an approved version, called a governed revision, and starts background publication. Each saved snapshot records proposed content and validation evidence. The latest saved snapshot is the draft head. Several snapshots can belong to one open proposal without creating several governed revisions. Delivery runs asynchronously afterward. Keep drafts, governed revisions, and protection states separate throughout this journey.

Actors, Capabilities, and Policy Grants

The following names describe responsibilities, not additional product roles.

The table summarizes each governance responsibility, its required authority, and its limit:

Responsibility	Required Authority	Boundary
Author Alex	Require `policy:edit` and applicable policy owner/editor access.	Save and submit proposed work without approving it.
Reviewer Morgan	Require `policy:review`.	Inspect saved validation and request changes without acquiring approval authority.
Approver Morgan	Require `policy:approve`.	Approve the current reviewed submission, not an earlier draft.
Operator Sam	Require `policy:audit` for restricted diagnostics.	Inspect operations without automatically gaining recovery mutation authority.
Read-only stakeholder	Require permitted view access.	Inspect permitted information without changing policy state.

The policy_author authority supplies author capabilities, not review or approval. The policy_viewer authority supplies viewing capability. The policy_admin mapping includes broader review, approval, and recovery capabilities. Do not grant it merely to reproduce this example. Use your deployment’s approved authority and gateway-permission mappings.

Owner/editor grants establish policy resource access. They do not supply command capabilities. An author role mapping alone does not prove that the caller holds a grant on an existing policy. Review and approval remain distinct capabilities even when one approved mapping supplies both. Policy does not define a separate policy_reviewer role. Refer to roles and permissions.

Follow the Handoff

To complete the separate-user author and reviewer handoff, follow these steps:

As Alex, save a Data or artificial intelligence (AI) draft.
As Alex, submit current saved work.
As Morgan, review the submission using a separate authenticated account.
As Morgan, request changes with an actionable reason.
As Alex, correct and resubmit.
As Morgan, approve the new reviewed head.
Follow publication and target-specific evidence.

Use separate authenticated accounts for this example. Never share credentials or send another user’s name as the audit actor. Your organization may impose additional separation-of-duties rules. This example does not claim that Policy mandates different people for every command.

Manage Policy Access

An authorized owner can manage active owner/editor grants through the application programming interface (API) access operations. Listing grants requires policy:view. Creating or revoking grants requires active ownership or authorized administrator recovery, not an editor grant alone. Do not assume the Panel exposes every access-management operation.

Before changing access, ask a Protegrity Provisioned Cluster (PPC) user with administrator permissions to confirm the recipient’s identity mapping. For a user grant, use the exact gateway-verified login username. For a role grant, use an authority the gateway actually forwards for the intended accounts. This can be a permission name, not a PPC role’s identifier or display name. Do not substitute opaque PPC account identifiers, display names, or runtime principals from the authoring catalog. Never supply or spoof gateway identity headers. Follow the subject identity rules and access operations. After a change, list grants again to confirm the intended active owner/editor entry. Listing confirms persistence, not effective recipient access.

Preserve a valid owner when removing access. During an approved handoff, have the recipient confirm intended access using their own authenticated account through the supported workflow. For ownership transfers, confirm ownership-management access before removing the previous owner’s access. An editor grant does not authorize ownership administration by itself. Do not broaden roles to solve a missing policy grant. For owner-recovery cases, involve an authorized administrator using the audited recovery path.

Change or Retire Governed Work

Editing a governed policy leaves its current approved revision unchanged. Normal Edit resumes existing open work. Refer to rollback or archive only for their distinct purposes. Inspect history before making either decision.

Automatic recompilation can create compilation minors without changing author intent. A compilation minor is a recompilation within the same governed revision, not another approval of changed intent. Refer to automatic recompilation. For a complete example, follow your first policy.

1 - Submit Saved Work for Review

Submit the exact current saved draft and hand it to another authenticated reviewer.

Act as the author who has prepared and saved proposed policy work.

Before You Begin

Complete these prerequisites before submitting work:

Save and inspect the proposed work.
Confirm policy:edit and applicable owner/editor access through capabilities and grants.
Identify the reviewer who will receive the policy identifier.

Submit Current Work

To submit the current saved work, follow these steps:

Open the saved policy in Policy Library.
Inspect its current draft content and validation findings.
Correct hard failures before continuing.
Select Submit for Review when Policy offers the action.
Supply reasoning and acknowledge only the current, permitted reviewable conflicts when prompted.
Confirm In Review in current policy detail. Submission changes the saved draft’s review status. It does not publish the policy.
Give the policy identifier to the separately authenticated reviewer.

Use a specific handoff message, such as: “Review this policy’s current submission, classification scope, and principal permissions.” Do not send credentials or ask the reviewer to reuse your browser session.

Direct API Handoff

For the application programming interface (API), use POST /policies/{policy_id}/submit relative to the configured API base. Refer to submission request examples.

For a direct API handoff, follow these request checks:

Read GET /policies/{policy_id} before submitting.
Put the exact current draft token in If-Match.
Use reviewNotes and acknowledgedConflictIds only as the endpoint specifies.
Do not send submittedBy. Policy derives the actor from authenticated identity.
Check that the returned draft status is In Review and retain its new Draft-ETag value.

Do not substitute the governed-policy ETag for the current Draft-ETag. An entity tag (ETag) is a server-issued concurrency validator, not a permission or approval. Send the current Draft-ETag value in If-Match to bind the command to the current draft head. The head is the latest saved snapshot of proposed content and validation evidence. Treat tokens as opaque. Never construct or parse them. Submission changes the draft head. The reviewer must obtain the post-submission token rather than reuse your pre-submission token. Repeated saves and submission can change snapshot identity without creating a new governed revision.

Verify or Stop

Confirm In Review through policy detail and permitted history. An approval or publication event should not follow from submission alone.

If validation findings changed, read the new messages before acknowledging them. If Policy rejects a stale token, reload the policy and compare its content with the draft you intended to submit. Do not merely copy a fresh token onto an old decision. Compare the current content and findings first. If submission times out, inspect current detail before repeating it. Do not create a replacement policy to bypass an uncertain result.

Next, the reviewer follows review and approval. For returned work, follow correction and resubmission.

2 - Review and Decide on a Submission

Inspect current saved work, request actionable changes, or approve the exact reviewed draft.

Authenticate as the reviewer, using your own account.

Before You Begin

Complete these prerequisites before reviewing a submission:

Obtain the submitted policy identifier from the author.
Confirm policy:review to inspect saved validation and request changes.
Confirm policy:approve if you will approve the submission.

An owner/editor grant does not supply either capability. Refer to authority requirements.

Inspect the Current Submission

To inspect the submitted policy, follow these steps:

Open the policy identifier that the author handed off.
Confirm that the current draft remains In Review.
Inspect classifications, principals, methods, and permissions.
Inspect the current validation findings.
Read permitted history and the author’s review reasoning.

For direct application programming interface (API) use, read policy detail and GET /policies/{policy_id}/validation under your reviewer identity. Saved validation returns the exact current head and its Draft-ETag. The head is the latest saved snapshot in the proposal. The entity tag (ETag) is a concurrency validator, not approval evidence. Use that current token for the decision. Do not reuse the author’s pre-submission token.

If dependencies or findings changed, review them again. Resolve non-overridable failures through author correction. Only explicitly reviewable conflicts permit acknowledgement with reasoning.

Request Changes

To request changes to the submission, follow these steps:

Select Reject when the action is available.
Enter a nonblank reason that names the correction and expected result.
Confirm the request. Policy returns editable work while preserving its content.
Give the author the policy identifier and correction request.

For example: “Use a title that identifies the protected classification and intended principal.” The current application programming interface limits this reason to 512 characters. Keep the reason actionable rather than pasting an entire investigation.

For direct clients, use POST /policies/{policy_id}/request-changes with reason and the current draft token in If-Match. The response contains a new token in its draft summary. There is no separate reject endpoint.

The Panel labels this request-changes action Reject. Open Change History and check that the request records your reason and user identity. The interface can label the returned proposal Rejected. The author can still edit that work. Any previously approved version remains unchanged. Returned work awaits author correction. Resubmitted work has entered In Review again and needs a new review. The author continues with correction and resubmission.

Approve the Reviewed Submission

Proceed only after reviewing the current submission, including any resubmitted corrections. You must hold approval authority, even if you previously requested changes.

To approve the reviewed submission, follow these steps:

Refresh the policy’s current submitted content and findings.
Confirm that no hard failures remain.
Acknowledge only the required, permitted current conflicts.
Select Approve Policy on the review page.
Enter nonblank review notes that explain the decision.
Confirm approval. Policy creates the governed revision and queues asynchronous publication.
Reload the policy and open Change History to check the approved version, your user identity, and your notes.

For direct clients, use POST /policies/{policy_id}/approve with reviewNotes and applicable acknowledgedConflictIds. Put the exact reviewed draft token in If-Match. Do not send approvedBy. Policy records your authenticated identity. Refer to API reference.

Stop Conditions

Stop when the draft changed, the token became stale, or new findings appeared. Reload the policy and validation results, then review any changed content before deciding again. Do not acknowledge hard failures or approve an older copied submission. If approval or rejection times out, check Change History for the decision before sending it again.

Approval starts background publication of the reviewed configuration. Continue with delivery verification.

3 - Correct Returned Work and Resubmit

Address reviewer feedback within the same policy proposal and return current saved work for another review.

Act as the author after a reviewer requests changes. Use your own authenticated account with edit capability and policy resource access. The returned proposal remains editable, even when the interface labels it Rejected. An existing governed revision remains unchanged. Returned work is not yet a new submission. Save records corrections. Resubmission returns those corrections to In Review.

Before You Begin

Complete these prerequisites before correcting returned work:

Obtain the policy identifier and correction request from the reviewer.
Confirm edit capability and applicable owner/editor access.
Keep the existing proposal. Do not create a replacement policy.

Correct the Proposal

To correct the returned proposal, follow these steps:

Open the policy identifier that the reviewer returned.
Read the reviewer’s reason in the available decision or history information.
Open the available edit or resume action. Policy reopens the existing proposal.
Correct the named title, classification, principal, method, or permission input.
Save the corrected draft.
Reopen the policy to verify the saved correction.

If your account cannot see the full reasoning, ask the reviewer for actionable feedback. Do not interpret a redacted or unavailable note as an empty decision. Do not create another policy merely to avoid the returned-work status.

Refer to Data Save or artificial intelligence (AI) preview and Save for lane-specific validation. If Save fails, preserve the current edits and visible error. For a connection or directory error, ask the administrator of the named integration to restore access before retrying Save.

Resubmit and Hand Off

To resubmit the corrected work, follow these steps:

Inspect current saved findings.
Correct hard failures or address permitted reviewable findings.
Follow submission using the current saved draft.
Confirm In Review.
Hand the same policy identifier back to the reviewer.

For direct application programming interface (API) use, obtain the current draft token. The server-issued draft entity tag (ETag), returned as Draft-ETag, identifies the current head for concurrency checks. Do not reuse a token from before the request for changes or later Save. Do not send another user’s name as the actor.

Verify the Handoff

History should retain the earlier request and the later resubmission. The reviewer must reload the submitted draft and review its corrected content before approval. If another user changed the draft, compare their changes with yours before saving again. Stop rather than overwriting unknown newer work.

Next, the reviewer follows review and approval. After approval, follow delivery.

4 - Restore Policy Intent or Retire a Policy

Propose earlier governed content through rollback or start asynchronous withdrawal through archive.

Policy rollback and archive solve different problems. Rollback proposes earlier policy intent for another review. Archive removes this policy’s configuration from the receiving products. Neither operation restores a database or rolls back a software installation. Restoring database contents is an operator recovery task, not a policy rollback. Closing a draft abandons only proposed changes. It does not withdraw approved output.

Refer to history and states and revisions first.

Before You Begin

Complete these prerequisites before restoring or archiving a policy:

Identify the policy and the intended outcome: restore earlier intent or retire its contribution.
Confirm policy:rollback and applicable owner/editor access for rollback.
Confirm policy:archive and the retirement impact for archive.
Arrange an authorized operator’s withdrawal check if you lack audit access.

Restore Earlier Policy Intent

You need policy:rollback and applicable policy owner/editor access. Choose an earlier governed revision, not the current revision or an arbitrary saved snapshot. A governed revision records approved intent. A draft snapshot records saved proposed work.

To restore earlier policy intent, follow these steps:

Inspect current governed and open-draft information.
Identify the earlier governed revision that contains the intended policy content.
Select Roll back when the action is available.
Select the intended earlier governed revision in the dialog.
Review the warning about existing open draft work.
Enter a reason for restoring that revision.
Acknowledge replacement if an open proposal exists.
Confirm the rollback decision. Rollback creates a new In Review proposal from the selected content.
Open the resulting draft and Change History to check its content and the version selected for rollback.

The current governed revision remains unchanged. Follow review before the restored proposal can become governed. If you edit that proposal, save and resubmit the corrected work before approval. Replacement confirmation applies only to the exact open draft head shown by the server. If that head changes, inspect the newer work before confirming again. Do not treat successful rollback as immediate target recovery.

If you cannot identify the correct source revision, stop. Ask an authorized reviewer to confirm the intended content. For direct clients, follow the exact rollback preconditions in the application programming interface (API) reference.

Archive a Policy

You need policy:archive and a clear retirement reason. Confirm the policy identifier and impact on shared protection before proceeding.

To archive a policy, follow these steps:

Inspect the current governed revision and any open draft.
Review affected targets and shared contributions.
Select Archive when the action is available.
Enter a nonblank reason.
Confirm the retirement decision. Policy closes applicable open work and starts asynchronous withdrawal.
Inspect policy detail and the withdrawal operation.
Follow withdrawal verification.

For direct clients, use POST /policies/{policy_id}/archive with reason and the current governed-policy ETag in If-Match. Do not substitute a draft token. Do not send archivedBy. Policy derives the actor from trusted identity. Refer to canonical API examples.

An initial archive response does not prove completed withdrawal. Withdrawal removes this policy’s contribution from applicable target output. Archive completion does not prove that every shared location became unprotected. Other policies can retain protection over shared resources.

Verify or Stop

Reload the policy and check Change History for the rollback or archive request before repeating a command that timed out. If Policy reports changed content or a conflicting Policy Integration Manager (PIM) object identifier, send the error to your Policy administrator. The administrator can follow recovery.

For draft-only abandonment, use close an open draft.