Third-country transfer with SCCs and a TIA: what businesses must document

A third-country transfer based on standard contractual clauses is only properly documented when the business has assessed the specific data flow, the applicable module and the actual access risks. Signing an SCC document does not replace choosing the correct module or checking whether public-authority access in the recipient country can be effectively limited.

This article is for businesses that transfer personal data from Austria or another EEA country to a third country, or make data available to a service provider there. It focuses on the transfer scope, the transfer impact assessment, technical and organisational supplementary measures and the evidence that should be connected across the records of processing, supplier file and ongoing review.

Chapter V GDPR applies where personal data are transferred from the EEA to a recipient in a third country or made available there for that recipient. The production database location is not the only relevant fact. A support team, remote administration account or subprocessor outside the EEA may also create a relevant data flow.

Article 44 GDPR requires the level of protection under the Regulation not to be undermined by the transfer. Standard contractual clauses are one safeguard under Article 46 GDPR. They operate within their scope and alongside the other GDPR duties. Roles, purposes, data categories and recipients should therefore be clear before the clauses are selected.

The records of processing should not hide the transfer in a single country field. Map the processing activity, exporter, importer, subprocessors, transfer route, safeguard, SCC module and supplementary measures. This makes it possible to explain which review belongs to which data flow.

Commission Implementing Decision (EU) 2021/914 contains a modular set of standard contractual clauses. The selection depends on who exports and who imports: controller to controller, controller to processor, processor to processor or processor to controller. The business should assess the role for the specific activity rather than relying on the provider’s commercial label.

The clauses include the description of the transfer and the technical and organisational measures. Annex I should explain data categories, data subjects, purposes, frequency, duration and recipients. Annex II should not merely refer to a general security brochure where access restrictions, encryption or deletion processes are important.

A provider chain must also show subprocessors and further recipients. An agreement with the immediate vendor does not automatically reveal who can access data in support, hosting, backup or security operations. The overview of processors and service providers helps with the underlying role and contract review.

A TIA does not ask only whether a country appears on an internal list. It examines the specific transfer, the laws in the recipient country and how those laws operate in practice. This includes possible public-authority access, powers and procedures, available remedies, the type of data, the purpose of access and the likelihood that the importer will actually be required to disclose data.

Start with facts. What data are transferred? Are they processed in clear text? Who can read, administer or restore them from backups? Is support provided from the third country, and can the vendor log and limit access? Then relate the law and practice of the recipient country to that precise data flow.

The conclusion should not simply say “SCCs in place”. Record whether the clauses and supplementary measures together provide an essentially equivalent level of protection, which assumptions apply and whether open points limit the transfer. If the level cannot be reached, the business must suspend, redesign or replace the transfer arrangement.

Supplementary measures must match the risk. End-to-end encryption can be particularly effective where the importer cannot access the keys. Pseudonymisation may help where the re-identification key remains separate and securely controlled by the exporter. Role-based access, separate administrator accounts, logging, short-lived permissions and controlled support can further reduce access routes.

The measure must work in practice. Check who manages keys, whether an emergency process can force access, which metadata appear in logs and backups and whether support personnel can reverse pseudonymisation. Contractual assurances alone do not always prevent access required by the law of the recipient country. They can complement technical and organisational measures, but do not replace testing their effectiveness.

The processor checklist provides a starting point for responsibilities, access, subprocessors and evidence. The role check helps with the role allocation. Neither replaces the transfer assessment, but both help organise the information it needs.

The supplier file should contain the agreement, selected SCC module, completed annexes, current recipient and subprocessor list and the TIA. Add the data-flow description, risk assessment, decision on supplementary measures and the person responsible for the processing.

The TIA should match the records of processing and the privacy information. If the privacy notice describes an EEA location but the vendor permits support from a third country, there is a gap that needs to be resolved. The same applies where the contract states a short retention period while backups remain accessible for substantially longer.

Also record a decision not to transfer or not to use a particular provider where it is part of risk management. The evidence need not preserve every internal discussion. It should show which facts were checked, which measures were selected and when the decision will be reviewed. The Austrian Data Protection Authority emphasises, in the context of accountability, that controllers must be able to demonstrate their organisational and technical measures in a traceable way.

A transfer does not stay unchanged because the contract has been signed. New subprocessors, a different support model, an additional analytics feature or a new data location may change the core risk. Define review triggers and assign responsibility for following them.

When a service changes, update the data flow first. Then check whether the SCC annexes, TIA, privacy notice, records of processing and technical configuration still match. A periodic review may be sensible, but it does not replace an event-driven assessment after a material change.

If the clauses or measures are no longer sufficient, the business must act. Options include redesigning the technology, restricting support, moving the processing into the EEA, changing provider or suspending the affected flow. An open risk note without an owner is not a lasting solution.

Checking only the server location: Remote access, support, backups and subprocessors remain outside the assessment even though they may determine actual access.

Filing an unchanged SCC template: The module, parties and annexes do not match the factual roles or contain no useful description of data and measures.

Treating the TIA as a vendor statement: A promise to comply with the law does not replace an assessment of law, practice, access and effective safeguards.

Claiming encryption without testing it: Nobody checks who controls the keys, which metadata remain readable or whether the vendor can access plaintext during support.

Ending the review at signature: Changes in subprocessors, product functions or public-authority practice never reach the transfer file.

Start with one transfer map for one processing activity. Record exporter, importer, roles, data, data subjects, purposes, systems, access points, subprocessors and the actual route. Then mark the relevant SCC module and supplementary measures.

Keep the legal and practical assessments distinct but tied to the same facts. Record sources, facts, assumptions, risk assessment and conclusion in a traceable order. A later review can then see whether the decision still rests on the current data flow.

Finally, create an ongoing process: an owner, provider-change notification, review trigger, technical check and decision path for a new risk. The privacy compliance and governance section explains how to embed these responsibilities in a business privacy system.

We can review the specific data flow, roles, SCC module, annexes and supplementary measures with you. This includes support access, subprocessors, legal context, the TIA and ongoing review in one coherent file. Contact us with the agreement, provider overview or existing transfer file so that open points can be addressed clearly.