An ERP is not just another application. The same database holds orders, invoices and negotiated prices right next to national ID numbers, home addresses, salaries and HR files. It is multi-user, with roles that must not see each other's things, and it has to answer, a year later, the question "who changed this field, and when?" That stopped being merely a security requirement — it is GDPR (Art. 5, 25, 30) and ISO 27001 at the same time.
The good news: the technologies that make an ERP compliant are not exotic. They are mature, available and — crucially — best fitted at the start, not at the end. Below are the ones we use, each tied to the GDPR principle it serves. Not because "that's how it's done", but because without them a multi-tenant ERP simply cannot be defended in a serious audit.
Encryption in transit and at rest — confidentiality
The starting point, no exceptions. All traffic runs over TLS 1.3, with HSTS
enabled (Strict-Transport-Security) so the browser refuses any downgrade to HTTP from
the outset. Without HSTS, an attacker on the network can force a first unencrypted
connection; with it, that window disappears.
At rest, the database and files sit encrypted (AES-256 at the volume and storage layer). In practice, if someone got hold of a backup or a disk, they'd get noise, not ID numbers.
- GDPR principle: confidentiality (Art. 5(1)(f)) and appropriate technical measures (Art. 32).
- Why an ERP specifically: personal and commercial data move constantly between client, server and storage. An unencrypted channel exposes all of it at once.
Row-Level Security in Postgres — everyone sees only what's theirs
This is where a multi-tenant ERP is won or lost. The convenient temptation is to filter
data in the application: WHERE org_id = :currentOrg. It works — until one endpoint
forgets the filter, a developer writes a new query in a hurry, or an authorization bug
lets one organization see another's rows.
We move the rule to where it can't be bypassed: into the database, via Row-Level Security (RLS). We enable RLS on tables and define policies that bind every row to the organization and user allowed to see it. From there, even if the application gets it wrong, Postgres returns zero rows. Security no longer depends on the discipline of every single query.
- GDPR principle: integrity and confidentiality; minimizing access.
- Why an ERP specifically: it is multi-tenant and multi-role by definition. Isolation between customers cannot be a convention — it has to be a law of the system.
Our opinion, bluntly: if tenant isolation lives exclusively in application code, you have a vulnerability, not an architecture. RLS costs a few days of design up front and spares you a reportable incident later.
Audit log — who, what, when, immutable
The question "who changed the price on this order three months ago?" must have an answer. Without a log, the answer is a shrug — unacceptable in a system that holds personal data.
We log every sensitive operation: actor, action, entity touched, before/after values and timestamp. The log is immutable — append-only, no UPDATE or DELETE from the application — with a defined retention (90 days), after which entries expire in a controlled way. We don't keep everything forever; retaining beyond what's needed is itself a GDPR risk.
- GDPR principle: accountability (Art. 5(2)) and records of processing activities (Art. 30).
- Why an ERP specifically: it is the system of record for money and for people. At an ISO 27001 audit, or when a data subject submits a request, the log is the difference between "we can demonstrate" and "we believe".
A log that can be edited by the people it monitors is not a log, it's decoration. Immutability is not a nice-to-have — it's the entire point.
Least-privilege access + MFA (TOTP)
The safest access is the one you never grant. We start from least privilege: each role gets exactly the permissions it needs, nothing more. A warehouse operator doesn't see salaries; an accountant doesn't edit production recipes.
On top of that we add two-factor authentication via TOTP (Authenticator-style apps), mandatory or optional depending on how sensitive the role is. A stolen password is no longer enough to get in.
- GDPR principle: minimizing access, technical and organizational measures (Art. 32).
- Why an ERP specifically: it concentrates many categories of data in one place. The fewer people who can reach the sensitive ones, and the harder it is to log into an account, the smaller the attack surface.
Signed, short-lived URLs for documents
Documents — contracts, HR files, scans — don't sit behind public links that "work if you know them". That is exactly the pattern through which data leaks: a URL that ends up in an email or a browser history stays valid forever.
We use signed URLs with a short expiry (5 minutes). The system generates the link on demand, only for whoever is entitled to it, and after five minutes the link is dead. If it leaks somewhere, it no longer downloads anything.
- GDPR principle: data minimization put into practice — access exactly as much as needed, for exactly as long as needed.
- Why an ERP specifically: attachments frequently contain the most sensitive data (ID documents, contracts). A permanent link is a leak waiting to happen.
Pseudonymization, minimization and defined retention — privacy by design
The last layer is also the hardest to add later, because it lives in the data model. The questions we ask from the design stage:
- Do we even need this field? If not, we don't collect it. Data you never collected can't be lost.
- Can we pseudonymize? Wherever possible, we separate identity from data via references (opaque IDs), so reports and analytics never work directly on real identifiers.
- How long do we keep the data? Each category has a defined retention, with automatic deletion or anonymization at expiry.
This is the essence of Art. 5 and Art. 25 — privacy by design and by default. The default setting protects, rather than exposes.
Compliance-by-design: GDPR and ISO become a property, not a scramble
None of these technologies is revolutionary on its own. Their power lies in being built into the architecture, not bolted onto a finished system. When RLS, the immutable log, least-privilege access, signed URLs and defined retention are already in the foundation, GDPR and ISO 27001 stop being a pre-audit crisis project — they're simply how the system works.
The practical difference is enormous. Compliance added at the end means months of remediation, rewritten queries and procedures that contradict the code. Compliance built from the start means the auditor checks what already exists and leaves.
Practical takeaway: when you evaluate an ERP — built in-house or bought — ask five concrete questions. Is traffic on TLS with HSTS? Is tenant isolation enforced at the database (RLS) or only in the application? Is there an immutable audit log with defined retention? Is access least-privilege with MFA? Do documents use signed links that expire? If the answer to any of these is "no" or "we'll handle it in procedures", you have an architecture problem, not a paperwork one — and it's far cheaper to fix now than after the first data-subject request.
