Overview
Domains and multi-tenancy were introduced into QRadar to enable customers to have stricter and more configurable control over the accessing, sharing and correlation of network data within their organization.
This article explains points to be considered before proceeding with the removal of a domain and the data related to that domain. This is a common requirement for Managed Security Service Provider (MSSP) clients who need to offboard one of their customers completely from the QRadar SIEM. We should note that deleting a Domain and its associated data from the QRadar console requires careful consideration to ensure there is no impact on other active Domains or shared configurations.
When offboarding a domain in QRadar, it's not just about removing the domain itself—cleaning up associated content is equally important. This document serves as a guide to ensure the smooth and complete removal of a Domain, its associated Tenant, and all related data. We will also cover some common errors that could be encountered during the deletion process. Before diving into the actual domain offboarding process, let's first understand the concepts of Domains and Tenants in QRadar
The following sections outline the key topics discussed in this article:
What is a Domain?
A domain is a segment of a network that is defined by a boundary, and which contains one or more network entities. In QRadar, we use network entities, such as event collectors, log sources and fow collectors to define domain boundaries.
The domain allow you to map the following:
- Domains can be mapped to these event sources:
- Event Collector (EC Domain)
- Log Source (LS Domain)
- Log Group (LSG Domain)
- Custom Event Properties (CEP Domain)
- Domains can be mapped to these flow sources:
- Flow Collectors (FC Domain)
- Flow Source (FS Domain)
- Flow VLAN IDs (VLAN Domain)
- Domains can be mapped to Vulnerability Assessment (VA) Scanners
What is a Tenant?
In QRadar, a tenant is a way to logically separate data, users, and configurations within a single deployment. It allows organizations to isolate security data by department, business unit, or client—ideal for MSSPs or large enterprises. Each tenant has its own rules, dashboards, and access controls, ensuring data privacy and administrative independence.
Example: Domain and Tenant Deletion
To better illustrate the domain offboarding process, let’s walk through a practical example of how to delete a domain along with its associated tenant in a QRadar deployment.
The screenshot below displays the current setup of domains and tenants in our test environment, providing a clear starting point before we proceed with the removal steps.
Domains in the deployment.

Tenants in the deployment.

Backend entries before deletion:
[root@console ~]# psql -U qradar -c "select * from domains;"
id | name | description | deleted | editdate | tenant_id
----+----------+-------------+---------+---------------+-----------
0 | | | f | 0 |
1 | Domain 1 | | f | 1741588368525 | 1
2 | Domain 2 | | f | 1741588728318 | 2
3 | Dummy | | t | 1741588845247 |
(4 rows)
[root@console ~]# psql -U qradar -c "select * from tenant;"
id | name | description | eps | fpm | deleted | editdate
----+----------+-------------+------+------+---------+---------------
1 | Tenant 1 | | 1000 | 1000 | f | 1741588459982
2 | Tenant 2 | | 2000 | 2000 | f | 1741588479402
(2 rows)
Scenario:
In this
scenario, we are preparing to delete Domain 1 and its Tenant, which is
being offboarded along with its associated data.
We are offboarding Domain 1 from QRadar, along with its data, and will
demonstrate the steps to delete it from the deployment.
In this
scenario, we are preparing to delete Domain 1 and its Tenant, which is
being offboarded along with its associated data.
We are offboarding Domain 1 from QRadar, along with its data, and will
demonstrate the steps to delete it from the deployment.
In this
scenario, we are preparing to delete Domain 1 and its Tenant, which is
being offboarded along with its associated data.
We are offboarding Domain 1 fg with its data, and will
demonstrate the steps to delete it from the deployment.In this scenario, we are preparing to delete Domain 1 and its Tenant, which is being offboarded along with its associated data.
We are offboarding Domain 1 from QRadar, along with its data, and will demonstrate the steps to delete it from the deployment.
About the Scenario:
In our example:
- Domain 1 has an Event Processor (Endpoint) associated as a source.
- Tenant 1 is assigned to this domain (Domain1).
It is crucial to complete the steps outlined in the "Essential Steps for Domain Offboarding in QRadar" checklist below, before proceeding with the domain deletion.
Essential steps for Domain Offboarding
Offboarding a Domain in QRadar is a complex process that requires careful planning to avoid data loss, misconfigurations, and compliance issues.
Before proceeding, follow the key steps below to ensure a seamless transition.
- Back-Up All Critical Data
- Remove Domain-Specific Integrations
- Remove Domain-Specific Use Cases.
- Remove Authorization service Token
- Remove Applications Instances Linked To The Domain
- Remove Users And Security Profiles Of The Domain
- Remove The Domain-Specific Reference Sets
- Remove IP Ranges From Network Hierarchy Of The Domain
- Remove Domain and Tenant
- Remove Domain-Specific Data From The Disk
1.Backup All Critical Data
Before deleting a Tenant or Domain in QRadar, it's crucial to create a full system backup. This precaution helps prevent accidental data loss and ensures you can restore your system configurations if needed. Keep in mind that this backup captures the entire QRadar deployment and is not limited to any specific domain.
For detailed backup and recovery procedures, refer to IBM’s official guide: QRadar Backup & Recovery Guide.
2. Remove Domain-Specific Integration
Identify all log sources integrated with the specific domain and analyse their dependencies. These log sources must be disabled or removed.
Important Step Before Proceeding Further:
The first action is to stop the incoming data flow to IBM QRadar for the domain being decommissioned. To achieve this:
-
- Reach out to each end customer.
- Instruct them to coordinate with their respective endpoint teams.
- Ensure all log sources related to the domain are stopped from sending logs to IBM QRadar
- If there are REST APIs or other pull-based log source integrations, these should be disabled directly from the Log Sources tab in QRadar to stop data collection.
This step is critical to ensure that QRadar no longer receives data from the domain scheduled for removal.
3. Remove Domain-Specific Use Cases
Before offboarding a domain in QRadar, it's important to identify and remove any domain-specific use cases/Rules that were created for it. If rules, logic, or other content were created specifically for the domain being decommissioned, they can become irrelevant once the domain is gone, be sure to review and clean them up as part of your offboarding process.
Failing to remove domain-specific rules can result in:
• Unused rules cluttering the rule engine
• Irrelevant alerts generating noise
• Unnecessary resource consumption
By cleaning up these rules, you maintain a lean and efficient QRadar environment—and prevent potential confusion or misfires down the line.
Identifying and Removing Domain-Specific Rules with the Use Case Manager App
QRadar's Use Case Manager (UCM) app makes it easy to identify domain-specific rules and remove them as part of your offboarding checklist.
Steps to Check Rules via Use Case Manager App
-
- Log in to the QRadar Console.
- Navigate to the Use Case Manager (UCM) app.
- Apply a domain filter (e.g., Domain1) to isolate rules associated with the domain you're offboarding.
- In addition to filtering by domain, you can refine your search using any custom identifiers you may have implemented to distinguish domain-specific rules, such as:
- Keywords in rule names (e.g., including Domain1 as a prefix or tag).
- Organizing rules into separate rule groups created specifically for the domain.
- Review the filtered rules to ensure they are not used elsewhere or no longer needed.
- Select and delete the domain-specific rules you want to remove.
In the screenshot provided, we’ve applied a filter to show only the rules related to “Domain 1” for easy identification.

4. Remove Authorized Service Tokens
As part of the domain offboarding process in IBM QRadar, it’s essential to remove Authorized Service Tokens linked to the domain being decommissioned. These tokens are often tied to application instances running within the domain, and failing to remove them can leave behind unnecessary dependencies or access points.
Authorized Service Tokens grant access for apps and integrations. If these tokens are left active after a domain is offboarded, they may still retain permissions tied to now-removed entities, which can create confusion or even pose security risks.
Identifying and Removing Authorized Service Tokens
You can locate and delete domain-specific tokens using the Authorized Services window in the QRadar Admin interface.
Steps to Check token via Authorized Services window
To delete the authorized service token you can follow below steps from Authorized Service window.
-
- Login to the QRadar Console.
- Navigate to Admin from the QRadar navigation menu.
- Under System Configuration, select Authorized Services.
- Apply a filter using the relevant Security Profile or User Role (e.g., Domain1) to identify tokens associated with the domain you’re offboarding.
- Select the specific Authorized Service entry you wish to remove.
- Click the Delete button to complete the removal.
Refer to the screenshot below for visual guidance on identifying and deleting the correct token.

Cleaning up these tokens ensures your QRadar environment remains secure and free from unused or outdated configurations.
5. Remove Applications Instances Linked To The Domain
When offboarding a domain in IBM QRadar, it’s important to remove any multi-tenant application instances associated with that domain. These instances are often deployed to provide domain-specific visibility and control for individual tenants in a shared QRadar environment.
When managing multiple domains, it's common to deploy separate instances of a security application—such as a User Behavior Analytics (UBA) app—for each domain. This approach helps monitor activities independently across environments.
However, once a domain is decommissioned, it's important not to overlook the cleanup of associated application instances. Leaving these instances active can lead to unnecessary resource usage and potential configuration conflicts.
As a best practice, always include a review and removal of domain-specific application instances as part of your domain offboarding checklist.
How to Identify and Remove Domain-Specific App Instances
You can identify these instances using the Assistant App.
Steps to Check Application Instances via Assistant App
-
- Login to your QRadar SIEM console.
- Open the Assistant App in your management interface.
- Navigate to the Applications tab.
- Click the Manage button.
- You'll see a list of installed applications.
Look for the "Number of Instances" column – this will indicate how many instances of each app are currently running.
For example, in the screenshot provided, you can see that the UBA App has three active instances, each likely tied to a specific domain.

-
- Click on the application name (e.g., UBA App) to view instance details.
- From the list of instances, locate the one running in the domain you plan to offboard.
- Click the three dots under the Options column and select Delete Instance to safely remove it.
In this example the screenshot provided, we will delete the instance of the UBA app associated with Domain 1.

For detailed steps please review Managing application instances in QRadar Assistant
6. Remove Users and Security Profiles Of The Domain
When offboarding a domain in QRadar, it’s crucial to remove any user accounts and security profiles specifically tied to that domain. These accounts and profiles control user access to the domain’s data, and they must be deleted to ensure proper decommissioning. Doing so is critical not only for maintaining a clean and secure environment but also from a compliance and audit perspective.
A. Removing User Accounts:
You can use the User Management tool under the Admin tab to identify and remove users associated with the domain.
Additionally, make sure to reassign any dependencies tied to those users (like active offenses, rules, or report.
For a step-by-step guide, refer to IBM’s official documentation: How to Delete User Accounts in QRadar and Reassign Dependencies
Identifying and Removing Users associated with domain being offboarded.
You can locate and delete Users specific to domain using the User Management tool in the QRadar Admin interface.
Steps to Check token via User Management tool
To delete the Users you can follow below steps User tool.
-
- Login to the QRadar Console.
- Navigate to Admin from the QRadar navigation menu.
- Under User Management, select Users.
- Apply a filter using the relevant Security Profile or User Role (e.g., Domain1) to identify tokens associated with the domain you’re offboarding.
- Select the specific User you wish to remove.
- Click the Delete button to complete the removal
Refer to the screenshot below for visual guidance on identifying and deleting the correct User.

B. Removing Security Profiles:
Security profiles define what data and functionality a user can access within QRadar.
Use the Security Profile Management tool under the Admin section to identify and remove any security profiles associated with the domain.
Identifying and Removing Security profiles associated with domain being offboarded.
To delete the security profile you can follow below steps Security Profile Management window.
-
- Login to the QRadar Console.
- Navigate to Admin from the QRadar navigation menu.
- Under User Management, select Security Profiles.
- In the left pane, select the security profile that you want to delete.
- Apply a filter using the relevant Security Profile or User Role (e.g., Domain1) to identify tokens associated with the domain you’re offboarding.
- Click the Delete button to complete the removal.
For further guidance, refer to: How to Delete a Security Profile in QRadar
Refer to the screenshot below for visual guidance on identifying and deleting the correct security Profile.

Ensure that all domain-specific user accounts are deactivated or deleted, and that any custom roles, security profiles, or access policies tied to the offboarded domain are thoroughly reviewed and removed.
7. Remove The Domain-Specific Reference Sets
As part of the domain or tenant offboarding process in IBM QRadar, it's important to remove any reference sets that were specifically created for that domain. Reference sets are commonly used to store dynamic data such as IP addresses, usernames, and custom indicators, which are often utilized in correlation rules, searches, or offenses. Removing the .
Removing these sets is not only a best practice for maintaining a clean deployment but is also essential from a compliance and audit standpoint—especially when the reference sets contain tenant-specific or sensitive information.
Identifying and Removing Reference Sets that associated with tenant being offboarded.
To delete the Reference set you can follow below steps from Reference Set Management tool.
-
- Login to the QRadar Console.
- Navigate to Admin from the QRadar navigation menu.
- Under System Configuration, select Reference Set Management tool.
- Click on the Tenant column to sort the list with tenant Name.
- Select the reference set which is created for Tenant(e.g., Tenatn1) which you are going to offboard.
- Click the Delete button to complete the removal.
Refer to the screenshot below for visual guidance on identifying and deleting the correct Reference set

For detailed instructions, refer to IBM’s guide: Deleting Elements from a Reference Set in QRadar
Cleaning up unused reference sets is a small but critical step in maintaining a clean, optimized, and secure QRadar environment.
8. Remove IP Ranges from Network Hierarchy Of the Domain
In IBM QRadar, network hierarchy plays a crucial role in the structured representation of network devices and segments within your environment. It includes elements such as subnets, VLANs, IP ranges, and specific devices, all organized hierarchically to enhance security monitoring and incident response efficiency.
When offboarding a QRadar domain, it's important to remove its network components if they have been added to QRadar through the network hierarchy. This ensures that your network representation remains accurate and up-to-date.
You can identify the elements in the network hierarchy specific to the domain and you have those removed.
Identifying and Removing the IP/CIDR ranges that associated with Domain being offboarded.
To delete the IP/CIDR range for network you can follow below steps from Network Hierarchy.
-
- Login to the QRadar Console.
- Navigate to Admin from the QRadar navigation menu.
- Under System Configuration, select Network Hierarchy.
- In the Network Views window, look under the Domain column to find the domain you're offboarding (e.g., Domain 1).
- Identify the Network Name associated with the domain you want to remove.
- Select the appropriate network entry, then click Delete to remove it from the hierarchy.
Refer to the screenshot below for visual guidance on identifying and deleting the correct Network for the offboarded Domain.

By following these steps during domain offboarding, you ensure that QRadar remains clean, accurate, and optimized for performance and detection.
9. Remove Domain and Tenant
When offboarding clients from your QRadar deployment, following a structured and well-defined sequence is essential to prevent configuration issues, dependency errors, or lingering access.
Here’s the recommended order for a smooth and compliant offboarding process:
1. Delete the Domain
Start by removing the domain associated with the client. Domains serve as key identifiers and logical containers within QRadar, and deleting them first ensures that other linked entities are properly detached.
2. Remove the Tenants
After the domain is deleted, proceed to remove any tenants associated with that domain. This final step ensures that all access boundaries and configuration layers tied to the client are fully removed.
⚠️ Important: Always follow this sequence—domain first, then tenant—to avoid dependency-related complications in the offboarding process.
Identifying and Removing Domain1 i.e Domain being offboarded.
QRadar provides a simple yet powerful interface to manage domains through the Domain Management tool within the Admin panel.
Steps to Delete the Domain via Domain Management tool.
-
- Log in to the QRadar Console
- Navigate to the Admin Panel
- Under the System Configuration section, select Domain Management.
- Locate the Domain
- Find the domain you intend to delete (e.g., Domain1) in the list. Click on the row to select.
- Initiate Deletion.
- Click the Delete button. A confirmation dialog box will appear.
- Confirm the Deletion
- Carefully review the warning prompt and confirm your action.
Domain1 will now be permanently removed from your QRadar deployment.
Deleting a domain is a straightforward process in QRadar, but it should always be handled carefully to avoid unintended impacts on your deployment.
Kindly refer to the screenshot below for a visual reference of the Domain Management interface and the deletion process.

Identifying and Removing Tenant 1 i.e Tenant being offboarded.
Once Domain 1 has been successfully deleted as part of the offboarding process, the next step is to remove the associated tenant—in this case, Tenant 1.
Removing the tenant ensures that all remaining access boundaries, user roles, and isolated configurations are completely decommissioned, leaving no trace of the offboarded client in your deployment.
This ensures that all linked components are fully decommissioned from the QRadar deployment.
QRadar provides a simple yet powerful interface to manage Tenant through the Tenant Management tool within the Admin panel.
Steps to Delete the Tenant via Tenant Management tool.
-
- Log in to the QRadar Console
- Navigate to the Admin Panel
- Under the System Configuration section, select Tenant Management.
- Locate the Tenant
- Find the Tenant you intend to delete (e.g., Tenant1) in the list. Click on the row to select.
- Initiate Deletion.
- Click the Delete button. A confirmation dialog box will appear.
- Confirm the Deletion
- Carefully review the warning prompt and confirm your action.
Tenant1 will now be permanently removed from the QRadar deployment.
Kindly refer to the screenshot below for a visual reference of the Tenant Management interface and the deletion process.

How to Verify Deleted Domains and Tenants in QRadar Using CLI
When managing Domains and Tenants in QRadar, ensuring that deletions are successfully to processed is crucial. Even after deleting a domain or tenant from the Admin UI, the record still exists in the backend database with a deleted flag.
Verifying deletions through the CLI provides assurance that Domains and Tenants are completely decommissioned in QRadar.
This not only helps maintain a clean and efficient deployment but also supports audit readiness and security best practices.
10. Remove Domain-Specific Data From The Disk
Offboarding a domain from a QRadar deployment involves more than just removing it from the system. Depending on the associated infrastructure—such as Event Collectors, Event Processors, or Data Log Collectors (DLCs)—additional cleanup steps may be necessary to ensure data hygiene and system integrity.
Here’s a breakdown of key considerations and actions to take after removing a domain:
1.If a DLC (Data Log Collector) Is Associated with the Domain.
When a DLC is the only component associated with the domain:
-
- Offboard the DLC log sources.
- Proceed to remove the DLC itself from the deployment.
Note that data collected by the DLC is typically forwarded to a shared Event Processor or the console. In this case, Back up the relevant data from the target system and then clean up the residual event data from the host.
2.If a Dedicated Event Collector Is Associated with the Domain
Once the domain and its associated tenants have been fully removed from the deployment, any dedicated Event Collector tied to that domain can be decommissioned. Ensure that all preceding offboarding steps are completed before taking this action.
Event collectors will have an Event Processor as the destination; the tenant's data will need to be removed from the Event Processor.
3. If a Shared Event Processor Is in Use
In cases where a shared Event Processor is the destination for an Event Collector linked to the offboarded domain, event data may still reside on that shared system. Each tenant has a uniquely identified folder on the Event Processor, based on its Tenant ID. You can retrieve this ID by running:
psql -U qradar -c "select * from tenant;"
This command lists all tenants along with their corresponding IDs. Once you identify the appropriate Tenant ID, you can manually back up the data folders, then proceed with deletion. Common folder paths include:
Events: /store/ariel/events/records/aux/<TenantID>/Year/Month/Day/Hour/Minute
Flows: /store/ariel/flows/records/aux/<TenantID>/Year/Month/Day/Hour/Minute
Ensure proper backups are taken before removing any data in case it required later.
4. If a Dedicated Event Processor Is Associated with the Domain.
If the offboarded domain used a dedicated Event Processor, take a complete backup of all relevant data first. For comprehensive guidance, refer to IBM's official documentation: QRadar Backup & Recovery Guide
After ensuring backups are safely stored, then you can remove the Event Processor from your QRadar deployment.
By following these domain-specific cleanup steps, you can ensure a clean and consistent QRadar environment post-domain offboarding. Always remember to validate data integrity and backups before proceeding with any deletions or system changes.
Common Errors During Domain Offboarding
ERROR: “Cannot delete Tenant that has assigned Domains. Remove all Domains from this Tenant and try again.”
Cause: This error occurs because QRadar prevents the deletion of tenants while they still have domains assigned to them. Attempting to delete tenants before removing their associated domains causes the system to block the operation to maintain data integrity.
Resolution:
The correct sequence is to first delete the domains assigned to the tenant, and only then proceed to delete the tenant itself. By following this order, you ensure a smooth offboarding process that respects system dependencies and prevents errors.
Following this best practice helps maintain a clean and error-free environment during domain offboarding in QRadar.
Below is a screenshot of the error message for your reference:

ERROR: “Domain cannot be deleted as it is assigned to one or more deployed security profiles.”
Cause: This happens when a Security Profile is still associated with the domain you’re trying to delete. QRadar prevents domain deletion until these linked Security Profiles are removed.
Resolution:
Delete the Security Profile(s) associated with the domain first.
Before deleting Security Profiles, ensure that any users assigned to those profiles have their dependencies properly reassigned. This step is crucial to maintain correct access controls and permissions across your environment.
For visual guidance, please refer to the attached screenshot

If you need detailed instructions on how to delete a user and reassign their dependencies safely, refer to the official IBM support page:
QRadar Deleting User Account and Reassignment of Dependents.
For added clarity, please refer the attached screenshot showing users assigned to a Security Profile during the deletion process.

ERROR: “You must remove the association with the Application Instances below before this Security Profile can be deleted.”
Cause:This occurs because the Security Profile is still linked to one or more Application Instances. Additionally, you might see a related error such as:
Resolution:
These errors indicate that before deleting the Security Profile, you must:
- Remove the association with all relevant Application Instances linked to the domain.
- Revoke the authorization service tokens for those applications.
Failing to perform these steps will prevent the successful removal of the Security Profile.
By carefully removing these dependencies first, you ensure a smooth and error-free Security Profile deletion during domain offboarding in QRadar.
For visual guidance, please refer to the attached screenshot showing the associations with Application Instances and authorization tokens that must be addressed during the deletion process.

Once you have successfully deleted the associated Security Profile(s), you can safely proceed to delete the Domain without encountering further errors.
Conclusion
Whether you are an organization looking to separate different divisions or a large MSSP managing data for multiple tenants, IBM QRadar’s multi-tenancy solution has you covered. This article has demonstrated the best practices for offboarding a Domain in QRadar. We’ve highlighted important considerations before removing any domain or tenant, provided step-by-step instructions to ensure a smooth removal process, and explored domain-aware QRadar features designed to cleanly erase all domain-specific data—leaving no residual traces on the MSSP platform.
For an in-depth understanding of QRadar Domains and Multi-Tenancy, check out the following resources:
If at any point in time, you have any questions, have any comments or want to discuss this further, feel free to get in touch with us and we would be more than happy to answer any of your queries: Kajol Khojare – kajol.Khojare@ibm.com or alternatively, you can reach out to IBM Support by raising a support ticket.
Special thanks to Vishal Tangadkar (vishal.tangadkar1@ibm.com) for reviewing this blog.