Skip to content
Back to Deliverable Templates
Transfer assessmentEuropean UnionUnited KingdomChina (Mainland)All industriesGenAI & foundation modelsEnterprise SaaSAI agents

Transfer Impact Assessment (TIA) — supporting Clause 14 of the EU Standard Contractual Clauses

Completed before transferring personal data to a third country under a Chapter V Art. 46 tool — in practice the (EU) 2021/914 standard contractual clauses — to support the warranty in Clause 14(a) and to satisfy Clause 14(d), under which the parties agree to document the assessment and make it available to the competent supervisory authority on request. For companies moving EU personal data to China, or giving China-based teams remote access to EU data, this is the document EU customers almost always ask for; vague drafting stalls deals, while a solid version can be reused across customers. The structure crosses the three elements of Clause 14(b) with the six steps of EDPB Recommendations 01/2020.

Audience: The EU data exporter and its DPO, EU supervisory authorities, customers’ privacy and procurement teams, and the internal transfer-approval committee.

Verified against official sources · 2026-09-12Verified against official text
Download Markdown skeleton

Obligations this document answers

Structure (9 sections)

  1. 1. 1. Know your transfers: map every flow (Step 1)

    Step 1 of EDPB Recommendations 01/2020 is "know your transfers". The output here is a transfer inventory, one row per flow, with: flow id; exporter and importer entities; importer’s country; data categories and categories of data subject; purpose; mode (copied transfer / stored locally but remotely accessible / remote support access / backup and disaster recovery / logs and telemetry); volume and frequency; retention; and whether onward transfers occur and to whom. Two kinds of flow are missed most often: remote access by support and operations staff, which creates no copy but is still a transfer; and observability flows — logs, crash reports, inference records. Confirm one baseline here too: that the data transferred is necessary and minimised. Set out the trimming already done to reduce it (field removal, aggregation, pseudonymisation), because the risk conclusion later turns heavily on what is actually being sent.

    Evidence to attach

    • · Transfer inventory with the fields above, using flow ids the later sections can cite
    • · Data-flow diagram marking the border and the direction of access
    • · The corresponding transfer entries in the Art. 30 records
    • · Minimisation measures with a before/after field comparison
    • · Inventory of remote-access accounts and a sample of access logs

    Common pitfalls

    • · Counting only copied transfers and excluding remote access and ad-hoc troubleshooting access;
    • · Leaving out logs and telemetry, which often carry raw user input;
    • · An empty onward-transfer column, so the chain breaks at the first hop;
    • · An inventory with no ids, so later sections cannot cite specific flows and review stays at the level of generalities.
  2. 2. 2. Identify the transfer tool relied on (Step 2)

    Step 2 confirms which Chapter V tool each flow relies on: an Art. 45 adequacy decision, an Art. 46 appropriate safeguard (standard contractual clauses, binding corporate rules, an approved code of conduct or certification mechanism), or an Art. 49 derogation. If the destination is covered by an adequacy decision and this transfer falls within its scope — noting that scope can be narrow, for example limited to entities certified under a particular framework — the Step 3 legal-environment assessment is not needed. If relying on an Art. 49 derogation, remember it is exceptional and generally unsuited to regular or large-scale transfers. Most Chinese companies are on the SCC route, so record: which module or modules apply (Module One controller-to-controller, Module Two controller-to-processor, Module Three processor-to-processor, Module Four processor-to-controller); the signing entities and dates; whether Annex I (the parties, the description of transfer, the competent supervisory authority) and Annex II (technical and organisational measures) are filled in to reflect reality; and whether the docking clause was used to add parties.

    Evidence to attach

    • · Determination table mapping each flow id to its tool and the basis
    • · The executed SCCs in full, with Annexes I–III
    • · Reasoning for the module chosen, based on the role determination
    • · Where adequacy is relied on: a scope check confirming the importer is covered
    • · Where an Art. 49 derogation is relied on: written justification and why it is exceptional

    Common pitfalls

    • · Choosing the wrong module — signing controller-to-processor for what is processor-to-processor — which misallocates every obligation in the set;
    • · Annex II copied from the sample, inconsistent with the measures actually deployed, which undercuts the Clause 14(b)(iii) assessment;
    • · Using Art. 49(1)(a) explicit consent as the standing basis for regular, large-scale transfers;
    • · New group entities never added via the docking clause, leaving real transfers outside any contract.
  3. 3. 3. The specific circumstances of the transfer (Clause 14(b)(i))

    Clause 14(b)(i) enumerates the specific circumstances the parties must take due account of when giving the Clause 14(a) warranty: the length of the processing chain, the number of actors involved and the transmission channels used; intended onward transfers; the type of recipient; the purpose of processing; the categories and format of the transferred personal data; the economic sector in which the transfer occurs; and the storage location of the data transferred. Write each one concretely rather than summarising. "Format" is often skipped but matters: plaintext, ciphertext (and where the key sits), hashes, pseudonymous identifiers or aggregated statistics each change how strong the legal-environment conclusion can be. "Economic sector" has substance too: some sectors — telecoms, finance, critical infrastructure — attract additional government-access requirements in the destination country. Give the storage location down to country and availability zone, and say whether cross-region replication or disaster-recovery copies exist.

    Evidence to attach

    • · A table answering each of the seven Clause 14(b)(i) elements
    • · Data-format description (encryption scheme, where keys are held, pseudonymisation method)
    • · Evidence of storage location (cloud region configuration screenshots, region commitments in the contract)
    • · List of onward recipients and their countries
    • · Processing-chain diagram showing every hop, its actor and its channel

    Common pitfalls

    • · Saying "the data is encrypted" without saying who holds the keys — if the keys travel with the data, encryption does little against government access;
    • · Giving only the cloud provider’s name without the region, so the actual country of landing cannot be determined;
    • · Ignoring the disaster-recovery region, which is frequently in a different jurisdiction;
    • · Describing the recipient type as "a partner", without saying whether destination law might classify it as, for example, an electronic communications service provider.
  4. 4. 4. Assessment of destination-country laws and practices (Clause 14(b)(ii) / Step 3)

    Clause 14(b)(ii) requires account to be taken of the laws and practices of the third country of destination — including those requiring disclosure to public authorities or authorising access by them — as relevant in light of the specific circumstances of the transfer, together with the applicable limitations and safeguards. Clause 14(a) supplies the benchmark: laws and practices that respect the essence of fundamental rights and freedoms and do not exceed what is necessary and proportionate in a democratic society to safeguard one of the objectives in Art. 23(1) GDPR are not in contradiction with the Clauses. So this section is not a survey of destination law but an assessment of the access powers **relevant to this transfer**: name the specific provisions, the entities they reach (do they cover this importer’s line of business), the data they can obtain, whether judicial authorisation is required, whether notification and redress exist, and how they are applied in practice (published statistics, transparency reports, known cases). When assessing Chinese law, cover at least Art. 36 of the Data Security Law — under which data stored within China may not be provided to foreign judicial or law-enforcement authorities without approval from the competent authority, a blocking provision that works in the exporter’s favour — as well as the security and criminal-procedure laws that may compel cooperation, and state expressly why any provision does not apply to your business. Where no empirical evidence exists, label it "no public information" and raise the uncertainty accordingly rather than filling the gap with speculation.

    Evidence to attach

    • · Verbatim citations of the relevant destination-country provisions, with official source links
    • · Applicability analysis: does this importer fall within the scope of each provision
    • · Historical statistics or transparency reporting on government access requests, where publishable
    • · Local legal opinion, if obtained, naming the firm and the date
    • · A list of "no public information" items and how each affects the conclusion

    Common pitfalls

    • · Listing destination-country statutes wholesale while never answering whether they apply to this importer;
    • · Citing only the favourable provisions (the blocking rule) and avoiding those that may compel cooperation, which destroys the conclusion’s credibility;
    • · Substituting "it is understood that" and "the industry generally considers" for citations;
    • · Concluding "risk acceptable" with no empirical material anywhere in the document;
    • · Assessing once and never updating, while destination law and practice keep moving.
  5. 5. 5. Handling public-authority access requests (Clause 15)

    Clause 15 of the SCCs sets out the importer’s obligations on public-authority access, and this section turns them into an executable internal process. Clause 15.1 requires the importer to notify the exporter promptly, and where possible the data subject, if it receives a legally binding request from a public authority, including judicial authorities, under destination-country law for disclosure of personal data transferred under the Clauses, or becomes aware of any direct access by public authorities to such data; the notification is to include the personal data requested, the requesting authority, the legal basis for the request and the response provided. Where destination-country law prohibits notification, the importer agrees to use its best efforts to obtain a waiver so as to communicate as much information as possible as soon as possible, and to document those efforts so it can demonstrate them on request. So far as destination-country law permits, the importer agrees to provide the exporter, at regular intervals over the contract, with as much relevant information as possible on the requests received — in particular the number of requests, the type of data requested, the requesting authorities, whether requests were challenged and the outcome. Clause 15.2 requires the importer to review the legality of the disclosure request, in particular whether it remains within the powers granted to the requesting authority, and to challenge it where, after careful assessment, it concludes there are reasonable grounds to consider it unlawful under destination-country law, applicable obligations under international law and principles of international comity; under the same conditions it must pursue possibilities of appeal; when challenging, it must seek interim measures to suspend the effects of the request until a competent judicial authority decides on the merits; and it must not disclose the requested personal data until required to do so under the applicable procedural rules. Two further Clause 15.2 requirements are routinely missed: (b) the importer agrees to document its legal assessment and any challenge and, so far as destination-country law permits, make that documentation available to the exporter and, on request, to the competent supervisory authority; and (c) when responding to a disclosure request, the importer agrees to provide the minimum amount of information permissible on a reasonable interpretation of the request — turn that into a concrete step in the process: who narrows the response, against what criteria, and who reviews and records the result. Chinese companies must also embed the Art. 36 Data Security Law approval step: approval from the competent authority is required before providing data stored in China to a foreign judicial or law-enforcement authority, and that step belongs in the process with its own timeline.

    Evidence to attach

    • · SOP for handling access requests: intake, review, challenge, notification and approval, each with an owner and a deadline
    • · Notification template covering the four items required by Clause 15.1(a)
    • · Template and past records of "best efforts to obtain a waiver" where notification is prohibited
    • · Arrangements for legal support on legality review and challenge, in-house or external
    • · The Art. 36 Data Security Law approval process and the department to approach
    • · Template for the periodic request statistics under Clause 15.1(c)
    • · Criteria for narrowing a disclosure to the minimum permissible, and the record of each narrowing (Clause 15.2(c))
    • · Where the legal assessment and challenge documentation is kept, and how it reaches the exporter (Clause 15.2(b))

    Common pitfalls

    • · A process that stops at "escalate to legal", with no concrete steps on challenge, interim measures or withholding disclosure;
    • · No notification template prepared, leaving it to be drafted under time pressure when a request actually lands;
    • · Reading Art. 36 of the Data Security Law as "we cannot provide it" and never designing the lawful approval route;
    • · Periodic statistics never produced, so the standing Clause 15.1(c) duty goes unperformed;
    • · No trace of the "best efforts to obtain a waiver", which cannot then be demonstrated to the exporter.
  6. 6. 6. Supplementary measures (Clause 14(b)(iii) / Step 4)

    Clause 14(b)(iii) requires account to be taken of any relevant contractual, technical or organisational safeguards put in place to supplement the safeguards under the Clauses, including measures applied during transmission and to the processing of the personal data in the country of destination; Step 4 of EDPB Recommendations 01/2020 sets out types of supplementary measure and their scenarios, and says expressly that the list is not exhaustive. Organise the section in three groups: technical measures (strong encryption in transit and at rest with keys held by the exporter inside the EU and no plaintext access for the importer; split processing; pseudonymisation with the additional information needed for re-identification retained in the EU; edge processing returning only aggregates; secure multi-party computation); contractual measures (transparency and notification commitments, commitments to challenge, audit rights, express prohibition on back doors and voluntary cooperation, disclosure of request statistics, remedies and rights to suspend or terminate); and organisational measures (internal access approval and least privilege, a mandatory escalation path for government requests, personnel vetting and confidentiality, periodic internal audit with reporting to the exporter, incident-response drills). The critical step is assessing, measure by measure, whether it actually blocks the specific access risk identified in section 4: contractual and organisational measures alone cannot stop a lawful compelled access, so explain how they combine with technical measures. If the conclusion is that no measure effectively blocks the risk on a given flow, say so and carry it into section 7.

    Evidence to attach

    • · Supplementary-measures table: measure, the specific access risk it addresses, the effectiveness argument, and how it is verified
    • · Encryption design and key-management architecture, including where keys sit and who can use them
    • · Pseudonymisation design and technical proof that the additional information is segregated
    • · The text of the supplementary contractual clauses, executed with the SCCs or as a side agreement
    • · Evidence that the organisational measures run (access approvals, internal audit reports, drill records)
    • · Independent verification of effectiveness (penetration testing, third-party audit, code review)

    Common pitfalls

    • · A long measures list where nothing maps to a specific access risk from section 4;
    • · "The data is encrypted" as a universal answer, without saying whether the importer must decrypt to process — in most business cases it must, so encryption does not block access;
    • · Concluding "risk effectively mitigated" on contractual and organisational measures alone, with no technical measure;
    • · Measures on paper that have never been verified, which a reviewer cannot accept;
    • · Counting measures that operate only on the exporter’s side as mitigation of destination-side risk.
  7. 7. 7. Conclusion and procedural steps (Step 5)

    State a clear conclusion per flow, choosing among three: the transfer may continue under the existing safeguards; the transfer may proceed only once specified supplementary measures are in place (list them with owners and deadlines); or equivalent protection cannot be ensured, so the transfer must not begin or an existing transfer must be suspended. Conclusions must attach to flow ids, not to the document as a whole. Record the procedural points too: supplementary measures that contradict the Clauses, or directly or indirectly breach them, or lower the level of protection they provide, must not be adopted; and if the Clauses need to be amended beyond completing the annexes, assess whether they thereby cease to be the standard contractual clauses unchanged within the meaning of Art. 46(2)(c), which may require supervisory-authority authorisation under Art. 46(3)(a). Close with the approval: who approved, in what role, on what date, which flows it covers and for how long. Clause 14(f) sets out what follows: after a Clause 14(e) notification, or where the exporter otherwise has reason to believe the importer can no longer fulfil its obligations, the exporter must promptly identify appropriate measures to address the situation, must suspend the transfer if it considers that no appropriate safeguards can be ensured or if instructed by the competent supervisory authority, and may terminate the contract insofar as it concerns the processing of personal data under the Clauses.

    Evidence to attach

    • · Conclusion table by flow id (conclusion, preconditions, validity period)
    • · Action plan for outstanding supplementary measures (measure, owner, deadline, acceptance criterion)
    • · Decision record for suspending or terminating a transfer, where applicable
    • · Approval record (signatory, role, date, scope)
    • · Where the Clauses are amended beyond the annexes: the authorisation analysis and any regulator correspondence

    Common pitfalls

    • · A single line of "risk assessed as acceptable overall", with no per-flow conclusions;
    • · A conclusion resting on supplementary measures not yet implemented, while the transfer has already started;
    • · Substantively amending the Clauses (narrowing audit rights, weakening notification) without assessing loss of Art. 46(2)(c) status;
    • · An approver without the authority to carry the risk;
    • · No validity period, so the assessment is treated as valid indefinitely.
  8. 8. 8. Documentation and availability to the supervisory authority (Clause 14(d))

    Clause 14(d) is explicit: the parties agree to document the assessment under Clause 14(b) and make it available to the competent supervisory authority on request. "The parties" means the importer participates and retains a copy too — Clause 14(c) has the importer warrant that, in carrying out the Clause 14(b) assessment, it has made its best efforts to provide the exporter with relevant information and agrees to continue cooperating in ensuring compliance. So record: who holds the assessment and where (a copy each at exporter and importer), the format and retention period, version control, and the process and turnaround for producing it to an authority. Prepare a shareable version as well: the full document may contain trade secrets and security-sensitive detail, so a redacted version is usually what goes to customers — but redaction must not remove the conclusion or the key reasoning, or diligence will simply demand the full text. Agree the redaction rules with legal in advance rather than re-cutting the document for every customer enquiry.

    Evidence to attach

    • · Where the assessment is stored and who may access it, at exporter and importer alike
    • · Version history (version, date, change summary, approver)
    • · Authority-request response process and named contact
    • · The shareable version and the redaction rules behind it
    • · Records of the importer supplying information under Clause 14(c)

    Common pitfalls

    • · Only the exporter holding the assessment while the importer has never seen it, making the Clause 14(c) cooperation duty hollow;
    • · No shareable version, so diligence gets either the full text with sensitive detail or a refusal that stalls the deal;
    • · Over-redaction that removes the conclusion and reasoning, which customers treat as no disclosure at all;
    • · No version control, so different customers hold versions that contradict each other.
  9. 9. 9. Re-evaluation triggers and ongoing monitoring (Clauses 14(e)–(f) / Step 6)

    Step 6 of EDPB Recommendations 01/2020 requires re-evaluation at appropriate intervals, and Clause 14(e) turns the most important trigger into a contractual duty: the importer agrees to notify the exporter promptly if, after agreeing to the Clauses and for the duration of the contract, it has reason to believe it is or has become subject to laws or practices not in line with Clause 14(a) — including following a change in third-country law or a measure such as a disclosure request indicating an application of such laws in practice that is not in line with Clause 14(a); under Module Three the exporter forwards the notification to the controller. Turn this into a trigger list with a named monitor: changes in destination-country legislation or judicial interpretation; the importer’s first disclosure request or a change in the nature of requests; a material change in the importer’s control or scope of business; a change in the categories, scale or purpose of the data transferred; falsification of a supplementary measure’s effectiveness (a penetration test finding a bypass); and new guidance or decisions from supervisory authorities. Each re-evaluation records the trigger, what changed, whether the conclusion moved, and whether supplementary measures must be adjusted or the transfer suspended. Set the interval at no less than annually and put it in the calendar — "re-evaluate when something changes" means, in practice, never re-evaluating.

    Evidence to attach

    • · Trigger list with a named monitor for each
    • · The scheduled re-evaluation calendar and the most recent record
    • · Any Clause 14(e) notifications received from the importer
    • · The sources monitored for destination-country legal change
    • · Records of measures adjusted or transfers suspended following a re-evaluation

    Common pitfalls

    • · Writing Clause 14(e) into the contract but never telling the importer’s operational teams, so nobody there knows the duty exists;
    • · An interval of "as needed", which turns out to be three years untouched;
    • · The importer receiving its first disclosure request without notifying, with the exporter learning of it during a customer audit;
    • · A trigger list covering legal change only, ignoring changes on your own side such as growing volumes or expanded purposes.

Related standards

  • ISO/IEC 27701:2025 Privacy information management systems — Requirements and guidance · ISO/IEC 27701:2025 (edition 2, 2025-10), cancelling and replacing ISO/IEC 27701:2019
  • ISO/IEC 27001:2022 Information security management systems — Requirements · ISO/IEC 27001:2022 (edition 3, 2022-10); European adoption EN ISO/IEC 27001:2023, including Amendment A1:2024

Sources (5)

Content as of 2026-09-12 · corpus 2026.09|Compiled from public official sources with links and review dates for compliance decision support. Rules change; have licensed professionals review before external disclosure, regulatory filing or contractual commitments.

GDPR · PIPL · CCPA control mapping
Traceable AI · cited when sourced
ISO 27001 alignment in progress
WCAG 2.1 AA accessibility target
Transfer Impact Assessment (TIA) — supporting Clause 14 of the EU Standard Contractual Clauses · Deliverable template | HaiWen HQ