Security
GDPR on a shared platform: the choices that actually matter
On platforms used by several companies, compliance is not achieved with a document: it is achieved with choices made during construction. Isolation enforced by the database rather than the code, data minimisation, explicit roles, a request register, and restore drills that also verify the protections. A perfect privacy notice on the wrong foundation protects nobody.
When a company asks us whether its platform is "compliant", the conversation almost always starts from the privacy notice and consent. Those are the visible part, and they are necessary. But if two customers' data can end up on the same screen because of a programming mistake, no notice will save you.
On a platform used by several companies, data protection is decided in five places — and all five are decided while building, not afterwards. Here is how we handled them on a CRM hosting a network of agencies: a head office, partner companies and people working for more than one.
1. Isolation belongs in the database, not in the code
It is the most important decision and the least visible one. On a shared platform every query must be filtered by the company of whoever is looking. If that filter lives in the code, sooner or later someone writes a new function and forgets it: not out of incompetence, but because across a few thousand lines it happens.
That day one customer sees another's data, and the worst part is that nobody notices: no error, no alert, just extra rows on a screen.
Our choice is to put the rule inside the database, with row-level access policies, and connect the application with an account that has no power to bypass them. Code can be wrong; the database cannot. The permission becomes data you can read and revoke, instead of a branch scattered across thirty files.
If protection depends on nobody making a mistake, it isn't protection: it's hope.The principle we apply to shared platforms
2. Collecting less is easier than protecting more
Minimisation is the most quoted and least practised principle. Concretely it means asking an uncomfortable question of every field in the form: what do we need it for? If the answer is "it might be useful", that field is a risk with no return.
Data you never collected cannot be stolen, doesn't need anonymising, doesn't appear in a backup to manage and doesn't turn up in an access request. It is the only security measure that costs nothing to maintain.
The same applies to history: keeping everything forever is a choice, and it has to be justified. Knowing how long you keep each category of data — and actually deleting it when the time is up — is half the compliance work.
3. Roles are data, not a series of exceptions
In the agency network mentioned above, the structure has three levels: the network groups companies sharing a perimeter of tools, the company is the customer, and a person may work for several companies with the session remembering which one they are operating on.
The temptation in such cases is to write exceptions: "if it's head office then they see everything". We did the opposite: head office is a company with a different kind, and privilege is data. Data can be read, revoked and — above all — understood by the database, which a condition buried in code cannot be.
The practical effect is that the menu doesn't even draw the entries the perimeter excludes: an operator who is not an owner sees the company sheet read-only without anyone having to remember to hide it.
4. Data subject requests are handled before they arrive
Anyone has the right to know what data you hold about them, to correct it, to get a copy and in many cases to have it deleted. The wrong moment to work out how is when the request arrives, with a month to answer.
Three things make the difference between an afternoon and a week of panic: knowing where a person's data lives (in how many tables, which attachments, which external systems), having a way to export it in a readable format, and keeping a register of requests received with what was done and when.
On that platform the register is part of the product, not a spreadsheet kept on the side: it is the evidence you need if someone asks you to account for how you answered.
5. Deleting isn't always deleting (and backups complicate everything)
There is a real tension here, and anyone hiding it is not helping you. On one side a person can ask for deletion; on the other you cannot throw away an invoice, which the law requires you to keep.
The workable route is to separate the two: what is legally required stays, everything else is anonymised — the link between the data and the person is broken, while the figures remain for accounting. The tax document survives; the identity does not.
Then there are backups, which by definition contain yesterday. Deleting today does not rewrite yesterday's copies, and rewriting them would be worse: it would mean they can be tampered with. The accepted approach is to declare how long copies live, never fish data back out of them to put deleted records into circulation, and protect them like live data. It is a position to write down, not to improvise when someone asks.
The test almost nobody runs
There is one check we recommend to anyone running a platform with several customers' data, and almost nobody performs: restore a backup and verify that the protections really come back.
Not counting that the rules exist: counting is not enough. You have to connect the way the application would, without declaring whose data you are looking at, and verify that no row comes back. If the account had returned with the wrong privileges, the rule count would look identical while every customer saw everyone else's data — silently, until the day someone notices.
On that platform the drill runs automatically every week onto a throwaway database, which is then dropped. The restore never touches the live database: it creates a new one, so if it doesn't convince you there is still a way back.
None of these five choices appears in a privacy notice, and all five decide whether your customers' data is genuinely separated. If you are building a shared platform, these are the questions to ask whoever is writing it — now, not at the first audit.