Neurodata Governance Toolkit Explorer

Four tools that take a collaboration from “what are these data?” to the clauses its agreement needs.

1 · Classify

What can the data reveal or enable, for this recipient? Tool 1 assigns a tier by functional exposure.

2 · Test the pathway

Can the proposed transfer or access carry the safeguards that tier requires, under the law at both ends? Tool 2 decides: proceed, proceed with conditions, redesign, or do not proceed.

3 · Reassess derivatives and models

Features, embeddings, synthetic data and model weights are reassessed before release. Tool 3 applies the anonymity test as the gate.

4 · Select the clauses

Tool 4 maps the results to the modules of the Modular Neurodata Transfer and Access Agreement (MDTAA).

Open the tools See the workflow Sixteen worked examples

Built from the law of 93 countries in Africa, Europe, and Latin America and the Caribbean. The tools structure the questions and record the answers. They do not establish that a transfer is lawful, and they do not replace ethics, repository, institutional or legal review.

Tiered Neurodata Risk Classification Framework based on functional exposure

Classifying neurodata by the capacity to enable inference, reconstruction, profiling or harm.

Download tier figure (PNG) Download tier figure (PDF)

Risk category

Risk tier & description

Illustrative artefacts requiring assessment

Conventional privacy-based riskTiers 1, 1b, 2 and 3

Risk linked primarily to identifiability and individual privacy. Tier 1b is assessed from the recipient’s perspective.

Post-transformation functional-exposure tiersTiers 4 and 5

Risk driven by the capacity to support inference, profiling or harm, independent of identifiability.

Tier 1 — Anonymised aggregate outputs

Group-level or summary information with no participant-level record and no reasonable small-group disclosure risk. Minimal risk of re-identification or individual inference.

Group-level activation maps (voxel-wise averages)
Aggregated connectivity matrices
Summary statistics (e.g., mean amplitudes by group)
Published group results with no individual-level data

Tier 1b — Participant-level, non-linkable neurodata

Participant-level records with identifiers, identifying anatomy and metadata removed, no linkage key available to the intended recipient, and a documented disclosure-risk assessment for that recipient (for public release: any member of the public). Recipient-relative.

Defaced structural MRI released without any key
EEG/MEG with identifying metadata removed and key destroyed
Participant-level summary derivatives that reveal no more than the source
Synthetic participant-level data with reproduction excluded by testing

Tier 2 — Pseudonymised / controlled-access neurodata

Participant-level data linkable to an individual through a code, repository record or institutional key available to the recipient; re-identification risk mitigated but not eliminated.

Pseudonymised EEG or fMRI time series
Structural MRI (T1-weighted) with participant code
Clinical neuropsychological scores with codes
Data stored in controlled-access repositories

Tier 3 — Directly identifiable or intrinsically traceable neurodata

Data containing direct identifiers, recognisable anatomy, identifying acquisition metadata or intrinsic signal characteristics that permit identification or tracing without reliance on a separately protected key.

Non-defaced structural MRI; raw DICOM with headers
EEG/MEG/ECoG with identifying metadata or demonstrated fingerprinting capacity
Implant telemetry or BCI logs with device identifiers
Neurodata linked to names, voice or video

Tier 4 — Functionally revealing derivative neurodata

Transformed data with excess inferential capacity: inference outside the authorised purpose, re-identification by the derivative alone, or reconstruction of stimuli, speech, imagery or signals. Standard summary derivatives retain the source tier.

Connectome fingerprints and participant-unique embeddings
Decoders reconstructing stimuli, speech or imagery
Cognitive, emotional or behavioural profiles beyond the approved purpose
Risk scores and biomarkers used for prohibited inferences

Tier 5 — Model-associated or computationally persistent neurodata

Neural information dispersed across AI models, synthetic-data generators or computational infrastructure with continuing functional exposure, where inference, extraction or reconstruction may be possible without the original dataset.

Model weights trained on neurodata
Latent representations in generative models
Federated-learning updates and model gradients
Synthetic neurodata generators; persistent embedding stores

Key principle Tier assignment is informed by functional exposure; legal status remains determined under applicable law. The highest applicable tier governs; an Unknown answer takes the more protective tier; participant status (Step 0B) can raise the minimum tier.

The four tools

Each tool is a sequence of questions. Click a step to expand its answer rows and required actions; the search box filters steps by text.

Downloads

Print-ready PDFs (A4 landscape) of the four tools, the workflow figure and the tier framework.

All four tools (PDF, 46 pp.)Tool 1 (PDF)Tool 2 (PDF)Tool 3 (PDF)Tool 4 (PDF)Workflow figure (PNG)Workflow figure (SVG)Tier figure (PNG)Tier figure (PDF)

Assigns a functional-exposure tier (5, 4, 3, 2, 1b, 1) to the specific object for the specific recipient. Highest tier governs; Unknown resolves upward; Step 0B can raise the minimum tier.

Download Tool 1 as PDF

Tool 1 — Neurodata Governance Decision Tool

Applicability checkpointWhich statutory access regimes and ex ante data-protection, privacy-impact or privacy-risk assessment requirements may apply to the proposed activity? Consider the data category, holder, purpose, jurisdiction and application date, including EHDS where relevant. Assess legal applicability separately from functional-exposure tier.

Answer	Risk tier	Required action
Complete checkpoint	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record potentially applicable regimes and assessment requirements in Neurodata Governance Assessment Record (Schedule B of the MDTAA) Record any unresolved applicability question and refer it to the responsible legal or institutional reviewer in Neurodata Governance Assessment Record (Schedule B of the MDTAA) Continue to Step 1. Completion of this checkpoint does not resolve or waive an outstanding legal requirement.

0BParticipant status. Do the neurodata relate, in whole or in part, to (a) minors; (b) adults who lacked capacity to consent at collection; (c) deceased persons; (d) members of an Indigenous people or a community-governed or otherwise defined population with recognised governance interests; or (e) persons in a dependent relationship with the collecting institution (patients, employees, students, detainees)?

Answer	Risk tier	Required action
Yes (select all that apply)	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record each applicable status and the consent, assent, proxy-consent, community-approval or post-mortem rule relied on under Applicable Law in the Neurodata Governance Assessment Record (Schedule B of the MDTAA). Treat the minimum tier available at the Final Decision as one tier higher than otherwise determined (Tier 1 → Tier 1b; Tier 1b → Tier 2), unless a documented ethics or community determination permits otherwise. Where (d) applies, mark Tool 4 (Supplementary Table 9) Step 17 as required. Continue to Step 1.
No	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record the basis for the answer in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Continue to Step 1.
Unknown	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record the uncertainty; obtain the information from the Principal Investigator or data steward. Apply the ‘Yes’ action provisionally. Continue to Step 1.

1Does this object contain, represent or derive from human neurodata? ? Examples include MRI, fMRI, EEG, MEG, ECoG, neural implant data, BCI recordings, neural features, embeddings, predictions, or AI models trained using neurodata.

Answer	Risk tier	Required action
No	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record why the object falls outside this Tool’s scope in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Record the outcome as “Not applicable” in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Follow the institution’s ordinary data-governance procedures. End this Tool.
Yes	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record the object’s human-neurodata source or relationship in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Continue to Step 2A.
Unsure	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record the uncertainty in Neurodata Governance Assessment Record (Schedule B of the MDTAA) Obtain clarification from the Principal Investigator, data steward or technical lead before beginning the proposed sharing or analysis. Pause this assessment. Return to Step 1 when the evidence supports “Yes” or “No”.

2AIs the object under assessment itself a trained AI model, model component, model gradient, shared embedding store, synthetic-data generator, federated-learning artefact or other persistent computational artefact that was trained on, fitted to or otherwise derived from human neurodata? Examples include model weights, foundation models, federated-learning systems, synthetic-data generators, model gradients, or shared embedding repositories.

Answer	Risk tier	Required action
Yes	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record the artefact, its version and the form of incorporation in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Mark Tool 3 (Supplementary Table 8) as required for this object. Continue to Step 2B.
No	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record the basis for this answer in Neurodata Governance Assessment Record (Schedule B of the MDTAA). If a model has been or will be trained on this object, note that the model is a separate object requiring its own Tool 1 and Tool 3 assessment. Continue to Step 3.
Unknown	Tier 5	Record provisional Tier 5 in Neurodata Governance Assessment Record (Schedule B of the MDTAA) and apply the Tier 5 safeguards specified in Annexure 1 §3.5 to the relevant object and activity. Request technical confirmation of whether incorporation has occurred. Continue to Step 3 to identify additional exposure and safeguards. When clarification is available, return to Step 2A: if “Yes”, continue to Step 2B; if “No”, document resolution of this provisional finding and continue to Step 3. Do not finalise a lower tier or proceed with affected sharing, transfer or deployment while this uncertainty remains unresolved.

2BIs there evidence, or a reasonable possibility, that neural information persists within the model or computational infrastructure in a manner capable of supporting identification, inference, reconstruction, extraction or profiling of individuals or groups? Consider model memorisation, inversion, membership inference, extraction attacks, reconstructive outputs, shared embeddings and other forms of persistent representation.

Answer	Risk tier	Required action
Yes	Tier 5	Record a provisional Tier 5 condition in Neurodata Governance Assessment Record (Schedule B of the MDTAA) and apply Tier 5 safeguards provisionally under Annexure 1 §3.5. Record the evidence or credible technical assessment supporting continuing functional exposure in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Initiate or complete Tool 3 (Supplementary Table 8) and apply the Tool 3 (Supplementary Table 8) return procedure below. Continue to Step 3 to identify additional exposure and safeguards. Tier 5 remains unconfirmed until the required assessment establishes its criteria
No	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record the supporting technical assessment in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Complete Tool 3 (Supplementary Table 8) because Step 2A was answered “Yes”; this answer does not remove that requirement. Apply the Tool 3 (Supplementary Table 8) return procedure below. Continue to Step 3. Do not remove an existing higher-tier finding solely on the basis of this answer.
Unknown	Tier 5	Record provisional Tier 5 in Neurodata Governance Assessment Record (Schedule B of the MDTAA) and apply Tier 5 safeguards under Annexure 1 §3.5. Record the unresolved exposure question in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Obtain appropriate specialist technical, legal, ethics or institutional review and complete Tool 3 (Supplementary Table 8). Apply the Tool 3 (Supplementary Table 8) return procedure below. Continue to Step 3 to identify additional exposure and safeguards. Do not finalise a lower tier or proceed with affected sharing, transfer or deployment until the uncertainty is resolved.

3Is this object a derived neurodata product rather than the original neurodata? ? Examples include embeddings, feature vectors, neural fingerprints, cognitive profiles, classifiers, predictions, or reconstructed neural representations.

Answer	Risk tier	Required action
Yes	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record the source neurodata and the transformation that produced the object in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Continue to Step 4.
No	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record the basis for treating the object as original neurodata. in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Continue to Step 5 to assess direct identification and traceability.
Unknown	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Obtain provenance or processing information from the data steward or technical lead. Retain all existing tier findings and safeguards. Pause progression beyond this step. Return to Step 3 when the evidence supports “Yes” or “No”.

4Does this derived object have excess inferential capacity, that is, can it, alone or with information reasonably available to the intended recipient: (i) support inference about neurological, cognitive, emotional or behavioural states or traits outside the purpose for which the source neurodata were authorised; (ii) identify or trace a participant by itself (for example a functional-connectome fingerprint or a high-dimensional embedding unique to a participant); or (iii) reconstruct stimuli, speech, imagery or neural signals? Standard summary derivatives that reveal no more than the source dataset already reveals (for example regional volumes, connectivity matrices or spectral summaries used for the authorised purpose) do not satisfy this question and retain the source tier. Apply Annexure 1 §4.1.6 and the §2.1 distinction between ordinary aggregate description and material group-level Functional Exposure.

Answer	Risk tier	Required action
Yes	Tier 4	Record a Tier 4 finding and the relevant capability in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Restrict access to controlled access; document permitted uses and prohibited inferences inNeurodata Governance Assessment Record (Schedule B of the MDTAA); prohibit unauthorised profiling, reconstruction and general-purpose AI training; and maintain provenance records. Obtain specialist governance review and complete Tool 3 (Supplementary Table 8). Complete Neuro-TADT (Tool 2) (Supplementary Table 7) before external sharing or international transfer. Retain any higher tier finding. Continue to Step 5.
No	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record the evidence supporting this answer in Neurodata Governance Assessment Record (Schedule B of the MDTAA), including why the derivative reveals no more than the source dataset and the additional information reasonably available to the intended recipient. Continue to Step 5.
Unknown	Tier 4	Record provisional Tier 4 and the capability requiring assessment in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Apply the safeguards specified in the Step 4 “Yes” row provisionally. Complete Tool 3 (Supplementary Table 8) and obtain the specialist review needed to resolve the uncertainty. Retain any higher tier finding. Continue to Step 5.

5Does the object contain direct identifiers, recognisable identifying anatomy, identifying acquisition metadata, or intrinsic information that reasonably permits participant identification or tracing beyond linkage through a separately protected code or mapping? Examples include names, identifying DICOM headers, non-defaced facial anatomy, identifying voice or video, or device identifiers and timestamps that enable tracing. Being a raw EEG, MEG, ECoG or MRI acquisition is not, by itself, a “Yes”; linkage solely through a protected code or mapping is assessed at Step 6.

Answer	Risk tier	Required action
Yes	Tier 3	Record a Tier 3 finding and the identifiers or intrinsic traceability identified in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Store the object in a secure controlled environment with encryption, role-based access, audit logs, and formal access approval. Remove unnecessary identifiers where feasible and restrict downloads and onward sharing. Complete Neuro-TADT (Tool 2) (Supplementary Table 7) before international transfer or external access. Retain any higher tier finding. Continue to Step 6.
No	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record the basis for concluding that the specified identifiers and intrinsic traceability are absent in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Continue to Step 6.
Unknown	Tier 3	Record provisional Tier 3 in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Apply the safeguards specified in the Step 5 “Yes” row provisionally. Assign an identifier and traceability review to the responsible data steward or technical reviewer. Retain any higher tier finding. Continue to Step 6. Return to Step 5 when the review supports “Yes” or “No”.

6Does the object still contain participant-level neurodata that can be linked back to an individual through a code, repository record or institutional key that is available to, or obtainable by, the intended recipient? Where a key exists but is held by another party under a documented undertaking not to disclose it, answer ‘No’ for that recipient and ‘Yes’ for the key-holder, and record both. Example: a pseudonymised EEG dataset whose participant identifiers are held by the originating institution (‘Yes’ for the originating institution; ‘No’ for an external recipient that has no access to the key).

Answer	Risk tier	Required action
Yes	Tier 2	Record a Tier 2 finding, the linkage mechanism and the responsible custodian in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Use controlled-access repositories; separate and protect the linkage key; encrypt data in storage and transit; maintain access logs; and restrict re-identification and onward sharing. Put any required Data Use or Transfer Agreement in place before the relevant access or transfer. Where another institution holds the key, record its custody and restrictions without obtaining or disclosing the key. Retain any higher tier finding. Proceed to the Final Decision.
No	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record the evidence that no linkage mechanism is available to the intended recipient (key destroyed; or key-holder identified with its undertaking recorded) in Neurodata Governance Assessment Record (Schedule B of the MDTAA). If a candidate, provisional or confirmed Tier 3, Tier 4 or Tier 5 finding remains active, proceed to the Final Decision. Otherwise, continue to Step 7.
Unknown	Tier 2	Record provisional Tier 2 in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Apply the linkage safeguards specified in the Step 6 “Yes” row to any existing or potentially retained linkage mechanism. Request confirmation from the data holder or repository custodian about whether participant-level linkage remains possible. Retain any higher tier finding. Proceed to the Final Decision with the uncertainty unresolved. When confirmation is available, return to Step 6 and follow the “Yes” or “No” branch.

7Does the object contain only aggregated or summary-level information with no participant-level records or persistent participant trace? Example: A published study reporting only group-average brain activation patterns, summary statistics, or aggregate connectivity measures with no participant-level records or re-identifiable individual data.

Answer	Risk tier	Required action
Yes	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record the aggregation or summarisation method and the evidence that no participant-level records or persistent participant trace remain in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Continue to Step 8.
No	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record that the object contains participant-level records without an available linkage mechanism (candidate Tier 1b) in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Continue to Step 8 for the disclosure-risk assessment. Do not record ‘Unclassified’ at this step.
Unknown	No tier is assigned at this step. Follow the instructions in the Required action column. Any tier identified at an earlier step remains applicable unless resolved through documented reassessment.	Record that aggregate-only status has not been established Neurodata Governance Assessment Record (Schedule B of the MDTAA). Request technical review of participant-level records, persistent traces and the aggregation or summarisation method. Pause classification and retain any existing safeguards. Do not approve release through this Tool while the uncertainty remains unresolved. Return to Step 7 when the evidence supports “Yes” or “No”.

8Could an individual or small group still reasonably be identified by means reasonably likely to be used by the intended recipient (for public release: by any member of the public), through rare conditions, small sample sizes, unique characteristics, intrinsic signal characteristics known to permit re-identification for this modality (for example residual facial features after defacing; connectome fingerprints), accompanying metadata, or linkage with data reasonably available to the recipient? Example: a dataset describing a single participant with a rare neurological disorder, a very small cohort from one clinic, or records containing unique demographic or geographic metadata.

Answer	Risk tier	Required action
Yes	Tier 2 (minimum)	Record Tier 2 as the minimum applicable tier and identify the disclosure mechanism in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Increase aggregation, suppress disclosive information or strengthen de-identification where feasible. Determine and record the necessary access restrictions, including controlled access where required. Reassess the modified object before release, repeating Steps 5–8 and any earlier step affected by the modification. Retain any higher tier finding unless documented reassessment resolves it. Proceed to the Final Decision.
No — and the object is aggregate-only (Step 7 ‘Yes’)	Tier 1 Note: A Tier 1 outcome does not automatically exclude Annexure 3 in the MDTAA. Apply the exception and triggers in Annexure 1 §7.2 in the MDTAA to the particular object and proposed activity, and record the reason for completing or omitting Annexure 3 in the MDTAA. A Tier 1 outcome shall not override a higher candidate, provisional or confirmed tier identified elsewhere in the assessment.	Record a Tier 1 finding and the supporting disclosure-risk assessment in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Document the aggregation or anonymisation method and confirm that no participant-level record, persistent participant trace or linkage mechanism remains in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Check the triggers and exceptions in Annexure 1 §7.2 and record why Tool 3 (Supplementary Table 8) is required or may be omitted. Do not use this finding to override a higher candidate, provisional or confirmed tier. Proceed to the Final Decision.
No — and the object is participant-level (Step 7 ‘No’)	Tier 1b Note: a Tier 1b finding is made for a specified recipient (or for the public) and may differ from the tier applying to the Data Exporter, which may retain a key (Tier 2). A Tier 1b outcome shall not override a higher candidate, provisional or confirmed tier identified elsewhere in the assessment.	Record a Tier 1b finding and the supporting disclosure-risk assessment in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Document the de-identification method (including defacing, header stripping and date shifting, with software and version), the absence of an available linkage mechanism, and the recipient (or ‘public’) for which the finding is made. Select and record the licence or access condition required by Annexure 1 §3.1b(d), including a prohibition on re-identification attempts. Apply any uplift required by Step 0B. Check the triggers and exceptions in Annexure 1 §7.2 and record why Tool 3 (Supplementary Table 8) is required or may be omitted. Do not use this finding to override a higher candidate, provisional or confirmed tier. Proceed to the Final Decision.
Unknown	Tier 2	Record provisional Tier 2 in Neurodata Governance Assessment Record (Schedule B of the MDTAA). Obtain a disclosure-risk review addressing rare conditions, small samples, unique characteristics, and accompanying metadata. Withhold release pending resolution of this uncertainty. Retain any higher tier finding. Proceed to the Final Decision with the uncertainty unresolved. Return to Step 8 when the review supports “Yes” or “No”.

Final DecisionHave all applicable steps and required classification reviews been completed?

Answer	Risk tier	Required action
Complete assessment	-	Record the highest applicable tier and whether it is provisional or confirmed. Do not finalise a lower tier while a higher candidate or provisional finding remains unresolved. Retain all safeguards whose underlying conditions remain present. Save the outcome, supporting evidence, outstanding actions and responsible reviewer in the assessment record; incorporate or reference it in Neurodata Governance Assessment Record (Schedule B of the MDTAA). where applicable. Complete or update Tools 2 (Supplementary Table 7) and 3 (Supplementary Table 8) where required, then proceed to Tool 4 (Supplementary Table 9) where contractual implementation is needed. Do not begin the proposed activity until required safeguards and approvals are in place. Apply any tier uplift recorded at Step 0B before finalising.

Asks whether the proposed pathway can carry the tier’s safeguards: recipient type (including the gated public-release branch), matrix class (Step 6A), origin- and destination-side restrictions (Step 6B), exporter and importer checks, linkage, AI use, purpose, onward sharing and safeguards. Four outcomes.

Download Tool 2 as PDF

Tool 2 — Neurodata Transfer and Access Decision Tool, Neuro-TADT

General instructions before using this tool: Assess the proposed transfer or access arrangement using the tier and safeguards identified in Supplementary Table 6. Wherever this Tool says “record”, enter the information against the relevant step in the transfer and access section of the Neurodata Governance Assessment Record. Where the MDTAA applies, incorporate or reference that assessment in Schedule C and link it to the classification recorded in Schedule B. Record supporting evidence, outstanding actions and responsible persons. Continuing through the assessment does not authorise transfer or access. A later answer does not remove an earlier restriction or unresolved requirement. Before Step 7, complete the pathway lookup at Step 6A and the restrictions check at Step 6B; the actions recorded there are prerequisites for Outcome 1 or 2.

1What are you planning to do with the neurodata? Example: Using an EEG dataset to train a machine learning model for early detection of Alzheimer's disease.

Answer	Required action
Internal use only with no external or cross border sharing or access to data.	Record the internal use and why no listed external or cross-border pathway applies. Apply the safeguards identified in Supplementary Table 6 and assess applicable statutory access and authorisation requirements. Record “Neuro-TADT not required for this arrangement” and end this Tool. Other applicable governance assessments remain required
Share with another institution; international transfer; repository deposit; cloud-hosted access; or AI platform or vendor access.	Record every selected pathway and the proposed activity. Continue to Step 2.
Unsure	Obtain clarification of the proposed storage, sharing, access and processing arrangements. Pause the assessment and do not begin the proposed transfer or external access. Return to Step 1 when the pathway is established.

2Has the neurodata already been assigned a risk tier using (Tool 1) Supplementary Table 6? Example: The neurodata has been classified as Tier 2 (Moderate Risk) using the criteria in Supplementary Table 26 before planning further processing or sharing.

Answer	Required action
Yes	Record the tier, whether it is provisional or confirmed, the applicable safeguards and the (Tool 1) Supplementary Table 6 assessment reference. Carry forward all unresolved conditions and restrictions. A provisional tier may support pathway assessment but does not remove required review. Continue to Step 3.
No	Complete (Tool 1) Supplementary Table 6 to get a risk tier assigned to the particular data object and proposed activity. Return to Step 2 after a tier has been assigned. If (Tool 1) Supplementary Table 6 cannot establish a tier and requires specialist review, select Final Decision Outcome 4 below.
Unsure	Locate the existing classification and check that it covers the object, version and proposed activity. Complete or update records according to Supplementary Table 6 if the classification is absent or no longer applicable. Return to Step 2 when the tier and safeguards are established.

3Who will receive or access the neurodata? Example: An approved research collaborator, an international research consortium, or a trusted cloud service provider processing the neurodata under a data processing agreement.

Answer	Required action
Named collaborating institution; repository; cloud provider; commercial partner; or AI developer. Select all that apply.	Record each recipient’s name, role and proposed access or processing activity. Continue to Step 4.
Unknown recipients	Record which recipients remain unidentified. Obtain recipient information from the proposed collaborator, repository, provider or other responsible party. Do not begin transfer or access. Return to Step 3 once recipients are identified. If they cannot be identified, select Final Decision Outcome 4 below.
Public or unrestricted release (open repository deposit, open licence, public model weights, publication of participant-level supplementary data)	Record the release channel, licence and any registration or click-through conditions. Public release is permitted through this Tool only where (a) Tool 1 (Supplementary Table 6) records a confirmed Tier 1 or Tier 1b finding made for the public as recipient, or (b) for a model or other computational artefact, Tool 3 (Supplementary Table 8) Step 7 records leakage testing with no material exposure for the intended release conditions and a documented anonymity assessment. If neither condition is met, record ‘Public release not supported by current classification’ and either select Final Decision Outcome 3 (redesign: controlled access, gated or registered access, or federated access) or return the object to Tool 1/Tool 3 for further de-identification or testing. If a condition is met, record ‘Recipients: public’ at Steps 4 and 12, treat Step 5 as ‘Downloadable copy’, and continue to Step 6.

4Can every recipient and subprocessor be identified? Example: All recipients are known by name, including collaborating institutions, cloud service providers, and any contracted subprocessors.

Answer	Required action
Yes	Record each recipient and subprocessor, its role and the information available about its access. Continue to Step 5.
No or Unsure	Request a complete recipient and subprocessor list from the responsible organisation or provider. Do not begin transfer or access while required identities remain unresolved. Return to Step 4 when the list is complete. If the required information cannot be established, select Final Decision Outcome 4 below.
Not applicable — public release recorded at Step 3	Record ‘Not applicable: public release permitted under Step 3’. Continue to Step 5.

5How will recipients access the neurodata or governed artefact? Example: The recipient can download and retain a local copy of the neurodata rather than accessing it only through a secure remote environment.

Answer	Required action
Downloadable copy	Record what may be downloaded, by whom and to which environment. Specify tier-appropriate controls for local storage, copying, access, onward sharing, retention and deletion. Continue to Step 6.
Remote or controlled access without downloading the underlying object	Record the access environment, authorised users and restrictions on downloading or exporting data and outputs. Specify access controls, logging and output review appropriate to the tier. Continue to Step 6.
Query-only or federated access	Record where processing occurs and what queries, outputs, gradients or other information may leave each environment. Specify controls on queries, outputs, access and logging appropriate to the tier. Continue to Step 6.
Unsure	Obtain confirmation of the access modes and export capabilities from the recipient or infrastructure provider. Pause the assessment and do not begin access. Return to Step 5 when the access arrangements are established.

6Will the neurodata be transferred to, stored in, or remotely accessed from another legal jurisdiction? Example: neurodata remains on a server in South Africa but is accessed remotely by researchers in Germany.

Answer	Required action
Yes	Record every relevant originating, receiving, hosting and remotely accessing jurisdiction, including relevant subprocessor locations. Continue to Step 7.
No	Record the locations and the basis for concluding that no cross-jurisdictional transfer, storage or remote access is involved. Continue to Step 7.
Unsure	Obtain location and remote-access information from the recipients and infrastructure providers. Do not begin transfer or access while relevant jurisdictions remain unresolved. Return to Step 6 when the locations are established. If they cannot be established, select Final Decision Outcome 4 below.

6APathway class. What is the compatibility class of the origin→destination pathway (and of each origin→hosting and origin→remote-access pathway) in Supplementary Data 2 (or the current online version of the matrix)? Record the matrix version and date. Where the destination is the United States or Canada, use the North American governance-unit analysis (Supplementary Figure 1) and record the applicable federal, state or provincial regime instead of a class. Example: Nigeria → Germany is Class B; Germany → Brazil was Class C at the study cut-off and is adequacy-based (Class A2) since 26 January 2026.

Answer	Required action
A1 (unified legal space)	Record ‘A1: no transfer mechanism required’. The lawful basis for processing in both environments and any sector-specific or institutional condition remain required at Step 7. Continue to Step 6B.
A2 (convergent; adequacy-type recognition)	Record the adequacy decision, regulation or recognition relied on, its date and any scope limits (for example sectoral or organisational limits, as for Canada (commercial organisations) or the United States (DPF-certified organisations only)). Verify that the recipient falls within the scope; if it does not, treat the pathway as Class B. Continue to Step 6B.
B (standard transfer instrument)	Record the instrument required by the origin regime (see the Step 6B regime table and the MDTAA Transfer-Instrument Modules). Mark the corresponding MDTAA module for activation at Tool 4 (Supplementary Table 9) Step 2. Continue to Step 6B.
C (operationally conditional)	As for Class B, and in addition: mark Tool 4 Step 3 (Supplementary Safeguards Module) as required; require a documented transfer-risk or impact assessment at Step 7(i); and record the supplementary institutional, repository or technical safeguards that make the pathway navigable. Continue to Step 6B.
D (restricted in practice)	Record that the pathway is restricted. Default to Final Decision Outcome 3: redesign toward remote access, federated or query-only access, aggregation to Tier 1, or an alternative destination. Proceed with a transfer of participant-level data only where counsel in the origin jurisdiction documents a lawful mechanism and the authorisations required at Step 6B. Continue to Step 6B.
E (insufficient legal certainty)	Record that legal certainty is insufficient. Default to Final Decision Outcome 4 unless counsel in the origin jurisdiction documents a lawful mechanism; where that is done, treat the pathway as Class D. Continue to Step 6B.
Not in matrix / Unsure	Record the gap. Obtain an origin-jurisdiction legal assessment and treat the pathway as Class C pending that assessment. Continue to Step 6B.

6BOrigin-side and destination-side restrictions. Using the Step 6B regime table (and Supplementary Data 3 for jurisdictions not listed), does any of the following apply? (a) a statutory prohibition on transferring this category of data or this type of database (e.g., LGPD art. 13 §2); (b) a localisation, serving-copy or in-country processing duty (e.g., Kenya reg. 26; Rwanda art. 50); (c) a requirement of prior authorisation, notification, licence or registration by a regulator before transfer or storage abroad (e.g., POPIA s. 57(1)(d); NCSA authorisation); (d) sanctions, export-control or national-security screening of the destination or recipient (e.g., US DOJ Data Security Program, 28 CFR Part 202; OFAC) where any Party is a US person or the data concern US persons; (e) a research export permit, ethics-committee export clearance or data-transfer approval required by the origin jurisdiction (e.g., NACOSTI; NHREC); (f) a destination-side import condition (registration, local representative, sectoral hosting certification such as HDS in France).

Answer	Required action
Yes (select all that apply)	Record each applicable restriction, the responsible Party, the competent authority and the evidence required. Where (a) applies, select Final Decision Outcome 3 (redesign so that no transfer of the prohibited category occurs, for example analysis within the origin environment with export of results only) or Outcome 4. Where (b)–(f) apply, mark each as a prerequisite: Outcome 1 may not be selected until the authorisation, registration, serving copy, screening or permit is documented; Outcome 2 may be selected where the action is pending. Continue to Step 7(i).
No	Record the basis for concluding that none applies, with reference to the regime table or Supplementary Data 3. Continue to Step 7(i).
Unsure	Obtain origin-jurisdiction and destination-jurisdiction review. Do not begin transfer or access. Return to Step 6B when established; if it cannot be established, select Final Decision Outcome 4 below.

7(i)Exporter side. Under the law of the originating jurisdiction, have the following been identified and documented: the lawful basis or justification for the disclosure; the transfer mechanism indicated at Step 6A (or the reason none is required); the transfer-risk, transfer-impact, privacy-impact or data-protection assessment required for that mechanism or by the origin regime; the authorisations identified at Step 6B; the exporter’s authority to make the present transfer or release under any upstream conditions (consent scope, ethics approval, repository or funder terms, community agreements); and the ethics, institutional and repository approvals required? Consider consent or another lawful basis, statutory transfer provisions, adequacy-type mechanisms, contractual safeguards, DPIAs, PIAs or other jurisdiction-specific assessments, regulatory authorisation and institutional approval, as applicable.

Answer	Required action
Yes	Record each item with its reference and status. Verify the Data Exporter’s authority to make the present transfer or release, including applicable upstream conditions. Mark outstanding items as pending. Continue to Step 7(ii).
No or Unsure	Identify the missing basis, mechanism, assessment, approval or evidence of authority. Obtain the necessary origin-jurisdiction legal, ethics, institutional or repository review. Do not begin transfer or access. Return to Step 7(i) when documented. If no applicable lawful pathway can be established, select Final Decision Outcome 4 below.

7(ii)Importer side. Under the law of each receiving, hosting and remotely accessing jurisdiction, have the following been identified and documented: the recipient’s own lawful basis or justification for processing (including any special-category, health-data or sensitive-data condition); any registration, notification, licensing, local-representative or data-protection-officer requirement applying to the recipient; any sectoral hosting requirement (for example health-data hosting certification); and the recipient’s ethics or institutional approval for the proposed use?

Answer	Required action
Yes	Record each item with its reference and status. Continue to Step 7A.
No or Unsure	Identify the missing item and obtain destination-jurisdiction review. Do not begin transfer or access. Return to Step 7(ii) when documented; if it cannot be established, select Final Decision Outcome 4 below.

7ADoes the proposed activity require a statutory access authorisation, data permit or research permit under the origin regime or the hosting regime? Examples: a Findata permit (Finland); a Health Data Hub/CESREES authorisation (France); a Forschungsdatenzentrum authorisation (Germany); a Garante authorisation under art. 110 of the Privacy Code (Italy); a NACOSTI permit (Kenya); a UNCST clearance (Uganda); a COSTECH permit (Tanzania); CONEP approval of an international collaboration (Brazil); or, from 26 March 2029, an EHDS data permit.

Answer	Required action
Yes	Record the competent body, required authorisation, application or approval status, and reference. Record the authorised purpose, users, duration, processing location and release conditions once established. Mark an authorisation not yet obtained as pending; do not begin the activity requiring it. Continue to Step 8.
No	Record the basis for concluding that no such authorisation is required for this activity. Continue to Step 8.
Uncertain	Obtain review of the authorisation requirement. Do not begin the affected transfer or access. Return to Step 7A when the requirement is established. If it remains unresolved, select Final Decision Outcome 4 below.

8Can the receiving or accessing governance environment implement and maintain the safeguards required for the assigned tier? Consider institutional oversight, repository governance, technical controls, contractual compliance, auditability, enforcement and available remedies.

Answer	Required action
Yes	Record the evidence of capacity to maintain the required safeguards. Identify any safeguards that the environment can support but has not yet implemented, for verification at Step 13. Continue to Step 9.
No	Record which required safeguards cannot be maintained and why. If an alternative access model or governance arrangement could provide the required protection, select Final Decision Outcome 3 below. If no feasible alternative is identified, select Final Decision Outcome 4 below.
Unsure	Record which safeguards cannot yet be verified. Request evidence from the recipient or provider (policies, certifications, repository governance documents, audit or penetration-test reports, Annexure 5 self-assessment). Do not begin transfer or access until capacity is verified. Return to Step 8 when evidence is available. If evidence cannot be obtained, select Final Decision Outcome 3 where an alternative access model could provide the required protection; otherwise select Final Decision Outcome 4 below.

9Will the neurodata be linked with additional datasets after transfer or access? Examples include genomic, electronic health-record, wearable-device, consumer or public-register data.

Answer	Required action
Yes	Record the additional datasets, linkage purpose, responsible party and proposed resulting object. Apply Supplementary Table 6 to the proposed linked dataset or resulting object before linkage begins. Update the tier and safeguards recorded at Step 2 and review Steps 3–8 and 7A against that assessment, revising affected answers. Once the affected checks are complete and no blocking outcome applies, continue to Step 10. Do not repeat the same linkage assessment unless relevant circumstances change.
No	Record that linkage is outside the assessed arrangement and requires reassessment before introduction. Continue to Step 10.
Unsure	Record that linkage has not been excluded. Prohibit linkage contractually pending clarification (activate Tool 4 (Supplementary Table 9) Step 12 in its prohibitory form). Obtain confirmation from the recipient. Return to Step 9 when the answer is established; if it remains unresolved at the Final Decision, Outcome 1 may not be selected.

10Will the neurodata or a derivative artefact be used to train, fine-tune, validate, benchmark or deploy an AI or machine-learning system? Example: An external collaborator will use a transferred EEG dataset to fine-tune a model for detecting cognitive impairment, or use the dataset to validate the performance of an existing predictive model.

Answer	Required action
Yes	Record the proposed AI activities, system, responsible parties and intended outputs. Complete Tool 3 (Supplementary Table 8) for the proposed activity and follow its Final Decision instructions. If the tier or safeguards change, update Step 2 and repeat the affected pathway checks before continuing. If Tool 3 (Supplementary Table 8) requires unresolved specialist review or prohibits proceeding in the current form, select Final Decision Outcome 4 below. Otherwise, continue to Step 11, carrying forward all outstanding safeguards and restrictions.
No	Record that these AI activities are outside the assessed arrangement and require assessment before introduction. Continue to Step 11.
Unsure	Obtain confirmation of the intended AI activities from the recipient. Prohibit unassessed AI use pending clarification. Return to Step 10 when the answer is established. If the intended use cannot be established, select Final Decision Outcome 4 below.

11Will the neurodata be used for a purpose materially different from the approved research purpose? Examples may include commercial development, employment, insurance, clinical deployment or unrelated secondary research where these activities fall outside the already approved purpose, consent, ethics approval or other applicable authorisation. Interpretive note: Assess the proposed purpose against the authorisations and conditions applicable to this activity, including upstream restrictions and relevant consent, ethics and institutional requirements. A purpose different from the original study is not automatically prohibited, and public availability does not automatically authorise it. Record the basis for permitting the proposed use or the additional review or approval required.

Answer	Required action
Yes	Record the proposed purpose and the gap between it and the approved purpose, the consent, the ethics approval and any upstream condition. Do not begin the new use. Obtain the approvals required under Applicable Law and institutional rules: an ethics amendment; re-consent, or a documented compatibility or secondary-use assessment where the origin regime permits research reuse without re-consent; Data Access Committee approval; and the Data Exporter’s written approval. If the proposed purpose is commercial or involves product development, licensing or deployment, mark Tool 4 (Supplementary Table 9) Step 10 as required and Step 11 as not applicable. If the proposed purpose is clinical deployment, record the applicable medical-device or clinical-governance requirements under Tool 4 Step 19. Return to Step 11 when approvals are documented; otherwise select Final Decision Outcome 4 below.
No	Record the approved purpose and the authorisation or conditions covering it. Continue to Step 12.
Unsure	Clarify the proposed purpose with the recipient and compare it with applicable authorisations and restrictions. Do not begin the uncertain use. Return to Step 11 when the answer is established. If it remains unresolved, select Final Decision Outcome 4 below.

12May the recipient disclose, transfer, or provide access to the neurodata or resulting artefacts to another party? This includes collaborators, repositories, vendors, cloud providers, subprocessors and downstream recipients.

Answer	Required action
Yes	Record permitted onward recipients or recipient categories, purposes and conditions. Check that onward permission is consistent with upstream conditions. Distinguish permission already granted from permission requiring separate approval. Require applicable safeguards to continue throughout the onward pathway and mark outstanding approvals as pending. If the proposed onward arrangement introduces recipients, locations or access modes not yet assessed, update Steps 3–8 and 7A before continuing. Continue to Step 13.
No	Record and contractually implement the prohibition on onward transfer or access. Continue to Step 13. This prohibition concerns the recipient’s onward sharing; authority for the Data Exporter’s present transfer remains subject to Step 7.
Unsure	Clarify the onward-sharing permissions and upstream restrictions. Do not permit onward sharing while permission remains unresolved. Return to Step 12 when the answer is established. If the arrangement cannot be assessed without resolving this issue, select Final Decision Outcome 4 below.
Public release recorded at Step 3	Record that onward use is governed by the licence selected at Step 3 and that no further recipient-specific control is possible. Confirm that the licence prohibits re-identification and requires attribution and notification of suspected re-identification. Continue to Step 13.

13Have all legal, institutional, repository, technical and contractual safeguards required for the assigned tier and proposed pathway been implemented and documented? Example: Before an international transfer of Tier 3 MRI data, the parties have confirmed the applicable transfer mechanism and approvals, implemented encrypted transfer and role-based access, enabled audit logging, restricted onward sharing, and documented permitted uses, retention, deletion and incident-response requirements.

Answer	Required action
Yes	Record the implementation evidence and responsible verifier. Proceed to the Final Decision below and check the conditions for Outcome 1. Outstanding requirements identified earlier must still be satisfied.
No, but they can be implemented.	Record each outstanding safeguard, the responsible party and the evidence needed to verify implementation. Proceed to the Final Decision below and select Outcome 2 only if its conditions are met. Do not begin transfer or access before implementation is verified.
No, and they cannot be implemented within the proposed pathway	Record the safeguards that cannot be implemented. Select Outcome 3 if a feasible alternative arrangement may provide the required protection. Otherwise, select Final Decision Outcome 4 below.
Unsure	Obtain verification from the responsible technical, legal or governance reviewer. Do not begin transfer or access. Return to Step 13 when implementation can be established. If material uncertainty remains, select Final Decision Outcome 4 below.

Final Decision: Select and document one outcome Interpretive note: A Neuro-TADT outcome provides structured governance decision support. It does not independently authorise processing, establish formal legal adequacy or replace any required legal, ethics, institutional, repository or regulatory determination.

?Outcome

Answer	Required action
Decision Criterion

1Proceed subject to applicable approvals

Answer	Required action
Select only where the applicable lawful basis, transfer or access mechanism, required approvals and authority for the present transfer have been confirmed, and all required safeguards are implemented and documented. Record the approved recipients, purposes, access conditions, supporting evidence and reviewer. Proceed only within those confirmed approvals and conditions. Reassess before a material change to the object, purpose, recipient, jurisdiction or access arrangement. Outcome 1 may not be selected while any Step 6B prerequisite, Step 7(i)/(ii) item or Step 9 uncertainty remains open. For public release, Outcome 1 additionally requires the Tier 1/1b or model-anonymity condition at Step 3 to be confirmed, the licence to be recorded, and a takedown and re-identification-response procedure to be documented.

Answer

Required action

Select only where the applicable lawful basis, transfer or access mechanism, required approvals and authority for the present transfer have been confirmed, and all required safeguards are implemented and documented. Record the approved recipients, purposes, access conditions, supporting evidence and reviewer. Proceed only within those confirmed approvals and conditions. Reassess before a material change to the object, purpose, recipient, jurisdiction or access arrangement. Outcome 1 may not be selected while any Step 6B prerequisite, Step 7(i)/(ii) item or Step 9 uncertainty remains open. For public release, Outcome 1 additionally requires the Tier 1/1b or model-anonymity condition at Step 3 to be confirmed, the licence to be recorded, and a takedown and re-identification-response procedure to be documented.

2Proceed after supplementary safeguards are implemented

Answer	Required action
Select where the applicable legal and approval prerequisites are established, but specified safeguards remain to be implemented within the current pathway. Record each outstanding safeguard, responsible party and verification requirement. Withhold transfer or access until implementation is verified. Return to Step 13 and, if all conditions are satisfied, record Outcome 1.

3Redesign the transfer or access pathway

Answer	Required action
Select where required safeguards cannot be maintained under the current arrangement but a feasible alternative may provide the required protection. Record why the current pathway is unsuitable and the proposed changes. Do not begin transfer or access through the unsuitable pathway. Repeat this Tool for the redesigned arrangement, updating Supplementary Table 6 if the changes could affect functional exposure or the required tier.

Answer

Required action

Select where required safeguards cannot be maintained under the current arrangement but a feasible alternative may provide the required protection. Record why the current pathway is unsuitable and the proposed changes. Do not begin transfer or access through the unsuitable pathway. Repeat this Tool for the redesigned arrangement, updating Supplementary Table 6 if the changes could affect functional exposure or the required tier.

4Do not proceed and obtain specialist review

Answer	Required action
Select where a required legal basis, mechanism, approval, recipient identity or material governance issue remains unresolved, or the required protection cannot be maintained. Record the reason, required review and responsible person or body. Do not begin the affected transfer or access. Following review, return to the affected step and update all dependent answers. If no acceptable pathway is established, retain this outcome.

Answer

Required action

Select where a required legal basis, mechanism, approval, recipient identity or material governance issue remains unresolved, or the required protection cannot be maintained. Record the reason, required review and responsible person or body. Do not begin the affected transfer or access. Following review, return to the affected step and update all dependent answers. If no acceptable pathway is established, retain this outcome.

Reassesses derivatives and models for identification, inference and persistence; Step 7 holds the leakage and anonymity assessment that gates public release. Five outcomes.

Download Tool 3 as PDF

Tool 3 — Derivative and Embedding Governance Decision Tool

1Has the neurodata undergone, or will it undergo, technical transformation; will it be used in an AI or machine-learning system; or may neurodata-derived information persist in a model or computational infrastructure? Apply the triggers and exceptions in Annexure 1 §7.2. Examples include feature extraction, dimensionality reduction, embedding generation, predictive modelling, synthetic-data generation or AI-model training.

Answer	Required action
No	Record why none of these triggers applies. Retain the tier and safeguards established under Tool 1 / Supplementary Table 6. Record “Tool 3 (Supplementary Tool 8) not required for this activity” and return to the referring Tool at its next applicable step. Reassess if the activity or object changes.
Yes	Record the applicable trigger. If an exception under Annexure 1 §7.2 is established for this particular object and activity, document the exception and return to the referring Tool. Do not apply that exception to AI activities requiring assessment under Supplementary Table 7 Step 10. Otherwise, continue to Step 2.
Unsure	Obtain clarification of the processing, AI activity or possible computational persistence. Do not mark the activity as exempt while applicability remains uncertain. Pause this assessment and return to Step 1 when the answer is established.

2What form of transformation has occurred or is proposed? Examples include feature vectors, embeddings, connectivity measures, reconstructed signals, classifiers, predictions, synthetic neurodata, trained models, model gradients, or other derived representations.

Answer	Required action
One or more forms or activities identified	Record the transformation or activity, purpose, source neurodata, technical method and resulting or assessed artefact. Identify its version and any retained intermediate representations requiring separate assessment. Continue to Step 3.
Other, but sufficiently described	Describe the activity and artefact in technical terms sufficient to assess exposure, even if no listed category fits. Continue to Step 3.
Unclear	Obtain a description from the technical lead, recipient or provider. Pause progression until the activity and assessed object can be identified. Return to Step 2. If essential information cannot be obtained, select Final Decision Outcome 4 below.

3Can the resulting artefact circulate, be accessed, queried or be deployed independently of the source neurodata? Example: a trained model, embedding repository or predictive classifier is shared without distributing the original EEG or MRI dataset.

Answer	Required action
Yes	Record the intended recipients, access mechanisms and deployment environment. Identify the controls needed when the artefact is used without the source data. Continue to Step 4. Independent circulation does not itself determine a tier.
No	Record how the artefact remains connected to, or controlled with, the source neurodata. Continue to Step 4.
Unsure	Record independent circulation as possible pending technical confirmation. Request confirmation of the architecture and access arrangements. Continue to Step 4, retaining the unresolved issue for the Final Decision.

4Can the resulting artefact, alone or with information reasonably available to the intended recipient, identify or trace a participant or re-establish linkage to the source neurodata? Examples: an embedding or latent representation unique to a participant; a synthetic dataset that reproduces training records; a model that memorises participant-level signals; outputs that carry source identifiers or acquisition metadata.

Answer	Required action
Yes	Record the identification or tracing mechanism and supporting evidence. Flag the finding for classification under Tool 1 / Supplementary Table 6 and retain applicable identification and linkage safeguards. Continue to Step 5; do not determine the final tier from this answer alone.
No	Record the supporting evidence and the additional information considered. Continue to Step 5. Absence of identification does not establish absence of inference or computational persistence.
Unknown	Record the unresolved identification or linkage question and request technical assessment. Apply the relevant provisional safeguards under Tool 1 / Supplementary Table 6. Continue to Step 5 and retain the uncertainty for the Final Decision.

5Can the artefact reveal, predict, reconstruct or profile neurological, cognitive, emotional or behavioural characteristics of an individual or group, even without directly identifying a participant?Distinguish ordinary aggregate description from material group-level Functional Exposure under Annexure 1 §2.1. Example: an EEG-derived embedding predicts cognitive decline, or a model output classifies stress, attention or neurological status.

Answer	Required action
Yes	Record the capability, affected individuals or group, supporting evidence and relevant access conditions. Record a candidate Tier 4 condition and apply Tier 4 safeguards provisionally, retaining any higher applicable safeguards. Continue to Step 6.
No	Record the evidence supporting this conclusion and its limitations. Continue to Step 6.
Unknown	Record the unresolved inferential, reconstructive or profiling capability. Apply provisional Tier 4 safeguards, retaining any higher applicable safeguards. Request the technical assessment needed to resolve the question. Continue to Step 6.

6Has neural information become, or may it reasonably have become, computationally persistent within a model, shared embedding, model gradient, synthetic-data generator, or other infrastructure in a manner capable of supporting continuing inference, reconstruction, extraction or profiling? Model incorporation alone is not sufficient; consider whether information derived from the neurodata may persist and create continuing functional exposure.

Answer	Required action
Yes	Record a candidate Tier 5 condition and the evidence of continuing functional exposure. Apply Tier 5 safeguards provisionally pending completion of the assessment. Continue to Step 7. Confirm Tier 5 only if the completed assessment meets Outcome 3.
No	Record the technical evidence supporting the absence of continuing computational exposure and its limitations. Do not assign Tier 5 solely because model incorporation occurred. Continue to Step 7.
Unknown	Record provisional Tier 5 and the unresolved persistence or exposure question. Apply Tier 5 safeguards provisionally and request specialist assessment. Continue to Step 7. If material uncertainty remains at the Final Decision, select Outcome 4 rather than confirming Tier 5.

7Has the artefact or model been evaluated, where technically relevant, for memorisation, training-data extraction, model inversion, membership inference or other forms of information leakage, under the intended access and release conditions? Where public or unrestricted release is proposed, apply the anonymity assessment: (1) likelihood of direct extraction of participant-level information from the artefact (weights, embeddings, generator); (2) likelihood of obtaining participant-level information through queries or outputs, considering all means reasonably likely to be used by any member of the public; (3) documentation of the methods, thresholds, versions and residual risk (cf. EDPB Opinion 28/2024). Example: testing assesses whether prompts, queries or attacks can recover participant-related neural information or determine whether particular records contributed to model training.

Answer	Required action
Yes—material exposure was identified	Record the methods, findings, artefact version and tested access conditions. Update the findings at Steps 4–6 as indicated by the evidence. Record a candidate Tier 5 condition where leakage demonstrates continuing model-associated or computationally persistent exposure. Continue to Step 8. Record ‘Public release not supported’.
Yes—no material exposure was identified	Record the testing scope, methods, thresholds, artefact version and access conditions. Where the tested conditions include public release and steps (1)–(3) are documented, record ‘Anonymity assessment documented: public release may be considered at Tool 2 (Supplementary Table 7) Step 3’. Do not treat the result as proof of absence of exposure beyond those conditions or automatically remove an earlier finding. Continue to Step 8.
Not tested or unknown	Obtain a technical assessment of whether testing is relevant, proportionate and feasible. Record required testing or alternative evidence, the responsible person and any remaining uncertainty. Retain applicable provisional safeguards and continue to Step 8. If material exposure cannot be assessed reliably, select Outcome 4 at the Final Decision. Record ‘Public release not supported’.
Not technically applicable	Record the technical justification and responsible reviewer. Continue to Step 8. This answer does not resolve other exposure findings. Record ‘Public release not supported’.

8Are the provenance and transformation history of the artefact sufficiently documented? Consider the source neurodata, lawful provenance, preprocessing, training purpose, model architecture, training or fine-tuning procedure, model version, vendors, cloud providers, sub processors and subsequent modifications.

Answer	Required action
Yes	Preserve or reference the provenance and version records. Continue to Step 9.
No	Identify the missing records and request them from the responsible parties. Record whether each gap affects the assessment or proposed use. Continue to Step 9, carrying unresolved gaps to the Final Decision. Do not approve affected sharing or deployment while essential provenance remains unresolved.
Unknown	Obtain information from the technical team, recipient, vendor or provider. Record the outstanding provenance questions and responsible person. Continue to Step 9, carrying unresolved gaps to the Final Decision.

9Will the proposed access or deployment conditions materially affect functional exposure? Consider downloadable copies, public release, API or query access, external hosting, fine-tuning, transfer learning, model merging, distillation, commercial deployment or access by additional recipients.

Answer	Required action
Yes	Record the conditions, their effect on exposure and the safeguards required. Revisit Steps 4–7 if those conditions change the evidence supporting an answer. Mark Supplementary Table 7 for completion or update where an external transfer or access pathway is involved. Continue to Step 9A
No	Record the assessed access and deployment conditions and why they do not materially change exposure. Continue to Step 9A.
Unknown	Obtain clarification of intended access, hosting and deployment. Do not approve the unresolved arrangement. Return to Step 9 when the conditions are established. If material uncertainty remains, select Final Decision Outcome 4.

9AHave the proposed outputs, including features, embeddings, synthetic outputs, and model weights, been assessed against applicable authorisation and release conditions?

Answer	Required action
Yes	Record the assessment, applicable conditions, responsible reviewer and approval status. Mark outstanding approvals as pending and withhold release until required approvals are obtained. Continue to Step 10.
No	Identify the required output or release assessment and responsible reviewer. Withhold release pending that assessment and any required approval. Continue to Step 10 with the requirement recorded as outstanding.
Uncertain	Obtain confirmation of the applicable conditions and whether they have been assessed. Withhold release while unresolved. Continue to Step 10, retaining the uncertainty for the Final Decision.

10Are retention, withdrawal, deletion, decommissioning and, where technically feasible, model-unlearning procedures documented and capable of implementation? Example: the project specifies how model versions and embeddings will be retained, how access will be terminated, whether derived artefacts can be deleted and what alternative controls will apply if reliable unlearning is not technically feasible.

Answer	Required action
Yes	Record the applicable triggers, responsible parties, procedures, timeframes and verification requirements. Assess the effects of EHDS opt-out, consent withdrawal, erasure requests and contractual termination separately, including their implications for previously authorised processing. Continue to Step 11.
Partly	Record unavailable controls and their consequences. Obtain review of proportionate alternatives, such as access withdrawal, version retirement, decommissioning, output restrictions or prohibition of further training. Record accepted alternatives, outstanding implementation actions and responsible parties. Continue to Step 11. Do not treat a proposed alternative as an implemented safeguard.
No or unknown	Obtain specialist technical and governance review of the limitations and possible alternative safeguards. Withhold external sharing or deployment pending that review. Continue to Step 11 with the review requirement recorded as outstanding.

11Can the identified functional exposure be managed through proportionate legal, institutional, repository, technical and contractual safeguards throughout the proposed use and deployment? Example: An fMRI-derived predictive model remains capable of neurological inference, but access is limited to approved researchers within a secure environment; queries and outputs are monitored; unauthorised profiling, retraining and onward sharing are contractually prohibited; and audit, incident-response, retention and model-decommissioning procedures are documented and enforceable.

Answer	Required action
Yes	Record the safeguards and supporting assessment. Proceed to the Final Decision. Any unresolved issue from an earlier step remains applicable.
Only after additional safeguards	Record each safeguard, responsible party and implementation evidence required. Proceed to the Final Decision, identifying any suitable tier outcome separately from outstanding implementation conditions. Do not begin the affected activity until the required safeguards are implemented and verified.
Unsure	Record the unresolved governance question and required review. Select Final Decision Outcome 4.
No	Record why the exposure cannot be managed under the proposed arrangement. Select Final Decision Outcome 5.

Final Decision: Select and document one outcome Reassessment and implementation: If the assessment changes the provisional tier, return to the Neurodata Governance Decision Tool (Supplementary Table 6). If it affects an existing or proposed transfer or access pathway, repeat the Neurodata Transfer and Access Decision Tool (Supplementary Table 7). The resulting governance determinations should then be implemented through the MDTAA Clause Selection Tool (Supplementary Table 9) where contractual governance is required.

?Outcome

Answer	Required action
Decision criterion and required action

1Retain the existing Tier

Answer	Required action
Select where documented evidence supports the existing classification of the assessed artefact, no new or increased exposure requires a higher tier, and the applicable safeguards remain suitable. Record the tier, supporting evidence, limitations and any outstanding implementation conditions. Do not convert a candidate or provisional tier into a confirmed tier through this outcome. Resolve material classification uncertainty through Outcome 4. If returning to an unfinished Tool 1 / Supplementary Table 6 assessment, resume at its next applicable step and complete Steps 5 and 6. Complete or update Tool 2 / Supplementary Table 7 where an external pathway is involved.

Answer

Required action

Select where documented evidence supports the existing classification of the assessed artefact, no new or increased exposure requires a higher tier, and the applicable safeguards remain suitable. Record the tier, supporting evidence, limitations and any outstanding implementation conditions. Do not convert a candidate or provisional tier into a confirmed tier through this outcome. Resolve material classification uncertainty through Outcome 4. If returning to an unfinished Tool 1 / Supplementary Table 6 assessment, resume at its next applicable step and complete Steps 5 and 6. Complete or update Tool 2 / Supplementary Table 7 where an external pathway is involved.

2Refer for Tier 4 classification / re-assessment

Answer	Required action
Select where a derived artefact supports identification, tracing or material inference, reconstruction or profiling consistent with Table 6 Step 4, and the assessment provides sufficient evidence that Tier 5 criteria are not met. Record the evidence and apply Tier 4 safeguards provisionally. Return to Tool 1 / Supplementary Table 6 at Step 3, follow the Tier 4 pathway and complete Steps 5 and 6. Document resolution of any candidate or provisional Tier 5 finding addressed by this assessment. Absence of evidence alone does not resolve material uncertainty. Do not automatically lower a previously confirmed Tier 5: apply the documented reassessment and approval requirements in Annexure 3 §10.3. Complete or update Tool 2 / Supplementary Table 7 using the resulting classification and safeguards where an external pathway is involved.

Answer

Required action

Select where a derived artefact supports identification, tracing or material inference, reconstruction or profiling consistent with Table 6 Step 4, and the assessment provides sufficient evidence that Tier 5 criteria are not met. Record the evidence and apply Tier 4 safeguards provisionally. Return to Tool 1 / Supplementary Table 6 at Step 3, follow the Tier 4 pathway and complete Steps 5 and 6. Document resolution of any candidate or provisional Tier 5 finding addressed by this assessment. Absence of evidence alone does not resolve material uncertainty. Do not automatically lower a previously confirmed Tier 5: apply the documented reassessment and approval requirements in Annexure 3 §10.3. Complete or update Tool 2 / Supplementary Table 7 using the resulting classification and safeguards where an external pathway is involved.

3Confirm Tier 5 classification

Answer	Required action
Select where the completed assessment demonstrates continuing functional exposure through neural information persisting within a model or computational infrastructure. Model incorporation alone is insufficient. Record the evidence and confirm Tier 5 finding. Return to Tool 1 / Supplementary Table 6 at Step 2B, record Tier 5 as confirmed and continue from Step 3, including Steps 5 and 6, to identify cumulative safeguards. Reference this completed Tool 3 / Supplementary Table 8 assessment; do not restart it solely because Tool 1 / Supplementary Table 6 refers to it. Complete or update Tool 2 / Supplementary Table 7 where an external pathway is involved.

Answer

Required action

Select where the completed assessment demonstrates continuing functional exposure through neural information persisting within a model or computational infrastructure. Model incorporation alone is insufficient. Record the evidence and confirm Tier 5 finding. Return to Tool 1 / Supplementary Table 6 at Step 2B, record Tier 5 as confirmed and continue from Step 3, including Steps 5 and 6, to identify cumulative safeguards. Reference this completed Tool 3 / Supplementary Table 8 assessment; do not restart it solely because Tool 1 / Supplementary Table 6 refers to it. Complete or update Tool 2 / Supplementary Table 7 where an external pathway is involved.

4Specialist review required

Answer

Required action

Select where material questions about exposure, persistence, testing, provenance, authorisation conditions, deployment or lifecycle controls remain unresolved. Record each unresolved question, required evidence and responsible reviewer. Retain the applicable protective provisional tier and safeguards. Where continuing computational exposure remains materially uncertain, retain provisional Tier 5 safeguards. Do not begin the activity that depends on resolution of the outstanding issue. Following review, return to the affected step, update dependent answers and reconsider the Final Decision.

5Do not proceed in the current form

Answer

Required action

Select where exposure cannot be managed proportionately, essential provenance or oversight cannot be obtained, required lifecycle controls or acceptable alternatives cannot be implemented, or the proposed activity cannot satisfy applicable conditions. Record the reasons and retain the assessment and established tier findings. Do not commence or continue the affected activity in its assessed form. If the artefact, model, access arrangement or purpose is redesigned, repeat the affected assessments before proceeding.

Maps the recorded tier, pathway conditions and transformation findings to the modules of the Modular Neurodata Transfer and Access Agreement, including the transfer-instrument module for the origin regime.

Download Tool 4 as PDF

Tool 4 — MDTAA Clause Selection Tool

1. Baseline governance moduleIs the MDTAA being used to govern the processing, access, transfer or reuse of neurodata or a governed derivative artefact? Example: A university intends to provide an external collaborator with controlled access to coded EEG recordings under an MDTAA.

If YES	If NO
Activate the Baseline Governance Module. Identify the parties, assessed objects and activities governed by the arrangement. Continue to Step 2 (Articles 3–7, 9–10 and 14–17; Schedules A and B; Annexure 4, section 5.1.)	Record “MDTAA Clause Selection Tool not applicable”. Identify whether another agreement or governance mechanism is required. End this Tool.

2. Cross-Border Transfer ModuleDoes the arrangement involve international transfer, storage in another jurisdiction or remote access from another legal jurisdiction? Example: MRI data collected in South Africa will remain on a South African server but will be accessed remotely by researchers in Germany.

If YES

If NO

Activate the Cross-Border Transfer Module. Record the originating, receiving, hosting and remotely accessing jurisdictions, the pathway class from Tool 2 (Supplementary Table 7) Step 6A and the restrictions recorded at Step 6B. Activate the Transfer-Instrument Module corresponding to the origin regime (MDTAA Part III: T-EU, T-UK, T-CH, T-BR, T-AR, T-ZA, T-NG, T-KE, T-RW, T-CA, T-US or T-GEN) and record the mandatory instrument in Schedule A Part E.5. Continue to Step 3. (Core Articles 12, 13 and 13A; the activated Transfer-Instrument Module; Annexure 2; Schedule C, where applicable.)

Do not activate this module on the basis of this step. Continue to Step 3.

3. Supplementary Safeguards ModuleDid the Neuro-TADT identify supplementary safeguards as a condition for proceeding? Examples include enhanced encryption, controlled access, local storage, additional oversight or restrictions on government access.

If YES	If NO
Activate the Supplementary Safeguards Module. Specify each safeguard identified by Tool 2 / Supplementary Table 7, the responsible party and the evidence required to verify implementation. Continue to Step 4. (Article 13A; Schedule C; relevant Annexures as identified by the Neuro-TADT).	Retain the baseline safeguards and all other safeguards required by the preceding assessments. Continue to Step 4.

4. Enhanced Neurodata Protection ModuleDoes Tool 1 / Supplementary Table 6 assessment require Tier 3, Tier 4 or Tier 5 safeguards, whether under a confirmed classification or provisionally pending further assessment? Example: Raw intracranial recordings containing persistent participant and device identifiers have been classified as Tier 3 and require enhanced access, security and accountability controls.

If YES

If NO

Activate the Enhanced Neurodata Protection Module. Incorporate the safeguards required for the applicable Tier 3, Tier 4 or Tier 5 classification, retaining safeguards associated with other conditions that remain present. Mark the selection as provisional where the classification remains provisional. Continue to Step 5. (Articles 10A and 11A; Annexure 1; Annexure 5; Schedule B-D, where applicable).

Retain the safeguards required for the applicable tier and any separately identified conditions. Continue to Step 5.

5. Derivative Neurodata ModuleDoes the arrangement involve features, embeddings, connectivity measures, predictions, reconstructed signals, synthetic neurodata or other transformed neural representations? Example: The recipient will generate and retain fMRI-derived embeddings and functional-connectivity measures rather than receiving only the original imaging dataset.

If YES	If NO
Activate the Derivative Neurodata Module. Specify the governed artefacts, permitted transformations and uses, access conditions and prohibited activities. Incorporate applicable findings from Tool 3 / Supplementary Table 8 or reference the documented exception under Annexure 1 §7.2. Continue to Step 6. (Article 10B; Annexure 3; Article 11B where deletion or unlearning is implicated.)	Do not activate this module on the basis of this step. Continue to Step 6.

6. AI and Model Governance ModuleWill neurodata or derivative artefacts be used to train, fine-tune, validate, benchmark, query or deploy an AI or machine-learning system? Example: An external research team will use EEG recordings to fine-tune and validate a machine-learning model for predicting cognitive impairment.

If YES	If NO
Activate the AI and Model Governance Module. Specify authorised AI activities, systems or models, technical environments, access restrictions and oversight requirements. Incorporate applicable conditions from Tools 2 and 3 / SupplementaryTables 7 and 8. Module selection does not itself establish Tier 5. Continue to Step 7. (Article 6A; relevant provisions in Schedule D where applicable).	Do not activate this module on the basis of this step. Continue to Step 7.

7. Controlled Access, Repository and Infrastructure ModuleWill access or processing occur through a repository, secure enclave, trusted research environment, federated system, cloud platform, vendor environment or other controlled infrastructure? Example: Researchers will analyse participant-level MRI data inside a trusted research environment that permits approved queries but prohibits downloading the underlying data.

If YES	If NO
Activate the Controlled Access, Repository and Infrastructure Module. Specify the infrastructure, access model, administrators, providers, security controls and output or download restrictions. Continue to Step 7A. (Articles 6B, 10A, 10B, and 13A; Annexures 2 and 5; Schedules C and D, where applicable.)	Do not activate this module on the basis of this step. Continue to Step 7A.

7A. Statutory Access ConditionsDoes the arrangement operate under an EHDS permit or another statutory authorisation?

If YES	If NO
Record the statutory authorisation, its status and its applicable conditions in Schedules C and D, as relevant. Identify the selected provisions that implement each condition; use Step 19 for any additional provisions required. Record any pending authorisation or unresolved condition as outstanding. Continue to Step 8.	Reference the determination made under Tool 2 / Supplementary Table 7 Step 7A that no such authorisation is required. Continue to Step 8.

8. Onward Transfer and Sub-Processor ModuleMay the recipient appoint sub-processors or provide the neurodata, derivatives or model-associated artefacts to additional recipients? Example: The receiving university proposes to use a cloud provider for processing and to share derived embeddings with another consortium partner.

If YES	If NO
Activate the Onward Transfer and Subprocessor Module. Specify permitted recipients or recipient categories, purposes, approval conditions and safeguards that must continue throughout the onward arrangement. Distinguish existing permission from permission requiring further approval and check consistency with upstream conditions. Continue to Step 9. (Article 8; SCC Annex III where applicable).	Record that onward transfer or appointment of sub-processors is not permitted under the assessed arrangement. Continue to Step 9 to specify the applicable prohibition and any approval procedure.

9, No Onward Transfer ModuleMust onward transfer, third-party access, subcontracting, cloud replication or redistribution be prohibited unless prior approval is obtained? Example: The recipient may analyse the EEG data internally but may not upload it to another repository, engage a new cloud vendor or share it with another collaborator without prior written approval.

If YES	If NO
Activate the No Onward Transfer Module. Specify the prohibited activities and any expressly permitted exceptions or prior-approval procedure. Reconcile these restrictions with Step 8 so that permitted onward activities and prohibited activities are clearly distinguished. Continue to Step 10. (Articles 8).	Confirm that any permitted onward activities and their conditions have been addressed at Step 8. If Step 8 was also answered “No”, clarify the onward-sharing position and revise Step 8 or Step 9 before continuing. Continue to Step 10.

10. Commercial Use and Intellectual Property moduleDoes the arrangement involve a commercial partner, product development, licensing, intellectual-property generation or another anticipated commercial use? Example: A medical-device company will use transferred neurodata to develop and commercialise an algorithm for detecting neurological deterioration.

If YES	If NO
Activate the Commercial Use and Intellectual Property Module. Specify permitted commercial activities, if any, together with ownership, licensing, publication and benefit-allocation conditions. Do not treat the involvement of a commercial partner or the creation of intellectual property as permission for commercial use. Continue to Step 11. (Article 3A; Schedule B where applicable).	Do not activate this module on the basis of this step. Continue to Step 11.

11. Research Use Only ModuleMust use of the neurodata and resulting artefacts be restricted to the approved non-commercial research purposes? Example: A university consortium may use the data only for the approved academic study and may not use them for product development, commercial licensing, employment screening or insurance assessment.

If YES

If NO

Activate the Research Use Only Module. Specify the approved non-commercial research purposes, authorised users and prohibited uses. Check consistency with Step 10. Where both modules apply, ensure that intellectual-property or commercial-partner provisions do not authorise prohibited commercial use. Continue to Step 12. (Articles 3–6 and 10; incorporated SCC purpose-limitation provisions; Schedules A and B; Schedules C and D, where applicable.)

Do not activate the Research Use Only Module. Specify the other authorised purposes and applicable restrictions; this answer does not permit unrestricted use. Continue to Step 12.

12. Dataset Linkage ModuleWill the neurodata be linked with genomic, clinical, behavioural, wearable, consumer, administrative, public-register or other datasets? Example: Pseudonymised EEG recordings will be linked with genomic variants and electronic health records to investigate predictors of neurodegenerative disease.

If YES

If NO

Activate the Dataset Linkage Module. Specify authorised datasets, linkage purposes, responsible parties, reassessment requirements and restrictions on further linkage. Incorporate the classification and pathway requirements identified through Tool 2 / Supplementary Table 7 Step 9 and the resulting Table 6 assessment. Continue to Step 13. (Article 4.2(b); Articles 10A and 10B; Annexure 1, section 6.1(a); Annexure 2, sections 7.1(j) and 8.1(f); Annexure 3, sections 7(e) and 10.1(e); Schedule B, Parts B–D and I; Schedule C, Parts H–I and K; Schedule D, Part H, where applicable.)

Record that dataset linkage is outside the assessed arrangement and requires reassessment before introduction. Continue to Step 13.

13. Permitted Inference and Prohibited Use ModuleCan the neurodata or governed artefact support sensitive inference, reconstruction or profiling, or are particular inferences or uses required to be prohibited? Examples include cognitive profiling, emotional inference, reconstruction of neural activity, employment screening or insurance use. Example: The approved project permits inference concerning cognitive fatigue but prohibits emotional profiling, employment screening, insurance assessment and reconstruction of unrelated mental states.

If YES

If NO

Activate the Permitted Inference and Prohibited Use Module. Specify authorised analyses, prohibited inferences and decisions, and output-review requirements. Distinguish technically possible activities from activities that are authorised. Continue to Step 14. (Article 3A; Articles 6A, 10.6, 10A and 10B; Annexure 1, sections 2–4; Annexure 3, sections 7–8 and 12; Schedule B, Parts C and I; Schedule C, Parts H–I; Schedule D, Parts D–E, where applicable.)

Retain baseline purpose limitations and all existing use restrictions. Continue to Step 14.

14. Enhanced Audit and Monitoring ModuleDo the assigned tier, Neuro-TADT outcome, AI use, recipient environment or identified uncertainty require enhanced audit, monitoring or incident reporting? Example: Access to a Tier 5 model must be logged continuously, with quarterly access reviews, documented model-version changes and immediate reporting of attempted extraction or inversion attacks.

If YES	If NO
Activate the Enhanced Audit and Monitoring Module. Specify logging, reporting, inspection, testing and audit requirements, including frequency and responsible parties. Continue to Step 15. (Articles 6, 6A.9, 13A and 15; Annexure 2, sections 6–8; Annexure 3, sections 7–10; Annexure 5; Schedule C, Parts I and K; Schedule D, Parts F and H, where applicable.)	Retain baseline audit, monitoring and incident-reporting obligations. Continue to Step 15.

15. Return, Deletion and Certification ModuleMust neurodata, copies or derivative artefacts be returned, deleted or certified as destroyed at the end of the project, following withdrawal or after another specified event? Example: At project completion, the recipient must delete all local EEG copies and derived feature files and provide written certification of deletion within 30 days.

If YES

If NO

Activate the Return, Deletion and Certification Module. Specify the objects and copies covered, applicable triggers, timeframes, responsible parties, verification evidence and permitted archival exceptions. Continue to Step 16 to address any retained model or persistent artefact separately. (Article 6 and incorporated SCC Clause 8.5; Articles 10, 11B and 15; Annexure 3, sections 7–10; Annexure 5; Schedule B, Parts D and I; Schedule C, Parts I and K; Schedule D, Parts G–H, where applicable.)

Record the authorised retention period, purpose and applicable conditions. Do not treat this answer as permission for indefinite retention or as displacing mandatory deletion obligations. Continue to Step 16.

16. Persistent Artefact, Model Retention and Unlearning ModuleDoes the arrangement involve a model, embedding or computational artefact that may persist after the source neurodata are deleted, returned or withdrawn? Example: A predictive model trained on participant neurodata will remain operational after the source dataset is deleted, requiring documented model-retention, version-retirement, decommissioning and technically feasible unlearning procedures.

If YES

If NO

Activate the Persistent Artefact, Model Retention and Unlearning Module. Specify retention, version retirement, access withdrawal, decommissioning, deletion and technically feasible unlearning procedures, including approved alternatives where necessary. Reconcile these provisions with Step 15 and the findings of Table 8. Continue to Step 17. (Articles 6A, 10B and 11B; Annexure 1, section 3.5; Annexure 3, sections 8–10; Schedule B, Parts H–I; Schedule C, Parts G–I and K; Schedule D, Parts E, G and H, where applicable.)

Do not activate this module on the basis of this step. Continue to Step 17.

17. Community, Collective and Indigenous Data Governance ModuleDoes the project involve an Indigenous community, defined population, patient group or other collective with relevant governance authority, cultural interests or community-approved conditions? Example: Neuroimaging data were collected from an Indigenous community whose recognised governance body requires continuing approval of secondary uses and representation on the data-access committee.

If YES

If NO

Activate the Community, Collective and Indigenous Data Governance Module. Specify the relevant governance body or representatives, consultation requirements, permissions, access conditions and continuing governance arrangements. Continue to Step 18. (Article 3A; Articles 5A and 9, where applicable; Schedule A, Parts A–D; Schedule B, Part I; Schedule D, Part B, where a Data Access Committee exercises continuing authority; Annexure 4, section 5.17.)

Do not activate this module on the basis of this step. Continue to Step 18.

18. Benefit Sharing and Capacity Development ModuleDoes the arrangement require benefit-sharing, local analytical access, training, infrastructure support, co-authorship, technology transfer or other capacity-development commitments? Example: An international collaborator receiving neurodata from a lower-resourced institution must provide local researchers with analytical training, access to computing infrastructure, opportunities for co-authorship and participation in downstream model development.

If YES	If NO
Activate the Benefit Sharing and Capacity Development Module. Specify the commitments, beneficiaries, responsible parties, timeframes and evidence of fulfilment. Continue to Step 19. (Article 3A; Schedule A, Parts A–B; Schedule B, Part I; Annexure 4, sections 5.10, 5.17 and 5.18, as applicable.)	Do not activate this module on the basis of this step. Continue to Step 19.

19. Optional Project-Specific ModuleAre additional jurisdictional, institutional, funder, community or project-specific requirements not addressed adequately by the preceding modules? Examples include export controls, device regulation, cybersecurity certification, publication review or specialised funder conditions. Example: A brain–computer interface project must comply with medical-device requirements, cybersecurity certification conditions and a funder obligation requiring public release of specified aggregate findings.

If YES

If NO

Activate the Optional Project-Specific Module. Specify requirements not adequately addressed by the other selected modules, including any outstanding implementation provisions identified at Step 7A. Identify the source of each requirement and how it relates to the other MDTAA provisions. Continue to Step 20. (Articles 4–5 and 18; Schedules A–D; relevant Annexures and SCC Annexes I–III, as applicable; Annexure 4, section 5.19.)

Do not activate this module. Continue to Step 20.

20. Contractual Coordination and Precedence ModuleWill the MDTAA operate alongside other legal or governance instruments? Examples include Standard Contractual Clauses, a Data Use Agreement, repository terms, institutional agreements, cloud contracts or funder conditions. Example: The transfer is governed simultaneously by the MDTAA, European Union Standard Contractual Clauses, a repository-access agreement, an institutional Data Use Agreement and the recipient’s cloud-services contract.

If YES

If NO

Activate the Contractual Coordination and Precedence Module. Identify the other governing instruments, applicable mandatory requirements and the procedure for resolving inconsistencies. Record relevant expiry or termination dates and surviving permissions or obligations. Refer proposed retention, reuse, onward transfer or model persistence beyond those dates for review where required; do not presume that expiry automatically ends all downstream permissions or obligations. Proceed to Final Decision and Implementation. (Articles 3B, 18 and 19; Schedules A–D; SCC Annexes I–III, where incorporated; Annexure 4, sections 2.7 and 5.20.)

Record the basis for concluding that no additional governing instrument applies. Confirm that the MDTAA remains consistent with applicable mandatory law and institutional requirements. If another governing instrument is identified, revise this answer to “Yes”. Proceed to Final Decision and Implementation.

Final Decision and Implementation: After completing Steps 1–20 Interpretive note: Selection of an MDTAA module does not establish that the underlying processing or transfer is lawful or that the resulting agreement is enforceable in every jurisdiction. Applicable mandatory law and authorised legal, regulatory, ethics, institutional and repository determinations continue to govern.

1.Compile and recordCompile the Baseline Governance Module and all additional modules selected. Record each selection, its trigger, the responsible party and the provisions implementing it. Complete the relevant schedules, annexures and project-specific fields.

If YES	If NO

2. Check consistencyCheck the selected provisions against Tables 6–8 and other applicable instruments. Resolve conflicting permissions or restrictions, particularly between Steps 8–9, 10–11 and 15–16. Return to the relevant assessment or selection step where clarification is required.

If YES	If NO

3. Review and finalizeObtain required legal, ethics, institutional, repository or regulatory review. Do not finalise or execute the MDTAA while mandatory review or another prerequisite remains unresolved. Record the approved agreement version and outstanding implementation conditions.

If YES	If NO

4, Implement and reassessDo not commence the relevant activity until required approvals and safeguards are in place. Reapply the affected assessments and module-selection steps when material changes alter the object, tier, purpose, recipients, jurisdictions, infrastructure, access arrangements or required safeguards.

If YES	If NO

Workflow

The four tools are used in sequence: classify the object, assess the pathway, reassess any transformation, then select the contract modules. Linkage, AI use and material changes loop back to earlier tools.

Download figure (PNG) Download figure (SVG)

Click any step to highlight what feeds it and what it feeds, and to read what the step decides. Click the background or “Reset” to clear. Hover shows a short summary.

decision stepoutputhand-off to the next toolloop back

Sixteen worked examples

Realistic arrangements drawn from current practice in the sampled regions; a red dot marks the cases that end in “do not proceed”. Click one to open it below the list: parties, data, the path through the four tools, the legal points that decide the case and the questions to put to counsel.

Open deposit of defaced MRI/fMRI from a German lab on OpenNeuro under CC0

A cognitive-neuroscience lab at a German public university has finished a study on 120 healthy adults and wants to deposit the dataset on OpenNeuro, the open neuroimaging repository operated by Stanford University, under a CC0 licence. The data have been defaced, DICOM headers stripped and acquisition dates shifted, but the lab keeps its subject-code key for future follow-up. Participants signed a GDPR-edition Open Brain Consent form that mentions open, worldwide release.

Data providerGerman public university, cognitive-neuroscience lab (controller under GDPR and §27 BDSG; ethics approval from the university committee).

RecipientOpenNeuro (Stanford University, United States): a public repository with no data-use agreement, CC0 licensing and a stated prohibition on re-identification attempts; downstream users are the general public.

DataT1-weighted structural MRI (1 mm), task fMRI runs and behavioural logs in BIDS format; defaced; no demographic detail beyond age band and sex; no clinical diagnoses.

Origin regimeGermany (GDPR, §27 BDSG)

DestinationUnited States (public repository)

Access modeDownloadable copy, public

DeterminationProceed (conditions documented)

Path through the tools

Tool 1

0B No2A No5 No6 No (public) / Yes (lab)7 No8 NoTier 1b for the public; Tier 2 for the lab's own copy. Confirmed.

Tool 2

1 Repository deposit3 Public or unrestricted release5 Downloadable copy6 Yes6A North American governance unit6B No7(i) Yes7(ii) Yes9 / 10 / 11 No12 Public release13 YesOutcome 1 — Proceed. Licence recorded; re-identification ban; takedown and response procedure documented.

Tool 3

1 NoNot required.

Tool 4

1 NoNot required.

Step-by-step

Tool 1Tier 1b for the public; Tier 2 for the lab's own copy. Confirmed.

Step	Answer	Note
0B	No	Consenting adults; no vulnerability flag.
2A	No	The object is a dataset, not a model.
5	No	Defaced; headers and dates removed; tool and version recorded.
6	No (public) / Yes (lab)	Key not available to OpenNeuro or its users; lab retains it.
7	No	Participant-level, so candidate Tier 1b.
8	No	Disclosure-risk assessment for the public: healthy cohort, no rare diagnoses, residual-risk literature noted.

Tool 2Outcome 1 — Proceed. Licence recorded; re-identification ban; takedown and response procedure documented.

Step	Answer	Note
1	Repository deposit
3	Public or unrestricted release	Permitted: Tool 1 holds a confirmed Tier 1b finding for the public.
5	Downloadable copy
6	Yes	Hosting in the United States.
6A	North American governance unit	No transfer mechanism required for data anonymous to the recipient; DPF would be unavailable to a university anyway.
6B	No	No prohibition, localisation, authorisation, sanctions or permit.
7(i)	Yes	Art. 9(2)(j) GDPR + §27 BDSG; consent covers open release (Open Brain Consent); ethics approval on file.
7(ii)	Yes	OpenNeuro terms recorded; no GDPR obligations on the repository.
9 / 10 / 11	No
12	Public release	Onward use governed by CC0 plus the repository's re-identification prohibition.
13	Yes	De-identification, licence terms, takedown procedure.

Tool 3Not required.

Step	Answer	Note
1	No	No transformation by the depositor.

Tool 4Not required.

Step	Answer	Note
1	No	No bilateral agreement for a public deposit.

Legal points that decide the case

CJEU C-413/23 P (EDPS v SRB, 4 Sept 2025): pseudonymised data may be non-personal for a recipient without means of re-identification.
Residual re-identification risk after defacing (Schwarz 2019; Steeg 2024) must be weighed in the Step 8 assessment.
EU–US DPF is available only to FTC/DOT-regulated organisations; irrelevant for anonymous data, decisive if the data were personal.

Questions to put to counsel

Does the consent text cover open, worldwide release and commercial reuse?
Is the defacing method adequate for 7T or high-resolution T1 images?
Who answers a re-identification report, and how fast?

Nigerian clinical EEG, federated training with a German consortium, public release of model weights

A federal teaching hospital in Lagos holds clinical EEG from 400 patients treated for epilepsy, including adolescents. A German university consortium proposes federated training of a seizure-detection model: raw EEG never leaves the hospital, model updates are aggregated on a cloud server, and the consortium wants to publish the final weights on a public model hub. This is the example used in the main text of the paper.

Data providerNigerian federal teaching hospital (data controller under the NDPA 2023; NHREC-registered ethics committee; likely a ‘data controller of major importance’ with NDPC filing duties).

RecipientGerman university consortium (controllers under GDPR for gradients and weights; §27 BDSG research basis) with a cloud aggregation server run by a commercial provider; the public as recipient of the released weights.

DataScalp EEG recordings (19–32 channels) with device identifiers and timestamps in the headers, seizure annotations, age, sex and medication; model gradients exchanged during training; final model weights and a model card.

Origin regimeNigeria (NDPA 2023; GAID 2025)

DestinationGermany (GDPR); public release

Access modeFederated / query-only, then public weights

DeterminationProceed in two gated passes

Path through the tools

Tool 1

0B Yes2A No5 Yes → strip → No6 YesTier 2, confirmed; nothing below Tier 2 is available because of Step 0B.

Tool 2 (training pathway)

3 Named consortium + cloud aggregator5 Federated / query-only6 Yes6A Class B6B Yes: (c) and (e)7(i) Pending7(ii) Yes10 YesOutcome 2 — Proceed after the 6B prerequisites are documented; cannot reach Outcome 1 until then.

Tool 3 (weights)

1 Yes3 Yes4 Unknown → test5 No6 Yes7 Tested, no material exposure9 / 9A Public release flagged10 YesReleased weights: Outcome 1 with the documented anonymity assessment. Development checkpoints and gradients: Tier 5 confirmed, controlled.

Tool 2 (release pathway)

3 Public release6B(d) No12 Public releaseOutcome 1 — Release with licence (no re-identification, no retraining for employment or insurance screening) and takedown procedure.

Tool 4

2 Cross-border + T-NG6 AI and model governance7 Controlled access13 Permitted inference16 Persistent artefacts and unlearning18 Benefit sharing20 Coordination; governing lawMDTAA executed with the Nigeria transfer-instrument module; no EU SCC material.

Step-by-step

Tool 1Tier 2, confirmed; nothing below Tier 2 is available because of Step 0B.

Step	Answer	Note
0B	Yes	Patients in a dependent relationship; some minors → minimum tier uplifted by one.
2A	No	Dataset, not a model.
5	Yes → strip → No	Device IDs and timestamps gave Tier 3; after stripping, reassessed.
6	Yes	Hospital holds the key; data stay in the hospital.

Tool 2 (training pathway)Outcome 2 — Proceed after the 6B prerequisites are documented; cannot reach Outcome 1 until then.

Step	Answer	Note
3	Named consortium + cloud aggregator	Aggregation server location recorded.
5	Federated / query-only	Raw EEG stays; gradients leave.
6	Yes	Gradients received in Germany.
6A	Class B	Nigeria → Germany: standard instrument under origin law; MDTAA module T-NG marked.
6B	Yes: (c) and (e)	NDPA s. 41(2) record and NDPC-recognised safeguard; NHREC clearance for the international collaboration.
7(i)	Pending	s. 30 sensitive-data basis; instrument from 6A; authority under consent and ethics.
7(ii)	Yes	German importer: Art. 9(2)(j) + §27 BDSG for gradients, treated as personal data pending Tool 3.
10	Yes	AI training → Tool 3 required before this pass can finish.

Tool 3 (weights)Released weights: Outcome 1 with the documented anonymity assessment. Development checkpoints and gradients: Tier 5 confirmed, controlled.

Step	Answer	Note
1	Yes	Model training and persistence.
3	Yes	Weights circulate independently.
4	Unknown → test	Can the weights trace a participant?
5	No	Seizure detection is the authorised purpose; no excess inference.
6	Yes	Persistence possible → candidate Tier 5.
7	Tested, no material exposure	Extraction, membership-inference and query tests documented for public release.
9 / 9A	Public release flagged	Output-release conditions assessed.
10	Yes	Checkpoint retirement and unlearning plan.

Tool 2 (release pathway)Outcome 1 — Release with licence (no re-identification, no retraining for employment or insurance screening) and takedown procedure.

Step	Answer	Note
3	Public release	Permitted because Tool 3 Step 7 holds the documented assessment.
6B(d)	No	No US party; DOJ programme not engaged.
12	Public release	Model licence with field-of-use limits.

Tool 4MDTAA executed with the Nigeria transfer-instrument module; no EU SCC material.

Step	Answer	Note
2	Cross-border + T-NG
6	AI and model governance
7	Controlled access
13	Permitted inference	Seizure detection only.
16	Persistent artefacts and unlearning
18	Benefit sharing	Local analytical access and co-authorship.
20	Coordination; governing law	Nigerian or German law chosen from the menu.

Legal points that decide the case

NDPA 2023 ss. 41–43: adequacy, appropriate safeguards or a s. 43 condition; record the basis (s. 41(2)); GAID 2025 instruments and filings [verify current NDPC list].
EDPB Opinion 28/2024 provides the model-anonymity test used at Tool 3 Step 7.
Gradients can be personal data (membership inference); treat as such until tested.

Questions to put to counsel

Has the NDPC designated any adequate country or approved instrument that covers Germany?
Does the NHREC approval name the German parties and the public release?
Which model licence terms are enforceable against downstream users?

South African university shares pseudonymised fMRI and clinical data with a UK university

A South African university hospital research group has collected task fMRI and clinical depression scores from 90 adults and wants to send a downloadable, pseudonymised copy to a UK university for joint analysis of treatment response. South Africa has no adequacy list under POPIA and health data are ‘special personal information’, so the Information Regulator’s prior-authorisation rule is in play.

Data providerSouth African public university and its academic hospital (responsible party under POPIA; information officer; NHREC-registered REC).

RecipientUK university research department (controller under UK GDPR; DPA 2018 research condition; university ethics approval).

DataTask fMRI (defaced, headers removed), structural scans, clinical depression inventories, medication history and demographics, pseudonymised with a code held by the South African group.

Origin regimeSouth Africa (POPIA)

DestinationUnited Kingdom (UK GDPR)

Access modeDownloadable copy

DeterminationProceed after authorisation

Path through the tools

Tool 1

0B Yes5 No6 YesTier 2, confirmed.

Tool 2

3 Named institution5 Downloadable copy6A Class B6B Yes: (c)7(i) Pending7(ii) Yes13 No, but can be implementedOutcome 2 — Proceed once the s. 57 authorisation (or documented s. 72(1)(a) assessment) and the agreement are in place.

Tool 3

1 NoNot required (reassess if models are built).

Tool 4

2 Cross-border + T-ZA4 Enhanced protection9 No onward transfer20 Governing lawMDTAA with the South Africa module; EU SCC articles not activated.

Step-by-step

Tool 1Tier 2, confirmed.

Step	Answer	Note
0B	Yes	Patients; dependent relationship → uplift.
5	No	Defaced; headers removed.
6	Yes	UKZN holds the key; York could request re-linkage for follow-up.

Tool 2Outcome 2 — Proceed once the s. 57 authorisation (or documented s. 72(1)(a) assessment) and the agreement are in place.

Step	Answer	Note
3	Named institution
5	Downloadable copy
6A	Class B	South Africa → UK.
6B	Yes: (c)	POPIA s. 57(1)(d): health data to a country without an adequacy finding → prior authorisation from the Information Regulator, unless s. 72(1)(a) adequacy is documented.
7(i)	Pending	s. 72(1)(a) binding agreement with substantially similar protections and onward-transfer clause; NHREC-registered REC approval; SA DTA 1.1 language.
7(ii)	Yes	York: UK GDPR Art. 9(2)(j) + DPA 2018 Sch. 1 para 4.
13	No, but can be implemented	Encryption, role-based access, audit log.

Tool 3Not required (reassess if models are built).

Step	Answer	Note
1	No	Analysis only, no model release planned.

Tool 4MDTAA with the South Africa module; EU SCC articles not activated.

Step	Answer	Note
2	Cross-border + T-ZA	Schedule ZA adopts SA DTA 1.1 s. 72 undertakings.
4	Enhanced protection	Tier 2 with 0B uplift.
9	No onward transfer	Without UKZN's written approval.
20	Governing law	South African law selected; no EU court clause.

Legal points that decide the case

POPIA s. 72(1)(a)–(e) transfer grounds; s. 57(1)(d) prior authorisation; s. 26 special personal information.
No South African adequacy list exists; institutions either apply under s. 57 or document s. 72(1)(a).
NHREC Guidelines 3rd ed. (2024).

Questions to put to counsel

Will the Regulator treat the UK as providing adequate protection for s. 57 purposes?
Does the DTA's onward-transfer clause satisfy s. 72(1)(a)(ii)?

Brazilian university hospital sends pseudonymised EEG and clinical labels to a US university for machine learning

A Brazilian university hospital research body has accessed a public-health study database (EEG with diagnoses) under LGPD art. 13 and a US university wants a downloadable copy to train a classifier. The Brazilian side has CEP approval and participant consent, and assumes this is enough; the LGPD prohibition on transferring art. 13 databases to third parties is the decisive rule.

Data providerBrazilian university hospital research body (‘órgão de pesquisa’ under LGPD art. 5 XVIII; CEP/CONEP ethics system).

RecipientUS public university (IRB; not a HIPAA covered entity for this project; not a Brazilian research body, so unable to rely on the LGPD research basis).

DataRoutine clinical EEG reports and raw traces, ICD diagnoses, age and sex, pseudonymised with a hospital-held key.

Origin regimeBrazil (LGPD; ANPD Res. 19/2024)

DestinationUnited States

Access modeDownloadable copy

DeterminationRedesign, then Proceed

Path through the tools

Tool 1

0B Yes6 YesTier 2, confirmed.

Tool 2

3 Named institution6A North American governance unit6B Yes: (a)Outcome 3 — Redesign: analysis inside the Brazilian environment (remote or federated access) with export of results only; or re-base the dataset outside art. 13.

Tool 2 (redesigned)

5 Remote access, no download6 Yes6A Governance unit6B (c)7(i) Yes7(ii) YesOutcome 2 — Proceed after CONEP approval and the access environment are documented.

Tool 3

1 Yes9A PendingOutcome 4 until output-release review is done; model stays inside the environment.

Tool 4

2 Cross-border + T-BR7 Controlled access7A Statutory conditions20 Governing lawMDTAA with the Brazil module; EU SCC Clause 8 not incorporated.

Step-by-step

Tool 1Tier 2, confirmed.

Step	Answer	Note
0B	Yes	Patients.
6	Yes	Hospital holds the key.

Tool 2Outcome 3 — Redesign: analysis inside the Brazilian environment (remote or federated access) with export of results only; or re-base the dataset outside art. 13.

Step	Answer	Note
3	Named institution
6A	North American governance unit	US not ANPD-adequate; standard instrument needed.
6B	Yes: (a)	LGPD art. 13 §2: a research body may not transfer a public-health study database to any third party. Also (c): CONEP approval of the international collaboration.

Tool 2 (redesigned)Outcome 2 — Proceed after CONEP approval and the access environment are documented.

Step	Answer	Note
5	Remote access, no download	UT Austin analysts work in the hospital's secure environment.
6	Yes	Remote access from the US.
6A	Governance unit
6B	(c)	CONEP approval; ANPD standard clauses for any residual transfer of personal data (results are anonymised).
7(i)	Yes	art. 11 II(c) for the Brazilian research body; consent scope checked.
7(ii)	Yes	IRB; HIPAA not engaged.

Tool 3Outcome 4 until output-release review is done; model stays inside the environment.

Step	Answer	Note
1	Yes	Classifier trained inside the environment.
9A	Pending	Release conditions for model and results.

Tool 4MDTAA with the Brazil module; EU SCC Clause 8 not incorporated.

Step	Answer	Note
2	Cross-border + T-BR	ANPD standard clauses attached unmodified; §6(a) art. 13 warranty.
7	Controlled access
7A	Statutory conditions	CONEP conditions recorded.
20	Governing law	Brazilian law.

Legal points that decide the case

LGPD art. 13 caput and §2; art. 5 XVIII (research body must be Brazil-seated); art. 11 II(c) unavailable to the US recipient.
Res. CD/ANPD 19/2024: standard clauses mandatory and unmodifiable; adaptation period ended 23 Aug 2025.
EU–Brazil mutual adequacy (26 Jan 2026) does not help a US destination.

Questions to put to counsel

Is the dataset an art. 13 public-health study database, or a clinical research dataset outside art. 13?
Does CONEP require a specific international-collaboration approval for remote access?

Texas HIPAA-covered hospital sends Safe-Harbor de-identified intracranial EEG to Charité

A Texas hospital that is a HIPAA covered entity has intracranial EEG from 60 epilepsy-surgery patients and wants to send a Safe-Harbor de-identified copy to Charité in Berlin for a methods collaboration. Dates are shifted and all 18 HIPAA identifiers removed; the hospital keeps the re-identification key.

Data providerTexas academic hospital (HIPAA covered entity; IRB; de-identification determination under 45 CFR 164.514(b)).

RecipientCharité – Universitätsmedizin Berlin (controller under GDPR; Art. 9(2)(j) research basis; Berlin data-protection law for hospitals).

DataIntracranial EEG (sEEG/ECoG) with electrode coordinates, seizure-onset annotations with shifted timestamps, age band, sex and surgical outcome; no names, dates or device serials.

Origin regimeUnited States (HIPAA; Common Rule)

DestinationGermany (GDPR)

Access modeDownloadable copy

DeterminationProceed

Path through the tools

Tool 1

0B Yes5 No6 No (Charité) / Yes (hospital)Tier 1b for Charité (recipient-relative), Tier 2 for the hospital; with the 0B uplift, Tier 2 governs the pathway.

Tool 2

3 Named institution6A Governance unit → EU6B (d) screened: No7(i) Yes7(ii) YesOutcome 1 — Proceed, with the recipient-relative status recorded in Schedule B.

Tool 3

1 Yes7 To be tested before any releaseOutcome 1 for internal use; release gate applies later.

Tool 4

2 Cross-border + T-US6 AI and model governance20 Governing lawMDTAA with the US module.

Step-by-step

Tool 1Tier 1b for Charité (recipient-relative), Tier 2 for the hospital; with the 0B uplift, Tier 2 governs the pathway.

Step	Answer	Note
0B	Yes	Surgical patients → uplift.
5	No	Identifiers removed per 45 CFR 164.514(b).
6	No (Charité) / Yes (hospital)	Key stays in Texas.

Tool 2Outcome 1 — Proceed, with the recipient-relative status recorded in Schedule B.

Step	Answer	Note
3	Named institution
6A	Governance unit → EU	No US transfer mechanism; import into the EU needs no mechanism.
6B	(d) screened: No	Germany is not a country of concern under 28 CFR 202.
7(i)	Yes	IRB approval; de-identification determination documented; no DUA needed (would be needed for a Limited Data Set).
7(ii)	Yes	Charité: Art. 9(2)(j) basis recorded in case the data are personal for it.

Tool 3Outcome 1 for internal use; release gate applies later.

Step	Answer	Note
1	Yes	Charité will train models.
7	To be tested before any release

Tool 4MDTAA with the US module.

Step	Answer	Note
2	Cross-border + T-US	HIPAA status and DSP screening recorded.
6	AI and model governance
20	Governing law	Texas law; Article 14.1 public-university liability limitation completed.

Legal points that decide the case

45 CFR 164.514(b) de-identification; 164.514(e) Limited Data Set DUA if dates were retained.
OHRP 2008 coded private information guidance: not human-subjects research for the recipient without the key.
28 CFR Part 202 applies only to countries of concern and covered persons.

Questions to put to counsel

Would date-shifted timestamps plus seizure-onset times be identifying in combination with publications?
Does Charité need a DPIA for intracranial recordings?

UT Austin shares a 2,500-participant MEG/EEG cohort with the Cuban Neuroscience Center

A US public university wants to share a 2,500-participant MEG/EEG ageing cohort, coded but with cognitive scores, with the Cuban Neuroscience Center in Havana under a long-standing collaboration. Cuba is a sampled jurisdiction and a ‘country of concern’ under the US Data Security Program, so sanctions and data-security screening decide the case.

Data providerUS public university (IRB; Common Rule; subject to the DOJ Data Security Program and OFAC as a US person).

RecipientCuban Neuroscience Center (CNEURO), a state research institute in Havana.

DataResting-state MEG and EEG, cognitive test scores, age, sex, education, APOE status for a subset; coded with the key held in Austin.

Origin regimeUnited States

DestinationCuba

Access modeDownloadable copy requested

DeterminationProceed after screening (or redesign)

Path through the tools

Tool 1

0B Yes6 YesTier 2, confirmed.

Tool 2

3 Named institution6A Governance unit → LAC6B Yes: (d)7(i) PendingOutcome 2 or 3 — Proceed only after screening documents that the transaction is exempt or licensed; otherwise redesign to remote analysis with aggregate outputs.

Tool 3

1 NoNot required.

Tool 4

2 Cross-border + T-US9 No onward transfer19 Project-specificMDTAA with the US module.

Step-by-step

Tool 1Tier 2, confirmed.

Step	Answer	Note
0B	Yes	Older adults, some with impairment → uplift.
6	Yes	Key held in Austin.

Tool 2Outcome 2 or 3 — Proceed only after screening documents that the transaction is exempt or licensed; otherwise redesign to remote analysis with aggregate outputs.

Step	Answer	Note
3	Named institution
6A	Governance unit → LAC
6B	Yes: (d)	Cuba is a country of concern under 28 CFR Part 202 (DOJ Data Security Program); personal health data threshold 10,000 and biometric identifiers 1,000 must be checked; covered-person rules; OFAC Cuban Assets Control Regulations govern the collaboration; EAR for software.
7(i)	Pending	Screening memorandum; OFAC general licence basis; IRB consent scope for international sharing.

Tool 3Not required.

Step	Answer	Note
1	No

Tool 4MDTAA with the US module.

Step	Answer	Note
2	Cross-border + T-US	Screening record in Schedule US.
9	No onward transfer
19	Project-specific	Export-control and licence conditions.

Legal points that decide the case

28 CFR Part 202, effective 8 April 2025; affirmative obligations from 5 October 2025; countries of concern include Cuba and Venezuela.
OFAC 31 CFR Part 515; research exemptions and general licences.
Thresholds are counted over the preceding 12 months across transactions.

Questions to put to counsel

Does the cohort size and data type meet a bulk threshold, and is any recipient a 'covered person'?
Which OFAC general licence covers the collaboration and the data exchange?

McGill gives ICM Paris remote-only access to pseudonymised 7T MRI plus genomic data

The Montreal Neurological Institute (McGill) will give researchers at the Paris Brain Institute (ICM) remote-only access to 7T MRI and genomic variants inside a Montréal secure enclave; no download is allowed, and linkage with genomic data is planned. Québec’s Law 25 treats remote access from outside Québec as a communication outside Québec.

Data providerMcGill University / Montreal Neurological Institute (public body under Québec’s access and privacy legislation; REB under TCPS2).

RecipientInstitut du Cerveau (ICM), Paris (controller under GDPR; CNIL reference methodology MR-004).

Data7T structural and diffusion MRI (defaced), genome-wide variant calls, clinical phenotypes for a neurodegeneration cohort; pseudonymised, key held by McGill; analysis outputs reviewed before export.

Origin regimeQuébec (Law 25; public-sector Act)

DestinationFrance (GDPR; CNIL MR-004; HDS)

Access modeRemote access, no download

DeterminationProceed after PIA

Path through the tools

Tool 1

0B No5 No6 YesTier 2, confirmed; reassessed after linkage (Step 9) — remains Tier 2 but identifiability from genomics recorded.

Tool 2

3 Named institution5 Remote access without download6 Yes6A Governance unit → EU6B (c)7(ii) Yes9 YesOutcome 2 — Proceed after the s. 17 PIA and agreement are documented.

Tool 3

1 Yes9A YesOutcome 1 — retain Tier 2 for exported summary results; models stay inside the enclave.

Tool 4

2 Cross-border + T-CA7 Controlled access12 Dataset linkage14 Enhanced auditMDTAA with the Canada module.

Step-by-step

Tool 1Tier 2, confirmed; reassessed after linkage (Step 9) — remains Tier 2 but identifiability from genomics recorded.

Step	Answer	Note
0B	No
5	No	Defaced 7T images; residual risk noted.
6	Yes	McGill holds the key.

Tool 2Outcome 2 — Proceed after the s. 17 PIA and agreement are documented.

Step	Answer	Note
3	Named institution
5	Remote access without download
6	Yes	Remote access from France counts as communication outside Québec.
6A	Governance unit → EU
6B	(c)	Law 25 s. 17: privacy impact assessment before communication outside Québec and a written agreement; s. 21 PIA if no consent; REB approval.
7(ii)	Yes	ICM: Art. 9(2)(j) + MR-004 compliance; no French hosting, so HDS certification not triggered.
9	Yes	Linkage with genomics → Tool 1 reapplied; dataset-linkage module.

Tool 3Outcome 1 — retain Tier 2 for exported summary results; models stay inside the enclave.

Step	Answer	Note
1	Yes	Features and models derived inside the enclave.
9A	Yes	Output review before export of results.

Tool 4MDTAA with the Canada module.

Step	Answer	Note
2	Cross-border + T-CA	s. 17 PIA referenced in Schedule C.
7	Controlled access	Enclave rules.
12	Dataset linkage
14	Enhanced audit

Legal points that decide the case

Québec Law 25 s. 17 (PIA, equivalent protection, written agreement) and s. 21 (research without consent).
CNIL reference methodology MR-004; HDS certification (CSP L.1111-8) if health data are hosted in France.
TCPS2 REB approval.

Questions to put to counsel

Does the public-sector Act's equivalent of s. 17 apply to McGill as a public body?
Does any caching in France amount to hosting under HDS rules?

Finnish registry neurodata accessed by a German group through Findata

A German group applies through Findata, the Finnish social and health data permit authority, for secondary use of registry EEG reports and diagnoses. Analysis takes place in Findata’s Kapseli environment and only anonymised results may leave after Findata’s review.

Data providerFindata (Finnish Health and Social Data Permit Authority) on behalf of registry controllers, under the Act on Secondary Use 552/2019.

RecipientGerman university research group (permit holder; analysis inside Kapseli; no copy of the data).

DataRegistry EEG reports, ICD-10 diagnoses, medication purchase records and demographic variables, pseudonymised by Findata; exported results are aggregate tables and model coefficients after anonymisation review.

Origin regimeFinland (Act 552/2019)

DestinationGermany

Access modeRemote secure environment; results only

DeterminationProceed

Path through the tools

Tool 1

0B Yes6 YesTier 2 inside Kapseli; exported results assessed separately (Tier 1).

Tool 2

5 Remote or controlled access without downloading6A Class A16B No7A Yes12 NoOutcome 1 — Proceed within the permit.

Tool 3

1 Yes9A YesOutcome 1 — Tier 1 for released results; models remain in the environment unless separately reviewed.

Tool 4

7 Controlled access7A Statutory access conditions20 CoordinationMDTAA used as the consortium's internal agreement; no transfer-instrument module needed.

Step-by-step

Tool 1Tier 2 inside Kapseli; exported results assessed separately (Tier 1).

Step	Answer	Note
0B	Yes	Patients.
6	Yes	Findata pseudonymises; key held by Findata.

Tool 2Outcome 1 — Proceed within the permit.

Step	Answer	Note
5	Remote or controlled access without downloading
6A	Class A1	Finland → Germany: same legal space; no transfer mechanism.
6B	No
7A	Yes	Findata data permit; conditions recorded.
12	No	Only anonymised results leave after Findata review.

Tool 3Outcome 1 — Tier 1 for released results; models remain in the environment unless separately reviewed.

Step	Answer	Note
1	Yes	Models trained in Kapseli.
9A	Yes	Findata anonymisation review of outputs.

Tool 4MDTAA used as the consortium's internal agreement; no transfer-instrument module needed.

Step	Answer	Note
7	Controlled access
7A	Statutory access conditions	Permit conditions implemented.
20	Coordination	Findata terms prevail.

Legal points that decide the case

Act on Secondary Use of Health and Social Data 552/2019.
EHDS secondary-use chapter applies from 26 March 2029 (2031 for some categories).

Questions to put to counsel

Does the permit cover model training and the export of model weights, or only statistical results?

Chilean university shares consumer-grade EEG from adolescents with a Spanish university

A Chilean university ran a classroom attention study with 14–17-year-olds using consumer EEG headsets and wants to send raw data to a Spanish university. Chile’s constitution protects brain activity, its new data-protection law enters into force on 1 December 2026, and the participants are minors, so consent scope and the neuro-specific rules decide the case.

Data providerChilean public university (Law 19.628 until 30 November 2026, Law 21.719 thereafter; scientific ethics committee approval; parental consent and adolescent assent).

RecipientSpanish public university (controller under GDPR and the LOPDGDD; Art. 9(2)(j) research basis).

DataConsumer-grade EEG (4–8 channels) with headset identifiers, attention-task behavioural data, classroom and school identifiers, age and grade; coded with a key held in Chile.

Origin regimeChile (Law 19.628 until 30 Nov 2026; Law 21.719 from 1 Dec 2026; Constitution art. 19 No. 1)

DestinationSpain (GDPR; LOPDGDD)

Access modeDownloadable copy

DeterminationProceed after consent and basis documented

Path through the tools

Tool 1

0B Yes5 No6 YesTier 2, confirmed; minimum Tier 2 regardless of de-identification.

Tool 2

6A Class B (from Dec 2026) / consent-based (until then)6B Yes: (f) and neuro-specific flag7(i) Pending7(ii) YesOutcome 2 — Proceed after consent scope and the Chilean transfer basis are documented; re-run on 1 Dec 2026.

Tool 3

1 Yes5 YesOutcome 2 — Refer Tier 4 for the classifier outputs.

Tool 4

2 Cross-border + T-GEN (Chile)4 Enhanced protection13 Permitted inference15 Return and deletionMDTAA with the generic module and a dated reassessment trigger.

Step-by-step

Tool 1Tier 2, confirmed; minimum Tier 2 regardless of de-identification.

Step	Answer	Note
0B	Yes	Minors → uplift; assent and parental consent recorded.
5	No
6	Yes	University holds the key.

Tool 2Outcome 2 — Proceed after consent scope and the Chilean transfer basis are documented; re-run on 1 Dec 2026.

Step	Answer	Note
6A	Class B (from Dec 2026) / consent-based (until then)	Chile → Spain; the matrix entry should be date-stamped.
6B	Yes: (f) and neuro-specific flag	Constitutional protection of brain activity (Law 21.383); Supreme Court Emotiv ruling on deletion of neural data; from 1 Dec 2026 Agency rules on transfers and minors.
7(i)	Pending	Consent of parents and assent; ethics approval; from Dec 2026 the new transfer mechanism.
7(ii)	Yes	Spain: Art. 9(2)(j) + LOPDGDD DA 17ª; minors' consent at 14 for the Spanish side.

Tool 3Outcome 2 — Refer Tier 4 for the classifier outputs.

Step	Answer	Note
1	Yes	Attention classifiers.
5	Yes	Attention/emotion inference → candidate Tier 4; permitted-inference module needed.

Tool 4MDTAA with the generic module and a dated reassessment trigger.

Step	Answer	Note
2	Cross-border + T-GEN (Chile)	Until the 2026 regime is in force.
4	Enhanced protection
13	Permitted inference	Attention only; no emotional profiling.
15	Return and deletion	Deletion on request, reflecting the Emotiv precedent.

Legal points that decide the case

Law 21.719 published 13 Dec 2024, in force 1 Dec 2026 (Agencia de Protección de Datos Personales).
Constitution art. 19 No. 1 as amended by Law 21.383 (2021); Corte Suprema Rol 105.065-2023 (Girardi v Emotiv), 9 Aug 2023.
GDPR Art. 8 and LOPDGDD art. 7 (minors' consent at 14 in Spain).

Questions to put to counsel

What transfer basis applies under Law 19.628 before December 2026?
Does the Chilean ethics approval cover export of raw neural data from minors?

KEMRI–Wellcome shares hospital EEG with Oxford, hosted in a UK cloud region

The KEMRI–Wellcome Trust Research Programme in Kenya holds clinical EEG from children with cerebral malaria and proposes to host the full dataset on a UK cloud region for joint analysis with Oxford. Kenya’s regulations require a serving copy of health-care data to remain in Kenya and a permit for research export.

Data providerKEMRI–Wellcome Trust Research Programme, Kilifi (data controller registered with the ODPC; KEMRI Scientific and Ethics Review Unit; NACOSTI research permit).

RecipientUniversity of Oxford (controller under UK GDPR) with a commercial cloud provider as processor in a UK region.

DataPaediatric clinical EEG, admission records, outcome scores at discharge and follow-up, geolocated clinic identifiers; pseudonymised with a KEMRI-held key.

Origin regimeKenya (DPA 2019; General Regulations 2021)

DestinationUnited Kingdom (UK GDPR)

Access modeCloud-hosted copy in the UK

DeterminationProceed after serving copy and permits

Path through the tools

Tool 1

0B Yes6 YesTier 2, confirmed.

Tool 2

3 Named institution + cloud provider5 Downloadable copy (cloud)6A Class B6B Yes: (b), (c), (e)7(i) Pending7(ii) YesOutcome 2 — Proceed after a serving copy is retained in Kenya, the ODPC/NACOSTI steps are documented and the reg. 41 instrument is executed.

Tool 3

1 NoNot required.

Tool 4

2 Cross-border + T-KE8 Onward transfer / sub-processor18 Benefit sharing20 Governing lawMDTAA with the Kenya module.

Step-by-step

Tool 1Tier 2, confirmed.

Step	Answer	Note
0B	Yes	Children, patients → uplift.
6	Yes	KEMRI holds the key.

Tool 2Outcome 2 — Proceed after a serving copy is retained in Kenya, the ODPC/NACOSTI steps are documented and the reg. 41 instrument is executed.

Step	Answer	Note
3	Named institution + cloud provider
5	Downloadable copy (cloud)
6A	Class B	Kenya → UK.
6B	Yes: (b), (c), (e)	Reg. 26: health-care data must be processed via a Kenyan data centre or a serving copy kept in Kenya; sensitive-data transfer needs explicit consent under s. 49 or an approved safeguard (reg. 41/46); ODPC registration; NACOSTI permit and KEMRI SERU approval; reg. 47 onward-transfer condition.
7(i)	Pending	Reg. 41 binding instrument (this agreement) or reg. 42 deemed safeguards; consent scope for export.
7(ii)	Yes	Oxford: UK GDPR Art. 9(2)(j) + DPA 2018 Sch. 1 para 4; cloud contract terms.

Tool 3Not required.

Step	Answer	Note
1	No	Analysis only at this stage.

Tool 4MDTAA with the Kenya module.

Step	Answer	Note
2	Cross-border + T-KE	Schedule KE records reg. 26 serving copy and reg. 47 undertaking.
8	Onward transfer / sub-processor	Cloud provider listed.
18	Benefit sharing	Local analytical access and training.
20	Governing law	Kenyan law.

Legal points that decide the case

Kenya Data Protection (General) Regulations 2021 regs 26, 40–48.
Reg. 42 deems states that ratified the Malabo Convention to provide appropriate safeguards (the UK has not).
Kenya DPA 2019 ss. 48–49.

Questions to put to counsel

Does 'provision of health care' in reg. 26 cover a research cohort drawn from hospital records?
Is a serving copy in a Kenyan commercial data centre acceptable to KEMRI's governance?

Argentine neuroscience institute shares pseudonymised MEG with a Spanish university under mutual adequacy

A CONICET-affiliated neuroscience institute in Buenos Aires shares pseudonymised MEG and structural MRI from 150 adults with a Spanish university for a joint study of language processing. Argentina holds a European Commission adequacy decision and recognises the EU as adequate under its own law, so no transfer instrument is needed in either direction; the example shows the simplest pathway in the matrix.

Data providerCONICET institute (controller under Law 25.326; registered database with the AAIP; institutional ethics committee).

RecipientSpanish public university (controller under GDPR and LOPDGDD; Art. 9(2)(j) research basis).

DataMEG recordings, defaced T1 MRI for source localisation, language-task behavioural data, age, sex and handedness; pseudonymised with a key held in Buenos Aires.

Origin regimeArgentina (Law 25.326; AAIP)

DestinationSpain (GDPR)

Access modeDownloadable copy

DeterminationProceed

Path through the tools

Tool 1

0B No5 No6 YesTier 2, confirmed.

Tool 2

3 Named institution5 Downloadable copy6A Class A26B No7(i) Yes7(ii) Yes13 YesOutcome 1 — Proceed.

Tool 3

1 NoNot required.

Tool 4

1 Baseline2 Cross-border (adequacy recorded)11 Research use onlyShort MDTAA; governing law chosen by the parties.

Step-by-step

Tool 1Tier 2, confirmed.

Step	Answer	Note
0B	No	Consenting adults.
5	No	Defaced; headers removed.
6	Yes	Institute holds the key.

Tool 2Outcome 1 — Proceed.

Step	Answer	Note
3	Named institution
5	Downloadable copy
6A	Class A2	Argentina → Spain: AAIP recognises the EU as adequate; EU recognises Argentina. No instrument required; record both decisions.
6B	No	No restriction; AAIP database registration confirmed.
7(i)	Yes	Consent and ethics approval cover the collaboration; Law 25.326 art. 12 satisfied by adequacy.
7(ii)	Yes	Spain: Art. 9(2)(j) + LOPDGDD DA 17ª.
13	Yes	Encryption, access control, DUA.

Tool 3Not required.

Step	Answer	Note
1	No	No models planned.

Tool 4Short MDTAA; governing law chosen by the parties.

Step	Answer	Note
1	Baseline
2	Cross-border (adequacy recorded)	No transfer-instrument module; adequacy references in Schedule A E.5.
11	Research use only

Legal points that decide the case

EU adequacy decision for Argentina (2003, confirmed in the 2024 review); AAIP list of adequate jurisdictions includes the EU/EEA.
Law 25.326 art. 12 (international transfer) and art. 7 (sensitive data).

Questions to put to counsel

Does the AAIP database registration describe the international transfer?
Is a replacement Argentine data-protection law in force at the time of transfer?

Libyan rehabilitation clinic asked to send identified EEG and video to an Italian university — do not proceed

A neurorehabilitation clinic in Benghazi treating stroke and traumatic brain injury patients is approached by an Italian university to supply EEG recordings together with video of therapy sessions for a gait-and-attention study. Libya has no comprehensive data-protection law or supervisory authority, the clinic has no research ethics committee of its own, and the videos are directly identifying. The matrix codes Libya pathways as Class E (insufficient legal certainty).

Data providerPrivate neurorehabilitation clinic in Benghazi, Libya (no data-protection statute; no research ethics committee; patient consent forms cover treatment only).

RecipientItalian public university (controller under GDPR; Garante authorisation requirements for health research under art. 110 of the Privacy Code; university ethics committee).

DataScalp EEG during therapy, synchronised video of patients and therapists, clinical notes with names and dates of birth, mobile numbers for follow-up.

Origin regimeLibya (no data-protection law; Class E)

DestinationItaly (GDPR; Garante art. 110)

Access modeDownloadable copy requested

DeterminationDo not proceed

Path through the tools

Tool 1

0B Yes5 Yes6 YesTier 3, confirmed.

Tool 2

3 Named institution5 Downloadable copy6A Class E6B Unsure7(i) No7(ii) NoOutcome 4 — Do not proceed. Specialist review may propose a redesign (ethics review through a recognised committee, de-identification, analysis in place with results only).

Tool 3

1 —Not reached.

Tool 4

1 —Not reached.

Step-by-step

Tool 1Tier 3, confirmed.

Step	Answer	Note
0B	Yes	Patients, some with cognitive impairment → uplift.
5	Yes	Faces in video, names and dates of birth in notes → Tier 3.
6	Yes	Clinic records link everything.

Tool 2Outcome 4 — Do not proceed. Specialist review may propose a redesign (ethics review through a recognised committee, de-identification, analysis in place with results only).

Step	Answer	Note
3	Named institution
5	Downloadable copy
6A	Class E	Libya → Italy: insufficient legal certainty; default Outcome 4 unless origin-jurisdiction counsel documents a lawful mechanism.
6B	Unsure	No regulator to authorise; no research-permit system; no ethics review in the origin country.
7(i)	No	No lawful basis under any origin regime can be documented; treatment consent does not cover research export; the clinic has no authority to release identified records.
7(ii)	No	Italian importer would need an art. 110 authorisation or ethics-committee route that cannot be satisfied without an origin-side ethics approval.

Tool 3Not reached.

Step	Answer	Note
1	—	Not reached.

Tool 4Not reached.

Step	Answer	Note
1	—	No agreement can be compiled while Outcome 4 stands.

Legal points that decide the case

Class E in the compatibility matrix: no statutory transfer regime, no supervisory authority, no research-governance framework to anchor consent or ethics approval.
GDPR does not restrict imports, but the Italian controller still needs a lawful basis and an ethics route that depends on origin-side approval; Garante authorisation art. 110 Privacy Code.
Identified video of patients is biometric and health data of the highest sensitivity in every regime.

Questions to put to counsel

Is there a recognised ethics committee in Libya or a regional committee that could review the study?
Could the clinic de-identify (EEG only, no video, no notes) and would that change the Tool 1 tier enough to permit a redesign?

California consumer-EEG company offers app users’ data to a Dutch university — do not proceed

A San Francisco neurotechnology company sells a meditation headband and app. It offers a Dutch university 50,000 users’ EEG sessions with mood self-reports for a stress-prediction study. Users agreed to a privacy policy covering ‘product improvement’; there was no research consent. Under California law neural data are sensitive personal information, and the purpose change is the decisive issue.

Data providerVenture-backed consumer neurotechnology company, San Francisco (business under the CCPA/CPRA with neural data as sensitive personal information; no IRB; privacy policy consent only).

RecipientDutch public university (controller under GDPR and the UAVG; research ethics committee; would need a lawful basis for data collected without research consent).

DataFour-channel consumer EEG sessions (5–20 minutes each), app usage logs, self-reported mood and sleep, device IDs, account e-mail hashes, coarse location; 50,000 users worldwide including EU residents and minors.

Origin regimeUnited States (California CCPA/CPRA neural-data provisions)

DestinationNetherlands (GDPR; UAVG)

Access modeDownloadable copy

DeterminationDo not proceed (redesign with new consent)

Path through the tools

Tool 1

0B Yes5 Yes6 YesTier 3, confirmed (Tier 2 after stripping identifiers, with 0B uplift).

Tool 2

3 Named institution6A Governance unit → EU6B Yes: neuro-specific flag7(i) No7(ii) No11 YesOutcome 4 — Do not proceed in the proposed form. Redesign: prospective opt-in research consent in the app for new sessions; or company-side aggregation to Tier 1 statistics.

Tool 3

1 —Not reached.

Tool 4

1 —Not reached.

Step-by-step

Tool 1Tier 3, confirmed (Tier 2 after stripping identifiers, with 0B uplift).

Step	Answer	Note
0B	Yes	Minors among users; consumers in a dependent relationship with the service → uplift.
5	Yes	Device IDs and hashed e-mails; sessions linkable to accounts → Tier 3 unless stripped.
6	Yes	Company holds account mapping.

Tool 2Outcome 4 — Do not proceed in the proposed form. Redesign: prospective opt-in research consent in the app for new sessions; or company-side aggregation to Tier 1 statistics.

Step	Answer	Note
3	Named institution
6A	Governance unit → EU	Consumer-privacy regime; EU import needs no mechanism but importer basis required.
6B	Yes: neuro-specific flag	CCPA/CPRA: neural data are sensitive; purpose limitation and opt-out/limit rights; data-protection assessment required before sale/sharing of sensitive data.
7(i)	No	Privacy-policy consent for ‘product improvement’ does not cover research transfer; ‘sale/sharing’ of sensitive personal information to a third party without the required notices; EU users’ data were collected without a GDPR research basis.
7(ii)	No	Dutch university cannot establish a lawful basis for data of EU residents collected without research consent; re-consent of 50,000 users is impractical.
11	Yes	Materially different purpose; approvals cannot be obtained.

Tool 3Not reached.

Step	Answer	Note
1	—	Not reached.

Tool 4Not reached.

Step	Answer	Note
1	—	Not reached.

Legal points that decide the case

California SB 1223 (2024): neural data are sensitive personal information under the CCPA/CPRA; purpose limitation, right to limit, risk-assessment regulations in force from 2026.
GDPR Arts 6, 9 and 14 for EU residents; purpose compatibility test Art. 6(4); minors’ consent Art. 8.
Consumer neurotechnology sits outside HIPAA and the Common Rule, so no research exemption applies.

Questions to put to counsel

Can the company lawfully run a prospective in-app research consent and share only newly consented sessions?
Would company-side aggregation (no participant-level records) satisfy Tier 1 and the CCPA de-identification standard?

Ontario hospital asked to give a US device company identified intracranial recordings for product development — do not proceed

A Toronto teaching hospital holds intracranial EEG and implant telemetry from 80 patients with responsive neurostimulation devices. The device manufacturer, a US company, requests the identified recordings with clinical notes to develop a commercial detection algorithm, offering a research grant. Ontario’s health-privacy law permits disclosure for research only under an approved research plan and a research agreement, and the proposed use is commercial product development with identified data.

Data providerToronto academic hospital (health information custodian under PHIPA; research ethics board; TCPS2).

RecipientUS medical-device manufacturer (commercial entity; FDA-regulated; not a HIPAA covered entity for this project; proposes to use data for product development and potential resale).

DataIntracranial EEG, device telemetry with serial numbers and stimulation logs, clinical notes with names and health-card numbers, seizure diaries; 80 patients, some minors.

Origin regimeOntario, Canada (PHIPA; PIPEDA)

DestinationUnited States (commercial)

Access modeDownloadable identified copy for commercial development

DeterminationDo not proceed (redesign as de-identified research disclosure)

Path through the tools

Tool 1

0B Yes5 Yes6 YesTier 3, confirmed.

Tool 2

3 Commercial partner5 Downloadable copy6A Governance unit6B Yes: (c)7(i) No11 YesOutcome 4 — Do not proceed. Redesign offered: de-identified dataset under a s. 44 research agreement for a defined research question, with commercial use governed separately (Tool 4 Step 10) and benefit sharing.

Tool 3

1 —Not reached.

Tool 4

1 —Not reached.

Step-by-step

Tool 1Tier 3, confirmed.

Step	Answer	Note
0B	Yes	Patients; minors → uplift.
5	Yes	Names, health-card numbers, device serials → Tier 3.
6	Yes	Hospital holds all links.

Tool 2Outcome 4 — Do not proceed. Redesign offered: de-identified dataset under a s. 44 research agreement for a defined research question, with commercial use governed separately (Tool 4 Step 10) and benefit sharing.

Step	Answer	Note
3	Commercial partner
5	Downloadable copy
6A	Governance unit	Ontario → US: PHIPA research disclosure rules; no adequacy concept; accountability by contract.
6B	Yes: (c)	PHIPA s. 44: disclosure for research only under an REB-approved research plan and a written research agreement; identified disclosure requires that de-identified data would not serve the purpose; commercial product development is not ‘research’ in the required sense.
7(i)	No	No REB-approved research plan covering commercial development; consent did not contemplate commercial use; de-identification would serve the purpose, so identified disclosure is not justifiable.
11	Yes	Commercial purpose materially different; approvals cannot be obtained in this form.

Tool 3Not reached.

Step	Answer	Note
1	—	Not reached.

Tool 4Not reached.

Step	Answer	Note
1	—	Not reached; a redesigned arrangement would activate Steps 2, 4, 6, 10 and 18.

Legal points that decide the case

PHIPA (Ontario) s. 44 research disclosure: research plan, REB approval, written agreement, and the requirement that identifying information be necessary.
PIPEDA accountability principle for any cross-border disclosure by a commercial recipient.
TCPS2 Chapter 5 (privacy) and Chapter 9 where Indigenous participants are involved.

Questions to put to counsel

Would a de-identified Limited-Data-Set-style extract serve the company’s stated purpose?
How are commercial benefit, IP and future resale handled if a redesigned research agreement is executed?

Dutch lab wants to publish a generative EEG model whose leakage tests fail — not in current form

A Dutch university lab trained a generative model on 3,000 clinical EEG recordings to produce synthetic seizures for teaching and benchmarking, and wants to publish the weights on a public model hub. Membership-inference and extraction tests show that the model reproduces near-verbatim segments of training recordings for rare seizure types, so the Tool 3 release gate fails.

Data providerDutch university hospital lab (controller under GDPR/UAVG; Art. 9(2)(j) basis for training; METC approval).

RecipientThe public, via a commercial model-hosting platform (no recipient-specific control; worldwide download).

DataGenerative model weights (diffusion architecture) trained on 3,000 pseudonymised clinical EEG recordings with seizure labels; synthetic outputs; development checkpoints and training logs.

Origin regimeNetherlands (GDPR; UAVG)

DestinationPublic release (model hub)

Access modePublic download

DeterminationDo not proceed in current form (retrain or gate)

Path through the tools

Tool 1

2A Yes2B YesTier 5, provisional.

Tool 3

1 Yes3 Yes4 Yes6 Yes7 Tested — material exposure identified10 Partly11 NoOutcome 5 — Do not proceed in the current form. Confirm Tier 5. Redesign: retrain with the rare-type records excluded and differential-privacy training, re-test; or gated access with query limits instead of weight release.

Tool 2

3 Public releaseOutcome 3 — Redesign (gated access) or wait for a re-tested model.

Tool 4

6 AI and model governance16 Persistent artefactsAgreement only for the gated-access alternative.

Step-by-step

Tool 1Tier 5, provisional.

Step	Answer	Note
2A	Yes	The object is a model → candidate Tier 5; Tool 3 required.
2B	Yes	Reasonable possibility of persistence → provisional Tier 5.

Tool 3Outcome 5 — Do not proceed in the current form. Confirm Tier 5. Redesign: retrain with the rare-type records excluded and differential-privacy training, re-test; or gated access with query limits instead of weight release.

Step	Answer	Note
1	Yes	Model training and public release.
3	Yes	Weights circulate independently.
4	Yes	Extraction tests reproduce near-verbatim training segments for rare seizure types.
6	Yes	Computational persistence confirmed.
7	Tested — material exposure identified	Membership inference above threshold; extraction of recognisable segments. Public release not supported.
10	Partly	Unlearning not reliable for the affected records; retraining without rare-type records proposed.
11	No	Exposure cannot be managed for a public release.

Tool 2Outcome 3 — Redesign (gated access) or wait for a re-tested model.

Step	Answer	Note
3	Public release	Not permitted: Tool 3 Step 7 records material exposure. Outcome 3 (redesign to gated access) recorded for the current weights.

Tool 4Agreement only for the gated-access alternative.

Step	Answer	Note
6	AI and model governance	For the gated alternative.
16	Persistent artefacts	Checkpoint retirement; re-test before any future release.

Legal points that decide the case

EDPB Opinion 28/2024: a model is anonymous only if extraction of personal data and extraction through queries are both unlikely by means reasonably likely to be used; documented testing required.
GDPR Art. 9 continues to apply to a model from which health data can be extracted; public release would be an unlawful disclosure.
Dutch UAVG art. 24 (scientific research exception) covers training, not public dissemination of extractable data.

Questions to put to counsel

Which leakage thresholds and attack models does the lab’s data-protection officer accept as the anonymity standard?
Does the METC approval cover synthetic-data generation and release, or only internal benchmarking?

Cairo hospital EEG to a London university where the required transfer licence cannot be obtained — do not proceed yet

Cairo University’s neurology department wants to send pseudonymised EEG and clinical data from 300 epilepsy patients to a London university for a genetics-of-epilepsy project. Egypt’s Personal Data Protection Law requires a licence from the Personal Data Protection Center for cross-border transfer of personal data, and the Center’s licensing procedure is not fully operational, so the prerequisite recorded at Step 6B cannot be satisfied.

Data providerCairo University Hospitals, neurology department (controller under Law 151/2020; faculty research ethics committee; Ministry of Health research approvals).

RecipientUK university research institute (controller under UK GDPR; HRA/REC approval for the UK arm; genomic data governance committee).

DataScalp EEG, clinical phenotypes, family history, planned linkage to genome sequencing performed in London; pseudonymised with a Cairo-held key; 300 patients including children.

Origin regimeEgypt (Law 151/2020; PDPC licence) [verify licensing status]

DestinationUnited Kingdom (UK GDPR)

Access modeDownloadable copy

DeterminationDo not proceed (licence prerequisite unmet)

Path through the tools

Tool 1

0B Yes5 No6 YesTier 2, confirmed.

Tool 2

3 Named institution6A Class B6B Yes: (c)7(i) No9 YesOutcome 4 — Do not proceed until the licence can be obtained. Redesign recorded: analysis in Cairo with export of aggregate results, or sequencing performed in Egypt with results-only exchange.

Tool 3

1 NoNot reached.

Tool 4

1 —Not reached.

Step-by-step

Tool 1Tier 2, confirmed.

Step	Answer	Note
0B	Yes	Patients; children → uplift.
5	No	Identifiers removed.
6	Yes	Cairo holds the key.

Tool 2Outcome 4 — Do not proceed until the licence can be obtained. Redesign recorded: analysis in Cairo with export of aggregate results, or sequencing performed in Egypt with results-only exchange.

Step	Answer	Note
3	Named institution
6A	Class B	Egypt → UK in the matrix; standard instrument under origin law.
6B	Yes: (c)	Law 151/2020 art. 14: cross-border transfer only with a licence or permit from the Personal Data Protection Center; health data are sensitive data requiring a licence to process. The Center’s licensing procedure is not operational [verify current status].
7(i)	No	Required licence cannot be obtained; no alternative mechanism in the statute; consent does not substitute for the licence.
9	Yes	Genomic linkage planned → would require re-tiering (Tier 2 remains, identifiability increases).

Tool 3Not reached.

Step	Answer	Note
1	No	Not reached for the transfer; relevant only to the redesigned analysis.

Tool 4Not reached.

Step	Answer	Note
1	—	Not reached.

Legal points that decide the case

Egypt Law 151/2020 arts 14–15 (cross-border transfer requires PDPC licence or permit); art. 12 sensitive data; executive regulations and Center operations [verify status].
UK GDPR import: no mechanism needed, but the UK controller must not induce an unlawful export.
Genomic linkage raises identifiability and triggers Tool 2 Step 9.

Questions to put to counsel

Has the Personal Data Protection Center begun issuing cross-border licences, and what is the application route for research?
Can the genetics work be re-designed so that only aggregate or non-personal results cross the border?

Sources and status

The four tools are published in the study A decision support toolkit for AI-ready neuroscience data governance (Botes et al., 2026), where they appear as Supplementary Tables 6–9; this is version 1.0. The study’s compatibility matrix, network and maps are interactive in the Legal landscape. Legal statements reflect the law in force at 31 December 2025; items marked [verify] in the examples await confirmation by the regional co-authors. Nothing on this site is legal advice.

Principal legal sources used in the examples

European Commission adequacy decisions (Argentina, Uruguay, UK renewal 19 Dec 2025, Brazil C(2026) 373 of 26 Jan 2026); EU SCCs, Decision (EU) 2021/914; EDPB Opinion 28/2024; CJEU C-413/23 P (4 Sept 2025); Regulation (EU) 2025/327 (EHDS); AI Act as amended by the Digital Omnibus (June 2026).
Lei 13.709/2018 (LGPD) arts 5, 11, 13, 33, 35; Resolução CD/ANPD 19/2024.
POPIA ss. 26, 34, 57, 72; NHREC Guidelines (2024); SA DTA 1.1.
Nigeria Data Protection Act 2023 ss. 30, 41–43; NDPC GAID 2025.
Kenya Data Protection (General) Regulations 2021 regs 26, 40–48; Rwanda Law 058/2021 arts 48–50; Botswana Act 18 of 2024.
Québec Act respecting the protection of personal information in the private sector ss. 17, 21; PIPEDA; PHIPA.
28 CFR Part 202 (DOJ Data Security Program); 45 CFR 164.514; 45 CFR 46; OFAC 31 CFR 515; Colorado HB24-1058; California SB 1223.
Chile Law 21.719 (in force 1 Dec 2026), Law 21.383, Corte Suprema Rol 105.065-2023; Mexico LFPDPPP (20 March 2025); Peru DS 016-2024-JUS; Finland Act 552/2019.