Drawing a black box over sensitive text in a PDF editor does not redact it. If the underlying data layer remains intact, anyone with a mouse can highlight the area, copy it, and paste the plain text into a new document.

That mistake has exposed public court filings, corporate M&A deals, and sensitive audit packages. It happens because three fundamentally different file controls—masking, redaction, and encryption—get treated as interchangeable synonyms.

They are not. Each control operates on a different layer of the data structure, solves a distinct security problem, and fails under entirely different conditions.

  • Masking substitutes values for non-production environments.
  • Redaction permanently strips content from shared copies.
  • Encryption restricts who can open and read the underlying file.

Applying the wrong control leaves a false sense of security while leaving the data exposed. This guide breaks down how each mechanism works, where each one stops, and how to combine them without leaving blind spots.

The Short Answer

Attribute Masking Redaction Encryption
What it does Replaces sensitive values with realistic fake ones Permanently removes sensitive content from a document Makes the whole file unreadable to anyone not authorized
Reversible? Usually not, by design No, if done correctly Yes, for authorized users
Who sees the sensitive part? Nobody downstream Nobody downstream Authorized people only
Best for Test and analytics data, realistic samples Documents shared outside with specific parts removed Files that must stay whole and only some people may open
Where it fails A mask that can be reversed or guessed A "redaction" that only hides the text visually Once an authorized person opens the file, the content is readable by them
Mostly applies to Structured data, such as databases Unstructured documents and files Unstructured files and objects

Hold that table in mind. The rest of this post is the reasoning behind each row.

Did the Original Ever Leave Your Control?

Redaction and masking change a copy. Encryption protects the original, wherever it travels. See how per-file protection works on your own documents in a two-week pilot.

See Per-File Protection on Your Own Files

What Is Data Masking?

Data masking replaces sensitive values with substitutes that look real but are not. A real credit card number becomes a different, valid-looking one. A real name becomes another name. The format survives; the information does not.

Masking exists because developers, testers, and analysts need realistic data without needing real people's data. A test database with real customer records is a breach waiting to happen. A test database with masked records is just a test database.

Masking has two common shapes. Static masking creates a permanently altered copy. Dynamic masking changes what a user sees at query time without changing the stored data.

Two things to know. First, masking is built mostly for structured data: rows and columns in databases and data warehouses. Tools in this category, such as Informatica and Delphix, work on that kind of data. Second, a mask is only as good as its irreversibility. If the substitute values follow a pattern, or the same input always produces the same output, someone can often work back to the original.

💡
Where masking stops: it does not help much with a contract, a design file, or a board deck. Documents are not tables.

What Is Redaction?

Redaction permanently removes sensitive content from a document before it is shared. Done correctly, the text is gone from the file, not covered up.

That last clause carries all the weight. Real redaction deletes the underlying text, images, and metadata. Fake redaction draws a box, applies a highlight, or changes a font color, and leaves the original content in the file for anyone who knows to look.

Redaction is the right tool when a document must be shared, but not all of it. Court filings, freedom-of-information responses, audit packages, contracts sent to third parties, and files given to a vendor all fit.

Adobe Acrobat Pro includes a redaction feature that removes the underlying content when applied. Many other tools do the same. Whichever you use, verify the result. Copy the "redacted" area into a text editor and see what comes out.

💡
Where redaction stops: it changes a copy. The original still exists, and anyone who can open the original can read everything you removed. Redaction protects the recipient from seeing the parts. It does not protect the original from being taken.

What Is Encryption?

Encryption transforms a file into unreadable data that only authorized people can turn back into the original. Unlike masking and redaction, it is reversible by design. The point is not to remove information. It is to control who can read it.

For files, there are different levels. Disk encryption protects a device if it is lost. Transfer encryption protects a file while it moves. File-level encryption protects the file itself, so the protection stays with it after it is downloaded, forwarded, or copied somewhere you do not control.

💡
Where encryption stops: once an authorized person opens the file, they can read it. Encryption decides who gets in. It does not shrink what they see. That is why encryption and redaction do different jobs, and why using one in place of the other leaves a gap.

How to Choose: Four Questions

Pick the control by asking what the recipient needs.

  1. Does anyone downstream need the sensitive part? If no, remove it. Use redaction for documents or masking for data sets. Nobody should receive what they do not need.
  2. Does the document have to stay whole? If yes, redaction is out. Use encryption, and decide who can open it.
  3. Could the original be taken, copied, or forwarded? If yes, redaction of a copy does not protect the original. Protect the original too.
  4. Do you need realistic data without real people? If so, that is masking for structured data.

Most real situations need two controls, not one.

Situation Right control
Sending a contract to an auditor who needs most of it but not the bank details Redact a copy
Giving developers a realistic customer database to test with Mask the data
Sharing a design file with a supplier who needs the whole file Encrypt the file, limit who can open it
Publishing a document with certain names removed Redact, then verify the redaction
Keeping a board deck confidential while executives forward it internally Encrypt the original
Giving a vendor a redacted contract while the original stays internal Redact the copy and encrypt the original

The last row is the one most programs miss. They redact the copy and leave the original in a shared folder with default permissions.

Where These Controls Fail

Each has a characteristic failure. Know it before you rely on it.

Fake redaction: A black box, a highlight, or white text on a white background. The content stays in the file. Check by selecting, copying, and pasting. Also check the metadata and document properties, which can hold names, tracked changes, and comments.

Reversible masking: If a mask follows a pattern, or the same input always gives the same output, an attacker with a little outside information can reverse it. Test it the way an attacker would.

The original still exists: Redaction and masking produce copies. The sensitive original sits somewhere. If its only protection is a folder permission, a stolen login opens it. This is the most common real-world gap.

Encryption that ends at the container: Disk and transfer encryption protect a laptop or a connection. They do nothing once the file lands in an inbox or a download folder in readable form. This is Teach A in its plainest form: your container security ends where the file does, and the file leaves the container every single day.

Over-sharing the decrypted file: Once an authorized user opens an encrypted file, they can read it. If they should have seen only part of it, encryption alone was the wrong tool. A redacted copy for that recipient would have fit better.

Where AI Tools Change the Question

AI assistants have made this decision more urgent. When someone pastes a document into an AI tool, everything in it goes with it.

A redacted copy limits what the tool sees, which is a reason to redact before anyone shares a document for summarization. But redaction depends on someone remembering to do it, correctly, every time. It also does nothing about the original, which the same person can paste in a minute later.

For the original, the question is what the AI tool can read when it receives the file. If the file is protected on its own, an unapproved tool receives nothing. Our post on stopping sensitive files from entering ChatGPT, Copilot, and Gemini covers how that works, and the AI acceptable use policy guide covers the policy side.

The point for this post is narrower. Redaction and encryption are not alternatives. Redaction decides what the recipient is allowed to see. Encryption decides whether the recipient may open the file at all. Mature programs use both.

Theodosian unifies continuous cloud discovery, agentic classification, and file-layer protection. It continuously inventories unstructured files across cloud storage, maps access risks, and enforces policy—from AI egress rules to per-file encryption. It does not perform database-row masking or document text redaction. If a recipient should only see part of a document, use a redaction tool on a copy, and let Theodosian discover, classify, and protect both the original and the redacted file.

What This Means for Your Security Program

The decision is not "which control is best." It is "what does each recipient need, and what happens to the original?"

If a recipient does not need the sensitive content, give them a copy without it. Mask or redact, then verify. If a recipient needs the whole file, make sure only the right people can open it. Encrypt it, per file, with an access rule that checks who is asking, from where, and when. And whichever you choose, protect the original, because the original is the file an attacker wants.

Redaction answers "what can this person see." Encryption answers "can this person open it." You need an answer to both.

See Per-File Protection on Your Own Files

We run a two-week pilot on a defined set of your files. You choose them. We show you what happens when one is downloaded, forwarded to an outside address, and then revoked.

Start a Two-Week Pilot

FAQs: Redaction, Masking, and Per-File Protection

Does Theodosian redact or mask data?

No. Theodosian provides continuous cloud discovery, agentic classification, and file-layer protection. It continuously inventories your cloud storage and controls who can open sensitive files. However, it does not redact text inside documents or perform database-row masking. If a recipient should see only part of a document, use a redaction tool on a copy, and let Theodosian discover, classify, and protect both the original and the redacted file.

If we already redact documents before sharing them, what does Theodosian add?

Redaction protects what a recipient sees in the copy you send. It does nothing about the original, which usually sits in a shared folder protected only by permissions. Theodosian gives the original its own key and an access decision every time someone opens it, so a stolen login or a forwarded file does not hand over the unredacted version. You keep your redaction process.

Can we protect both the original and the redacted copy?

Yes. Each file is protected on its own, so you can protect the original, protect the redacted copy, or both, and set different access rules for each. A common setup is to restrict the original to a small group and allow the redacted copy to a wider one.

What happens if someone forwards a protected file to an outside address?

The recipient receives an encrypted file. Opening it requires an access decision against your policy: who is asking, from which device, from where, and when. If your policy does not approve that person, they cannot read it, and the attempt is logged. You can revoke access after the file has left. In the pilot, you run this on your own files and watch the result.

Does protecting a file stop an authorized person from copying what they see?

No. Theodosian enforces context-aware access decisions (identity, device, location, time) at the moment a file is opened or decrypted. Once an authorized user opens an unencrypted view in a native application, it does not prevent them from copying text, printing, or taking a screenshot (full in-use DRM restrictions are on our product roadmap). If a recipient should only see part of a document, redact a copy for them prior to sharing.

What would a two-week pilot show us?

We protect a defined set of your files, over your existing Microsoft 365, Google Workspace, or cloud storage, with no data migration. You see what happens when a file is downloaded, forwarded outside the company, and then revoked, along with the per-file access record from your own environment. You finish with a clear answer to the question redaction cannot answer: what protects the original?

Data Classification Levels: How to Tier Your Files

What Does AI Data Governance Require at the File Layer?

Does Encrypting Your Files Actually Protect Them From Ransomware?

Per-File Encryption vs. Disk Encryption vs. DLP