Skip to main content

Customer Managed Policies

A Customer Managed Policy (CMP) is a reusable IAM policy document that you author once in Prism and attach to one or more permission sets. When a permission set with a CMP is provisioned to an AWS account, Prism materialises the policy in that account under the name Prism-<policy-name> and attaches it to the provisioned IAM role.

CMPs are the third policy category on a permission set, alongside AWS Managed Policies and Inline IAM Policies. They sit between the other two:

AWS Managed PoliciesCustomer Managed PoliciesInline Policies
Authored byAWSYouYou
Reusable across permission setsYesYesNo
Lives in target accountsCentrally (AWS)Per-account (Prism-<name>)Embedded in the role
Edits propagate across accountsn/a (AWS controls)Yes, automaticallyOnly after re-saving the permission set

Use a CMP when you have a custom policy document that needs to be attached to multiple permission sets, and you want a single edit to propagate everywhere that uses it.

Customer Managed Policies List

Navigate to Admin Portal > Customer Managed Policies from the sidebar. The page shows every CMP in the library with a search box, a count of total policies, and a New Policy button.

Available Actions

ActionDescriptionLink
New PolicyCreate a new customer-managed policyCreate a Customer Managed Policy
Edit (row action)Modify an existing policy's documentEdit a Customer Managed Policy
Delete (row action)Cascade-delete a policy from the library and from every accountDelete a Customer Managed Policy
rollouts (chip on the row)Open the per-account rollout history for this policyRollout Status

How Customer Managed Policies Work

When you attach a CMP to a permission set and provision an assignment to an AWS account:

  1. Prism looks up arn:aws:iam::<accountID>:policy/Prism-<name> in the target account.
  2. If the policy does not exist, Prism creates it with your stored document, the description Managed by Prism, and tags identifying it as Prism-managed.
  3. If the policy already exists and is already tagged as Prism-managed, Prism updates the document if it differs from the stored version (creating a new IAM policy version and setting it as default).
  4. Prism attaches the policy ARN to the provisioned IAM role.

Adoption

If an IAM policy named Prism-<name> already exists in the target account but isn't tagged as Prism-managed, Prism adopts it: it adds the Prism management tags and overwrites the document with your stored version. The IAM policy keeps its ARN — anything else attached to it continues to work — but Prism is now the source of truth for its contents.

warning

Adoption overwrites the existing policy's document. If you have a manually-managed Prism-<name> policy in any of your accounts and don't want Prism to overwrite it, rename it (or rename your CMP) before attaching.

What gets stored on the IAM policy

After provisioning, the policy in each target account carries these tags:

Tag keyValue
Prism:Managedtrue
Prism:CustomerPolicyIDThe CMP's UUID
Prism:Adoptedtrue (only on policies that existed before Prism took them over)
Prism:AdoptedAtISO timestamp of adoption

You can verify these via aws iam list-policy-tags --policy-arn arn:aws:iam::<accountID>:policy/Prism-<name>.


Create a Customer Managed Policy

Define a reusable IAM policy document that any permission set can attach.

Prerequisites

  • You should know which IAM actions and resources your policy needs to grant.
  • The policy document must be valid IAM JSON. See Inline IAM Policies for a refresher on policy structure.

Step-by-Step Guide

  1. Navigate to Admin Portal > Customer Managed Policies from the sidebar.
  2. Click New Policy in the top-right.
  1. Fill in the policy details:
    • Name, A unique name within your tenant. Becomes Prism-<name> in every target account. The helper text under the field shows the resulting AWS name as you type.
    • Description, Optionally, describe the purpose of this policy.
    • Policy Document (JSON), Paste or write the IAM JSON document.
  2. Click Save.

Field Reference

FieldTypeRequiredDescription
NameTextYesA unique CMP name within your tenant. Becomes Prism-<name> in target accounts. Allowed characters: alphanumeric and + = , . @ _ -. Maximum 122 characters (the 6-character Prism- prefix is added on top, fitting within AWS's 128-character IAM policy name limit).
DescriptionTextNoFree-form description shown in the library list and in target-account IAM consoles.
Policy Document (JSON)JSONYesA valid IAM policy document. Must include Version and a non-empty Statement array. Up to 6,144 non-whitespace characters (AWS's customer-managed policy size limit).
warning

If you type a name that matches a well-known AWS managed policy (e.g. IAMFullAccess, ReadOnlyAccess), a yellow warning appears suggesting you use the AWS Managed Policies section on the permission set instead. The warning does not block save — you can still create a CMP with that name if you genuinely intend to ship your own custom document.

tip

Names are realm-scoped, not globally unique. Two different tenants can each have their own CMP named S3ReadOnly; each gets its own Prism-S3ReadOnly policy in their accounts.

What Happens Next

After creating a CMP:

  1. The policy is stored in Prism's library. It is not yet in any AWS account.
  2. The CMP appears in the library list and is selectable from the Customer Managed Policies section of any permission set's edit form.
  3. The IAM policy is only materialised in an AWS account when a permission set that references this CMP is provisioned to that account (via an assignment).

Edit a Customer Managed Policy

Update a CMP's document. Saved changes propagate automatically to every AWS account where the policy is currently attached.

Prerequisites

  • The CMP must already exist in the library.
  • Note that edits propagate immediately; there is no draft mode.

Step-by-Step Guide

  1. On the Customer Managed Policies page, click the Edit icon for the row you want to change.

  2. The Edit Customer Managed Policy dialog opens, pre-filled with the current name, description, and document.

  3. Modify the Policy Document (JSON) (or description). The name cannot be changed once the policy exists in target accounts.

  4. Click Save.

  5. A Propagate update confirmation dialog appears showing how many accounts and which permission sets are affected:

    This will update the policy in N account(s). Affected permission sets: PS-1, PS-2, ...

  6. Click Save and propagate to confirm.

Field Reference

FieldEditable?Notes
NameNoThe name is part of the IAM policy ARN in every target account. Renaming would orphan the existing policy. Delete and re-create with a new name if you need to rename.
DescriptionYesUpdated in Prism's library only; not reflected in IAM until the next propagation creates a new policy version.
Policy Document (JSON)YesPropagates to every attached account as a new IAM policy version and is set as the default.
info

Propagation is asynchronous. The dialog dismisses immediately on confirm, but the per-account work happens in the background. Open the Rollout Status panel to monitor progress.

warning

AWS limits each customer-managed policy to 5 versions. When Prism propagates an edit and the policy is already at the limit, Prism deletes the oldest non-default version to make room for the new one. Older versions are not recoverable through Prism.

What Happens Next

For each account where the policy is currently attached, Prism:

  1. Records a PENDING row in the rollouts log.
  2. Connects to that account and calls CreatePolicyVersion with the new document, setting it as the default.
  3. If the policy is at AWS's 5-version cap, prunes the oldest non-default version first.
  4. Marks the rollout row SUCCESS (or FAILED with an error message).

If any rollouts fail, a banner with retry options appears in the Rollout Status panel.


Attach a Customer Managed Policy to a Permission Set

CMPs are attached to permission sets through the permission set edit flow, not from this page.

Step-by-Step Guide

  1. Navigate to Admin Portal > Permission Sets.
  2. Open the permission set you want to attach the CMP to (or create a new one — see Create Permission Set).
  3. In the edit form, expand the Customer Managed Policies accordion (between Inline Policies and any other sections).
  4. Tick the checkbox next to each CMP you want to attach. The count next to the section title updates live.
  5. Save the permission set.
tip

Selecting a CMP triggers immediate propagation to every AWS account where this permission set is already provisioned. You don't need to re-assign or re-provision — the policy is created and attached in each account asynchronously. Open the Rollout Status panel for the CMP to watch it land.

warning

A role can have at most 10 attached managed policies (AWS Managed + Customer Managed combined). Inline policies don't count toward this limit. If a save would push the total past 10, Prism rejects the update with a clear error.

Detach a CMP from a Permission Set

To remove a CMP from a permission set without deleting it from the library:

  1. Edit the permission set.
  2. Uncheck the CMP in the Customer Managed Policies accordion.
  3. Save.

Prism asynchronously detaches the policy ARN from every IAM role provisioned for this permission set, across every account. The IAM policy itself is not deleted — other permission sets in your tenant may still reference the same CMP, and the policy may be attached to non-Prism roles in your accounts.

You'll see DETACH events in the Rollout Status panel for each affected account.


Delete a Customer Managed Policy

Remove a CMP from the library and from every AWS account where it was attached.

Prerequisites

  • The action is irreversible. The IAM policy is deleted from every account where it is no longer attached to anything outside of Prism.

Step-by-Step Guide

  1. On the Customer Managed Policies page, click the Delete icon for the row.

  2. The Delete customer-managed policy dialog appears with a summary:

    This will detach the policy from N role(s) in M account(s) and delete the IAM policy from each. This cannot be undone.

  3. Type the exact policy name into the confirmation field.

  4. Click Delete.

warning

The Delete button stays disabled until the typed name matches the policy name character-for-character.

What Happens Next

Cascade delete runs in two phases:

Phase A — Library state (synchronous). Prism detaches the CMP from every permission set in the database and soft-deletes the library row. After Phase A, the CMP no longer appears in the library list or in any permission set's CMP picker, even if Phase B is still running.

Phase B — AWS state (asynchronous, per-account). For each AWS account where the policy was attached:

  1. Detach the policy from every Prism-managed role that referenced it.
  2. Check whether anything else is still attached to the IAM policy (for example, an admin attached Prism-<name> to a non-Prism role through the AWS console).
  3. If the policy has no remaining attachments, delete all non-default versions and then delete the policy.
  4. If the policy is still attached to non-Prism entities, skip the deletion and record a warning in the rollout row. The IAM policy is left in place; only Prism-owned roles lose access.

This conservative-delete behavior prevents Prism from breaking unrelated workloads.

info

Per-account results land in the rollout log with event_type = DELETE. Open the Rollout Status panel for the deleted policy to confirm everything cleaned up successfully.


Rollout Status

Every async action Prism takes against a CMP — create, adopt, edit, attach, detach, delete — is recorded in a per-account rollout log. Open it via the rollouts chip on any row in the Customer Managed Policies list.

Summary chips

At the top of the dialog, three chips summarise the latest rollout state:

  • N success — green; rollouts that completed without error.
  • N pending — orange; rollouts still in flight.
  • N failed — red; rollouts that hit an error.

Columns

ColumnDescription
AccountAWS account ID this row applies to.
EventWhat Prism tried to do in this account. See the table below.
StatusPENDING, SUCCESS, or FAILED.
ErrorIf status is FAILED, the AWS error message (e.g. role doesn't exist, permission denied). Empty for successful rollouts.
StartedWhen Prism began this account's work.

Event types

EventWhen you see it
CREATEPrism created Prism-<name> in the account for the first time.
ADOPTPrism found an existing Prism-<name> in the account, tagged it, and overwrote its document.
EDITPrism updated the policy to a new version.
ATTACHPrism confirmed the policy is attached to a role; no AWS call needed because the desired state already matched.
DETACHPrism removed the policy ARN from a role (PS update removed the CMP, or the CMP was deleted from the library).
DELETEPrism deleted the IAM policy from the account during cascade delete.

Retry failed rollouts

If any rows in the panel show FAILED, a Retry N failed button appears in the bottom-left of the dialog. Click it to re-run the most recent rollout for every failed account.

tip

Retry is manual, not automatic. If a rollout fails because of a transient AWS error (throttling, lost role assumption), retry usually clears it. If the underlying issue is permanent (e.g. you revoked Prism's cross-account role), fix that first, then retry.


Edge Cases & FAQs

I changed a managed policy on a permission set and my CMP is still attached. Is that expected?

Yes. CMPs are preserved across edits to other policy categories. When you change the AWS Managed Policies or Inline Policies on a permission set, Prism re-syncs the affected IAM roles but deliberately leaves attached CMPs in place. After the sync, Prism re-asserts every CMP on the role to confirm it's still attached. You'll see an ATTACH event in the rollout log for each CMP on the permission set — the policy was already there, so no AWS state changed.

I edited a CMP but the rollout panel shows zero work. What happened?

The CMP isn't currently attached to any provisioned assignment. CMPs are only materialised in AWS accounts when a permission set that references them is provisioned to that account. If the CMP is only in the library, an edit updates Prism's stored document but has nothing to propagate.

Can I attach more than 10 CMPs to a single permission set?

No. The IAM limit of 10 attached managed policies per role applies. CMPs and AWS-managed policies share the same budget. Inline policies are separate and don't count. Prism rejects PS edits that would push the combined count past 10.

What if my policy document is too large?

CMPs are subject to the same 6,144-non-whitespace-character limit that AWS enforces on customer-managed policies. Prism validates this on save. If you need a larger document, split it across multiple CMPs and attach all of them to the permission set.

What happens if someone edits Prism-<name> through the AWS console?

Prism does not currently watch for out-of-band edits. The next time you save a change to the CMP in Prism, your stored document overwrites whatever is in the target account. Treat the AWS console as read-only for Prism-<name> policies.

I deleted a CMP and the rollout panel shows a FAILED delete with "still attached to non-Prism entities." What now?

This is by design — Prism refuses to delete an IAM policy that is attached to anything outside of Prism's roles. To force the deletion, log into the affected AWS account, detach Prism-<name> from the non-Prism entity yourself, then click Retry N failed in the rollout panel.

How do I know which CMPs are attached to a permission set?

Open the permission set in Admin Portal > Permission Sets. The detail view shows attached CMPs in the Customer Managed Policies section alongside AWS managed and inline policies. The permission set list also shows a count chip.


  • Admin Portal > Customer Managed Policies, This page.
  • Admin Portal > Permission Sets, Attach CMPs to permission sets here.
  • Admin Portal > Assignments, Provision permission sets (and the CMPs they reference) to AWS accounts.