Compliance Is Not a Feature
There is a difference between a building that was designed to be fire-safe and a building that had fire extinguishers installed after it was built. Both might pass an inspection. But one of them was designed so that a fire cannot spread through the ventilation system, and the other one has a red cylinder on every floor and hopes for the best.
GDPR compliance works the same way. Most SaaS products achieved compliance by bolting on requirements after the fact: a consent management module, a data export endpoint, a privacy policy page, a cookie banner. These are necessary, but they are surface-level. They address the checklist. They do not address the architecture.
GDPR-native means something fundamentally different. It means the system was designed from the ground up so that personal data is protected by its structure, not by policies that sit on top of the code. The distinction matters because policies can be misconfigured, overlooked, or bypassed. Architecture cannot — at least not without deliberate effort.
What GDPR-Compliant Looks Like in Practice
A typical GDPR-compliant SaaS product has the following characteristics:
- A cookie consent banner that users can accept or reject.
- A privacy policy that describes what data is collected and why.
- A "right to be forgotten" form that queues a deletion request for someone to process manually.
- A data export feature that generates a ZIP file of user data on request.
- A data processing agreement (DPA) that you sign during onboarding.
All of these are required by GDPR, and all of them are important. But they are all reactive. They assume that personal data exists in a standard format in a predictable location, and that you can find it, package it, or delete it when someone asks. In practice, this assumption falls apart quickly.
Personal data in a real application is not confined to a "users" table. It is in logs, in cached responses, in search indexes, in analytics events, in backups, in third-party integrations, in webhook payloads, in email archives. A data export endpoint that queries the users table and a few related models will miss most of this. A deletion script that sets deleted_at on a user record does not touch any of it.
This is the gap between compliance and native design: compliant products can answer the question "where is the user data?" approximately. Native products can answer it precisely, because they were built so the answer is always known.
What GDPR-Native Looks Like in Practice
Encryption by Default with CipherSweet
At Fimula, we use CipherSweet for field-level encryption of sensitive personal data. This is not application-level encryption where the app encrypts and decrypts on every request. CipherSweet encrypts data at the storage layer using deterministic encryption for searchable fields and blind indexing for fast lookups.
What this means in practice: even if someone gains access to the database — through a SQL injection, a compromised backup, a misconfigured firewall — the personal data they find is encrypted. Not hashed (which is one-way), but encrypted (which is reversible with the key). The encryption keys are managed separately from the database, outside the data path. The database itself cannot decrypt the data without the key.
This is not a feature we added after launch. It is how we store personal data from day one. Every product on the Fimula platform uses CipherSweet for fields that contain personal information. There is no "encrypted" flag to enable. It is the default.
Tenant Isolation
The Fimula platform has two tiers: Fimula Lite uses a shared database with PostgreSQL Row-Level Security (RLS) to isolate each tenant's data. Fimula Core gives each tenant a dedicated PostgreSQL instance. In both cases, tenant A cannot access tenant B's data — not through the API, not through a database query, not through any application path.
With RLS, the isolation is enforced at the database level by PostgreSQL itself, not by application code. Even if our application had a bug that sent the wrong tenant ID, the database would return no rows. The policy is attached to the table, not to the request. This is structural privacy — it works even when the software does not.
With dedicated databases, the isolation is even stronger. Each tenant's data lives in a completely separate PostgreSQL instance with its own connection, its own encryption, its own backup schedule. There is no shared state. There is no possibility of cross-tenant data leakage because there is no shared storage.
EU Hosting and Data Sovereignty
Fimula is based in Slovenia, within the EU. Our infrastructure runs in EU data centres. Your data does not cross the Atlantic to be processed by a US cloud provider and then come back. It stays in the jurisdiction where GDPR has direct effect, where data protection authorities understand the law, and where your legal team does not need to navigate the complexities of international data transfer frameworks.
Data sovereignty is not an add-on. It is a location decision that affects every layer of the stack: where the servers run, where the backups are stored, where the encryption keys are managed, where the support team accesses the system from. We made these decisions before writing the first feature.
Bring Your Own Database
The strongest form of data control is ownership. Fimula's BYO model lets you connect your own PostgreSQL database and S3-compatible storage. We do not host your data. The application code runs on our infrastructure, but your data lives on your servers, in your region, under your encryption, with your backup schedule.
When you stop using Fimula, you revoke our credentials. Your data is already on your infrastructure. There is no export to request, no deletion queue, no 30-day retention period. The data is yours from the start, and it remains yours when we are done.
The Practical Difference
When a data subject submits a deletion request to a GDPR-compliant product, someone on the engineering team has to figure out where that person's data lives, write a script to delete it from all the places, run the script, verify the results, and hope they did not miss anything. This process takes days or weeks, and it is never fully reliable.
When a data subject submits a deletion request to a GDPR-native product, the system handles it precisely because it knows where the data is. CipherSweet-encrypted fields can be zeroed. RLS policies ensure no orphaned rows exist. Backups can be rotated. The process is automated, auditable, and complete.
When a regulator asks a GDPR-compliant vendor to demonstrate data isolation between tenants, the vendor points to application-level access controls and hopes those are sufficient. When a regulator asks a GDPR-native vendor the same question, the vendor points to database-level isolation enforced by PostgreSQL and, in the case of Fimula Core, physically separate database instances.
The difference is not theoretical. It is the difference between a compliance posture that relies on people following processes and one that relies on systems enforcing constraints. People fail. Systems do not — or at least, they fail in predictable ways that can be detected and fixed.
Compliance as a Marketing Term
"GDPR-compliant" has become a marketing term. Every SaaS vendor claims it. Very few can explain what it actually means in their architecture. Even fewer can demonstrate it with code-level specifics.
When you evaluate a SaaS vendor, ask these questions:
- Where is personal data encrypted, and what encryption method is used?
- How is tenant isolation enforced — at the application level or the database level?
- Where does the data physically reside, and under which legal jurisdiction?
- Can I use my own database and storage, so I own the data?
- How is a data deletion request processed — manually or automatically?
- Can you show me the actual code that handles data subject requests?
Most vendors cannot answer all of these. We can, because we built the system to answer them.
Built Differently, on Purpose
Fimula is GDPR-native because we are an EU company building software for EU businesses. We did not have to retrofit privacy. We started with it. CipherSweet encryption, RLS and Core isolation, EU hosting, BYO storage — these are not features on a pricing page. They are architectural decisions that shape every product on the platform.
If you are choosing between a product that bolted on compliance and one that was built with it from the start, the choice is clear. One has a privacy policy. The other has a privacy architecture.