Getting Ready for a Contact Data Audit Before Someone Asks for One

A security or privacy reviewer generally wants three things: where each data source's records come from, what legal basis the vendor claims for holding and sharing them, and how you handle a deletion or opt-out request once one arrives. They are rarely asking you to prove every single record is perfectly sourced. They are asking whether you have a process at all, and whether you can point to it quickly instead of describing it from memory in the moment.

For every enrichment or contact database vendor you use, keep a short record of what their contract or documentation says about sourcing, whether that's public web data, opted-in registrations, or licensed third-party records. Keep the actual document, not just your summary of it, since a reviewer may want to see the vendor's own language rather than yours. This takes an afternoon to assemble once and then only needs updating when you add or drop a vendor.

• Confirm which systems a contact record can end up in beyond the CRM, including outreach tools, marketing platforms, and any spreadsheet exports.
• Write down the exact steps to remove a record from each one, so the process doesn't depend on one person remembering where everything lives.
• Set a realistic time target for completing a request end to end, and track whether you actually meet it.
• Test the process on a real record at least once before you need it under pressure from an actual request.

A deletion process that only exists as a policy document and has never been run once is a liability, not a safeguard.

What counts as an acceptable legal basis for holding and contacting someone differs by jurisdiction, and rules for a contact in the European Union are meaningfully different from rules for one in the United States. This is not a place to guess or copy what a competitor seems to be doing. Have your counsel confirm what basis you're relying on for each region you actively prospect into, and keep that guidance alongside your vendor documentation rather than treating it as settled once and forgotten.

The most frequent finding isn't a bad vendor, it's a missing consent trail for contacts sourced from an older tool that's since been replaced, with nobody able to say where those specific records originally came from. Another common gap is an opt-out that was honored in one tool but never synced to the others a record also lives in, so someone who unsubscribed from your outreach platform still shows up in a separate list. Both are fixable once you know to look for them, but neither is obvious until someone actually checks.

Say a contact emails asking to be removed from your outreach entirely. Working the process end to end means pulling their record from the CRM, the outreach platform, any marketing list they landed on, and any spreadsheet a rep exported for a campaign. Confirm removal in each place individually rather than assuming a CRM delete cascades everywhere, since most stacks don't actually work that way. Log the date the request came in and the date you finished, so the next audit has a real example to point to instead of a process that's only ever been described, never run. A sourcing and deletion file that was accurate two vendor contracts ago is close to useless in a live review, so assign the update to whoever owns the vendor relationship and put a date on the document itself, so a reviewer can tell whether it reflects your current stack or one you replaced a year ago.