The legal name for keeping customer data on a server abroad is transfer of personal data outside Türkiye; the provision is written about a record tied to a person, not the machine holding it. That puts the first half of the answer in your data model rather than a legal text; a field you never collect has no country. No visitor record is created on the SsangYong showroom kiosk, so that line stays empty.
The rule is written about the record, not the machine that holds it
The question almost always arrives phrased as a location problem. Where should our server be. The provision on transfers abroad in Türkiye’s data protection law is not written that way; its object is personal data being transferred, and the Authority’s own page on the subject speaks the same language. Nowhere on that page is there a sentence about servers, about hosting, or about where data is stored. What running a machine in another country amounts to under that provision is not something this article decides. It names the question and leaves the answer to the source and to your lawyer.
There is work for a software team at this point, and it is not answering. The team can show whether the precondition of the question holds: is there a record tied to a person, or is there not. If there is none, the question has no subject. If there is one, the question is real and moves on to the next section. This is a factual finding rather than a legal assessment, and it is made by reading the data model and the code that writes to it.
Opposite cases sit side by side in our portfolio. On one store screen nothing at all is taken from the visitor; what the screen shows is the brand’s own product information. On a health platform a patient enters their own test values and a physician writes a comment, and there the record is the service. Put the same question to both systems and one returns an empty line while the other returns a full inventory. The question does not change. The length of the answer does.
The line is not a new one. It runs through the same place when a business keeps records about its own staff, and we wrote about that side of it in the piece on where software stops in employee monitoring.
If your record does tie to a person, this section resolves nothing. All it does is put the question on the table under its correct name and hand it over intact.
Read the regime in its own order: adequacy decision, then a safeguard, then an exceptional case
Readers want a clean yes or no at this point. The regime is not built to give one. It asks to be read in a fixed order, and until you know which question in that order falls to you, you cannot even negotiate with a provider, because the document you would ask them for changes with the position.
The order runs like this. The first thing examined is whether the destination country has been declared by the Board as one where adequate protection exists. If that declaration is in place, the reading stops there. If it is not, the next question arrives: is there an appropriate safeguard between the parties. The forms a safeguard can take are enumerated, and the source names them. A standard contract. Binding corporate rules approved by the Board. A written undertaking of adequate protection together with the Board’s permission. An agreement between public bodies, again with permission. If none of those is available, what remains are the exceptional cases the law and its regulation list “sınırlayıcı biçimde”, the source’s own phrase, meaning restrictively. The phrase carries information: this is not a list meant to be read expansively.
Which countries hold that declaration is not written here. A list of that kind changes over time, and an unverified one would send a reader into a provider meeting with a confidence nobody has checked. Read the list from the Board’s own announcement; the regime itself sits on the Authority’s page about transfers abroad.
One distinction gets confused often, and confusing it means writing to the wrong body. The body that adopted the standard contract texts is the Board. When you sign one of those texts with your provider abroad, the body you are dealing with is the Authority. They are separate. The decision date, the decision number and how a signed text is notified are written in the same source; read them there rather than here. The job of this article is to describe the shape of the regime, not to classify your situation inside it.
A software team contributes to that order indirectly, and the contribution is real. Once you are on the safeguard route, what you discuss with a provider is not a general promise about security; it is which record travels, with which fields. An inventory is what makes that conversation possible. Without one, the conversation stays inside the provider’s own marketing text and cannot be tested from your side. Wherever you land in the order, the list in your hand is the same list, and it also tells you what to ask for: no extra document where the declaration already exists, a signable safeguard text where it does not, and a lawyer’s desk rather than a software decision where no safeguard can be built.
A server is not a single place: which part of the request crosses a border
A provider contract names one machine, and that address produces the sentence that feels like it closes the subject: our server is in Türkiye. The sentence may well be true about that machine. It is rarely true about the whole request. A single submission of a web form runs several independent steps, and each step calls its own address. What closes an inventory is the list of those steps.
The code behind our own quote form makes those lines visible. The bot-verification challenge is generated on our own server: a random salt and a random number are chosen, a digest is taken, and the result is signed with our own key, after which the browser searches for the number itself. Nothing leaves for an outside service at that step. When the solution comes back, the comparison happens on the same server, and the solution is single-use; the marker recording that it has been spent is written to a private directory closed to the internet. If that directory is missing or cannot be written, the request is refused rather than waved through. The inventory line stays empty, because there is no external address for it to point at.
Uploaded files sit in a private directory closed to the internet as well. The form code checks whether the target directory resolves to somewhere inside the web root, and if it does, it looks for a server rule that closes that directory to the internet; without one it refuses to run. Both directory and file are written with permissions only the application account can read. The rate counter follows the same pattern, kept in a directory that does not follow symbolic links, and the form stops if that store cannot be written. The submission itself is never written to a database; the fields go into the body of a single email. That inventory line opens as “wherever the mailbox is hosted”, and the place has to be asked about separately; where it is, your own inventory records. What this article says is that the line exists.
The shape generalises. Your inventory should carry verification, files and notifications as separate lines, because steps running inside one request can call different addresses. In the patient app of the health platform in our portfolio, the service that delivers notifications sits outside; we wrote about why a phone counts as its own surface in the comparison of a mobile app with a mobile website.
The same split applies to parts you did not write yourself. When a request leaves your code for an outside service, the line is written against whoever’s machine that service runs on. Whether such a line exists is something you read from the code rather than from a contract: where the request goes, who produces the answer, which fields travel in the body. That is why a team producing an inventory does not stop at the architecture diagram and reviews the calls themselves.
The address of a single machine can be perfectly accurate and still leave the inventory open. What closes it is writing a separate line for every service the request touches.
Some records raise the question, and some never raise it at all
The fastest way to produce an inventory is to stop treating your data as one bag. Inside the same system, some lines never raise the question this regime asks, some raise it squarely, and some become a line of their own because they leave for an outside service. The table below sets record types from our portfolio and from the code of our own quote form next to each other. The columns ask, in order: is the record tied to a person, which question arises if the server sits abroad, and who answers it. The last column is what makes the table useful; where the answer is “nobody”, that line never reaches your lawyer at all.
| Record | Tied to a person | Question if the server sits abroad | Who answers |
|---|---|---|---|
| Vehicle range and trim package information (content shown on the kiosk) | No: the content is the brand’s product information and takes nothing from the visitor | None; the country of the machine holding that content is not what this regime asks about | Nobody is asked; the software team shows the content carries no visitor data |
| A “who compared what” usage log (on the kiosk) | Never created: nothing in front of the screen asks who the visitor is, and no account exists | None; a record that does not exist has no country to go to | Settled when the screen was built; the software team states no such record exists and nothing reaches the lawyer |
| The test value a patient enters and the comment a physician writes (Tahlil.com) | Yes: it is written to the patient’s account, and the physician’s approval lands on the same record | Which country holds the machine behind the record store; is there an adequacy decision for it, and if not, which safeguard | The software team supplies the inventory (field, system, country); the source and your lawyer answer the regime question |
| The part of a request that leaves for an outside service: the device key and payload sent to a notification service. In our own quote form this line is empty, because bot verification never leaves our server | The key is matched to a specific patient’s record, since it is what delivers a notification to that patient | Where the notification service’s machine sits; what travels alongside the key, a bare “ready” ping or the text of a comment | The software team states the payload and the service’s address; whether the key ties to a person is your lawyer’s assessment |
The kiosk lines live on the same device and say different things. One says the content is not personal data; the other says the usage log is never created. Collapse them into a single line and the counter-pattern disappears: in some systems the question fails to arise not only because the content is innocent, but because no measurement record is ever created.
Filling the table in for your own system works the same way. Name your record types, write next to each whether it ties to a person, look up the country of the machine for the ones that do, and give every part that leaves for an outside service a line of its own. Keep the lines that come back empty. An empty line is written proof that the record never comes into existence, and it answers your lawyer before they have to ask.
Nothing about the visitor exists on the kiosk, so the first question of the regime is never asked
The first question of the regime assumes there is personal data available to transfer. In some systems that assumption never forms, and there is an architectural reason for it.
The KGM SsangYong showroom kiosk is the clearest example of this in our portfolio. The vehicle range and the trim packages live on a touchscreen the dealership owns. No step in front of the screen establishes who is standing there. There is no download step, no sign-up step, no field that collects personal data. No record about the visitor is ever created. The visitor line in the inventory stays empty, and an empty line here is not an omission; it is the result of a design decision taken when the screen was built.
The direction of the flow confirms it. What comes down to the device from outside is a content update: a new model, a changed trim list. Nothing about the visitor travels the other way. Even if the server were abroad, what moves in that direction is the brand’s own catalogue rather than the kind of record the regime asks about.
The decision replaced a habit inherited from paper. A printed catalogue asks nothing of the person holding it, and a screen taking over its job may or may not keep that restraint. We opened up which threshold was kept in the piece on moving printed catalogues and menus into software. The same choice has a measurement side to it: where no visitor record is created there is nothing left to measure either, and we wrote about that cost in the piece weighing which pre-sale steps can be made self-service. For this article the meaning is that one decision shows up in a measurement list and in an inventory at once.
This answer is one addition away from ending. Put a contact form on that screen and a visitor record is created, and the answer in this section ends. The question turns into the question of the next section, and the empty inventory line fills.
When the record is the service, what you need from the software team is an inventory
In some businesses never creating the record is not an option, because the record is the service.
Tahlil.com works exactly that way. A patient enters their own test values; a physician writes a comment and approves it. Remove those steps and there is no service left. So the server-abroad question genuinely arises here, and architecture offers no way around it. The software team’s job is to show the record completely.
What gets shown is called an inventory: which record is kept, with which fields, through which system or service it passes, and to a machine in which country it is written. One page, fixed columns. Your lawyer forms an opinion on top of that page, and where the page is incomplete the opinion is incomplete too. The inventory is not there to persuade anyone. It is there to make asking easier.
What shortens the inventory is an architectural decision. On Tahlil.com the record sits in a single record store; the value the patient enters and the comment the physician writes both land in the same place. However many separate surfaces feed it, the inventory carries one address. Had a second data model been built per surface, the same record type would split across several inventory lines, each of them queried separately, and the list your lawyer reads would grow. A decision about where records live does not look like a legal decision, and it still sets the length of a legal question.
The inventory has a line that starts out full as well. Notifications are targeted, so they pass through an outside service, and that service holds a device key matched to a patient’s record. The line brings its own questions: where the service’s machine sits, and what travels alongside the key. The answer about the payload comes from the software team, because the payload is in the code. Whether the key ties to a person is your lawyer’s assessment.
The list is not a document you produce once and file. Add a field, connect a new outside service, open another surface, and the corresponding line changes. If it never changes, the list is describing the system as it once was rather than the system you run.
This section gives no legal opinion either; what it does is produce the list a lawyer will ask for, before they ask for it. Where the record is mandatory, an architectural answer cannot remove it; the only thing it can do is make the record countable.
The decision is made while the record is designed, not while the server is chosen
The server-abroad decision usually gets discussed in a meeting about choosing a provider. That meeting is where the consequences are counted, not where the decision was made. The real decision was taken much earlier, while the record was being designed, and it is taken with one question: is this field genuinely necessary.
The extremes sit in the same portfolio. On the store screen no field about a visitor is collected, so no field has a country to be asked about. On the health platform the record is the service, so every field has one. The gap between them opened while the first data model was being drawn, not in a provider contract.
This is one of the parts of software that does not correct easily after the fact. Choosing to stop collecting a field, once you have started, does not end with deleting a box from a form; it reaches back over the records you already hold. We wrote about why these decisions come before the code in the piece on architecture coming first.
The working order is this: the list of records, then the list of fields, then which fields point at a person, and the country of the machine last. A team that works in that order arrives at a lawyer with the question already narrowed. A team working in reverse spends the weeks after signing with a provider establishing why it collects each field, and that work gets paid for after the contract is signed.
Which records have to exist at all is settled before any code is written; the system architecture page shows how those decisions get made.
