Is Cloud Accounting Safe? How Tenant Isolation Works

Moving your books to the cloud gives you backups you no longer have to remember, access from anywhere, and software that updates itself. It also hands your most sensitive data (every sale, every supplier price, every customer's balance) to a provider that holds the same data for thousands of other businesses, possibly including your competitors.

How big is the risk for a small business?

Two widely cited studies frame it.

Verizon's 2025 Data Breach Investigations Report found that the share of breaches involving a third party, such as a supplier or service provider, doubled from 15% to 30% in a year. It also found ransomware present in 88% of breaches at small and medium-sized businesses, compared with 39% at larger organisations.

IBM's Cost of a Data Breach Report 2025, based on 600 organisations, put the global average cost of a breach at USD 4.44 million. That study covers organisations of all sizes and is dominated by larger ones, so the figure is not a forecast for a corner shop. The point is the direction: breaches are expensive, and your providers are part of your attack surface.

What does "multi-tenant" mean in cloud accounting?

Most cloud accounting is multi-tenant: many customers (tenants) share the same application and often the same database servers. That is what makes it affordable. It also means separation between tenants is not a physical fact like separate filing cabinets; it is enforced by software, and it is only as good as that software's design.

The UK's National Cyber Security Centre lists separation between customers as one of its fourteen cloud security principles. Its guidance is direct: you depend on the provider's security boundaries to control who can access your data, and the provider should be able to explain how it implements separation in compute, storage and networking.

What are the three ways to separate tenants?

1. Application-level filtering

Every query the application makes includes a condition such as "only rows for tenant X". This is common and can be done well. Its weakness is that it depends on every developer remembering the condition in every query, forever. One missed filter in one report, and data leaks.

2. Database-enforced isolation (row-level security)

The database itself refuses to return rows that do not belong to the current tenant, whatever query the application sends. In PostgreSQL, for example, this is done with row-level security policies. The application sets the tenant context for each transaction, and the database applies the rule.

This is much stronger, but it has traps that only a careful design avoids. PostgreSQL's own documentation states that superusers and roles with the bypass attribute always skip row security, and that a table's owner skips it too unless the table is set to force row-level security. An application that connects as the same database role that created the tables can have perfectly written policies that never apply. A well-designed system uses separate roles for creating tables and for running the application, and tests that isolation actually holds, including on reused connections where a previous tenant's context might linger.

3. Separate databases or instances

Each tenant, or each group of tenants, gets its own database. This gives a clear boundary and makes it easier to back up, restore or delete one customer's data. It costs more and is harder to operate at scale. Many providers combine approaches: separate databases for groups of tenants, with database-enforced isolation inside each.

No approach is automatically safe. What matters is that separation is enforced at more than one layer and is tested continuously.

How this looks in GrowMore

GrowMore keeps each shop's books apart with row-level security that the database enforces, not only the application. The role that owns and migrates the tables is not the role the application connects as; the application's role cannot bypass the rules, and the stack refuses to start if that ever changes; every accounting table forces the rule rather than merely enabling it. A request with no shop in its signed token sees zero rows, never all of them. Seven isolation cases run against a real database for every table, including a reused pooled connection. The security page describes each layer.

What questions should you ask a cloud accounting provider?

A provider that takes isolation seriously will answer these plainly.

How is my data separated from other customers'? Listen for more than one layer, and for enforcement by the database or infrastructure, not only application code.
How do you test that separation? Look for automated tests that attempt cross-tenant access and must fail.
Who on your staff can see my data, and is that access logged?
Is my data encrypted in transit and at rest?
How often are backups taken, and when did you last test restoring one?
Can I export all my data in a usable format, and what happens to it if I leave?
Which other providers do you rely on (hosting, email, payments), and where is my data stored?
How will you tell me about a security incident, and how quickly?

Which half of security stays your responsibility?

The provider secures the platform. You secure how your business uses it. Most incidents at small businesses involve the second half.

Individual logins. Shared accounts make an audit trail meaningless. Every person gets their own login.
Multi-factor authentication for everyone, and especially for the owner and anyone who can post or approve payments.
Least privilege. A cashier needs the till, not the payroll. Your external accountant may need to read everything; whether they also post directly or prepare drafts for your approval is your choice, as long as every entry they make is visible in the audit trail.
Leavers. Remove access on the day someone leaves.
Connected apps. Every integration, including AI agents, is a new door. Grant each the narrowest permission it needs, review the list quarterly, and revoke what is unused. (We cover AI agents in the books separately.)
Payment detail changes. Verify any change of supplier bank details by phone, using a number you already hold.

A worked example: four people and one accountant

A phone and electronics shop has an owner, a manager, two cashiers and an external accountant.

Before: everyone used the owner's login "because it was easier". When the cash box was short by 200 one Saturday, the system showed the owner had recorded every sale. When one cashier left, nobody changed the password.

After an afternoon's work:

Five individual logins, all with multi-factor authentication.
Cashiers can sell, take returns up to a limit and count their cash box, but cannot delete posted documents or change prices.
The manager can receive stock and prepare supplier invoices as drafts; only the owner posts payments.
The accountant has read access to everything and can post journal entries, with each one visible in the audit trail.
The leaver's access was removed and the list of connected apps was cut from seven to three.

None of this required new software, only the controls the system already had.

What to do this month

Ask your accounting provider questions 1, 2, 5 and 6 above, in writing.
Make sure every person has their own login, with multi-factor authentication switched on.
Review roles: who can post, who can delete, who can change prices, who can change bank details.
Remove access for anyone who has left.
List every connected app and integration; revoke any you do not use.
Write down how supplier bank detail changes are verified, and tell your staff.
Export a full copy of your data once, to prove you can.

Frequently asked questions

Can other businesses see my data in cloud accounting?

They should not, but the answer depends on how the provider separates customers. Ask whether separation is enforced by the database or infrastructure as well as the application, and how it is tested.

What is row-level security?

A database feature that returns only the rows a policy allows for the current tenant, whatever query the application sends. In PostgreSQL, superusers and roles with the bypass attribute always skip it, and a table's owner skips it too unless the table forces row-level security.

Is cloud accounting safer than desktop software?

It moves the risks rather than removing them. The provider takes on the platform, updates and backups; you still own logins, roles and connected apps. Compare providers on the questions in this article, not on the label.

Sources

UK National Cyber Security Centre, Cloud Security Principles, Principle 3: Separation between customers. https://ncsc.gov.uk/collection/cloud/the-cloud-security-principles/principle-3-separation-between-customers
UK National Cyber Security Centre, 'Technically enforced separation in the cloud'. https://ncsc.gov.uk/collection/cloud/understanding-cloud-services/technically-enforced-separation-in-the-cloud
PostgreSQL documentation, Row Security Policies (superusers and BYPASSRLS roles always bypass row security; a table's owner does too unless FORCE ROW LEVEL SECURITY is set). https://www.postgresql.org/docs/current/ddl-rowsecurity.html
Verizon, 2025 Data Breach Investigations Report (third-party involvement 30%, up from 15%; ransomware present in 88% of SMB breaches). https://www.verizon.com/about/news/2025-data-breach-investigations-report
IBM, Cost of a Data Breach Report 2025, summary by Baker Donelson (global average USD 4.44 million, 600 organisations). https://www.bakerdonelson.com/ten-key-insights-from-ibms-cost-of-a-data-breach-report-2025