Those commissioning an application handling personal data are the data controller under GDPR, regardless of whether they develop internally or rely on a software house. Responsibilities cannot be delegated to the vendor: contractual clarity (DPA), security audits, DPIA when necessary and data subject rights management are needed.
When a company decides to commission software, the typical questions concern features, timing, costs and technology. GDPR rarely tops the list. Yet, if that application handles personal data, the European data protection regulation is not a detail to be sorted out at the end: it's an architectural constraint to be considered from day one.
This article is not for DPOs or law students. It's for those commissioning software: entrepreneurs, IT managers, product managers who need to understand what to ask their vendor and what questions to raise before signing a 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.
