Data sovereignty
Your data is in your country. Where is the system that governs it?
The question asked most often when evaluating an enterprise data platform is “where does my data sit?” It is the right question, but an incomplete one: the table files can sit in a region inside your country while the system deciding who may read them runs somewhere else entirely.
Last updated: September 2026
What the sentence “my data is in-country” leaves out
Buying a managed data platform gets you two separate things. The first is the data plane: the files behind your tables, and the compute that runs queries over them. The second is the control plane: the catalogue itself, the access rules, query history, the audit log, connection credentials and the interface. When a vendor discusses region selection, they usually mean only the first.
The distinction is not academic. If the control plane runs abroad, then even when no row of your tables crosses the border, these do: table and column names, who read what, user identities, and very often the full text of the query. Query text is not innocent either — a `WHERE` clause containing an identity number or a customer name is itself personal data.
There is a quieter consequence. If the control plane holds your connection credentials, the parties technically positioned to reach your data are you and your vendor. That is an ability a contract can restrain, but not one the architecture has removed.
Two planes, two separate questions
Filling in these two columns separately tells you far more about a platform than a single question about regions.
| Managed service (typical) | Kauzas | |
|---|---|---|
| Table files | In your chosen region | In your cluster |
| Catalogue and metadata | In the vendor's cloud | In your cluster |
| Query text | Sent to the vendor | Never leaves the cluster |
| Audit log | Held by the vendor | Held by you |
| Connection credentials | Stored by the vendor | In your own secret store |
| If the internet drops | Access stops | The platform keeps running |
“Typical” because there are exceptions: some vendors offer deployments that run the data plane inside the customer's own account. The control plane stays with the vendor even in those — that is what the service is.
What changed under Türkiye's data protection law
Law No. 7499 amended Article 9 of the Personal Data Protection Law (KVKK). It was published on 12 March 2024 and took effect on 1 June 2024. The amendment added standard contracts and binding corporate rules to the recognised safeguards for transferring personal data abroad.
In practice this does not forbid transfer; it conditions it. A controller taking the standard-contract route must notify the Authority within five business days of signing. Onward transfer of that data to a third country falls under the same article — the obligation does not end with the first transfer.
The architectural observation that follows is this: every safeguard route creates an obligation you then have to maintain. Notification, renewal, tracking subprocessors, supervising onward transfers. The only arrangement that creates none of them is the one where no cross-border transfer arises in the first place.
This page is not legal advice. Which of your processing activities count as a transfer, and which safeguard route suits you, are questions for your own legal and compliance teams. Our contribution here is architectural rather than legal: making it visible where a transfer actually occurs.
How Kauzas is arranged
Kauzas is not a managed service; it is a platform you install into your own Kubernetes cluster. That has one consequence, and this whole page rests on it: the control plane runs on your side too.
Catalogue, authorization and audit stay in your cluster
Which tables exist, who may reach what, and who did what and when — all three sit in components you run. Novadsa has no access to those records, because there is no place it could technically reach them.
An internet connection is not a requirement
The platform runs without calling out. That was not designed as a compliance feature but so it could run on disconnected networks — though the compliance consequence is clear enough: not even licence validation crosses a border.
The infrastructure choice is yours
Run it entirely on your own hardware, in your own data centre, or on the AWS Local Zone infrastructure in Istanbul. The platform is the same platform in all three; only the iron underneath changes.
Seven questions to put to your vendor
None of these are specific to Kauzas; they can be asked of any data platform, and the answers tell you far more than a map of regions. It is worth having the answers in writing.
Which country does the control plane run in?
Region selection usually covers the data plane only. This question opens the other half.
Where are table and column names stored?
Schema alone can be sensitive: a column name gives away what is being collected.
Is query text transmitted to your systems?
An identity number or customer name inside a query is personal data in its own right.
Where are audit records written, and who can read them?
Auditability means something when nobody outside your organization can reach the audit log.
Who holds the credentials for my data sources?
Whoever holds the key is the party who can technically reach the data, whatever the contract says.
Does the platform keep working if the internet connection drops?
This answer shows where the real dependency lies faster than the other six combined.
Who are the subprocessors, and how are onward transfers handled?
Data transferred abroad and then on to a third country falls under the same obligation.
Let's have this conversation about your own organization.
We can map where the control plane sits in your current architecture, and show how Kauzas would be installed in your environment.