The GDPR (EU Regulation 2016/679) requires software developers to handle personal data with minimisation, purpose limitation, integrity and accountability. Compliance demands privacy by design, a DPIA for high-risk processing, records of processing activities, revocable consent management, AES-256 encryption and regular penetration tests.
In today's digital context, where personal data protection is a top priority, GDPR compliance has become an unavoidable responsibility for those developing software. Failing to comply with the regulation means exposing yourself to legal risk, financial penalties and damage to corporate reputation.
This article provides a practical, up-to-date checklist to help software houses, developers and companies build digital products compliant with the General Data Protection Regulation (GDPR).
What the GDPR is and why it matters in software development
The GDPR (EU Regulation 2016/679) came into force in 2018 with the aim of protecting the personal data of European Union citizens. It requires companies to handle data in a transparent, secure and responsible way.
Core principles of the GDPR:
- Data minimisation: collect only what is strictly necessary.
- Purpose limitation: use data only for the stated purpose.
- Integrity and confidentiality: protection against unauthorised access or loss.
- Accountability: responsibility for demonstrating compliance.
Personal data: what it is and how to identify it
What counts as personal data?
Any information that can directly or indirectly identify a natural person: name, email address, IP, geolocation, cookies. Sensitive data includes information on health, political opinions, sexual orientation, and so on.
Where is it found in software?
- CRM: customer records, email history
- E-commerce: shipping details, purchase preferences
- HR platforms: payslips, leave requests, CVs
GDPR checklist for software development
1. Privacy by Design and by Default
Integrate data protection from the design phase. Ensure that the software's default settings safeguard users' privacy.
Practical examples:
- Automatic masking of sensitive data
- Public sharing disabled by default
2. Data Protection Impact Assessment (DPIA)
Mandatory when processing may involve high risks to individuals' rights.
How to carry it out:
- Mapping of collected data
- Risk analysis and mitigation measures
- Involvement of the DPO
3. Consent management
Consent must be explicit, freely given, informed and easily revocable.
Best practice:
- Clear flows for requesting consent
- Tracking and logging of every consent obtained
- Easy access to modify or revoke it
4. Access and authorisations
Define roles and privileges for each user, ensuring secure access to data.
Key measures:
- Two-factor authentication (2FA)
- Encryption of data in transit and at rest
5. Records of processing activities
Required to document processing activities, mandatory for companies with more than 250 employees or those handling sensitive data.
Minimum contents:
- Purposes
- Data categories
- Processors involved
Recommended tools:
6. Data retention and right to be forgotten
Define data retention policies and automatic deletion of data that is no longer needed.
Actions to implement:
- Deletion or anonymisation after a defined period
- Automated handling of deletion requests
7. Data security
Essential to prevent breaches. Preventive measures and advanced security techniques must be in place.
Essential measures:
- Encryption (AES-256, TLS 1.2 or above)
- Encrypted backups
- Regular penetration tests
Commissioning the software: responsibility and contract
Who's responsible for what: a distinction that matters
GDPR introduces a fundamental distinction that many companies still underestimate: between data controller and data processor.
The controller decides why and how data are processed. In practice, this is almost always the company commissioning the software. The processor handles those data on behalf of the controller, often the software house that develops and manages the application.
This distinction has concrete implications. If something goes wrong, if there's a data breach or non-compliant processing, the controller answers to the supervisory authority and to data subjects. The processor answers to the controller, based on a specific contract that GDPR calls a DPA, Data Processing Agreement. Without this written agreement, the entire chain of responsibility is fragile, and in case of inspection or sanction the commissioning company's position becomes very hard to defend.
The first concrete thing to do, therefore, is to make sure the contract with your software vendor includes a proper DPA. It's not bureaucracy: it's the legal basis defining who does what with the data.
Privacy by design: not a slogan
Article 25 of GDPR explicitly speaks of privacy by design and privacy by default. In practice: data protection must be designed into the system, not added afterwards as a patch.
This has immediate practical effects on software development. It means, for example, that an application shouldn't collect more data than strictly necessary for the declared purpose. Sensitive data must be encrypted both in transit and at rest. Users must be able to exercise their rights, from access to deletion, and the system must support these operations in a structured way.
When commissioning an application, it's worth asking the vendor explicitly how they intend to implement these principles. It's not a trick question: a serious technical team can answer concretely. If the answer is vague, it's a signal not to ignore.
What a compliant application must contain
There's no universal list, because it depends on the type of data processed and the context. But some elements almost always appear when building a GDPR-compliant application.
Consent management. If the application collects data through forms, registrations or user interactions, you need a system to collect, record and manage consents in a documentable way. A checked checkbox is not enough: you must know when it was given, for what purpose, and you must be able to revoke it.
Access logs. Who viewed which data, when and from which system. In a business context, where multiple roles access the same database, this traceability is often mandatory and always useful in case of audit.
Role-based access control. Not all employees should access all data. A well-designed system limits access based on role and operational need.
Breach management. GDPR requires data breaches to be notified to the authority within 72 hours of discovery. This means the system must be monitored, and internal procedures must exist to detect, assess and report incidents.
Data subject rights. The application must concretely support user requests: access to their data, rectification, deletion, portability. If these operations require long and complex manual interventions, the system is not really compliant, only on paper.
The role of DPIA
For certain types of processing, GDPR requires a DPIA, Data Protection Impact Assessment. It's not required for all applications, but it triggers when processing is high-risk: systems profiling users at scale, applications handling special categories of data such as health or biometric data, surveillance or monitoring systems.
If your application falls within these scenarios, the DPIA must be done before the system goes into production, not after. It's a structured analysis identifying risks, evaluating mitigation measures and documenting decisions taken. At Redergo we tackle this analysis with the client in the initial design phases, precisely to avoid building something that then has to be dismantled and redesigned.
Third-party vendors and data transfers
Almost no modern application is an island. There are cloud services, CDNs, analytics platforms, payment systems, external APIs. Each of these subjects coming into contact with user data is potentially a sub-processor, and must be covered by adequate agreements.
A point that often causes problems is data transfer to non-EU countries. If the application uses a cloud service with US servers, or an analytics platform processing data outside Europe, you must verify on what legal basis that transfer happens. Standard Contractual Clauses are the most widespread tool, but they're not a form to sign mechanically: they must be evaluated case by case.
When we choose the technology stack for a project, we take these aspects into account from the planning phase. Changing a cloud vendor mid-project because it's not GDPR compliant is expensive and frustrating, for everyone.
How to approach the topic with your vendor
You don't need to become a legal expert to ask the right questions. A few concrete checks before and during the project suffice.
Before starting, it's useful to ask the vendor if they have previous experience with projects requiring GDPR compliance, if they propose certified or recognised tools for data management, and if they provide for signing a DPA. During development, it's worth asking how test data is handled, since development teams often work with real database copies without adequate anonymisation measures. And before go-live, it's appropriate to verify that mechanisms are in place to handle user rights and that there's a plan for incident management.
At Redergo we tackle these topics systematically in our custom software development projects, because compliance is not an obstacle to development: it's an integral part of a well-made product. An application that ignores GDPR isn't only at risk of sanctions, it's an application with technical and legal debt that will sooner or later show up to collect.
Sanctions and concrete risks
Sanctions provided by GDPR can reach 20 million euros or 4% of annual global turnover, whichever is higher. But beyond the maximum figure, which concerns the most serious violations, the point is that even minor infractions have consequences: adjustment requests, warnings, reputational damage.
The Italian Data Protection Authority has shown growing attention in recent years toward software applications, particularly in healthcare, financial and digital services sectors. Waiting for an inspection to deal with GDPR is a strategy that suits no one.
Investing in compliance during design always costs less than fixing afterwards. And often, addressing the topic seriously leads to building better systems: more secure, more reliable, easier to maintain over time.
Privacy isn't just a regulatory obligation, it's a value. Designing GDPR-compliant software means putting the user at the centre and building trust. This checklist gives you a concrete base from which to start or strengthen your compliance journey.
