Help: Our instance is full of test data. How to clean it without losing config?

Ah, the classic "we treated our production OneTrust instance like a developer's sandbox" scenario. I've seen this play out more times than I can count, usually because someone in Legal or Compliance got a demo license, handed out admin credentials like candy, and now, two years later, you've got 50,000 test records, 300 "TEST_DONT_USE" processing activities, and a bill that makes your CFO wince. The panic isn't about deleting data—it's about nuking the intricate web of policies, categories, and workflows you *actually* need.

First, a piece of hard-earned, somewhat sardonic advice: **Do not, under any circumstances, use the bulk delete in the UI for anything beyond the most trivial, recently created items.** It's a blunt instrument in a china shop. Your "config" – that's your Data Discovery scan configurations, your cookie rule bundles, your jurisdiction mappings, your custom assessment templates. These are often *referenced* by the test data, not the other way around. Delete the wrong record and you'll find a critical workflow now points to `[Object Not Found]`.

The path forward is methodological, not magical. You'll need to separate the wheat from the chaff. Here's how I'd approach it, leaning heavily on the APIs because the UI is built for compliance officers, not data janitors.

1. **Inventory & Map Dependencies:** Before you delete a single "TEST Customer," you need to know what's attached. Use the APIs to pull relationships.
* Export your Processing Activities (PIA) or Data Inventory.
* More critically, use the `/api/data-inventory/v2/assets/{id}/linked-records` endpoint (or its equivalent for your module) to see what Policies, Regulations, or Assessments are linked to each test asset. The goal is to build a list of IDs that are *safe* to delete—those with zero links to vital configuration.

2. **The Purge (Module by Module):** OneTrust's modularity is your friend here. You must clean each module separately, starting with the most dependent data (like individual data subject requests) and moving up to the foundational items (like test assets).
* **DSAR/Privacy Rights:** Use the Request Submission API to filter and delete based on a custom property (e.g., `"source": "TEST"`) you hopefully added. If not, filter by date and requester email patterns (`*@testcompany.com`).
* **Data Inventory:** This is the trickiest. Scripts are your only sane option. A pseudo-plan:
```python
# This is conceptual, not production-ready.
import requests

# 1. Fetch all assets tagged with "ENVIRONMENT=TEST"
test_assets = get_assets(filters="tag:ENVIRONMENT:TEST")

for asset in test_assets:
# 2. Check for links to NON-test configurations
links = get_linked_records(asset['id'])
if not any(link['type'] in ['PRODUCTION_POLICY', 'LIVE_REGULATION'] for link in links):
# 3. Safe to delete
delete_asset(asset['id'])
else:
# 4. Log for manual review - this test asset is linked to real config.
log_review_candidate(asset['id'], links)
```

3. **The Configuration Audit:** After purging the obvious test data, you must do a thorough audit of your remaining configurations. Do you have assessment templates called "SAMPLE"? Are your Data Discovery scan targets pointing to test databases? This is manual, tedious work, but it prevents the next crisis.

A final, heretical thought from someone who's paid these bills: If your test data volume is truly massive and your configuration is stable, investigate the cost and effort of using OneTrust's professional services to *clone* your production configuration into a fresh instance, leaving the garbage behind. It sounds extreme, but I've seen it be cheaper than months of developer time trying to surgically clean a hopelessly polluted instance. Then, enforce a brutal policy: all testing and development happens in a dedicated, separate, and crucially, *cheaper* sandbox instance.