The TIA template referenced from the Cross-Border Transfers procedure. Used by the General Counsel (Privacy Officer) before any new export of personal data outside the EEA / UK / Switzerland, and re-reviewed every 24 months or upon a material change in the recipient country’s legal regime.
Purpose. The TIA is a documented assessment supporting the conclusion that a transfer mechanism (SCCs, IDTA, BCRs, or DPF) provides a level of protection essentially equivalent to the EEA, in light of the laws and practices of the recipient country and any supplementary measures Neuroscale has put in place. Required by Schrems II (CJEU C-311/18) and EDPB Recommendations 01/2020.
How to fill in this template
Replace each {{placeholder}} with the specific facts. Save the completed TIA to the DPIA Register project in Linear (the same register hosts TIAs as a sub-type) and link it from the relevant DPA.
Section 1 — Transfer description
| Field | Value |
|---|
| Transfer reference ID | {{tia_id}} (matches the DPA / register entry) |
| Date of assessment | {{date}} |
| Owner | General Counsel (Privacy Officer) |
| Reviewers | CISO; product / data owner; outside counsel where relevant |
| Transfer mechanism | {{SCC Module 1/2/3/4 | UK IDTA | Swiss SCC Addendum | DPF | BCRs | Article 49 derogation}} |
| Data exporter | NEUROSCALE LLC (controller / processor — specify) |
| Data importer | {{importer_legal_name}}, located in {{country}} |
| Importer role | {{processor | sub-processor | controller | joint controller}} |
| Categories of data subjects | {{e.g., customers, end users of customers, employees}} |
| Categories of personal data | {{e.g., contact data, account credentials, content of communications, sensitive data — specify}} |
| Special-category data? | {{none | other — specify}} |
| Volume / frequency | {{one-off | continuous | periodic}}; estimated {{records / month}} |
| Purpose of the transfer | {{description}} |
Section 2 — Recipient-country law assessment
For the recipient country ({{country}}), assess:
- Surveillance and government-access laws — what laws permit public-authority access to data held by the importer? Cite specific statutes and any judicial decisions limiting their scope. Include FISA 702 / Executive Order 12333 (US), the Investigatory Powers Act 2016 (UK), and equivalents.
- Onward-transfer regime — what laws govern further transfers from the importer to other third parties or other jurisdictions?
- Data-subject redress — what avenues are available to EEA / UK / Swiss data subjects to challenge surveillance or seek remedies (judicial, administrative, ombudsperson)?
- Adequacy decisions — does the European Commission, the UK ICO, or the Swiss FDPIC consider the country adequate? In whole or in part (e.g., DPF for the US)?
- Practical considerations — is the importer subject to the laws above (e.g., is it an “electronic communication service provider” under FISA 702)? Has it received a government data-access request in the past three years that it can lawfully disclose?
Cite primary sources. The EDPB has published reference materials; outside counsel should be engaged for any non-trivial jurisdiction.
Section 3 — Risk assessment
| Risk vector | Likelihood | Severity | Notes |
|---|
| Government-access request (lawful) | {{low | medium | high}} | {{low | medium | high}} | {{rationale, citing Section 2}} |
| Government-access request (unlawful / extraterritorial) | {{...}} | {{...}} | {{...}} |
| Importer compelled to weaken security or disclose keys | {{...}} | {{...}} | {{...}} |
| Onward transfer without adequate safeguards | {{...}} | {{...}} | {{...}} |
| Insufficient redress for affected data subjects | {{...}} | {{...}} | {{...}} |
{{Low | Medium | High}}
Section 4 — Supplementary measures
Per EDPB Recommendations 01/2020, document the supplementary measures that, taken together with the transfer mechanism, bring the level of protection up to the EEA standard.
Technical measures
{{Encryption in transit (TLS 1.2+) and at rest (AES-256 / KMS) — Neuroscale-managed keys not accessible to the importer.}}{{End-to-end encryption with customer-held keys for high-sensitivity data.}}{{Pseudonymization or tokenization where reversible identifiability is not needed.}}{{Split-processing — importer receives only ciphertext or aggregates.}}
Contractual measures
{{Importer commits to challenge any disproportionate or unlawful government access request.}}{{Importer commits to publish a transparency report and notify the exporter of any request, where lawful.}}{{Indemnity for losses arising from importer's failure to satisfy the SCCs.}}{{Audit and on-site inspection rights.}}
Organizational measures
{{Internal policy commitments mirroring the SCCs across the importer's group.}}{{Documented contact for government requests, with mandatory legal review before disclosure.}}{{Training and awareness for importer staff handling exporter data.}}
Section 5 — Conclusion
| Field | Value |
|---|
| Conclusion | {{The transfer can proceed under [mechanism] with the supplementary measures above. | The transfer requires further measures before it can proceed. | The transfer cannot be lawfully made and an alternative recipient or mechanism must be identified.}} |
| Residual risk | {{Low | Medium | High}} after measures applied |
| Conditions | {{any ongoing conditions on the transfer}} |
| Approver | General Counsel (Privacy Officer) |
| Approval date | {{date}} |
| Re-review date | {{date — at most 24 months from approval, or earlier on material change}} |
Section 6 — Re-review log
| Date | Reviewer | Trigger | Outcome |
|---|
{{date}} | {{name}} | {{periodic | new CJEU judgment | new importer law | breach}} | {{still adequate / measures updated / transfer suspended}} |
Cross-references
Version history
| Version | Date | Description | Author | Approved by |
|---|
| 1.0 | May 8, 2026 | Initial version | Cameron Wolfe | Ishan Jadhwani |
