How policy application works

When a policy is attached to a product, the policy's compliance settings are applied to the product. Most surfaces are applied wholesale (the policy replaces the product's values). Permissions are the one surface where the product can add on top of the policy. This page explains exactly what happens so you can trust what's taking effect and manage your products with confidence.

The application rule

Attaching a policy overwrites the product's compliance configuration with the policy's settings on Product Access, Engine & Overrides, and Verification. There's no per-setting merge on those surfaces. The policy is applied wholesale.

Permissions are the exception. The policy's permissions are applied to the product and locked, but the product can still enable additional standard permissions beyond what the policy provides. Custom permissions remain policy-owned while a policy is attached.

Product identity fields (name, description, logo, and banner images) are unaffected because they're inherently per-product and not part of a policy.

Per-surface editability while attached

Surface	Editable on product?	Notes
Product Access	No	Includes minimum age settings, market-specific rules, and Data Lite mode.
Engine & Overrides	No	Includes global baseline, global minimums, and market overrides.
Verification Settings	No	Age assurance, age appeal, adult verification, and parental consent.
Permissions (standard)	Partial	Policy permissions are locked and badged. You can add more standard permissions.
Permissions (custom)	No	Custom permissions are policy-owned. Add them to the policy, not the product.

Non-permissions surfaces example

Setting	Before attaching	Policy value	After attaching
US min digital consent age	13	16	16
US age assurance required	No	Yes	Yes
GB min digital consent age	13	–	–

Attaching the policy replaces all Product Access, Engine, and Verification settings. The product's previous US digital consent age (13) is overwritten by the policy value (16). The GB digital consent age is removed because the policy doesn't define it.

Permissions example

Say your product had the analytics and data_collection permissions before attaching a policy, and the policy provides data_collection and marketing.

Permission	On product before	In policy	After attaching	Editable on product?
data_collection	Yes (Essential)	Yes (Recommended)	Yes (Recommended)	No (locked by policy)
marketing	No	Yes	Yes	No (locked by policy)
analytics	Yes	No	Yes	Yes (product-level addition)

The product keeps analytics as a product-level addition on top of the policy's permissions. data_collection is now managed by the policy and is locked. marketing is added by the policy.

If the product had any custom permissions before the policy was attached, those are dropped on attach. Add custom permissions to the policy itself if they should apply across attached products.

What happens on detach

When a policy is detached, the policy's current settings are copied onto the product as its own settings. Specifically:

• Product Access, Engine & Overrides, and Verification Settings are written onto the product as directly editable values matching the policy's last state.
• Permissions that came from the policy are written onto the product as standard permissions. Product-level additions (such as analytics in the preceding example) are preserved.
• Custom permissions the policy provided are copied to the product as its own custom permissions.

Detaching during a policy switch works differently. Because a new policy is immediately reattached, the previous policy's values aren't copied onto the product. The new policy's values take their place instead.

See Detaching a policy for the full detach flow.

When do changes take effect?

A policy update doesn't automatically change your product's test or live configuration. You must push to test and push to live for each product individually.

Here's the timeline of how policy changes flow to your products:

1. You update the policy. The policy record saves immediately.
2. Attached products still run on their previous configuration. Nothing changes automatically.
3. When you open a product, you'll see a "Policy updated" indicator if the policy changed since the last push to test.
4. Click Push to Test. The policy's configuration is applied and available for review.
5. Click Push Live. The configuration goes to production.

This ensures you have complete control over when changes take effect in each product, even when multiple products share a single policy.