Privacy is not only a document
Every modern SaaS product has a privacy policy. Most of them say the right things.
They describe what data is collected, how it is used, which categories of recipients receive it, how long it is retained, and how a customer can exercise their rights.
That is necessary — but it is not enough.
A privacy policy tells you what a vendor promises to do. The architecture of the product tells you what they could do.
If a policy says "we do not sell your data" but the architecture is built on advertising-tech infrastructure, the policy is doing a lot of heavy lifting. If a policy says "we keep your data secure" but the system is held together by twenty external services, the policy is making promises about parts of the system the vendor cannot fully control.
We believe privacy should be visible in the architecture first, and described in the policy second.
What "by architecture" actually means
Privacy by architecture is the idea that the structure of the system itself should limit how data can be collected, accessed, processed and shared.
It is the difference between "we choose not to do X" and "we built the platform in a way that makes X impractical".
The first is a culture. The second is a constraint.
Cultures shift. Constraints are stable.
The decisions that shape it
Privacy-by-architecture is not a single feature. It is a sequence of small decisions, repeated over years.
Choosing to operate components internally rather than route data through external services. Choosing to minimise the categories of data we collect. Choosing not to integrate with advertising or behavioural-tracking ecosystems. Choosing to store business data in regions our customers expect. Choosing to keep workspaces isolated. Choosing not to mine customer content for marketing insights.
None of those decisions is dramatic on its own. The cumulative effect is what shapes the platform.
What we deliberately do not collect
A useful exercise is the reverse of the typical privacy summary.
We do not collect behavioural profiles of your team for ad targeting. We do not record session replays of workspace usage. We do not deploy cross-site tracking from advertising networks inside the authenticated platform. We do not collect data we cannot justify needing.
Every additional data point a platform collects is a privacy decision. Most platforms err on the side of more. We err on the side of less.
What we deliberately do not share
There is no resale of customer information. There is no sharing with marketing partners. There is no data-broker pipeline. There is no "anonymised" dataset being licensed to third parties.
When a vendor says "we may share aggregated, anonymised data with our partners", it is worth understanding what that sentence actually allows. We did not want to write it.
What we deliberately do not retain forever
Backup retention exists, for reasons of operational reliability and regulatory obligation. We document our retention periods in the Privacy Policy.
But outside those explicit retention windows, we delete what we no longer need. We do not maintain customer information indefinitely as a default. We do not keep terminated accounts' data warm in case "you might come back". We do not stockpile information against future product ideas.
If we did not need to retain it, we delete it.
Why minimisation matters
Data minimisation is one of the core principles of GDPR. It is also good engineering.
Every additional piece of data a system stores is something that needs to be protected, secured, backed up, replicated, kept compliant, and eventually deleted. Less data means less surface to defend.
For our customers, it also means less to worry about. The information that exists is the information you put there — not a long shadow of behavioural metadata that someone, somewhere, might eventually find a use for.
Why isolation matters
Each KIMISUITE workspace is logically isolated from every other. Your business data does not mix with other customers' content. Operations between workspaces do not happen by default. Cross-workspace functionality is opt-in and explicit.
That isolation is built into how the platform works, not just into the policy.
Why architecture beats marketing
It is easy for any vendor to write "privacy is in our DNA" on a marketing page. It costs nothing.
It is harder to make architectural decisions that constrain the platform itself — decisions that have to be defended every time a competing requirement appears.
Internal teams will ask for more behavioural data. Sales teams will ask for richer customer profiles. Marketing will want session replays. Some future investor will suggest monetising "anonymised" datasets.
The answer to all of those, by architecture and by intention, is no.
Final thoughts
A privacy policy can describe what a vendor wants to do.
The architecture of a platform decides what a vendor can do.
We chose to make the two match — and to keep them matching as the platform grows.
If your business stores meaningful information inside a SaaS platform, that match is worth looking at carefully.
Continue reading the Trust Series:
← Previous: Who can access your business data?
→ Next: What happens to your data when you cancel?