If your software processes personal data of people in the EU or UK, the GDPR (and the UK GDPR) shapes how it must be built. In practice, a GDPR-compliant application collects only the data it needs, has a lawful basis for each use, lets people access, correct, export and delete their data, protects it with appropriate security, keeps processing records, and moves data outside Europe only through approved mechanisms. Fines can reach €20 million or 4% of global annual turnover, whichever is higher.
This checklist translates the regulation into concrete engineering and process tasks, including what to do when your development team is outside Europe. It is practical guidance, not legal advice.
Key takeaways
- GDPR applies to companies outside the EU if they offer goods or services to people in the EU or monitor their behavior.
- Build privacy by design and by default (Article 25): minimal data, privacy-friendly default settings.
- Your product needs working features for access, rectification, erasure and portability requests.
- Personal data breaches must generally be reported to the supervisory authority within 72 hours.
- Outsourcing to a country without an EU adequacy decision requires Standard Contractual Clauses and a transfer risk assessment.
Who needs to comply?
The GDPR applies to organizations established in the EU, and to organizations anywhere that offer goods or services to people in the EU or monitor their behavior (Article 3). The UK GDPR applies the same principles to people in the United Kingdom. B2B products are not exempt: names, email addresses and usage data of business users are personal data too.
Know your role. As a controller, you decide why and how data is processed. Your vendors, including hosting providers and usually your development partner, are processors acting on your instructions.
The GDPR checklist for software development
| Area | What to implement |
|---|---|
| Lawful basis | Document the legal basis for each processing activity (contract, consent, legitimate interests, legal obligation) |
| Consent | Granular, opt-in consent where required, stored with timestamps and easy to withdraw |
| Data minimization | Collect only fields you actually use; avoid "just in case" data |
| Privacy by default | Privacy-friendly default settings; optional data and tracking off by default |
| Right of access | A way for users, or your support team, to export all data held about a person |
| Right to rectification | Users can correct their personal data |
| Right to erasure | Reliable deletion across databases, files, search indexes, caches and backups (on rotation) |
| Data portability | Export in a structured, machine-readable format such as JSON or CSV |
| Retention | Defined retention periods with automated deletion or anonymization |
| Security (Article 32) | Encryption in transit and at rest, pseudonymization, access control, MFA, logging and regular testing |
| Breach response | Detection, incident runbooks and a process to notify the authority within 72 hours |
| Records of processing | A maintained record of what data you process, why, where and with whom |
| DPIA | A data protection impact assessment for high-risk processing, such as large-scale sensitive data or profiling |
| Cookies and tracking | Consent before non-essential cookies or tracking, with a real "reject" option |
| Processors | Data processing agreements (Article 28) with every vendor, and a list of sub-processors |
| International transfers | An approved transfer mechanism for any data leaving the EU or UK |
Engineering patterns that make compliance easier
- Map your data: keep a living inventory of personal data fields and where they flow.
- Centralize personal data instead of scattering copies across services, so deletion and export actually work.
- Use pseudonymous IDs in analytics and logs instead of names or email addresses.
- Keep personal data out of logs and error reports, or mask it automatically.
- Automate retention: scheduled jobs that delete or anonymize expired data.
- Build an admin tool for data subject requests so support can respond within the one-month deadline.
- Host personal data in an EU or UK region where it simplifies your transfer obligations.
Outsourcing development outside Europe, safely
Many European companies work with development teams in Asia, Eastern Europe or Latin America. That is fully compatible with GDPR if transfers are handled properly:
- Adequacy decisions: transfers to countries the European Commission has recognized as adequate (such as the UK, Switzerland, Japan or Canada for commercial organizations) need no extra mechanism. US companies certified under the EU-US Data Privacy Framework are also covered.
- Standard Contractual Clauses (SCCs): for countries without adequacy, such as India or Bangladesh, sign the European Commission's SCCs with your partner and complete a transfer risk assessment.
- UK transfers: use the UK International Data Transfer Agreement or the UK Addendum to the EU SCCs.
- Minimize transfers: the strongest approach is to keep production data in Europe and let the offshore team work with anonymized or synthetic data, with tightly controlled and logged access to production when truly needed.
For a complete view of working with offshore teams, read our offshore software development guide.
Do you need a Data Protection Officer?
A DPO is mandatory if you are a public authority, or if your core activities involve large-scale regular and systematic monitoring of individuals or large-scale processing of special categories of data, such as health data (Article 37). Many smaller software companies are not required to appoint one but still assign clear internal responsibility for data protection.
Common GDPR mistakes in software projects
- Pre-ticked consent boxes, or tracking that starts before consent.
- "Delete account" buttons that only deactivate the account.
- Personal data copied into test and staging environments.
- Analytics and marketing scripts added without data processing agreements.
- No process, or no tooling, to answer access requests within a month.
Frequently asked questions
Can I outsource software development outside the EU under GDPR?
Yes. Use an approved transfer mechanism such as Standard Contractual Clauses, assess the transfer risks, and limit the offshore team's access to personal data, ideally using anonymized data for development.
Is my software development partner a data processor?
Usually yes, if they can access personal data while building or maintaining your system. You need an Article 28 data processing agreement with them.
Does GDPR apply to B2B software?
Yes. Business contacts' names, work email addresses, phone numbers and usage data are personal data, so B2B products must comply too.
How is the UK GDPR different from the EU GDPR?
The core principles are almost identical. The main differences are the regulator (the ICO in the UK), the UK's own international transfer tools and some newer UK-specific reforms. Products serving both markets should meet both.
How long do we have to respond to a data subject request?
One month from receipt, extendable by up to two further months for complex or numerous requests, as long as you inform the person within the first month.
Build GDPR-ready software with Softxmind
Softxmind builds custom software for European and UK companies with privacy by design, and supports compliance with our security services. We are ISO 27001 certified, sign data processing agreements and Standard Contractual Clauses, and can work entirely on anonymized data. Talk to us about your project.
