When cloud email analysis becomes a cross-border transfer: GDPR Chapter V and KVKK Article 9

A compliance tool that analyses email in the cloud does something most buyers do not immediately register as a regulated act: it takes the content of a message, which is personal data and often concerns a third party, and sends it to wherever the analysis runs. If that destination is in another country, the organisation has just made a cross-border transfer of personal data, and both the GDPR and, for Turkish organisations, the KVKK treat that as its own regulated event with its own conditions. The detection quality of the tool is irrelevant until that transfer question is answered.

This is the mechanism behind the deployment decision, and it is worth understanding in its own right, because it is the thing a security review turns on and the thing a vague vendor answer cannot survive.

What counts as a transfer, and when it is triggered

The transfer is not the storage, it is the movement. The moment the message content leaves the controller’s jurisdiction to be processed elsewhere, the transfer has occurred, whether or not anything is retained afterward. An analysis that runs for two seconds and keeps nothing has still transferred the data for those two seconds. This catches teams who assume that “we do not store it” closes the question. It does not; it answers retention, not transfer.

So the first thing to establish about a cloud compliance tool is geographic: where does the processing physically happen, and does any sub-processor sit outside your jurisdiction. If the answer is “inside the EU” and you are an EU controller, there is no third-country transfer to manage. If the answer is “outside the EU”, or “inside the EU but a US-owned sub-processor may access it”, Chapter V is in play.

The GDPR mechanism: Chapter V

Under the GDPR, transfers of personal data to a third country are governed by Chapter V. Article 44 sets the general principle: such a transfer may only take place if the conditions of the chapter are met, and the level of protection guaranteed by the Regulation must not be undermined. From there, the lawful routes are, in order of simplicity:

• An adequacy decision (Article 45). If the European Commission has decided the destination country offers adequate protection, the transfer can proceed as if it were within the EU. This is the cleanest route, and it exists for a limited set of countries.
• Appropriate safeguards (Article 46). Where there is no adequacy decision, the transfer needs a safeguard such as standard contractual clauses, the clauses the Commission has approved for exactly this purpose, or binding corporate rules for intra-group transfers.
• Derogations (Article 49). Narrow, specific-situation exceptions, such as explicit consent for a specific transfer. These are meant for occasional cases, not as the standing basis for routing all your email through another country.

For a cloud compliance tool, the practical path when processing happens outside the EU is almost always Article 46 standard contractual clauses, plus a transfer impact assessment. That is manageable, and many firms do it routinely. It is also precisely the paperwork that some organisations are not permitted to rely on, which is where deployment, not contracts, becomes the answer.

The Turkish mechanism: KVKK Article 9

For a Turkish organisation the parallel is Article 9 of the KVKK, which governs the transfer of personal data abroad. Following the 2024 amendment that brought the regime closer to the GDPR, transfer abroad can rest on an adequacy determination, or on appropriate safeguards including a standard contract between the parties, with a duty to notify the Authority of that standard contract within the period the regulation sets. Explicit consent remains a route for one-off transfers but is a weak basis for continuous processing, and in an employment context it is weaker still, because consent given by an employee to an employer is rarely free.

The important operational point for a Turkish firm, a bank in particular, is that running message analysis in a foreign cloud is a transfer under Article 9 that has to be papered and notified. It is not covered by a generic data processing agreement that never mentions cross-border transfer. A vendor who says “we are GDPR compliant” has not answered the KVKK question, and signing as if they had is the mistake.

The “EU region, US-owned” trap

The most common place this goes wrong is subtler than offshore processing. A vendor says the data is processed in an EU region, which sounds like the clean “no transfer” case, but the infrastructure or the vendor is US-owned, and a US parent can be subject to disclosure obligations that reach data held by its subsidiaries. Since the Schrems II ruling invalidated the previous EU-US framework, this scenario has forced controllers to look past the region label and ask who can actually compel access to the data, not just where the server sits.

The practical check is two questions, not one. Where is the data processed, and who, by ownership or law, could be compelled to hand it over. An EU region operated by a vendor exposed to foreign disclosure law is not the same risk as an EU region operated by an EU entity, even though both say “processed in the EU”. For a bank or a public body this distinction is often decisive, and it is another reason the firms with the strictest requirements end up wanting the model inside their own network, where the question of who else could compel access does not arise.

A short decision table

The last row is the one that ends the paperwork conversation. For organisations on that line, the only compliant answer is to not transfer: process inside the jurisdiction, or inside the network. The transfer rules are a way to make a transfer lawful; they are not a way to make a prohibited transfer happen.

Where deployment comes in

This is why the same compliance check exists in more than one deployment edition. For a firm that can transfer with safeguards, the cloud edition, processing in the EU with content not retained, answers the question and the Chapter V work is light or unnecessary. For a firm that cannot transfer at all, no clause helps, and the model has to run where the data already is, in their own network. The regulation determines which edition is even available to you, before anyone discusses features.

Where the pre-send check fits

VerbaPulse is a pre-send check for accidental risk: it reads a draft before it is sent and returns the sentences that create legal exposure. The transfer analysis above is not about what it detects, it is about where the detection runs, and the editions exist so that a firm facing a hard transfer limit can still use the check without breaching Article 9 or Chapter V. It complements archiving and supervision and is not an adversarial boundary.

The takeaway

Before you sign for any cloud tool that reads communications, answer two questions in writing: where does the content get processed, and is a transfer to that place lawful for us. If you are an EU controller processing in the EU, you are clear. If processing is abroad, you need an Article 46 safeguard, or an Article 9 standard contract and notification for a Turkish controller, and you need it named in the contract, not assumed from a GDPR badge. And if the honest answer is that no transfer is permitted, stop evaluating cloud tools on that requirement and move the conversation to a deployment where the data never leaves.