Hello everyone. I’ve been deep in the weeds of OneTrust’s Data Mapping and Data Discovery modules for the last few months, trying to implement a coherent data retention policy across our organization. We have data flowing in from marketing, HR, customer support, and R&D, all with different regulatory and business needs.
My current challenge is translating our high-level retention rules—like "keep customer support tickets for 7 years" but "delete prospect marketing data after 2 years of inactivity"—into operational retention schedules within OneTrust. The documentation is comprehensive but a bit scattered on the practical "how."
I’d like to walk through my understanding of the configuration steps and would love this community’s feedback on whether this is the optimal workflow, or if I’m missing a more efficient path.
Here’s my current process:
* **Start with Inventory & Classification:** I’ve found you must first have your data categories and assets well-defined in your Data Inventory. The retention schedule is then attached to a Data Category, not directly to individual assets. So my first step was ensuring our categories (e.g., "Customer Payment Data," "Job Applicant CV," "Website Analytics Data") are correctly mapped.
* **Define Retention Rules in the Retention module:** Under Policies & Procedures > Retention, I create a new Retention Rule. This is where you set the core logic.
* **Retention Trigger:** This is critical. Is it from the date of creation, last interaction, contract termination, or after a specific business event? I set up different triggers for different categories.
* **Retention Period:** Straightforward—the number of years/months/days.
* **Legal Citation:** I link the relevant law (like GDPR, CCPA, labor laws) and article here for audit purposes.
* **Assign Rules to Data Categories:** This is the linking step. Back in Data Mapping > Data Categories, I edit each category and assign the appropriate Retention Rule from a dropdown. One nuance: a single category can sometimes have multiple applicable rules (e.g., a baseline business rule and an overriding legal hold), and the system needs to know which to prioritize.
* **Configure Disposal Workflows:** Simply defining the schedule isn’t enough. For each rule, I also have to define the disposal method (secure deletion, anonymization, archiving) and, importantly, the approval workflow. Who signs off before data is purged? I’ve set this to require the Data Category owner and our legal team’s review for high-risk categories.
My specific points of confusion are:
* How do you handle data categories that reside in multiple systems (e.g., "Employee Personal Data" in both our HR platform and our ticketing system)? Does the schedule apply universally once linked to the category, or do you need to configure something per system/asset?
* For "event-based" retention (e.g., "retain for 7 years after contract termination"), how are you practically tracking that termination event? Are you integrating with other systems, or is this a manual flag?
* Has anyone built a master reporting view to see all categories, their assigned rules, and next review/disposal dates in one place? I’m piecing together dashboards and it feels clunky.
I’m particularly interested in any templates or real-world workflow examples you might have for structuring these rules and the approval chains. The out-of-the-box settings felt too generic for our complex vendor and data landscape.
Thanks in advance for sharing your experiences.
— frank
buyer beware, but buy smart
Your foundational step is absolutely correct. The Data Inventory to Data Category linkage is the core of OneTrust's retention model, a design choice that mirrors how data governance operates at scale. It forces you to define policies based on data *type*, not storage location, which is essential for consistency.
A practical caveat from my implementation: you'll likely need to create more granular sub-categories than you initially anticipate. For example, "Customer Support Tickets" might need to split into "Active Support Cases" and "Closed Support Ticket Archives" if your 7-year rule only applies upon case closure. The trigger event for the retention countdown is configured within the schedule itself, but it relies on that categorical separation being in place first.
Also, test the "inactivity" rule for marketing data thoroughly in a sandbox. Defining the "last interaction" date field that OneTrust's schedule will evaluate is critical, and you must confirm your discovery scans can reliably populate that metadata field. If they can't, the schedule won't execute as expected.
Test it yourself.
Your first step is the only sane part of this whole compliance-as-a-service circus. Everyone rushes to define schedules before they even know what they're storing.
But if you think your "Customer Support Tickets" category is going to hold up, you're in for a surprise. The system will treat an open ticket and a 6-year-old archive exactly the same unless you split them. That's how you get legal demanding why you deleted an active case or an audit flag for keeping data past its retention.
You'll need sub-categories for every single retention trigger event. It's tedious, but it's the only way the automation won't break.
-- old school
You've nailed a key implementation detail with your example of splitting the ticket category. That granularity is often the make-or-break point for a schedule actually working.
I'd add that the trigger event itself--like "date of case closure"--needs to be a reliably populated field in your source system, or mapped in your integration. If that date is missing or defaults to a system null, the retention timer never starts, which is a compliance risk in itself.
So the workflow isn't just creating sub-categories; it's validating the data quality for the specific field each sub-category's schedule depends on.
Review first, buy later.
The bullet point about starting with inventory and classification is right, but I'd push on attaching schedules directly to a data category alone. In my experience, you also need to layer in business unit or legal jurisdiction rules.
For example, "Job Applicant CV" might have a base 2-year retention, but your EU subsidiary needs a different schedule due to local labor laws. You'll either need separate sub-categories per region, or use the policy exception workflow for specific assets. Otherwise, you'll create a schedule that's either non-compliant or overly aggressive.