Trust starts long before you upload your first file
When businesses evaluate software, they usually compare features. Can it manage customers? Can it create invoices? Does it support bookings? Does it include AI?
All important questions.
But there is another question that is just as important — and far fewer companies ask it.
Who can actually access our business data?
The answer is often more complex than most people expect.
Your software is more than an application
When you log into a business platform, it may appear as a single application. Behind the scenes, the same product is usually built from many separate services that talk to each other.
Each of those services represents a possible point of access. Each can be operated by your vendor, by a third party your vendor uses, or sometimes — through integrations you authorised — by a third party you chose yourself.
The total number of people and systems with theoretical access is usually larger than businesses assume.
The three layers of access
It helps to think of access in three layers.
The first layer is you and your team. You decide who is invited to your workspace, what role they have, and what they can see.
The second layer is the vendor's staff. A small number of operations engineers usually have the ability to access infrastructure for maintenance, support, and incident response. Reputable vendors limit who can do this, log every action, and require an explicit reason.
The third layer is everybody else. Sub-processors. Integrations. Audit firms. Backup operators. Any party in the operational chain that may have indirect contact with infrastructure.
It is the third layer that most businesses underestimate.
How KIMISUITE approaches access
We designed KIMISUITE so the third layer is intentionally small.
Most core platform components are operated by our own team. We do not outsource our customer support to a different company. We do not route operational analytics through a third-party observability platform. We do not let advertising networks see what happens inside workspaces.
There is no behavioural tracking in workspaces for ad targeting. There is no resale of customer information. There is no "data partnership" with any other SaaS company.
The smaller the third layer, the less surface area there is for misuse — accidental or otherwise.
What we do not do with your data
This is sometimes the more useful list.
We do not sell business data. We do not let third-party advertising networks profile your team. We do not train external AI systems on your private workspace content. We do not bundle your data into market-research products. We do not share your information with sister companies or holding-company subsidiaries (KIMISUITE LTD operates independently).
None of those statements are clever. They are simply choices we made — and choices we continue to make every time a new business model tempts us to revisit them.
What access actually requires
When a member of our operations team needs to access infrastructure, the request has to be justifiable, logged, and proportionate. Access to anything containing customer data is reserved for clearly defined operational scenarios — for example, restoring service during an incident or honouring a documented data-subject request.
It is not casual, and it is not routine. A vendor who tells you their staff "have access to your data so we can give you great support" is being more honest than most, but a vendor whose staff routinely look at customer content is taking a structural shortcut.
We chose the longer path.
The role of integrations
Integrations matter. They are also a deliberate decision you make as the customer.
When you connect a third-party tool to KIMISUITE — whether for payment processing, calendar sync, or any other purpose — that tool gains access to the data scope you authorise. Not more.
We make those scopes visible. We document them. And if you ever revoke an integration, the third-party tool's access is removed.
You stay in control of what leaves your workspace.
Why architecture matters
You cannot solve trust questions by adding a paragraph to a privacy policy.
The fundamental answer to "who can access our business data?" is shaped by the architecture of the platform, not by the language of the legal documents.
A platform built on twenty external services has a different access surface than a platform built primarily in-house. A platform that sells targeting data has a different access reality than one that does not.
Architecture creates the boundaries; policy describes them.
Final thoughts
The next time you evaluate business software, ask three questions.
Who, exactly, can access our data? How is that access logged? What is the smallest set of people and systems that could possibly see what we put into this platform?
If the answers are clear, specific and short, you are looking at a vendor who takes trust as seriously as features.
We believe that is the only kind of vendor a business should consider.
Continue reading the Trust Series:
← Previous: Your business data shouldn't pass through 20 different companies
→ Next: Privacy by architecture, not just by policy