Standard contractual clauses and DPAs
SCCs for processing in third countries: choosing modules, understanding the DPA relationship and completing the details for software development.
A Transfer Impact Assessment (TIA) assesses whether a third-country transfer relying on an Article 46 GDPR instrument actually provides the required protection. The assessment considers data flows, relevant law and practice, and effective safeguards. The editable T-NEX template connects those findings with sources, unresolved questions and the reasoned decision.
Sources checked on 10 September 2026. This guide is for businesses outsourcing development or support that need a traceable assessment of data access. A TIA records the assessment of a particular transfer; it is not a general supplier certification.
Where a third-country transfer relies on an Article 46 GDPR instrument, such as standard contractual clauses, assess the required protection before the transfer. The exporter is responsible for the assessment with the importer’s assistance. Clause 14 specifies this task for SCC Modules 2 and 3, frequently relevant to outsourced development.
First establish whether a transfer exists and which basis applies. An applicable adequacy decision or a valid Article 49 derogation changes the assessment route; its conditions still need checking. A TIA also differs from an Article 35 data protection impact assessment, which concerns processing likely to create high risks. A project may need both assessments.
The T-NEX template is an editable Markdown file with questions, tables and open assessment fields. Save a project copy and record the actual parties, countries, systems and evidence for each data flow. Fields start empty; no positive country or project assessment is preset.
Open the file in a text editor and replace the entries in square brackets. Give sources and evidence identifiers so that the reasoning traces back to the version assessed. Keep unknown facts unresolved; explain why a question is not applicable.
For additional regulatory methodology, CNIL publishes a final guide and an adaptable ODS template. Its publication page is dated 9 July 2025; the guide itself is the January 2025 final version. CNIL’s method is optional and contains no completed country assessments.
Start with the actual data flow. A contracting party, a cloud account and an access location are different facts. Record the legal entities, their roles, storage locations and actual access, including further recipients. The aim is to reconcile the transfer description with the contractual annexes and technical permissions.
The following information helps establish the facts for a development project. Each statement should have evidence describing the actual state.
| Area | Fact to establish | Relevant evidence |
|---|---|---|
| Contracts and roles | Who is the controller, processor and any sub-processor? | Contracts and role allocation for each processing activity |
| Production system | Which entity can read or change which personal data? | Approved permission model and verified access |
| Test environment | Which data is copied, and what makes it synthetic, anonymous or pseudonymised? | Documented data origin and assessment of identifiability |
| Support and collaboration | What personal information appears in tickets, logs, screenshots or collaboration services? | Data inventory and actual service configuration |
| Countries and further recipients | Where is access made from, and which other entities receive data? | Confirmed access countries and complete recipient chain |
| End of processing and changes | When do access and retention end, and how are changes detected? | Deletion/return rules, access removal and change procedure |
A separate supplier in a third country may be an importer through remote access even when the data remains on an EEA server. However, the EDPB's criteria require a separate recipient. Its example of an employee of the same organisation accessing data during a business trip therefore does not itself constitute a Chapter V transfer.
Assess the legal relationship alongside actual permissions: an employee, an independent supplier and a different group company are distinct situations. A person’s location alone does not establish customer-data access. Even outside a transfer, processing in a third country can present risks requiring particular safeguards.
An importer can be directly subject to the GDPR under Article 3 for a processing activity and still receive a third-country transfer. Article 1 of the 2021/914 SCCs instead scopes those clauses to importers whose relevant processing is not already subject to the GDPR. Record this scope question explicitly before selecting a module.
Module 2 addresses controller-to-processor transfers; Module 3 addresses processor-to-processor transfers. Both incorporate Article 28 requirements. The separate 2021/915 clauses are not themselves a third-country transfer instrument. For Module 4, assess the particular condition governing Clause 14; the working template includes it.
The country assessment must address rules and practices relevant to the importer and data concerned. These include public-authority access powers, limits on those powers and available remedies. A general country profile or a data protection statute considered without access rules does not answer these questions.
Record the source, its legal status and its relevance to the facts. The importer's account of previous practice may contribute to the assessment; a general statement that it has never received a request cannot carry the conclusion by itself. Conflicting information and unresolved questions need to remain visible in the assessment.
A measure must address the identified problem. Encryption in transit protects a different operation from a design in which the importer cannot decrypt the information. Where a supplier needs plaintext and problematic public-authority access rules apply to the transfer, the EDPB identifies no effective technical supplementary measure for its described Use Cases 6 and 7 at the state of the art assessed in the recommendations.
Pseudonymisation is not automatic approval either. Its protective effect depends, among other things, on who holds additional information and whether the people concerned can be identified again using available means. Removing names alone is insufficient. A short retention period limits storage but does not remove access that has already been enabled.
Suppose a business engages a legally separate supplier outside the EEA. Development initially receives only newly generated test records without personal data. Later, someone proposes adding a production screenshot containing a customer's name to a support ticket.
The original statement about test data is no longer sufficient for that support activity. The screenshot data, entities with access, ticketing service and further recipients need assessment. The assessment needs to cover this additional support activity before the screenshot is made accessible.
A practical approach is to decide in advance how faults will be reproduced without personal production data and who assesses an exception. Evidence then comes from the implemented working process and its controls, rather than a sentence in the TIA alone.
The conclusion must explain whether the chosen instrument and implemented measures provide the required protection for the described circumstances. A planned measure must not be treated as already implemented. If the required protection cannot be achieved, the transfer must not begin or must be suspended.
Keep a traceable record of the version assessed, factual basis, remaining actions, responsible participants and decision. The technical implementation, contractual terms and legal assessment must refer to the same state. External assistance does not remove the participating entities' respective obligations.
| Finding | Required action |
|---|---|
| Facts or evidence material to the decision are missing. | Assign and resolve open issues; do not count planned measures as implemented protection. |
| The instrument and measures actually implemented ensure the required protection. | Record the assessed scope, supporting evidence and reasoned decision. |
| The required protection cannot be ensured for the transfer considered. | Do not start or suspend the transfer; change architecture, recipient or workflow and reassess. |
A TIA needs to be updated when relevant circumstances change. A new recipient, another access location, a different data category or a change in applicable law may require reassessment. Appropriate review intervals should also be set; an annual review is not a general statutory substitute for responding to specific changes.
Connect review to the actual change process. Anyone introducing another support service or additional permission needs to know when the people responsible for data protection and contracts must be involved. This keeps the transfer description connected to development operations.
Yes. After downloading the Markdown file, edit it in a text editor. Replace placeholders, add data flows and link your evidence. The template contains no preset approval or country assessment; the conclusion comes from the completed assessment.
No. It assesses the effectiveness of the transfer instrument in the particular circumstances. A TIA does not replace the required legal basis or appropriate instrument.
You can use it as a working structure. Project-specific facts, legal sources, measures and conclusions still need to be established and reviewed. The CNIL template does not contain a completed country assessment.
No. A TIA concerns protection in a third-country transfer. A DPIA under Article 35 GDPR concerns processing likely to create high risks. A project may need both.
A shared assessment can support transfers only where its facts and legal assumptions actually cover them. Different recipients, access countries or data flows must not silently be treated as covered by the same conclusion.
The exporter is responsible for the assessment with the importer’s assistance. Specialist, legal and technical contributors provide the required assessments and evidence. The project needs a clear decision-maker for the described transfer and an escalation route for changes or insufficient protection.
SCCs for processing in third countries: choosing modules, understanding the DPA relationship and completing the details for software development.
Commission external software development with clear goals, data responsibilities, roles, acceptance criteria, handover and ongoing operational support.
Distributed software development with T-NEX: agree scope, collaboration and handover in advance, with costs considered across the full engagement.
Explore serviceT-NEX develops business applications and extends existing systems, from clickable prototypes and integrations to agreed handover and support.
Explore serviceBring a concrete task. Together, we will define what the application needs to do.
Discuss data access in a development project