GDPR Basics for Software Buyers: What to Ask Your Vendors
GDPR is not just a European concern or a legal team problem. If your software holds personal data, its concepts shape what you should demand from vendors.
The General Data Protection Regulation, GDPR, is the European Union framework governing how personal data is collected, processed, and protected. Its reach extends well beyond Europe: it applies to organizations handling the personal data of people in the EU regardless of where the organization sits, and it has become a de facto reference point for data protection expectations globally.
This primer is for buyers, not lawyers. It will not make you compliant - that requires proper legal advice for your situation - but it will give you the concepts to evaluate a vendor and ask the questions that matter when software holds personal data on your behalf.
The concepts a buyer should know
- Personal data: any information relating to an identifiable person - names, emails, and much more. GDPR is about how this is handled.
- Controller and processor: you (the controller) decide why and how personal data is processed; your vendor (the processor) processes it on your instructions. This split defines responsibilities.
- Lawful basis: there must be a valid reason to process personal data, such as consent or legitimate interest.
- Data subject rights: individuals can request access, correction, deletion, and portability of their data, and you need your tools to support fulfilling these.
Why the controller-processor split matters
When you use a software vendor to hold personal data, you are usually the controller and they are the processor. That relationship carries obligations on both sides, formalized in a Data Processing Agreement, or DPA. The DPA sets out what the vendor may do with the data, how they protect it, how they help you meet your obligations, and what happens to the data when you leave.
For a buyer, the practical implication is that you cannot outsource your accountability. You remain responsible for the personal data you collect, even when a processor holds it. That is why evaluating a vendor data practices is not optional box-ticking; their handling becomes part of your compliance posture.
Questions to ask any vendor
Concrete questions surface how seriously a vendor takes this. Do you offer a Data Processing Agreement? Where is our data stored and processed geographically? Can we export our data and have it deleted on request, and how quickly? How do you support data subject requests like access and deletion? Do you use sub-processors, and can we see who they are? How and when would you notify us of a data breach?
The quality and readiness of these answers is itself a signal. A vendor with mature data practices answers clearly and has the paperwork ready. A vendor that treats these as unusual requests is telling you something about how they operate.
Where Atlas fits
Atlas holds personal data on behalf of the organizations that use it, which makes these questions relevant when you evaluate it - as they are for any vendor. Buyers should ask about data processing terms, data location, export and deletion, and breach notification, and judge the platform on the substance of those answers rather than on a claim.
One structural advantage of a unified data model is worth noting for privacy work: when a person data lives in one coherent record rather than scattered across many tools, fulfilling requests like access, export, or deletion is more tractable, because there is one place to look rather than a dozen partial copies to chase. Fragmentation is the enemy of data subject rights as much as of productivity.