The Best Way to Redact Legal Documents Without Uploading Them to the Cloud

Most posts about cloud versus on-premise redaction treat the question as a checkbox exercise. Is the vendor SOC 2 certified? Do they encrypt at rest? Do they have a privacy policy? Three yeses and the document gets uploaded. For most office workers that is probably fine. For legal work it is the wrong question.

The question that actually matters, when you are redacting a privileged document, is not "is the vendor trustworthy". It is "does this document need to leave my device at all, and if it does, what changes about my duties under the rules of professional conduct?" Those are different questions, and they have different answers.

If you are here because your firm is working through whether a cloud-based redaction tool is the right fit for privileged material — or because you are the person in the firm uncomfortable with it and you are looking for a real framework rather than a vendor pitch — this post is for you. We will walk through what actually happens to a document when you upload it, why "the vendor is SOC 2" is a weaker answer than it sounds, how the rules of professional conduct treat third-party processing of privileged material, and the realistic alternatives with honest trade-offs on each.

The distinction almost nobody draws: processed on your device versus processed by a vendor

Start here, because the rest of the post depends on it. "Cloud" is a fuzzy word. In the redaction context it covers two very different things, and the marketing for both calls itself "cloud-based".

In the first model, the document stays on your device. The software runs in your browser or on your machine. There is still software involved — client-side JavaScript, WebAssembly, a native app — but the document itself never travels anywhere. There is no vendor copy, no processing server, no temp file on someone else's disk, no staging bucket waiting to be cleaned up. The only places the file has ever existed are the places you put it.

In the second model, you upload the document. It leaves your machine and travels to a vendor's servers, where their software processes it, stores the result, returns something to you, and (in theory) deletes the original at some point in the future. This is what most SaaS redaction services do. It is also what people usually mean when they say "the cloud".

Both get called cloud-based in marketing materials. They are the same word for two opposite risk profiles, and the difference is the whole ballgame for legal work. Any conversation about cloud redaction that does not draw this distinction first is not useful.

What actually happens to a document on a typical cloud-based redaction service

This is the section generic "is the cloud safe" posts skip, and it is the section lawyers should read most carefully. The due-diligence standard in most state bar ethics opinions is "understand, at a level you could explain, what happens to a document after you upload it". Here is what happens.

When you drag your PDF onto a typical SaaS redaction tool, the file travels over HTTPS from your browser to a load balancer inside the vendor's infrastructure. That load balancer usually logs the request. The log line includes your IP address, the filename, the file size, and a timestamp. Those logs are not typically classified as "sensitive data" by the vendor, so the retention policy on them is often different from — and longer than — the retention policy on the document itself.

The load balancer hands the file off to a processing server. That server writes the file to disk, either to a temp directory or to a staging bucket. Some vendors are careful and keep the file in memory. Most are not. Disk writes matter because they leave traces even after deletion, and because backups, snapshots, and disk images can capture them.

The processing server extracts text and structure, runs detection, and produces a redacted output. Most modern redaction tools are not monolithic — they call out to other services. OCR may be handled by a sub-processor. AI-based name recognition may go to a separate inference service, which may be another vendor entirely. Image processing may go somewhere else. Each of these calls is a place the document (or a derivative of it) crosses another system boundary. Each is a potential place for the file to be logged, cached, or copied.

Once the output is ready, the vendor stores both the input and the output in a results bucket. Retention on that bucket varies wildly. Some services delete within 24 hours. Some retain for 30 or 90 days for "user convenience". Some retain indefinitely unless the user explicitly requests deletion. The exact policy is usually in the privacy policy rather than on the main product page, and it may differ between the free tier and the paid tier.

The vendor also takes backups. Backups typically live longer than primary storage. A document deleted from the primary bucket on day one may still exist in a backup snapshot on day 90, accessible to anyone at the vendor with the right permissions. This is not a security failing — it is how backups work. It is also the reason "we deleted it immediately" is a weaker statement than it sounds.

Filenames, page counts, detection counts, and sometimes detection contents end up in observability systems — error logs, performance dashboards, debugging tools. This telemetry is usually retained longer than the documents themselves and is viewable by a broader set of vendor employees. A filename that contains a client name, a docket number, or a matter code has just been written into the vendor's internal systems. That may be fine. It may not be. You need to know before you upload.

Vendor employees with sufficient permissions can retrieve stored documents. Good vendors gate this behind a break-glass process that requires approval and is audited. Most vendors have at least some engineers with production access for debugging. This is not sinister. It is also not nothing, and it is the kind of detail that matters when a client asks who has seen their contract.

And finally: everything a vendor's systems can see, a vendor-side breach can expose. The question is not whether the vendor is trustworthy, because they almost always are. The question is whether their security posture is strong enough that you would be comfortable defending your choice to use them if their systems were breached tomorrow. That is a real question, and it is not answered by a SOC 2 logo on a homepage.

Why legal work changes the calculation

A generic "is the cloud safe" conversation treats all data as roughly equivalent. For legal work, three things change that. Each one raises the stakes of a wrong call, and each one shows up in the rules of professional conduct you are bound by.

Attorney-client privilege

Attorney-client privilege protects confidential communications between lawyer and client made for the purpose of legal advice. The question courts sometimes have to resolve is whether disclosure to a third party — like a vendor processing the document — waives that privilege. The modern answer from case law across multiple jurisdictions is that disclosure to a vendor who is bound to confidentiality and whose involvement is necessary for the rendering of legal services generally does not waive privilege. That is a meaningful protection, and it is the reason lawyers use vendors at all.

"Generally does not" is not "never does", though, and the protection assumes the vendor is actually bound to confidentiality in a legally enforceable way. A standard clickwrap Terms of Service on a SaaS redaction tool is not automatically such a binding. The risk is not that you will be sued for malpractice the moment you upload a document. The risk is that in the specific case where something goes wrong — a breach, a discovery dispute, a privilege challenge in the middle of litigation — your upload decision will be second-guessed, and "the vendor was SOC 2 certified" is a weaker answer in front of a judge than "the document never left my office".

Work product doctrine

Work product doctrine protects material prepared in anticipation of litigation. It has its own waiver rules, similar in structure to privilege but not identical. Sharing work product with third parties who are not covered by the protection can waive it, subject to the same kind of exceptions for vendors bound by confidentiality. The practical point is the same as for privilege: every additional party you add to the chain is additional surface area for a waiver argument, and the cleanest answer is always "the material never left the people who were supposed to see it".

ABA Model Rule 1.6(c) and the duty of technological competence

Rule 1.6(c) of the ABA Model Rules of Professional Conduct says a lawyer "shall make reasonable efforts to prevent the inadvertent or unauthorized disclosure of, or unauthorized access to, information relating to the representation of a client". Most states have adopted some version of this rule. Comment 18 to the rule lists the factors a lawyer should consider in assessing what counts as reasonable: the sensitivity of the information, the likelihood of disclosure if safeguards are not employed, the cost of additional safeguards, the difficulty of implementing them, and the extent to which safeguards would adversely affect the lawyer's ability to represent the client.

This is the rule lawyers point to when they talk about "reasonable efforts" with technology. Note what it does not say. It does not prohibit cloud tools. It does not mandate client-side processing. What it requires is a deliberate, informed choice about what to send to a third party and what not to, calibrated to the sensitivity of the material. A brief you are editing is not the same as a document containing a client's confidential business strategy, their medical history, or their unredacted financial records. Reasonable efforts for the first is not reasonable efforts for the second.

The rule also does not require you to be a security expert. It requires you to make decisions at the level of a competent lawyer who has thought about the specific risks and taken proportional steps. Uploading a highly sensitive document to a redaction service because it was the default tool in the firm's workflow, without having considered whether a non-upload alternative existed, is a weaker record than uploading the same document after documenting why no alternative was workable.

State bar ethics opinions on cloud computing

Multiple state bars — New York, California, Massachusetts, Pennsylvania, and many others — have issued ethics opinions addressing cloud computing and third-party processing of client information directly. The specifics vary. The through-line across jurisdictions is consistent: cloud computing is not per se prohibited, lawyers must perform reasonable due diligence on the vendor, they must understand where data is stored and who can access it, they must have a plan for retrieving or deleting the data at the end of the relationship, and they must disclose the use of the service to the client where it would be material to the client's understanding of the representation.

"Reasonable due diligence" is the load-bearing phrase. It is not satisfied by reading the vendor's homepage. It is not satisfied by a checkbox on an IT intake form. It means understanding, at a level you could explain to a partner, a client, or a bar counsel, what happens to a document after you upload it. Which is to say, it means understanding the walkthrough in the previous section. If you cannot describe it, you have not done the due diligence the opinions require.

The realistic options, with honest trade-offs

There are four workable approaches to redacting legal documents without exposing them to the kind of vendor-side processing the previous section describes. None of them is a universal answer. The right choice depends on the document, the client, the matter, and the infrastructure your firm already has.

Option 1: Client-side or in-browser redaction tools

These are tools that run entirely in your browser or as a local app, with the processing happening on your device. The document never travels to a vendor server. The vendor ships the software to you; the document stays where it was.

The strengths are exactly the things the first half of this post was about. There is no vendor copy. There is no sub-processor exposure. There is no temp file on someone else's disk. The privilege analysis is dramatically cleaner, because there is nothing to argue about — the document never left the people who were supposed to have it. The Rule 1.6 analysis is cleaner too: reasonable efforts is a very easy case to make when the file did not leave your device.

The trade-offs are real and worth naming honestly. The vendor ecosystem is smaller; there are fewer client-side redaction tools than server-side ones. Some heavy processing — very large AI models, massive OCR workloads — is slower or not available in a browser environment. You are still trusting the software itself to behave correctly, which is not the same as open-source or formally audited (though some client-side tools offer both). And you still have a vendor relationship for licensing, support, and billing — it just does not involve the document.

Option 2: On-premise desktop tools (Adobe Acrobat Pro, Nitro, Foxit)

The classic option. Install the software on your machine, run it locally, redact the document. The file never touches a remote server because there is no remote server in the workflow.

The strengths are feature depth and institutional familiarity. Acrobat in particular has been the baseline for legal document handling for two decades. Everyone knows how to use it. The IT team already supports it. The document stays on the endpoint throughout.

The trade-offs cluster around the two-step redaction process that these tools use. In Acrobat specifically, you mark redactions, then you apply them, then you run a separate Sanitize step to remove hidden data. Users who know the workflow get it right. Users who do not — which turns out to be most users — miss the apply step or skip the sanitize step, and the resulting file still contains the "redacted" text. This failure mode is the single most common source of the famous public redaction disasters, and we cover it in depth in our Adobe Acrobat vs RedactVault post. The short version is that on-premise is a good data-handling answer but it is only a good redaction answer if the people using it actually complete the two-step dance every time, without fail.

The other trade-off is that the document now lives on the endpoint, which makes endpoint security the limiting factor. A redacted document on a laptop that gets stolen is a different problem from a redacted document on a vendor server that gets breached. Most firms have better controls on the laptop than on the vendor, but "most" is not "all".

Option 3: Air-gapped workflow

For the most sensitive material — classified, export-controlled, matters under a strict protective order, certain national-security-adjacent work — the right answer is an air-gapped workstation. No network connection, no vendor calls, no telemetry. The document moves in and out on physical media, which introduces its own handling risk but removes the entire remote attack surface.

This is operationally painful and overkill for almost all normal litigation work. It is also the right answer when the wrong answer is career-defining. Firms that handle any regulated material at all usually have at least one such workstation somewhere. The relevant question for this post is not "should you use air-gapping for everything" — the answer is obviously no — but "does your firm know which documents should go to the air-gapped workstation, and is the workflow actually followed?"

Option 4: A managed cloud service under a strict vendor contract

For some kinds of legal work — large-scale e-discovery, document review pipelines running into the millions of documents, matters that require specialised processing at a scale no desktop can handle — a managed cloud service is the only realistic option. This is not a failure mode. It is a legitimate choice that the rules of professional conduct clearly contemplate and the case law has repeatedly accepted.

The key to making it a reasonable choice is the contract. A well-drafted data processing agreement or vendor services contract can bind the vendor (and its sub-processors) to the kind of confidentiality that privilege analysis requires. It should specify retention periods, deletion mechanics, breach notification timelines, sub-processor disclosure, employee access controls, and an exit process for retrieving or destroying the data at the end of the engagement. Reviewing that contract properly is legal work in itself, and it is not something to delegate to IT unless IT happens to be a lawyer.

The trade-off is that the contract protects you against claims but does not prevent the exposure itself. If the vendor is breached, the documents are exposed regardless of what the contract says. The contract is a defence, not a shield.

The meta-point: match the option to the document

Most firms use a single redaction workflow for every document, because that is the easy way to run a practice. The sensible approach is tiered. Not every document needs the same level of care, and not every document needs the same tool.

A rough tiering that works for most firms:

The point of tiering is not that cloud services are bad. The point is that "what tool do we use for this document" is a real question, and the answer depends on the document. Treating every document the same is how firms end up uploading the wrong thing.

A framework for deciding, in four questions

When you are staring at a specific document and trying to decide whether to upload it, these four questions will usually give you a clean answer in under a minute.

If the answer to question 1 or 2 is yes, and the answer to question 3 is "I do not actually need to upload", you should not be uploading. That is the simplest version of reasonable efforts, and it is defensible. Everything else is a judgment call based on the specifics of the document, the alternatives available, and the firm's overall risk posture.

Where RedactVault fits, and where it does not

Short and factual, because this is not a sales page. RedactVault is a browser-based redaction tool. The document is processed in your browser — detection, redaction, and export all run on your device. The file does not travel to our servers for processing, and we do not have a copy.

This is a good fit when the thing you are trying to avoid is exactly what the first half of this post described: the vendor-side copy, the sub-processor exposure, the backup retention, the telemetry, the argument about whether the upload waived privilege. If the document never leaves your browser, none of that applies.

It is not the right fit for every situation. We are not built for full-scale e-discovery pipelines running millions of documents — that is a different tool category with different requirements. We are not built for workflows that require server-side AI models too large to run in a browser. And we are not the answer for firms whose IT policy specifically requires a vendor contract with certain data residency or audit commitments that a browser tool cannot map onto cleanly.

We want to be the right answer for the "this document should not leave my office" use case. We do not want to be the wrong answer for anything else, and we will tell you when we are.

The through-line

Legal work does not raise the bar on redaction because clouds are bad. Clouds are fine. Legal work raises the bar because the downside risk of a wrong call is higher, the rules of professional conduct explicitly require you to think about it, and the default assumption — "this SaaS tool everyone uses is probably fine for this document" — is not a decision, it is the absence of one.

The right answer for most firms is tiered, matched to the sensitivity of the document in hand, and defensible if anyone asks about it later. The simplest way to make a document defensible is for it to never leave your device, which is what client-side and on-premise tools give you. The simplest way to make a document indefensible is to upload it without thinking, because it was the default, and to find out later that the default was wrong.

You have real options. Use the one that matches the document.