Sensitive data, handled properly.
Most transfer refusals come down to missing documents: a data flow diagram, a lawful basis written down per category, and a processor agreement with a named sub-processor list. The science is rarely the problem. We design the architecture so that as little as possible has to move, and we write the documents that say so.
When your data protection officer declines, it is usually because they are being asked to sign something nobody has described to them, and they are right to.
We have written these documents enough times to know which sentence a committee stops on, and which architecture makes the whole question smaller. The cheapest way to pass a data protection review is to need less data in fewer places.
So the work runs in that order: design the flow, minimise what moves, separate the keys, log everything. Only then do we write the paperwork, and by that point it simply describes what exists.
We act as your processor under a written agreement, and you remain the controller. That split decides who answers to whom.
Move the data, or move the model?
A multi-centre study needs one analysis across eleven hospitals. There are two architectures, and the choice decides how much of the next year you spend in meetings. Flip the switch.
Federated analysis is not always the answer. Pooling is sometimes required, and sometimes simply permitted. Either way, make the decision early, with the cost of each option on the table, so it does not surface in month seven.
Eight things that make a study approvable.
Written down before the first record
Which article, for which data category, for which purpose — including the special-category conditions research relies on, and the national derogations that qualify them.
- Article 6 and 9 bases stated per processing activity
- Consent, public interest or legitimate interest, with the choice justified
- Secondary use and further processing addressed up front
The link lives somewhere else
Identifiers replaced with study codes; the mapping held in a separate service with its own access control, so most of the team works on data that cannot identify anybody.
- Key custodian named, access to the mapping logged separately
- Re-identification only where the protocol requires it
- Quasi-identifier risk properly assessed
Your perimeter, if that is the answer
Your own datacentre or hospital network, one of ours, a partner datacentre in Denmark or Germany, a partner datacentre in the United States where that is appropriate, or public cloud. The system is the same in all of them. Which one we use is a policy decision we take with you per study; there are no product tiers.
- Data residency named in the contract, per study
- EU/EEA by default for special-category data; anything else is a documented decision
- Inside national secure environments where the data may not leave at all
Encrypted, minimised, accounted for
Transfers designed to carry the least that answers the question, over channels your security team has approved, with a record of exactly what left and who received it.
- Variable-level minimisation, not "the whole export"
- Modern transport and at-rest encryption with managed keys
- Transfer register: what, when, to whom, under which agreement
Least privilege, and a record of it
Role-based access reviewed at every amendment, multi-factor authentication or institutional single sign-on, and immutable logs that answer "who saw this record" in one query.
- Per-record read and write history
- Export events logged with justification
- Quarterly access review with a signed result
What your DPO actually asked for
DPIA, record of processing, processor agreement, data flow diagram, security description, retention schedule, and the ethics annexes that reuse all of it.
- Written in the committee's language
- Kept current as the study changes
- Reusable across your group's next application
Working inside somebody else's walls
Some data legally cannot leave the environment it lives in. We have collaborated with Statistics Denmark, the CPR register, Statens Serum Institut and several of the Danish regions — including a service of ours running inside the Capital Region of Denmark's own datacentre.
- Pipelines built to the environment's constraints: no internet, limited packages
- Outputs prepared to pass disclosure control the first time
- Deployment inside a hospital region's datacentre where that is the only option
Plans that name people
An incident response procedure with named humans and a 72-hour clock, and retention schedules that actually execute.
- Breach assessment and notification support
- Deletion on schedule, with a certificate
- Withdrawal that propagates to every copy
Making data shareable.
Groups often buy either of these on its own, when one dataset needs to become shareable and the rest of their infrastructure can stay as it is.
And an honest risk assessment
Structured data, free text and images de-identified to a stated standard, with a re-identification risk assessment to back it up. Health data with dates, diagnoses and a geography is very hard to make genuinely anonymous, and we would rather tell you where you actually stand.
- Quasi-identifier analysis, k-anonymity and population uniqueness
- Free text scrubbed, with the residual risk quantified
- DICOM de-identification including burned-in text in the pixels
- A written statement your DPO can rely on, including its limits
Realistic, and nobody in it
A generated dataset that preserves the structure, distributions and awkwardness of the real one without containing any real person. You can publish it as a reproducible supplement, teach a course with it, and test a pipeline on it before the approval arrives.
- Marginal and joint distributions preserved to a stated fidelity
- Utility and privacy both measured and reported
- Published alongside your code so a reviewer can run it
- Used for teaching, testing and development without an approval
Pick the option that needs the least permission.
Ranked by how hard they are to get approved. Most projects can move up this list without losing anything scientific — and the ones that cannot should find that out in week one.
| Option | What leaves the site | Use when | Approval burden |
|---|---|---|---|
| Federated analysis | Model parameters and aggregate statistics only. No records. | Multi-centre studies where the analysis can be expressed as fitting a model per site and combining. | Lowest — often no transfer agreement at all |
| Aggregate exchange | Counts, means and covariance matrices above a disclosure threshold. | Meta-analysis of individual sites, or descriptive comparison across a consortium. | Low — usually a data sharing letter |
| Pseudonymised transfer | Row-level data with identifiers replaced; key retained at source. | The analysis genuinely needs individual records together — joint models, matching, rare outcomes. | Moderate — processor agreement, DPIA, ethics annex |
| Analysis inside the source | Nothing. Results are checked for disclosure and exported. | Registry or regional data that may not leave the environment it lives in. | Moderate — the environment's own approval, granted to you, then output checking |
| Identifiable transfer | Data that can identify a person. | Almost never. Linkage and recruitment are the honest exceptions, and both can usually be redesigned. | Highest — expect to justify every field |
Compliance as a by-product of the build.
We generate these documents alongside the system, which is why they match what the software actually does. A data flow diagram drawn from the deployed architecture cannot drift from it.
Everything here is yours, in editable formats, reusable for your group's next application. Several departments now use our annex set as their internal template, which we take as a compliment and do not charge for.
- Written for the committee that has to read them
- Kept current, so an amendment updates the documents along with the code
- Reviewed by people who have sat on the other side of a submission
- Data protection impact assessment — with the risk table filled in for your study
- Record of processing — Article 30, per activity
- Data processing agreement — plus a current sub-processor list
- Data flow diagram — drawn from the deployed architecture
- Security description — encryption, access, logging, backup, testing
- Pseudonymisation procedure — including who holds the key
- Retention & deletion schedule — with the mechanism that executes it
- Incident response plan — named roles, 72-hour clock
- Ethics annexes — reusing all of the above, in their format
- Participant-facing information — in language a person can read
The rows your IT security team will tick.
- Encryption
- TLS 1.3 in transit; AES-256 at rest with keys in a managed key service or hardware security module. Key material never in the same trust boundary as the data it protects.
- Authentication
- Institutional single sign-on (SAML or OIDC) preferred; multi-factor authentication mandatory otherwise. Session policy and device requirements set with your security team, not by us alone.
- Authorisation
- Role-based with data access groups, least privilege by default, export rights held separately from read rights, and a documented approval step for any elevation.
- Logging
- Append-only audit logs for authentication, record access, changes and exports. Retained per your policy, queryable by you, and outside the reach of the accounts they record.
- Backup & recovery
- Encrypted backups with a 15-minute recovery point objective and a 4-hour recovery time objective. Restores tested quarterly, with the test result sent to you.
- Testing
- Dependency and container scanning in the pipeline, annual third-party penetration testing on internet-facing systems, and remediation timelines agreed by severity.
- Sub-processors
- A short, current, named list with the purpose and location of each. Changes notified in advance with a right to object. No sub-processor outside the EU/EEA without your explicit approval.
- Segregation
- One study, one isolated environment. No shared database schema between projects, no shared credentials, no cross-study analytics — including ours.
- Standards alignment
- ISO 27001-aligned engineering practice, ICH-GCP where the study is regulated, and NIS2 obligations respected where our client is in scope. We will tell you what we are certified for and what we are merely aligned with.
- Exit
- Full export in open formats, documented deletion of our copies with a certificate, and a transition period defined in the contract before you need it.
From "legal said no" to an approved flow.
Map what exists
Every place the data currently sits, every person who can reach it, every transfer that already happens. Usually more places than anyone expected.
- Systems, people, copies
- Existing approvals read
- Gaps listed plainly
Redesign the flow
Minimise, separate and relocate until the remaining question is small enough to be answered easily.
- Federated where it works
- Keys split from data
- Unneeded fields dropped altogether
Write the documents
DPIA, processing record, agreements and annexes describing the design as built, reviewed with your DPO before anything is submitted.
- Draft for your DPO
- One revision round
- Submitted in their format
Operate & review
Access reviews, log monitoring, amendment updates, and the retention clock actually running.
- Quarterly access review
- Documents kept current
- Deletion when due
What committees actually ask.
Are you a controller or a processor?
Processor, in essentially every research engagement. You determine the purposes and the means; we act on documented instructions under a written agreement. That means we cannot use your data for anything else — including improving our own products — and we do not.
There are narrow cases where we are a joint controller, typically when we contribute the research question as a partner rather than the infrastructure as a supplier. Where that applies we say so in writing and the agreement changes shape accordingly.
Can you work with the Danish registries and secure environments?
We have collaborated with Statistics Denmark, the CPR register and Statens Serum Institut, and with several of the Danish regions' own datacentres. The most concrete example: our transcription service for researchers runs inside the Capital Region of Denmark's own datacentre, on their hardware, under their policies — which is the same pattern any analysis inside a secure environment follows.
That experience means we know the constraints before we meet them: no internet, a fixed list of packages, and disclosure control on every output. We build pipelines to those limits and prepare exports so they clear disclosure control the first time. The access itself is granted to you, and we work under your project authorisation.
Is "anonymised" enough to escape GDPR?
Rarely, and treating pseudonymised data as anonymous is the single most common mistake we correct. Pseudonymised data is still personal data. Genuinely anonymised data — where re-identification is not reasonably possible for anyone, including the holder of the key — falls outside GDPR, but health data with dates, diagnoses and a geography is very hard to get there.
We assess it properly: quasi-identifier combinations, population uniqueness, and what an adversary with an auxiliary dataset could do. If the answer is that it is not anonymous, we say so, because being wrong about this is what turns a paper into an incident.
What happens when a participant withdraws?
The withdrawal is recorded with its scope and date, future contact stops immediately, and the participant's data is handled according to what the consent and the ethics approval actually say — which is often "no further collection" rather than "delete everything", for good scientific reasons.
We insist that the mechanism exists and works: withdrawal propagates to invitation lists, to the next analysis freeze, and to any downstream copy. If a withdrawal only updates one field in one system, the promise to the participant has not been kept.
Does the AI part change the data protection picture?
The principles stay the same; what changes is what has to be documented. In the configuration we recommend, the language model sees metadata only (variable names, types, value labels, missingness counts), and the code it writes executes next to the data inside your environment.
Where a model must run on content, we deploy it inside your perimeter. Either way the processing is described in the DPIA, the model provider appears on the sub-processor list if one is involved, and EU AI Act obligations are assessed explicitly. See AI-assisted analysis.
We had an incident. Can you help?
Yes. Speed comes first, and blame can wait. We help establish what happened and what data was involved, assess whether the notification thresholds are met, draft the notification and the participant communication if one is required, and then fix the cause.
If the system was ours, that assessment is ours to make and we will not soften it. If it was not, you get the same help without a lecture.
Governance is the floor the rest is built on.
Bring the objection. We will bring the document.
If a data protection review has stalled your study, send us what you have and what you were told. In a week you get an assessment of why it stalled, the architecture change that would remove the objection, and a draft of the document that is missing.