Your clinic stays the controller of every patient record you send to a lab; the lab is normally your processor. That single split drives everything else: a written Article 28 agreement, a short list of security measures, a fixed breach-reporting window and a retention rule for scans. If any of those four is missing, you have a compliance gap, not a paperwork nuance.
Scans, photographs and prescriptions describe the state of a patient's teeth and jaw, so they count as health data. GDPR Article 9 prohibits processing such data unless a specific exception applies, and the relevant exception for treatment is the healthcare exception in Article 9(2)(h). That exception requires processing by, or under the responsibility of, a professional bound by secrecy. Your lab technicians work under your instructions, so the secrecy duty has to reach them in writing.
The eight-point checklist for clinic-lab data flows
Use this table to audit your current lab relationship in ten minutes.
| Check | Who owns it | What good looks like |
|---|---|---|
| Roles defined | Clinic and lab | Clinic is controller, lab is processor, stated in a contract |
| Article 28 agreement | Clinic signs, lab complies | Covers instructions, confidentiality, sub-processors, deletion or return |
| Data minimisation | Clinic | Case code instead of name; no date of birth unless the appliance needs it |
| Secure transfer | Both | Encrypted portal, not ordinary email or consumer file-sharing |
| Sub-processor list | Lab | Named cloud, CAD and support vendors, with their locations |
| Breach window | Both | A fixed notification time written into the agreement |
| Retention rule | Clinic decides | Defined period for scans, photos and designs, plus a deletion routine |
| Records of processing | Both | Each party documents this processing |
Who is controller and who is processor?
The European Data Protection Board (EDPB) defines a controller as the party that decides why and how data is processed. A processor handles data on the controller's behalf and can never set its own purposes. A role comes from what a party actually does, not from its trade label.
For a standard order, the split is simple. You decide that a patient needs a retainer and what it should look like. The lab prints or thermoforms it to your prescription and deletes the data afterwards. That is textbook processor work.
The role flips when the lab starts deciding purposes of its own. Using your scans for marketing images, training an in-house design algorithm or building a case library for other clients are all examples. For those activities the lab acts as a controller and needs its own legal basis. Write the prohibition into the agreement.
Regulators check this. In April 2026 Estonia's Data Protection Inspectorate ordered a dental practice to rework its Invisalign processing because role allocation with the aligner manufacturer was unclear and its patient information fell short. The Inspectorate found that the manufacturer was at least a joint controller, not a mere processor. The lesson for labs and clinics is to settle roles before the first case, not after a complaint.
What the Article 28 agreement must contain
Article 28 requires a written contract, electronic form included. It must set out the subject matter and duration, the nature and purpose of processing, the types of personal data and the categories of patients. It must also bind the lab to:
- process data only on your documented instructions;
- keep everyone with access under a confidentiality duty;
- apply the Article 32 security measures;
- engage sub-processors only with your prior specific or general written authorisation, and inform you of changes;
- help you answer patient access and deletion requests;
- delete or return all data when the service ends;
- allow audits and give you the information needed to prove compliance.
Check the sub-processor clause first. A lab that hosts files with a cloud provider, uses a CAD platform with remote support or outsources printing is passing your patients' data down a chain. If the agreement allows general authorisation, insist on advance notice and a right to object.
Are STL files personal data?
Treat them as personal data. GDPR covers any information relating to an identifiable person, directly or indirectly, and identifiability depends on the means reasonably likely to be used. Not every STL is identifiable by itself. However, one academic analysis concluded that an intraoral scan can identify a patient through physical features, while a plaster model alone did not count as personal data, though both were medical documentation. Scans also usually arrive with a filename, scanner metadata or a prescription that names the patient.
Our own guide to STL files in orthodontics makes a related point: the mesh contains no patient identifier, so your filing system has to link each file to the right record. That is exactly where pseudonymisation helps.
Replacing the name with a case code reduces risk, and the EDPB encourages it. It does not take the data outside GDPR. Under the EDPB's January 2025 pseudonymisation guidelines, data that can be attributed to a person with additional information stays personal data, even when the key is held elsewhere. You still need the agreement, the security measures and the retention rule. The gain is that a misdirected email or a leaked file no longer reveals who the patient is.
Security measures that auditors expect
Article 32 asks for measures proportionate to the risk, "as appropriate": pseudonymisation and encryption, ongoing confidentiality and integrity, the ability to restore availability after an incident, and regular testing of the measures. For an orthodontic lab, that translates into concrete practice:
- Intake: an encrypted partner portal with per-user accounts, rather than attachments sent to a shared inbox.
- Production floor: workstation screens that show case code and appliance type, not a full patient name.
- Access: only the technicians working on a case can open it; leavers lose access the same day.
- Backups: encrypted, tested for restoration, and covered by the same deletion schedule as live files.
- Testing: a periodic check of who has access to what, documented.
Quality systems help here. Professional labs in the Baltics and Scandinavia typically align with ISO 13485, which already means checking each file at receipt. Our overview of orthodontic lab quality control shows where file receipt checks sit in that chain; the same intake gate is the natural place to verify that a case carries a code and no unnecessary identifiers.
Breach notification: the 72-hour clock
Under Article 33, you as controller must notify your supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless it is unlikely to risk patients' rights and freedoms. A late notification needs a written reason. The lab, as processor, must tell you without undue delay.
The law does not fix a number of hours for that last step, so your agreement should. Consider requiring notice within 24 hours, which leaves you most of your 72. Without a number, a lab that waits two days to tell you leaves you a very short window to investigate and report.
Consider a hypothetical example. A Helsinki clinic sends about 40 cases a month to a Tallinn lab. A technician attaches a scan and prescription to an email addressed to the wrong clinic. With a case-code system, the recipient sees a code, a scan and an appliance type. Without one, the recipient sees a full name and date of birth. The first is a contained incident and may be judged low-risk after assessment. The second is probably reportable. The technician's mistake is identical, but the outcome is not.
Enforcement in the region focuses on exactly this territory. Norway's authority fined St. Olavs Hospital NOK 750,000 (about €76,870) for security failures involving patient health data under Article 32. Breaches of the processor and security provisions fall under the lower fine tier of Article 83(4): up to €10 million or 2% of worldwide turnover, whichever is higher. No Nordic or Baltic fine against a dental lab turned up in our research, so treat the risk as real but unquantified for this sector.
Retention: how long may the lab keep scans?
Storage limitation means personal data may be kept only as long as needed for the purpose, and the European Commission notes that legal retention duties count when you set the period. Two different clocks apply in a lab.
The first is the MDR. Custom-made devices need an Annex XIII statement that identifies the patient by name, an acronym or a numerical code. The manufacturer must keep that statement for at least 10 years after the device is placed on the market (15 for implantables). A numerical code is enough, which is another reason to use case codes. This retention rule applies to the statement itself, not to every scan and photo behind it. Our guide to orthodontic lab regulatory compliance covers the MDR side in more detail.
The second clock is operational. Labs keep a digital archive so they can reproduce a lost retainer or modify an appliance without a new impression, which is a legitimate reason. The controller, you, decides how long that lasts. Pick a period, put it in the agreement and make the lab delete or return files when it expires. Indefinite storage "just in case" cannot be justified under the storage limitation principle.
International transfers and cloud vendors
A clinic in the Baltics or Nordics sending data to a lab in Estonia stays inside the EEA, so Chapter V of GDPR is not triggered by the handover itself. The risk sits further down the chain. If the lab's CAD vendor, cloud host or support team can reach files from outside the EEA, that remote access can count as a transfer. EDPB guidance says health data transferred outside the EEA must satisfy Chapter V in addition to the normal rules.
Valid tools are an adequacy decision, such as the EU-US Data Privacy Framework for certified US companies, or the Commission's standard contractual clauses with a transfer assessment. After the Schrems II ruling, exporters must check the destination country's law case by case and add supplementary measures where needed. In July 2026 the EDPB asked the Commission to examine whether a US Supreme Court judgment affects the Framework. It did not ask for suspension, and the decision remains in force as of this writing. Ask your lab which transfer basis each non-EEA vendor uses and keep the clauses as a fallback.
When these rules apply differently
Several situations change the picture:
- In-house or group labs. If the lab belongs to your own legal entity, there is no separate processor. Where a group shares decisions on purposes, you may be joint controllers and need a different arrangement.
- Large-scale processing. A Data Protection Officer is mandatory only when core activities involve large-scale processing of special-category data. A small clinic or lab often falls below that line, but the call depends on volume and national guidance. A DPIA is required before large-scale health-data processing.
- Records of processing. The usual exemption for organisations under 250 employees does not apply when special-category data is processed. Keep the record.
- National health laws. Sweden's Patient Data Act and Norway's Patient Record Act add health-sector rules on top of GDPR. Article 9(4) lets member states add conditions for health data, so check your own country's patient-record rules before setting retention.
None of this is legal advice. Have your data protection officer or counsel review the agreement before signing.
Where to start this week
Pull your current lab agreement and test it against the eight-point table: roles, sub-processors, breach window and retention are the usual gaps. Then switch your case submissions to case codes and an encrypted portal, which cuts risk faster than any policy document. Our guide to clinic-to-lab data exchange shows how to structure submissions so files arrive complete. If you want a lab partner that works through a dedicated partner portal and logs every case at receipt, contact the Nordicdens team and ask how your cases would be handled and documented.
