Most SaaS accounting platforms work the same way: one application, one database, every customer inside it. That is efficient for the vendor — and it means all customers share one fate. This article explains how that model works, what a breach looks like inside it, and how FiscFort is built differently.
How a typical shared SaaS stores your data
In a multi-tenant platform, many customers ("tenants") are served by the same application and, very often, the same database. Every row carries a tenant ID, and the application adds "only this tenant" to every query. The separation between customers is application logic: it holds only as long as every query, report, export and integration applies the filter correctly.
OWASP's guidance on multi-tenant security states the trade-off plainly: the architecture is cost-efficient and the foundation of modern SaaS, but a single vulnerability can expose all tenants' data and a misconfiguration can leak data across tenant boundaries (OWASP). Security testers make the same point: in a shared-database platform a single SQL injection or one mis-scoped filter can expose every tenant at once, because the isolation exists only in the application layer and is not enforced by the database itself (AppSecure).
What "compromised" means in each model
| Situation | Shared multi-tenant SaaS | FiscFort dedicated instances |
|---|---|---|
| Where customer data lives | In tables shared by all customers, separated by a tenant ID | In a separate database per client, inside that client's own Odoo instance |
| What enforces the separation | Application code that must be correct on every query | The database, containers, networks and credentials themselves |
| A bug in the tenant filter | Can expose many or all customers | Limited to that client's own instance; no other client's data sits in it |
| A leaked database or admin credential | Opens the shared database: every customer | Opens one client's database only; other clients use different credentials |
| One customer's account is taken over | The attacker starts inside the shared platform | The attacker is confined to that client's own instance |
| Hosting | Shared cloud platform | Dedicated, EU-hosted infrastructure |
How FiscFort is built
- One Odoo, one PostgreSQL database and its own storage per client. Separation is a property of the database, not of a filter that has to be right forever. Odoo's own multi-company mode keeps all companies in a single database and depends on record rules being correct on every model; we chose not to use it for exactly that reason.
- Its own network and firewall rules. Every client's containers run on their own pinned network, and each client's ports have their own explicit firewall rules.
- Its own credentials. Each client gets its own database password and its own API keys, generated for that client and never copied from another.
- Its own addresses and logins. The accountant reaches each client's Odoo at its own URL with its own login; the client reaches its own portal with its own login. The database list is never exposed — Odoo selects the client's database from the host name and nothing can be enumerated.
Who can reach what
- The client signs in to their own portal and sees only their own instance.
- The accountant signs in to each client's Odoo separately — one URL and one login per client — so access to one client never implies access to another.
- FiscFort operations hold administrator access in every instance, because patching and regulatory updates need it. That access is used by automated agents and workflows through a dedicated service account, not by people logging in, and its credential is different on every server and stored encrypted.
- Everyone else has nothing: the servers themselves have no public address.
Inside Odoo, every record shows who created or last changed it, and posted accounting entries can only be reversed, never edited. Odoo does not record who merely viewed a record; changes are what get logged.
The perimeter around it
Traffic reaches a client only through Cloudflare (DDoS protection and a web application firewall) and our reverse-proxy layer over HTTPS. The servers have no public IP address, only the portal and Odoo are exposed, and management access is not reachable from the internet. The other layers described on our product pages — the enterprise firewall, storage-level double encryption, redundant EU links, real-time antivirus scanning and URL monitoring — sit on top. The servers are monitored around the clock, and the operating system, Docker and vendor software are patched weekly, with a snapshot and rollback.
Always current, without moving your data
The same engine serves Lithuania and Belgium. A defined process and several AI agents check the official sources for both countries and, every early morning at 3 AM, update each client's Odoo with the current rules. The update changes the rules, not the data, and it is applied inside each client's own instance — one client's data never travels to another.
Questions to ask any SaaS vendor
- Is my data in a database shared with other customers?
- What stops a bug in the tenant filter from exposing everyone?
- How many customers does one leaked credential open?
- Who at the vendor can read my data, how is that access granted, and where is it logged?
- Where is the platform hosted, and who operates it?
Related
EU Data Residency for Client Bookkeeping Data, Explained
Sources
- OWASP — Multi-Tenant Security Cheat Sheet
- AppSecure — penetration testing for multi-tenant SaaS architectures (2026)
The description of shared SaaS platforms is the common pattern; individual vendors differ.