We Rewrote Our Legal Foundation

In the last few months, there have been three main signals that Blue’s terms and conditions needed to be updated.

We had 24 terabytes of pirated content on our servers.

Over the past few months, we terminated more than 100 accounts for uploading copyrighted material — software, films, music, books — that had no business being on Blue. These terminations were harder than they should have been, because our terms of service didn’t give us clean language to act on.

Blue runs the daily operations of 19,000+ organizations now.

Some of them are healthcare providers. Some are in financial services. Some are enterprises with procurement teams that read our DPA line by line before they’ll sign. The legal docs we started with — written when we were a much smaller, much simpler company — were not going to carry us into the next chapter.

V2 is coming. Our full platform rewrite ships soon.

It didn’t feel right to launch a new product with completely new infrastructure, on top of an old legal foundation.

So over the past few weeks, we rewrote it.

Legal as product

I’ve come to think that legal documents, for a SaaS company, are part of the product.

Not in a compliance-theater way. In the literal sense: what your Terms say changes what you can build, what you can promise, who will buy from you, and what you have to do when things go wrong. The docs are contracts with the real world. Writing them well is engineering with words.

So I treated this rewrite the way I’d treat a significant product release. We started with principles — what do we actually do, and what won’t we do? — mapped the surface area (nine documents, around 2,000 lines of prose), and rebuilt from the ground up.

What changed — the headlines

If you don’t want to read the rest, here’s the short version:

Two new documents. An Acceptable Use Policy and a unified list of Sub-Processors page.
Terms of Service rewritten. Numbered, modern structure. Clearer language. Explicit AI section. A document hierarchy so conflicts resolve predictably, especially for customers with custom contracts.
DPA modernized. Rewritten to contemporary enterprise standard — UK GDPR, Standard Contractual Clauses, UK IDTA, 72-hour breach notification, annual audit rights.
Sub-processors centralized. One page. Updated in one place. Clear PHI-authorized subset for healthcare customers.
AI scanning, explicit. We’ve clarified our position on using AI to scan content for abuse. We now say what we scan, why, and who makes the final call (a human, always).
Retention, unified. On termination, we send a CSV of direct download links for all your files — you have 30 days to pull everything. Data is then deleted from active systems within 90 days, and from backups within 90 days of that. The same numbers appear in every document.
“Blue is not a backup service.” Written into the AUP explicitly.

Splitting out the Acceptable Use Policy

The biggest structural change is the new Acceptable Use Policy.

Everything about prohibited content, prohibited uses, storage abuse, and enforcement used to be buried inside Terms of Service. That made it hard to update, hard for customers to find, and hard to cite when we needed to act on a violation.

The new AUP has its own page and its own lifecycle. It defines what abuse means, what happens when we see it, and — importantly — what happens to your data after. Accounts terminated for hosting pirated content get a seven-day export window for non-infringing data. CSAM (i.e. child sexual abuse material) is a zero-notice, zero-export termination, reported to NCMEC and law enforcement. Everything else has a proportional response and an appeals process with a 30-day human review.

Splitting this out means we can update acceptable-use rules as threats evolve without amending the entire Terms of Service every time.

A real sub-processor list

Our sub-processors used to be mentioned across three different documents, sometimes got out of sync with reality, and had different levels of detail.

Now there’s one page, with a table: who the sub-processor is, what they do, and where the data lives. It’s the canonical list. The DPA points to it. The BAA points to it. If we add or remove a vendor, there’s one file to update.

There’s also a separate PHI-authorized subset — only four vendors are permitted to touch Protected Health Information under our Business Associate Agreement. That used to be implicit. Now it’s explicit.

The DPA, brought forward

Our old Data Processing Agreement was functional but dated. The new one is rebuilt around how enterprise procurement teams actually read these documents in 2026.

Specifically: UK GDPR alongside EU GDPR. Standard Contractual Clauses and the UK IDTA as transfer mechanisms. A real security-incidents section with a 72-hour notification window, down from the old 14 days. An explicit audit clause, satisfiable by a SOC 2 Type II report. Clear sub-processor change procedures — 30 days’ notice, 14 days to object.

None of this is novel. All of it was missing. Enterprise buyers noticed.

AI, written down

Our policy on using AI to scan content for abuse has always been that AI systems flag potential violations. All enforcement decisions are made by humans.

The rewrite clarifies that in three places — the Terms, the Privacy Policy, and the GDPR page. The line we repeat across all three is the same: AI systems flag potential violations. All enforcement decisions are made by humans. That’s how we actually operate, and now it’s what the documents say.

Two other AI points are now explicit. We do not use your content to train AI models. And AI content scanning runs on EU-based endpoints, so your data doesn’t leave the EU for that purpose either.

Onward

Go read the updated Terms of Service, Acceptable Use Policy, Privacy Policy, and Data Processing Agreement. If you’re a healthcare customer, the HIPAA page and Business Associate Agreement have been updated too. If you’re in procurement, the Sub-Processors page is probably what you’re looking for.

V2 ships on top of this foundation. It feels right to build on something solid.