Skip to content
Notifications
Clear all

Help: Our data map is a mess. Best practice for a clean restart?

1 Posts
1 Users
0 Reactions
21 Views
(@elliotk)
Reputable Member
Joined: 3 months ago
Posts: 323
Topic starter   [#17215]

Alright, let's be real. Our "data map" is less of a map and more of a digital hoarder's attic. We started with good intentions, but between the rushed vendor onboarding, the spreadsheets that live in three different departments (all slightly different), and the custom fields we added for "just this one exception," it's become completely unmanageable. We can't trust the reports, and the idea of using it for anything automated (like triggering assessments) is a joke.

So, I'm throwing in the towel on incremental fixes. We need a clean restart, a ground-zero rebuild.

I'm looking for battle-tested strategies from anyone who's been through this. My current thinking is a phased approach, but I want to make sure we're setting the right foundations this time.

Here's my rough plan—tell me where I'm naive or what I'm missing:

* **Phase 1: The Great Audit & Blueprint**
* Freeze all updates to the current map. Create a "legacy" tag for it.
* Assemble a cross-functional tiger team (Legal, IT, Security, key business units).
* **Critical Question:** What's our single source of truth for *systems*? Do we force-link everything to our CMDB, or is that a bridge too far? How do you handle shadow IT that the CMDB doesn't know about?
* Define a **strict**, minimal data model. What are the absolute mandatory fields for every record? I'm thinking: Processing Activity Name, Legal Basis, Business Owner (one!), System of Record, Data Classification, Retention Period. No more "nice-to-have" custom fields at this stage.

* **Phase 2: The Controlled Migration**
* Build the new, empty structure in OneTrust based on the blueprint.
* Manually validate and migrate records in priority batches (e.g., start with all customer-facing, PII-heavy processes). This will be painful and manual, but I think it's necessary.
* **Big Dilemma:** Do we try to automate *any* of this ingestion from old spreadsheets? I'm tempted to build a simple CLI tool to parse and format, but worried it'll just perpetuate old garbage.

* **Phase 3: Governance & Lockdown**
* Establish a clear ownership and change request workflow *before* we go live with the new map.
* Set up mandatory linking to other modules (like Assessments, Vendors) so the map has real utility.
* Design the dashboard/reports *first*, then make sure the data captured supports them.

My biggest fear is that we'll spend months on this, only to end up with a slightly cleaner, but still fundamentally brittle, data graveyard. How have you ensured long-term hygiene and adoption? Are there specific OneTrust features (like Data Discovery insights or certain API endpoints) that became the cornerstone of your clean setup?

Also, any gotchas on purging or archiving the old data within OneTrust itself? I don't want to break historical report references if I can avoid it.



   
Quote