Why Your LaTeX Tool Needs a Signed DPA (and What’s In It)
If you write research in a browser-based LaTeX editor, your draft paragraphs, figures, citation library, and co-author email addresses all sit on someone else’s servers. That arrangement has a name under EU law. You are the data controller, the editor is the data processor, and the document that binds the two of you is the data processing agreement (DPA). Most academics never think about it. Their university’s legal team does, which is why a missing or unsigned DPA can quietly block a tool from ever being approved for institutional use.
This is the plain-English version. What a DPA actually is, why a LaTeX editor needs one, what clauses to look for, and how inscrive.io handles it.
What a data processing agreement actually is
The GDPR splits responsibility between two roles. The controller decides why and how personal data gets processed. The processor handles that data on the controller’s behalf. When you upload a manuscript with your collaborators’ names and institutional emails, you are processing personal data, and the editor that stores it is your processor.
Article 28 of the GDPR is explicit: a controller may only use a processor that provides “sufficient guarantees” to meet GDPR requirements, and that relationship must be governed by a contract. That contract is the data processing agreement. It is not optional. Without it, you (or more precisely, your institution) are technically in breach the moment real personal data lands in the tool.
A useful way to think about it: the DPA is the leash. It defines what the processor is allowed to do with your data, what it must never do, and what happens when the relationship ends.
Why a LaTeX editor needs one specifically
People assume DPAs are for CRMs and HR systems, the obviously personal-data-heavy software. A collaborative writing tool feels more innocent. It isn’t.
Consider what actually flows through a shared LaTeX project:
- Author names, affiliations, and email addresses in the project’s collaborator list.
- Acknowledgements, funding statements, and ethics declarations naming individuals.
- In some fields, the manuscript body itself contains personal data: interview excerpts, patient identifiers in a methods section, survey respondent details.
- Comments and edit history that reveal who wrote what and when.
That last point matters more than people realise. Unpublished work is sensitive in a way that has nothing to do with GDPR categories. A grant proposal, an embargoed result, a thesis chapter under examination. You want a contract that constrains how a vendor treats all of it, and the DPA is where that lives.
What’s actually in a DPA
A proper Article 28 agreement covers a handful of recurring clauses. Here is what each one means without the legalese.
| Clause | What it commits the processor to |
|---|---|
| Subject matter and duration | What data is processed, for what purpose, and for how long. |
| Processing only on instructions | The processor acts only on your documented instructions, never for its own purposes. |
| Confidentiality | Everyone with access is bound by confidentiality obligations. |
| Security measures | Specific technical and organisational measures (encryption, access control, the kind of thing certified by ISO 27001). |
| Sub-processors | Which third parties get involved, and your right to be informed and object. |
| Assisting the controller | The processor helps you answer data subject requests and breach notifications. |
| Deletion or return | At the end, data is deleted or returned, your choice. |
| Audits | You can verify compliance, often via an independent inspection or audit report. |
The two clauses that quietly cause the most trouble in academic procurement are sub-processors and international transfers.
Sub-processors: who else touches your data
Your editor probably doesn’t run its own data centre. It rents infrastructure, maybe uses an email provider, perhaps an analytics tool. Each of those is a sub-processor, and each one is another company touching your data. A good DPA lists them, commits the vendor to flowing the same obligations down to them, and gives you the right to object when a new one is added.
When the sub-processor list includes US-based companies, you inherit a transfer problem whether you wanted to or not. This is exactly the gap that bites EU universities reviewing American tools. We dig into the mechanics of that in our piece on Schrems II and your academic software stack.
International transfers: the clause that triggers Schrems II
If any personal data leaves the EU, the DPA has to address how that transfer is made lawful. Standard contractual clauses, transfer impact assessments, supplementary measures. It gets complicated fast. The cleanest way to make this clause boring is to never transfer data outside the EU in the first place.
How inscrive handles the DPA
inscrive is built in the EU for exactly this kind of scrutiny. Here is the concrete situation.
All data stays in the EU. Projects are hosted by Hetzner in Germany and Finland, in ISO 27001-certified data centres. No third-country transfers. That single fact removes the entire transfer-clause headache and sidesteps the Data Privacy Framework uncertainty that hangs over US-hosted competitors.
A signed DPA is part of the Organizations offering. For institutional customers, inscrive provides a signed data processing agreement alongside SSO, central user management, and EU data residency. That is the document your DPO or procurement office will ask for, and it exists. There is also an independent inspection and audit report backing the security claims, not just a marketing page.
inscrive never uses your data to train AI models. The Pro tier includes AI assistance that suggests fixes for LaTeX compile errors, but your manuscripts are not training material. We treat that as a baseline commitment, not a premium feature. More on that distinction in is your writing tool training AI on your unpublished research.
It is worth being clear about tiers. inscrive is freemium. The Free plan gives you EU data residency and full GDPR compliance at zero cost, up to 10 active projects with unlimited collaborators. The signed DPA specifically is part of the Organizations plan, because that is the document an institution signs centrally on behalf of its researchers. An individual on the Free tier still benefits from the same EU hosting and GDPR posture, but the negotiated, signed contract is an institutional artefact.
What to ask a vendor before you commit
If you are evaluating any LaTeX editor, or any cloud writing tool, these five questions separate the compliant from the hopeful:
- Will you provide a signed DPA, or only a click-through one in your terms?
- Where is the data physically stored, and is any of it outside the EU?
- Who are your sub-processors, and are any of them in a third country?
- Do you use customer documents to train AI or improve models?
- Can you show an independent audit or inspection report for your security claims?
A vendor that answers these crisply has done the work. One that gets vague about sub-processors or hosting location is telling you something. For a fuller buyer’s-side view of EU hosting and data residency, the inscrive GDPR page lays out the specifics, and our broader compliance overview covers the regulatory backdrop.
The short version
A data processing agreement is the contract that turns “we promise to look after your data” into something enforceable. For a collaborative LaTeX editor handling unpublished research and collaborator details, it is not paperwork you can skip. The cleanest setups make the hardest clauses, transfers and sub-processors, irrelevant by keeping everything in the EU and refusing to train AI on your work.
inscrive.io keeps your research on EU soil, signs a real DPA for institutions, and never trains AI on your documents. Start writing, it’s free, and check the GDPR page for the details your DPO will want.
