Data Privacy in ERP

ERPs hold personal data about employees, customers, suppliers’ staff, and sometimes end consumers. Privacy law now imposes real, enforceable obligations on how that data is handled — including in your dev and test environments.

The laws

Regulation Region Notable features
GDPR EU/EEA The template most others follow. Fines up to 4% of global turnover
UK GDPR + DPA 2018 UK Near-identical to GDPR
DPDP Act 2023 India Consent-centric, significant penalties
LGPD Brazil GDPR-like
PIPL China Strict cross-border transfer rules, data localisation
CCPA/CPRA California Consumer rights, opt-out of sale
PIPEDA Canada  
POPIA South Africa  
Privacy Act Australia  
PDPA Singapore, Thailand, Malaysia  
Bangladesh Draft data protection legislation; sectoral rules apply (e.g. Bangladesh Bank for financial data) Check current status

Assume GDPR-equivalent obligations by default. Designing to the strictest applicable standard is cheaper than building per-jurisdiction variants.

The core principles (GDPR Article 5)

Principle ERP implication
Lawfulness, fairness, transparency You need a lawful basis for each processing purpose
Purpose limitation Data collected for payroll can’t be repurposed for marketing
Data minimisation Don’t collect fields you don’t need
Accuracy Data must be correctable
Storage limitation Delete or anonymise when the purpose ends
Integrity and confidentiality Security controls
Accountability You must be able to demonstrate compliance

Personal data in an ERP

More than people expect:

Employee:     name, address, DOB, national ID, bank account, salary,
              performance, health, family/dependants, biometrics (time clocks)
Customer:     contact names, emails, phone, addresses, buying behaviour
Vendor:       contact names, individual contractors' details, bank accounts
Consumer:     if B2C — order history, payment data, delivery addresses
Users:        login records, IP addresses, activity logs
Free text:    ← the hidden one. Notes, comments, and attachments contain
              personal data nobody catalogued

Free-text fields and attachments are the blind spot. A “delivery instructions” field containing “leave with the neighbour Mrs Ahmed at number 14, she has the key” is personal data about a third party in a field nobody thought about.

Special category data

Requires stronger justification and stronger controls:

  • Health and medical (sick leave reasons, occupational health, disability accommodations)
  • Racial or ethnic origin (sometimes collected for diversity reporting)
  • Religious belief (dietary requirements, holiday scheduling)
  • Trade union membership (union dues deductions — a payroll field!)
  • Biometric data (fingerprint/face time clocks)
  • Sexual orientation, political opinions

Union dues in payroll and fingerprint time clocks are the two that catch ERP teams by surprise. Both are special category data by definition.

Data subject rights

You must be able to fulfil these, usually within 30 days:

Right ERP requirement
Access Produce everything you hold about a person — across all tables, logs, attachments, and backups
Rectification Correct inaccurate data
Erasure (“right to be forgotten”) Delete — heavily limited where legal retention applies
Restriction Stop processing while a dispute is resolved
Portability Export in a machine-readable format
Object Stop processing based on legitimate interest
Not be subject to automated decisions Relevant to credit scoring and automated approvals

The access request problem

“Give me everything you hold about me” is genuinely hard in an ERP:

A customer contact appears in:
  business_partner_contact
  sales_order (created_by, contact_person)
  delivery (recipient)
  invoice (bill-to contact)
  document texts and notes
  attachments (signed delivery notes with their name)
  email logs
  change_log entries
  application access logs
  backups

Build a data subject access report before you’re asked for one. A query that assembles everything for a given person, across every table, is a real engineering task and the deadline is 30 days.

Maintain a data map: which tables, which fields, which purpose, which lawful basis, which retention period. It’s required for accountability anyway (GDPR Article 30 records of processing), and it makes the access report buildable.

Erasure vs retention — resolving the conflict 

Employee leaves and requests erasure.

Must retain (legal obligation):
  - Payroll records (tax law: typically 6–10 years)
  - Employment contract, working time records
  - Financial transactions they were party to

Can delete:
  - Emergency contact details
  - CV, application materials, interview notes
  - Performance review free text (after the retention period)
  - Photograph, profile data
  - Non-essential contact details

The resolution is anonymisation, not deletion. Replace identifying data with a pseudonym or a placeholder while keeping the financial record structurally intact:

Employee 10045 "Nabila Rahman" → "Former Employee 10045"
  - Payroll journal lines: unchanged (they reference an ID, not a name)
  - Personal details: nulled or replaced
  - Bank details: deleted
  - Documents: retained where legally required, purged where not

Caution: true anonymisation is irreversible. If the data can be re-identified by combining it with other data you hold, it’s pseudonymisation, and it’s still personal data under GDPR. Deleting a name while keeping a unique employee number that maps to a name elsewhere is pseudonymisation, not anonymisation.

Non-production data — the biggest practical risk 

❌ Copying production to a test system unmasked
   = an unlawful disclosure to everyone with test access
   = a reportable breach in most jurisdictions
   = one of the most common privacy findings in enterprise IT

Masking is mandatory. Requirements:

  1. Referentially consistent — customer 100 has the same masked name in every table, or joins break and the data is useless
  2. Format-preserving — a masked tax ID must still pass validation; a masked IBAN must still have a valid checksum
  3. Realistic — masked data must exercise the same code paths (including non-Latin names, long names, edge-case addresses)
  4. Irreversible — no lookup table left behind that maps masked to real
  5. Complete — including free-text fields, attachments, and email addresses
Original                    Masked
──────────────────────────────────────────────
Nabila Rahman          →    Farhana Islam
nabila.r@example.com   →    user10045@example.invalid
+8801712345678         →    +8801700000045
Salary 85,000          →    Salary 78,000 (shifted, distribution preserved)
BD1234567890123        →    BD9876543210987 (valid format)

Also mandatory in the post-copy checklist: disable outbound email, SMS, print, and interfaces. The classic incident is a refreshed test system emailing 40,000 real customers. See Environments and Release Management.

Cross-border transfers

Personal data leaving its origin jurisdiction needs a legal mechanism:

  • Adequacy decision — the destination country is deemed adequate (UK, Switzerland, Japan, South Korea, and others for the EU)
  • Standard Contractual Clauses (SCCs) — the common mechanism
  • Binding Corporate Rules — for intra-group transfers, heavy to establish
  • Derogations — narrow, for specific situations

ERP implications:

  • A global ERP instance in one region processing EU employee data is a transfer
  • Support staff in another country accessing the system is a transfer
  • Backups in another region are a transfer
  • Your cloud provider’s sub-processors matter

China’s PIPL, India’s DPDP, Russia, Saudi Arabia, and several others impose localisation requirements that can force a separate regional instance. Design the regional split before your first customer in those markets, not after.

Privacy by design

Build it in:

□ Data minimisation — challenge every personal data field. "Do we need date of
  birth, or just an age band? Do we need the full national ID, or the last four digits?"
□ Purpose limitation — document why each field exists
□ Field-level access control on sensitive fields
□ Encryption at rest for sensitive fields; TLS in transit
□ Pseudonymisation where full identity isn't needed for the function
□ Retention rules implemented as automated jobs, not policy documents
□ Audit logging of access to personal data (reads, not just writes)
□ Deletion/anonymisation capability built, not promised
□ Data export capability built
□ Consent tracking where consent is the lawful basis
□ Privacy notices linked at the point of collection

A Data Protection Impact Assessment (DPIA) is required for high-risk processing — large-scale employee monitoring, biometrics, systematic profiling. An ERP implementation involving time-and-attendance biometrics or automated credit decisions typically triggers one. Involve the DPO early; it’s a project dependency, not a formality.

Breach notification 

Breach detected
  → Assess: what data, how many people, what risk
  → Notify the supervisory authority within 72 hours (GDPR)
  → Notify affected individuals if high risk to their rights
  → Document everything, including breaches you decided not to report

72 hours is short. You need: an incident response plan, the ability to determine quickly what data was exposed and whose, logs that make that determination possible, and a named decision-maker.

“We don’t know what was accessed” is itself a finding. It’s why access logging on personal data matters.

Employee monitoring

Particularly sensitive, and particularly relevant to ERP:

  • Time and attendance tracking
  • Productivity metrics in warehouses and services
  • Location tracking on mobile apps
  • Access log analysis

Requirements: transparency (tell employees what is monitored and why), proportionality (the least intrusive method that achieves the purpose), a lawful basis, and in Germany, the Netherlands, France and elsewhere, works council consultation or agreement.

A works council can block a deployment. In German-speaking Europe this is a real project risk on any HR or time-tracking implementation. Engage them in the design phase, not at go-live.

Developer checklist

  • A data map exists: table, field, purpose, lawful basis, retention
  • Non-production data is masked, consistently and irreversibly
  • Outbound communication disabled in non-production
  • Field-level access control on sensitive fields
  • Access to personal data is logged, including reads
  • Retention and deletion jobs exist and run
  • Legal hold overrides deletion
  • A data subject access report can be produced
  • Anonymisation capability exists and is tested
  • Export in a machine-readable format
  • Free-text fields and attachments are in scope of your privacy controls
  • Cross-border transfer mechanism documented for each data flow
  • Encryption at rest and in transit
  • Breach detection and response plan tested

Next