diff --git a/modules/ztp-removing-content-from-managed-clusters.adoc b/modules/ztp-removing-content-from-managed-clusters.adoc
new file mode 100644
index 000000000000..072513b51ded
--- /dev/null
+++ b/modules/ztp-removing-content-from-managed-clusters.adoc
@@ -0,0 +1,127 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/ztp_far_edge/ztp-configuring-managed-clusters-policies.adoc
+
+:_content-type: PROCEDURE
+[id="ztp-removing-content-from-managed-clusters_{context}"]
+= Changing applied managed cluster CRs using policies
+
+You can remove content from a custom resource (CR) that is deployed in a managed cluster through a policy.
+
+By default, all `Policy` CRs created from a `PolicyGenTemplate` CR have the `complianceType` field set to `musthave`.
+A `musthave` policy without the removed content is still compliant because the CR on the managed cluster has all the specified content.
+With this configuration, when you remove content from a CR, {cgu-operator} removes the content from the policy but the content is not removed from the CR on the managed cluster.
+
+With the `complianceType` field to `mustonlyhave`, the policy ensures that the CR on the cluster is an exact match of what is specified in the policy.
+
+.Prerequisites
+
+* You have installed the OpenShift CLI (`oc`).
+
+* You have logged in to the hub cluster as a user with `cluster-admin` privileges.
+
+* You have deployed a managed cluster from a hub cluster running {rh-rhacm}.
+
+* You have installed {cgu-operator-full} on the hub cluster.
+
+.Procedure
+
+. Remove the content that you no longer need from the affected CRs. In this example, the `disableDrain: false` line was removed from the `SriovOperatorConfig` CR.
++
+.Example CR
+
+[source,yaml]
+----
+apiVersion: sriovnetwork.openshift.io/v1
+kind: SriovOperatorConfig
+metadata:
+  name: default
+  namespace: openshift-sriov-network-operator
+spec:
+  configDaemonNodeSelector:
+    "node-role.kubernetes.io/$mcp": ""
+  disableDrain: true
+  enableInjector: true
+  enableOperatorWebhook: true
+----
+
+. Change the `complianceType` of the affected policies to `mustonlyhave` in the `group-du-sno-ranGen.yaml` file.
++
+.Example YAML
+[source,yaml]
+----
+# ...
+- fileName: SriovOperatorConfig.yaml
+  policyName: "config-policy"
+  complianceType: mustonlyhave
+# ...
+----
+
+. Create a `ClusterGroupUpdates` CR and specify the clusters that must receive the CR changes::
++
+.Example ClusterGroupUpdates CR
+[source,yaml]
+----
+apiVersion: ran.openshift.io/v1alpha1
+kind: ClusterGroupUpgrade
+metadata:
+  name: cgu-remove
+  namespace: default
+spec:
+  managedPolicies:
+    - ztp-group.group-du-sno-config-policy
+  enable: false
+  clusters:
+  - spoke1
+  - spoke2
+  remediationStrategy:
+    maxConcurrency: 2
+    timeout: 240
+  batchTimeoutAction:
+----
+
+. Create the `ClusterGroupUpgrade` CR by running the following command:
++
+[source,terminal]
+----
+$ oc create -f cgu-remove.yaml
+----
+
+. When you are ready to apply the changes, for example, during an appropriate maintenance window, change the value of the `spec.enable` field to `true` by running the following command:
++
+[source,terminal]
+----
+$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \
+--patch '{"spec":{"enable":true}}' --type=merge
+----
+
+.Verification
+
+. Check the status of the policies by running the following command:
++
+[source,terminal]
+----
+$ oc get <kind> <changed_cr_name>
+----
+
++
+.Example output
+[source,terminal]
+----
+NAMESPACE   NAME                                                   REMEDIATION ACTION   COMPLIANCE STATE   AGE
+default     cgu-ztp-group.group-du-sno-config-policy               enforce                                 17m
+default     ztp-group.group-du-sno-config-policy                   inform               NonCompliant       15h
+----
+
++
+When the `COMPLIANCE STATE` of the policy is `Compliant`, it means that the CR is updated and the unwanted content is removed.
+
+. Check that the policies are removed from the targeted clusters by running the following command on the managed clusters:
++
+[source,terminal]
+----
+$ oc get <kind> <changed_cr_name>
+----
+
++
+If there are no results, the CR is removed from the managed cluster.
\ No newline at end of file
diff --git a/scalability_and_performance/ztp_far_edge/ztp-configuring-managed-clusters-policies.adoc b/scalability_and_performance/ztp_far_edge/ztp-configuring-managed-clusters-policies.adoc
index 9d89f874d695..aac132b609d5 100644
--- a/scalability_and_performance/ztp_far_edge/ztp-configuring-managed-clusters-policies.adoc
+++ b/scalability_and_performance/ztp_far_edge/ztp-configuring-managed-clusters-policies.adoc
@@ -50,4 +50,6 @@ include::modules/ztp-restarting-policies-reconciliation.adoc[leveloffset=+1]
 
 * For information about using {cgu-operator-first} to construct your own `ClusterGroupUpgrade` CR, see xref:../../scalability_and_performance/ztp_far_edge/cnf-talm-for-cluster-upgrades.adoc#talo-about-cgu-crs_cnf-topology-aware-lifecycle-manager[About the ClusterGroupUpgrade CR].
 
+include::modules/ztp-removing-content-from-managed-clusters.adoc[leveloffset=+1]
+
 include::modules/ztp-definition-of-done-for-ztp-installations.adoc[leveloffset=+1]