Where personal data hides in a 200-person company: a system-by-system map

Why does personal data spread so far beyond HR?#

Personal data spreads beyond HR because every system that records work between people records the people too. A support ticket carries the requester's name and signature, a CRM activity carries a call summary, and a Slack thread carries whoever joined it and whatever they said about their weekend.

Mid-sized companies make the spread worse in predictable ways. They have adopted tools team by team, connected them with integrations that copy contact fields between systems, and exported data to spreadsheets whenever a report was needed. Each copy is a new location.

Which of that data counts as regulated personal information depends on the law and the context. In California, the CCPA's temporary exemptions for employee and business-to-business contact data ended on January 1, 2023, while Colorado's Attorney General says the Colorado Privacy Act does not cover people acting in a commercial or employment context. Which rules apply to your records is assessed with counsel.

The system-by-system map#

The system-by-system map below shows the usual personal data in each system, the fields where it hides and a starting risk level. Adjust the risk for your own configuration: a helpdesk used only for internal IT tickets carries different exposure from one that serves consumers.

Which fields hide personal data most often?#

Free-text fields hide personal data most often, because nobody designed them to hold it and nobody reviews what goes in. A structured phone number column is obvious; a phone number typed into a ticket comment, a delivery instruction or a meeting note is not.

When you scope a system, list the field types below for each object before deciding whether the object is in or out.

Integrations deserve their own line in the map. A CRM that syncs with the helpdesk, a billing tool that writes contact names into the ERP, or a chat app that unfurls ticket links into channels all copy personal data into places their owners never chose. Record each sync once, with its direction, so a field excluded in one system is not quietly licensed through another.

• 1Notes, comments and description fields on any record.
• 2Email signatures pasted into tickets, CRM activities and wiki pages.
• 3Attachments and screenshots, including images of IDs, invoices and error screens with account details.
• 4Custom fields created years ago for a purpose no one remembers.
• 5CC, BCC and distribution lists on synced email.
• 6Ship-to and delivery instruction fields on orders.
• 7Display names and email addresses inside system logs, audit trails and URLs.

How do you build the map without exporting everything?#

A personal data map is built from metadata and small samples, not full exports. Most of what you need sits in admin consoles and schema views: object lists, field lists, custom field definitions and integration settings.

Start with the list of systems people actually use, which the SSO directory and software billing usually reveal better than any policy document. For each system, record the objects, the fields that can hold personal data and the integrations that copy data elsewhere.

Then pull a small sample of free text and run it through a detector. Open-source tools such as Presidio combine named-entity recognition, regular expressions, rule-based logic and checksums to flag names, addresses, numbers and other identifiers in text. Treat the output as a lead list for human review, not a verdict.

How should each location be rated?#

Each location should be rated by what it would take to make it safe, not only by how much personal data it contains. A system full of names can be easy to clean if the names sit in structured fields; a system with fewer names scattered through free text can be harder.

Use four ratings so decisions are consistent across systems and reviewers.

Rate history separately from the live system. A helpdesk that now masks card numbers and strips signatures may hold years of tickets from before those settings existed, and a chat workspace with a strict channel policy today may carry older channels that grew without one. The oldest records in scope usually set the real rating.

Illustrative: a regional distributor maps its systems#

Illustrative: a fictional regional distributor runs NetSuite, Zendesk, Slack, Microsoft 365 and a shared drive, and wants to license order exception and support history. The IT lead builds the map from admin consoles over a few working sessions, without exporting a single table.

The map turns up surprises. Delivery instructions on orders for small contractors include personal mobile numbers. A Slack channel used for birthdays and leave announcements sits beside operational channels. A shared drive folder holds a payroll export someone saved for a one-off report, and a vendor onboarding folder holds scanned driver's licenses.

The decision follows the map: HR folders, social channels and vendor onboarding files are excluded, delivery instructions are cleaned with field rules, and ticket bodies go through detection and sampled review. The map becomes the scope document for the rest of the project.

How SourceX uses a personal data map#

SourceX starts with the same metadata. In the Supply step of the SourceX five-step transaction, the fit check collects system names, record families and years of history, never files, so the map can begin before anything is shared.

The map then drives the Preparation step, where personal and confidential details are removed field by field. The resulting decisions are written into the privacy record of the SourceX Evidence Packet, which the supplier approves before Delivery.