Home / Blog

GDPR and custom business software

Custom software gives you more control over personal data than a stack of SaaS tools, but control comes with responsibility. Here's what GDPR means in practice when you commission a system that holds client, employee and supplier data. This is a practical overview, not legal advice.

5 min read · 28 September 2026

Why custom software changes the GDPR picture

When your data is spread across a dozen SaaS tools, each vendor has its own processing terms, sub-processors, storage locations and deletion rules. Answering a simple access request can mean searching every one of them.

A custom company system puts most of that data in one place, under rules you define. That makes compliance easier to manage and to prove. It also means design decisions about personal data are yours to make, so they need to be made deliberately.

Who is who: controller and processor

Under GDPR, your company is the controller: you decide why and how personal data is processed. The agency that builds and hosts or supports your system, if it has access to the data, is typically a processor acting on your instructions.

That relationship needs a data processing agreement (Article 28). It should cover what the processor may do with the data, security measures, sub-processors such as hosting and AI providers, assistance with data subject requests and breaches, and what happens to the data when the contract ends. If a builder doesn't bring this up, ask for it.

Privacy by design, in concrete terms

GDPR requires data protection by design and by default (Article 25). In a business system, that translates into practical decisions.

  • Collect only what each process needs. If the field team doesn't need a client's date of birth, don't store it.
  • Role-based access: each role sees only the personal data its work requires. A technician sees the job address, not the client's payment history.
  • Sensible defaults: new records, exports and shares are restricted unless someone deliberately opens them.
  • Separate sensitive categories. HR data, health information in absence records and anything similar needs tighter access than sales data.
  • An audit log of who viewed or changed personal data, so questions can be answered later.

Employee data needs extra care

HR systems, shift planning and attendance tracking hold some of the most sensitive data in a company: contact details, contracts, pay, absences, sometimes health-related information, and in some cases location data from field devices.

Keep access narrow. Managers see what they need for scheduling, not medical notes. Location tracking, if used at all, should be limited to working time and a clear purpose, and staff should be told about it. Many countries add rules on employee monitoring and may require consulting employee representatives, so check local requirements before building anything that tracks people. Our article on HR systems for shift workers covers the operational side.

Retention and deletion

Personal data shouldn't be kept longer than needed. For most companies, that means different periods for different data: leads that never became clients, former employees, closed client accounts, CCTV or call recordings, job records needed for warranty or tax.

A custom system can enforce these rules automatically: flag records past their retention period, anonymise or delete them on a schedule, and keep what the law requires you to keep, such as accounting records. Agree the periods with your legal adviser, then build them in rather than relying on someone remembering to clean up.

Data subject rights

People can ask to see their data, correct it, have it deleted in certain cases, or receive it in a portable format. In a scattered tool stack, each request is a search across many systems.

In one system, it can be a single action: find the person, see every record linked to them, export or erase what's required, and log that the request was handled. Ask your builder to include this from the start; it's much cheaper than adding it later.

Security and breaches

GDPR requires security appropriate to the risk (Article 32), and notification of certain breaches to the supervisory authority within 72 hours of becoming aware of them (Article 33).

  • Individual accounts with strong authentication, and prompt removal of access when people leave.
  • Encryption in transit and at rest.
  • Backups that are tested by actually restoring them.
  • Monitoring and alerts, with a clear owner for responding.
  • A written plan for what happens if something goes wrong, including who decides whether to notify.

Keep your documentation in order

GDPR expects you to be able to show what you do with personal data. Most companies need records of processing activities (Article 30): what data you hold, why, for whom, how long and who it's shared with.

A custom system makes this easier to keep accurate, because the data model, roles and retention rules are all defined in one place. Ask your builder to document them in plain language as part of the delivery, so your records match what the system actually does.

Hosting and international transfers

Where your data is stored and processed matters. Hosting within the EU keeps things simplest. If any part of the chain, such as an email provider, AI model or monitoring tool, processes data outside the EU, there needs to be a valid transfer mechanism, such as an adequacy decision or standard contractual clauses.

Ask your builder for a list of every service that touches personal data in the system, where each one processes it, and on what basis. A good builder has this ready.

AI features and personal data

AI layers and AI staff process personal data too, so the same rules apply, plus some specific points.

  • Permissions: the AI should only read what the person using it is allowed to see.
  • No training on your data: make sure your data isn't used to train the provider's models. With our builds, it isn't.
  • Transparency: tell people when they're dealing with an AI, for example on the phone. The EU AI Act adds transparency duties for systems that interact with people.
  • Human oversight: decisions with significant effects on people, such as hiring, should not be left to AI alone.
  • Impact assessments: for higher-risk processing, like large-scale monitoring of employees, a data protection impact assessment (Article 35) may be required.

Questions to ask your builder

Will you sign a data processing agreement? Which sub-processors touch our data, and where? How are roles and permissions designed? Is there an audit log? How are retention and deletion handled? How would we answer an access request? What is your breach process? What can the AI read, and is anything used for training?

We build these into every system: role-based access, audit logs, backups, monitoring and AI that respects permissions. For groups of companies, Empire (from €120k) includes a security review, audit log and access controls across entities; Core (€18,000) and Maxxed (€48,000) are built on the same principles. If you'd like to discuss a system for your company, apply and show us how data moves through it today.

Questions

Is custom software more GDPR-compliant than SaaS?

Not automatically. It gives you more control and puts data in one place, which makes compliance easier to manage and prove, but the design decisions need to be made deliberately.

Do we need a data processing agreement with our software developer?

If the developer hosts, supports or otherwise accesses personal data on your behalf, yes. GDPR Article 28 requires one between controller and processor.

Can AI features be used under GDPR?

Yes, with care: permissions that limit what the AI sees, no training on your data, transparency toward people, human oversight for significant decisions and a valid basis for processing.

Where should our business data be hosted?

Hosting in the EU is simplest. If any service processes data outside the EU, there must be a valid transfer mechanism.

Is this article legal advice?

No. It's a practical overview. Confirm specific requirements, such as retention periods and legal bases, with your legal adviser or data protection officer.

Keep reading