What compliance frameworks expect when you process a document

This is not legal advice, and your obligations depend on your role, your jurisdiction, and your regulator. What follows is the shape of the problem, so you know which questions to take to someone qualified.

Uploading is a disclosure

The single fact that drives everything else: pressing "upload" on a document containing personal or health data discloses that data to another organisation. It does not matter that the purpose was mechanical, that the file came back seconds later, or that the service promises deletion. A copy left your control and entered someone else's systems.

Both major frameworks treat that event as significant.

Under GDPR, an organisation processing personal data on your instructions is a processor. Article 28 requires a written contract governing that relationship, covering the subject matter, duration, purpose, security measures, subprocessors, and what happens at the end. You are also expected to use only processors offering sufficient guarantees. A converter whose entire relationship with you is a web form has not provided any of that, and if their processing happens outside the EEA, transfer safeguards apply on top.

Under HIPAA, a vendor that creates, receives, maintains, or transmits protected health information on behalf of a covered entity is a business associate, and a business associate agreement is required before the disclosure happens. Free public converters do not sign them. There is no threshold below which a single upload becomes acceptable — one patient record is protected health information.

The redaction trap

Regulated document work very often means redaction, and redaction is where well-intentioned people generate breaches.

Drawing a black rectangle over text in an annotation tool adds an opaque shape to the page. It does not remove anything. The characters underneath remain in the content stream, fully selectable, fully searchable, and fully recoverable by anyone who copies the page text or opens the file in an editor. This has produced a long series of public embarrassments involving court filings, government disclosures, and published research, and it keeps happening because the result looks correct on screen.

Real redaction removes the underlying content and then draws the marker. The redaction tool works that way, and the detailed walkthrough covers how to confirm the removal actually happened rather than assuming it did.

For documents with many recurring identifiers — names, account numbers, dates of birth, national identifiers — the automatic identifier detection tool will find candidates for you. Treat it as a first pass that improves recall, not as a signoff. Detection misses things, particularly identifiers written in unusual formats, and a human still has to look.

What "verified" means

Both frameworks expect you to be able to demonstrate that a control worked, not merely that you intended it. For redaction that means a verification step you can describe:

1. Open the redacted output and select all the text on each affected page.
2. Paste it into a plain text editor and search for the terms you removed.
3. Check the document metadata as well as the page content — author names, titles, and keywords survive page edits.
4. Look for the same data in places page-level review misses: embedded attachments, form field values, annotation text, bookmark labels, and layers.
5. Record what you checked and when.

The privacy risk scanner automates most of that sweep by listing what a file still contains after you have finished editing it. Running it on the output rather than the input is the habit worth building.

Why local processing simplifies the paperwork

Processing a document in the browser does not change your legal obligations. You remain the controller or the covered entity, you still owe the same duties of security and minimisation, and you still have to handle the file responsibly on the device you used.

What it changes is scope. If no copy of the document was sent to a third party, then there is no processor to assess, no agreement to negotiate, no subprocessor list to review, no international transfer to justify, and no vendor deletion policy to audit. An entire branch of the compliance tree simply does not exist.

That is a mundane, practical benefit rather than a dramatic one, and it is usually the deciding factor for small teams. Most organisations handling regulated documents do not have the appetite to run a vendor assessment because someone needed to rotate a scanned page.

A short operating standard

• Never upload regulated documents to a tool you have no agreement with, however reputable it looks.
• Redact by removal, never by drawing, and verify the output every time.
• Minimise before you share: send the four relevant pages, not the whole file.
• Strip metadata before external distribution.
• Keep the file on managed devices and delete working copies when the task ends.
• Write down what your team is allowed to use. Ambiguity is what produces the 3 p.m. upload of a patient record to a random converter.

The goal is not to make document work harder. It is to make the easy path and the compliant path the same path.