---
name: workload-protection-ts-cdr
title: Troubleshooting IBM Cloud account not ingesting audit events with CDR
description: Resolve issues with your IBM Cloud account not ingesting audit events after enabling cloud detection and response (CDR), including verifying the trusted profile and IAM access policies.
last-updated: 2026-09-01
---

> ## Documentation Index
> The table of contents for this documentation set is at https://cloud.ibm.com/docs/workload-protection?format=markdown
> The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt
> Use these files to discover more information as needed.

# Troubleshooting IBM Cloud account not ingesting audit events with CDR
{: #ts-cdr}
{: troubleshoot}

Resolve issues with your IBM Cloud account not ingesting audit events after enabling cloud detection and response (CDR), including verifying the trusted profile and IAM access policies.
{: shortdesc}

After enabling CDR for your IBM Cloud account, the account does not appear as `Connected` under Integrations > Environments > IBM Cloud in your Workload Protection instance.
{: tsSymptoms}

The CDR connection might not be active for one of the following reasons:
{: tsCauses}

- The Trusted Profile was not created correctly, or the Workload Protection instance CRN is not set as a trusted entity in the profile.
- The Trusted Profile does not have the required IAM access policies to read from the Object Storage bucket or view the Service ID.
- The Activity Tracker Event Routing target is not writing to the Object Storage bucket correctly.
- The Code Engine application is not running, either because the registry secret is missing or the API key is incorrect.
- The IAM service-to-service authorization policy between Code Engine and IBM Cloud Object Storage is missing, preventing Object Storage event notifications from being delivered.
- The Object Storage event subscription destination does not match the Code Engine application name.
- The parameters in step 7 (`cdr_bucket_region`, `cdr_bucket_name`, `cdr_ingestion_url`) do not match the resources created in previous steps.

To resolve this issue, complete the following steps:
{: tsResolve}

1. Verify that the Activity Tracker Event Routing target is writing successfully to the Object Storage bucket:

   ```sh
   ibmcloud atracker target get --target <target_name>
   ```
   {: pre}

   Check that `Write Status` shows `success`. If it shows an error, verify that the service-to-service authorization between Activity Tracker Event Routing and IBM Cloud Object Storage is enabled and that the bucket exists in the expected region.

2. Confirm that the Trusted Profile includes the Workload Protection instance CRN as a trusted entity and has the required access policies:

   ```sh
   ibmcloud iam trusted-profile-get ibmcdr-wp-cos
   ```
   {: pre}

   Ensure the trust relationship points to the correct Workload Protection CRN and that policies for `cloud-object-storage` (Viewer, Reader on the bucket) and `iam-identity` (Viewer on the Service ID) are present.

3. Check that the Code Engine application is running:

   ```sh
   ibmcloud ce application get --name sccwp-cdr-app
   ```
   {: pre}

   If the application is not ready, verify that the `icr-secret` registry secret is correctly configured and that the `cdr-secrets` secret contains a valid API key. If the image cannot be pulled, confirm that the Service ID has Reader access to the IBM Cloud Container Registry.

4. Verify that the IAM authorization policy between Code Engine and IBM Cloud Object Storage exists:

   ```sh
   ibmcloud iam authorization-policies
   ```
   {: pre}

   Look for a policy granting Code Engine the `Notifications Manager` role on the IBM Cloud Object Storage instance. If missing, rerun the authorization policy command from step 6 of the setup.

5. Check that the Object Storage event subscription is ready and pointing to the correct application:

   ```sh
   ibmcloud ce subscription cos get --name cdr-cos-sub
   ```
   {: pre}

   Confirm that `Destination` matches `sccwp-cdr-app`, `Bucket` matches your Object Storage bucket name, and `Ready` shows `true`.

6. Verify that the Workload Protection instance was updated with the correct parameters by re-running step 7 of the setup with the correct values. Ensure that `cdr_bucket_region`, `cdr_bucket_name`, `cdr_trusted_profile_id`, `cdr_service_id`, and `cdr_ingestion_url` all match the resources created in previous steps.

7. After making any corrections, allow up to 5 minutes for the connection status to update in the Workload Protection UI.

For more information, see [Enabling Detection and Response for IBM Cloud](https://cloud.ibm.com/docs/workload-protection?topic=workload-protection-cdr-about&format=markdown).