GDPR Compliant Software Development: What EU Buyers Should Demand

Introduction

Choosing a software supplier for a European product now requires more than reviewing technologies, timelines and price. Buyers must also understand how the proposed system will handle personal data, third-party services, automated decisions and AI-generated outputs.

Yet the phrase GDPR compliant software development is frequently included in proposals without explaining what will actually be designed, tested or documented.

For a CTO or product owner, the practical question is therefore simple: what should you demand from a development partner before signing the contract?

The answer begins with evidence. A credible supplier should be able to translate privacy, security and AI governance requirements into architecture decisions, backlog items, acceptance criteria and operational controls.

Compliance should begin before the first sprint

GDPR compliance cannot be added as a final legal review shortly before launch.

The GDPR’s privacy-by-design principle requires organisations to consider technical and organisational safeguards from the earliest stages of a processing operation. Privacy-friendly defaults should also limit data collection, retention and access to what is genuinely necessary.

This affects early product decisions such as:

• What information the application collects.
• Why each data field is needed.
• Where information is processed and stored.
• Which users and systems can access it.
• How long records are retained.
• Which analytics tools, SDKs and cloud services receive data.
• How users can request access, correction or deletion.

A capable mobile app development partner should discuss these questions during discovery, particularly when the product includes accounts, location data, behavioural analytics, payments, health information or personalised experiences.

Starting early is also commercially sensible. Changing a database model, permissions structure or third-party integration during discovery is usually easier than redesigning the system after release.

GDPR compliant software development: the buyer’s checklist

When reviewing a supplier, ask how the team will convert GDPR principles into product functionality.

1. Data mapping and minimisation

The provider should propose a clear map of the information moving through the system.

That map should identify:

• The source of the data.
• The purpose for which it is used.
• The systems and suppliers receiving it.
• The people or roles that can access it.
• The relevant retention and deletion rules.

Be cautious when a supplier recommends collecting additional information simply because it might become useful later. GDPR principles include purpose limitation and data minimisation, meaning organisations should define a specific purpose and process only the data needed for it.

2. Privacy-friendly defaults

Ask what the product will do before a user changes any settings.

Permissions, public profiles, tracking, notifications and data-sharing options should begin from an appropriately protective position. The development team should be able to explain those defaults and include them in the acceptance criteria.

3. Access, retention and deletion

A privacy policy does not remove the need for technical workflows.

The system may require mechanisms that allow authorised teams to:

• Locate a user’s information.
• Correct inaccurate records.
• Export relevant data.
• Restrict processing.
• Delete information across connected systems.
• Preserve records that must legally be retained.

Retention should ideally be supported by automated rules rather than depending entirely on someone remembering to delete old records manually.

4. Security measures

The proposal should explain how the team will protect data through measures appropriate to the risk.

Relevant controls may include encryption, pseudonymisation, role-based access, audit logs, secrets management, secure backups and monitoring. The European Commission identifies encryption and pseudonymisation as examples of measures that can support data protection by design.

A custom software development partner should also explain how these controls will be tested and maintained after launch.

What buyers should demand from AI Act software

Adding an AI feature introduces a second set of questions.

The EU AI Act uses a risk-based framework. The obligations that apply depend on the intended purpose of the system, the role of each organisation and the way the technology is marketed or deployed.

Several parts of the legislation are already applicable. Transparency obligations for certain AI systems begin applying on 2 August 2026, including requirements connected with direct interaction with AI and specified categories of AI-generated or manipulated content.

Before choosing an AI development partner, buyers should request answers to the following questions.

Has the AI functionality been classified?

The supplier should document:

• The intended purpose.
• The target users.
• The operating environment.
• The expected output.
• Potential misuse.
• The role of human reviewers.
• The organisation acting as provider or deployer.

A vague statement that the system is “low risk” is insufficient. The conclusion should be based on a documented assessment that can be reviewed when the use case changes.

Will users know when AI is involved?

Interactive systems such as chatbots may need to inform people that they are interacting with AI. Certain generated or manipulated content may also require marking or disclosure.

The product team should decide how this information appears within the actual user journey. It should not be left as a sentence to add to the terms and conditions later.

Is there meaningful human oversight?

For functions that influence people, the system should make it possible for an authorised person to review, challenge, override or escalate an output.

Ask the supplier what happens when:

• The model is uncertain.
• Relevant data is missing.
• An output conflicts with a business rule.
• A user disputes the result.
• Performance changes after an update.

Human oversight needs an interface, permissions, records and operational ownership. It is a product requirement, not an abstract policy.

Can decisions and changes be traced?

The development team should define how it will record model versions, prompts, configurations, evaluations, data sources and material changes.

This helps investigate incidents, compare performance and understand why behaviour changed after an update.

Ask for evidence, not broad assurances

Reliable providers should be prepared to show how their process supports the claims in the proposal.

Useful evidence can include:

• Architecture and data-flow diagrams.
• Records of technical decisions.
• Threat models.
• Access-control matrices.
• Test plans and results.
• Dependency and third-party inventories.
• Model evaluation criteria.
• Incident-response procedures.
• Deployment and rollback processes.
• Documentation and knowledge-transfer plans.

For external teams, governance is equally important. A dedicated development team should provide regular demonstrations, visible tickets, risk updates and clear ownership of open decisions.

This reflects Unimedia’s service positioning around tailored teams, integration with client organisations, regular communication, adaptability and quality assurance.

Put responsibilities into the contract

Compliance responsibilities can become unclear when a project involves a customer, development agency, cloud provider, analytics vendor and external AI model.

The contract or statement of work should identify:

• Which party makes legal and product decisions.
• Who approves subprocessors and third-party integrations.
• Who prepares technical documentation.
• Who responds to security incidents.
• Who maintains the system after launch.
• How regulatory changes will be evaluated.
• What happens to data and documentation when the relationship ends.

The supplier should not claim that it can make your organisation compliant by itself. It should explain which controls it can build, which evidence it can provide and which decisions remain with the buyer.

Warning signs when evaluating a software partner

Treat the following responses cautiously:

• “Our cloud provider handles GDPR.”
• “The model provider is already compliant.”
• “We can review privacy shortly before launch.”
• “We do not need to document the AI risk because the feature is only experimental.”
• “You will receive the repositories when the project is finished.”
• “Security testing is outside the development scope.”
• “The user can always contact support if they want their data deleted.”

These answers usually reveal gaps in ownership, architecture or operational planning.

Conclusion

Effective GDPR compliant software development gives buyers more than a policy document. It produces a system with deliberate data flows, limited access, privacy-friendly defaults, testable controls and clear responsibilities.

AI features require the same discipline. Classification, transparency, human oversight, documentation and monitoring should be discussed before the functionality is built.

For European buyers, the strongest development partner is the one prepared to make these decisions visible throughout discovery, implementation and operation.

Unimedia Technology supports mobile, AI and custom software projects with dedicated teams that can integrate with the client’s organisation and connect technical delivery with business requirements. The company’s positioning centres on tailored teams, full-stack development and turning innovative ideas into working products.

FAQs

What does GDPR compliant software development mean?

It means designing and developing software so that personal data is processed lawfully, securely and only for defined purposes. It can involve data minimisation, privacy-friendly defaults, access controls, retention workflows, user-rights processes and appropriate documentation.

Can a software development company guarantee GDPR compliance?

A development company can implement controls and support technical documentation, but it cannot independently guarantee the customer’s overall compliance. Legal basis, organisational policies, internal governance and the way the product is used also affect compliance.

Does every application using AI fall under the same AI Act requirements?

No. Requirements depend on the intended purpose, risk category, organisational role and deployment context. Buyers should request an initial role and risk assessment for every material AI use case.

What should be included in an AI Act software checklist?

It should cover intended purpose, risk classification, prohibited practices, transparency, human oversight, documentation, model evaluation, logging, incident management and third-party model governance.

Should GDPR and AI Act requirements be included in the software contract?

Yes. The contract should define responsibilities, deliverables, documentation, third-party approvals, incident procedures, maintenance obligations, data return and secure deletion.