A Practical Data Privacy Checklist If You Have EU Customers

GDPR generally applies when you're processing personal data of people in the EU, either because you're established there or because you're specifically offering goods or services to people there or monitoring their behavior. Occasionally serving a customer who happens to be in the EU is a different situation from actively marketing to or targeting EU users.

This is exactly the kind of determination that depends on your specific business and should go through an attorney familiar with privacy law, not a general rule of thumb from a guide like this one.

Most privacy gaps come from data that ended up somewhere nobody planned for it to go: a customer's email pasted into a support ticket, a spreadsheet export sitting in someone's downloads folder, or a third-party analytics tool receiving more fields than anyone intended to send it. A policy document describing where data should live doesn't fix any of this.

Actually trace a piece of personal data from where it enters your system to everywhere it ends up, including logs, backups, and any third-party tool it flows into. The gaps you find this way are usually more useful than anything a policy review alone would surface.

A data processing agreement, or DPA, sets out how a vendor is allowed to handle personal data on your behalf. Before signing one, check what the vendor is actually permitted to do with the data (only what you've asked, or more), where the data is stored and processed, and what happens to it if you stop using the vendor.

Don't treat signing a DPA as the finish line. It's a commitment from the vendor, not a guarantee that your own use of their tool is compliant, and the specifics of any agreement should be reviewed by counsel before you rely on it.

A handful of gaps show up constantly regardless of which privacy law technically applies:

• No real process for deleting a specific person's data on request
• Personal data sitting in analytics or logging tools with no retention limit
• Support and sales teams pasting customer data into tools that were never reviewed for it
• No record of which vendors actually receive personal data at all

Fixing these is worth doing on its own, separate from any specific regulation, because they're the gaps most likely to actually cause a problem.

Before making that claim to a customer, confirm with your own counsel whether the relevant laws actually apply to your business, confirm you can locate and delete a specific person's data across every system it touches, confirm your vendor DPAs are current and actually reviewed, and confirm your privacy policy describes what your systems actually do rather than a generic template. A claim of compliance you can't back up in a customer's security review is worse than not making the claim at all.

When one or two engineers built the whole product, keeping track of where personal data flows is mostly a matter of remembering your own decisions. Once support, sales, and a growing engineering team all touch customer data day to day, that informal tracking breaks down, because no single person can see every place data moves anymore.

This is the point to formalize what used to be tribal knowledge: a written record of what data each tool receives, reviewed periodically rather than reconstructed from memory whenever a question comes up. It's slower to set up than relying on one person's memory, but it's the only version that still works once that person is out sick, on vacation, or has moved to a different team.