GDPR in ERP: Customer Data, DPA & Deletion Concept

Let's be clear up front: from a data protection standpoint, an ERP system is one of the most sensitive places in your company - this is where customer master data, order histories, payment information and sometimes even HR data all come together. The GDPR requires a legal basis for all of this, technical and organisational safeguards, a clear way of handling data subject rights and a deletion concept that fits together with statutory retention periods. If you run a cloud ERP, a data processing agreement (DPA) with the provider is added on top. This article explains neutrally and practically what matters when it comes to "GDPR in ERP" - without replacing legal advice.

Which legal basis do you need for customer data in your ERP?

Every processing of personal data requires a legal basis under Art. 6 GDPR. In day-to-day ERP work, three are especially relevant:

• Performance of a contract (Art. 6(1)(b)): You process a customer's name, delivery address and order details in order to fulfil their order - no separate consent is needed for that.
• Legal obligation (lit. c): You have to retain invoice data for tax and commercial law reasons. This is at the same time your legal basis for continued storage after the contract ends.
• Legitimate interest (lit. f): For example for credit checks or moderate marketing to existing customers - here a balancing of interests is required and data subjects can object.

The principle of purpose limitation is key: data you collected for order processing may not simply be used for other purposes. A cleanly maintained customer master record with a documented collection purpose is therefore not an end in itself, but data protection in practice.

Data minimisation as a system requirement

The GDPR demands that you collect only as much data as you actually need. A good ERP supports this through configurable mandatory fields and the option not to create sensitive fields in the first place. Critically review which data fields in forms and imports are really necessary - every superfluous field becomes a risk later on.

Data processing: the DPA with your ERP provider

As soon as an external service provider processes personal data on your behalf, this constitutes data processing under Art. 28 GDPR. With a cloud ERP, the provider operates the servers and theoretically has access to your data - which is why you absolutely need a data processing agreement (DPA). Without this contract, operation is unlawful, regardless of how good the software is.

Responsibility for the data remains with you as the company, not with the provider. The DPA governs what the processor may and must do. Watch out for these mandatory components:

Actively ask the provider for the DPA template and the list of sub-processors. Both should be transparently available - even for on-premise operation, as soon as the provider offers remote maintenance or support with data access. You can find details on providers and their operating models in the ERP directory.

Data subject rights under the GDPR: what your ERP has to be able to do

The GDPR grants every person rights over their data, and you have to fulfil them within one month. Your ERP has a say in whether this is a laborious chore or the snap of a finger:

• Access (Art. 15): Which data have you stored on a person? A good search function via matchcode and a complete export are worth their weight in gold here.
• Rectification (Art. 16): Incorrect data must be correctable - ideally with a change history.
• Erasure (Art. 17): The "right to be forgotten" - often collides with retention duties (more on that shortly).
• Data portability (Art. 20): Handover in a common, machine-readable format.
• Objection (Art. 21): For example against advertising - has to be representable in the system as a blocking flag.

Access and export in practice

When an access request comes in, you have to gather all the data on a person - including from linked modules such as documents, communication and tickets. Systems with a clean data model and a golden record per customer make this enormously easier. Where data is scattered across interfaces and third-party systems, the response quickly becomes incomplete - an argument you should factor into every system integration.

Deletion concept vs. statutory retention

The most common misconception: "GDPR means delete." In reality, two obligations stand opposed. The GDPR demands erasure as soon as the purpose no longer applies - tax and commercial law demand retention. A workable deletion concept resolves this conflict by cleanly separating the two.

The retention obligation under GoBD, HGB and AO overrides the right to erasure: data relevant to accounting may and must remain, even if the customer demands deletion. The right answer is then not erasure, but restriction of processing (blocking): the data is only kept for the statutory retention purpose but is no longer actively used.

A practicable deletion concept defines a deletion rule per data type (period, trigger, responsible person) and automates the implementation as far as possible. Make sure your system can delete selectively - not just entire records, but individual fields, while the mandatory accounting data is preserved. This is exactly where practical viability parts ways with theory.

Planning periods concretely

Set the periods stored within the system rather than tracking them manually. An example: if you only delete at the end of the period, you need an automated check run that reports expired records. If this function is missing, old data accumulates unnoticed - a GDPR violation that can become expensive during an audit.

Roles and permissions concept: limiting access

Not every employee is allowed to see all customer data. Under the heading of "confidentiality" (Art. 32), the GDPR requires that only authorised persons gain access. This is implemented via a roles and permissions concept: every authorisation is tied to a role, not to individual people, following the principle of least privilege.

Concretely, you should look out for these functions:

• Fine-grained permissions down to module, field or record level (e.g. Sales cannot see bank details).
• Client separation, if you run several companies or brands.
• A seamless audit trail that logs who viewed or changed which personal data and when - the basis for proving access if it comes to it.
• Secure authentication via SSO or multi-factor methods, so that accounts are not compromised via weak passwords.

The permissions concept is at the same time your most important organisational measure (TOM) and a checkpoint in every data protection documentation.

Data residency and international transfers

Where your data physically resides is decisive from a data protection standpoint. Data residency describes the storage location - and within the EU/EEA, processing is uncomplicated because the same GDPR rules apply everywhere. As soon as data flows into a third country (such as the USA), you need an additional basis under Chapter V GDPR.

For the USA, the EU-US Data Privacy Framework has existed since 2023: data transfers to certified US companies are permissible on this basis. If a provider is not certified, the standard contractual clauses (SCCs) generally apply, supplemented by a transfer impact assessment. Practical consequences for ERP selection:

• Clarify in which data centre and country your production data resides - and where backups are stored.
• Also check the sub-processors (support, monitoring, AI functions) for their location.
• If you want pure EU data storage, have it contractually guaranteed; many providers offer dedicated EU regions.

For a planned migration or a new rollout, the question of data residency belongs on the requirements list early - relocating data storage later is laborious. You can compare which systems offer which operating and hosting models in the comparison.

Conclusion

"GDPR ERP" is not a box you tick once, but the interplay of a legal basis, a DPA with the provider, deliverable data subject rights, a deletion concept in line with retention periods, a lived roles and permissions concept and clarified data residency. When selecting a system, look specifically for selective deletion functions, fine-grained permissions, a complete audit trail and transparent hosting locations. When it comes to implementation in the project, a structured ERP consultancy that considers data protection from the outset helps. And for all detailed legal questions the rule is: when in doubt, coordinate with a data protection officer or lawyer before it comes to a complaint.