Remove Sensitive Material From a Pitch PDF: Redact the File or Rebuild a Clean Edition?
Remove Sensitive Material From a Pitch PDF: Redact the File or Rebuild a Clean Edition?
A black rectangle over a phone number is a drawing. Not a removal — a drawing, sitting on top of text that is still in the file, still selectable, still extractable, still there. The page looks right at 100% zoom on a bright screen, which is the entire sense in which it is clean.
The subtler version of the same mistake: the redaction that was applied, on a file that still carries the attached budget, the reviewer's sticky note, the paragraph hidden under a shape on page two. Both failures come from collapsing two questions into one.
What is this recipient allowed to receive? That is a disclosure decision.
How do I get the excluded material out of the file? That is a removal operation.
Do them in that order. The first one produces a list you can check against. The second produces a file that either matches the list or doesn't.
There are two honest routes. Applied redaction, where you work on the existing document and remove regions of it. And a clean rebuild, where you author a new, smaller document from approved material and never import the rest. They fail differently, they cost differently, and neither is proved successful by how the pages look.
Define the shareable account before touching the file
Start with the recipient and the purpose, because those two facts decide almost everything downstream. A development executive deciding whether to take a meeting needs different material than a co-production lawyer reading a term sheet, and a deck built for the second reader is not a safe starting point for the first.
Then write two lists. Not in your head — on the same page as the file you're about to produce.
The approved content set: every claim, image, and figure that may leave, in the form it may leave in. The removal list: everything excluded, with the specific string, object, or region identified well enough that someone else could search for it.
The removal list is where people get lazy, and the laziness has a shape. It tends to contain names, numbers, and anything that looks like a secret, while missing the sentences that quietly qualify a claim. Here is a real dilemma hiding in an ordinary sentence:
We can shoot inside the depot in week one. Access is agreed in principle with the site manager, Dee Marchetti; the signed facilities release is still outstanding.
Suppose the site manager has asked not to be named at this stage. The name is a removal item. The caveat is a survival item — the claim "we can shoot inside the depot in week one" is not accurate without it, and "still outstanding" is doing more work than most of the page. They live in the same sentence. A redactor working region by region will delete the whole thing and walk away satisfied, having removed exactly what the list asked for.
So the approved content set has to specify what a claim means once it survives, not just which blocks are permitted. Write the replacement sentence down. If the recipient cannot be told about the outstanding release, the claim has to weaken — "we have agreed access in principle with the site" — and someone has to decide that on purpose, not discover it in the export.
One thing this does not do: it does not decide whether you are allowed to disclose any of it. That decision belongs upstream, with whoever holds the rights and the relationships, and the file work below assumes it has already been made in your favor.
Choose the route that fits the source and the required result
Now the comparison, and it is not a comparison of safety. It is a comparison of what each route makes easy and what each makes invisible.
Applied redaction suits a document where the layout carries meaning and most of the content is approved: a designed deck with a director's statement, stills placed at particular sizes, a one-page schedule that reads as a schedule. You keep the structure and the existing assets, and you pay for that by inheriting the whole container — every channel the document accumulated on its way to you.
A clean rebuild suits a small approved set, or a source where the excluded material is scattered, layered, or invisible. You start from nothing and add only what is approved, and you pay for that by authoring a document where context can quietly go missing — and by creating a fresh opportunity to reintroduce excluded material when someone gets tired and pastes a whole page across.
A third option belongs here too, because it is often the right answer and rarely considered: a new one-page summary written for this recipient, of which the twelve-page deck is the private original. If the approved content set is four paragraphs and two stills, you are not producing a reduced edition of the pitch. You are producing a different document that happens to be about the same film.
Now the fixture, so the rest of this is concrete. Everything about it is invented; no real material appears in it.
A fictional feature documentary, Nightjar. A two-page pitch, nightjar_pitch_v7.pdf, prepared for a development executive. Page one holds the logline, a director's statement, the depot access claim and its caveat, and a contact block. Page two holds two cleared stills, a top-line budget range, and the ask.
Permitted to leave: the logline, the statement, the access claim with the site manager's name removed and the caveat kept, the schedule line, the company email and production office phone, the two stills, the single budget range.
Not permitted: the director's personal mobile and personal email in the contact block; the site manager's name, Dee Marchetti, inside the page-one access sentence, while the caveat sharing that sentence survives; a sticky note anchored to the post-production line reading "Deferred rate, not yet agreed — do not quote this figure"; an embedded spreadsheet, nightjar_budget_working_v3.xlsx; a paragraph on page two sitting under an opaque panel, containing the phrase "two-part pre-sale" and a commercial detail that must not circulate before the trade announcement; the document properties, where the Author field holds a personal name and the Title holds nightjar_pitch_v7_FINAL_KH; and a hyperlink on page two whose visible label is "Sizzle reel — password nightjar26", pointing at an unlisted URL.
Seven things to find. Two of them — the panel paragraph and the comment — are not visible on the page in the ordinary sense. That asymmetry is the argument for reading the removal list before choosing a route, because one of these routes requires you to see what you are removing, and the other does not.
Apply removal rather than covering the page
Adobe's Acrobat desktop help describes the sequence as marking regions for redaction, applying the redaction, an offered sanitization step, and saving the result (its Redact sensitive content in Acrobat Pro page, checked September 2026). The menu path changes between builds and I am not going to reproduce one here; go to your own build's current documentation, because the sequence is the part that travels and the clicks are the part that doesn't.
What travels is this: a mark is not an applied redaction. Marking is how you tell the tool where; applying is what removes the content from the page and replaces the region with a filled box. A document closed with unapplied marks still contains every character those marks sat on. If you have ever dismissed a warning about unsaved redactions and assumed the file was safe because the boxes were on screen, that is this moment.
Applying redactions handles content. It does not handle the document. Adobe treats hidden-information removal as a separate operation, covering metadata, comments, and hidden layers, with a choice between removing everything or only selected items (Sanitize PDFs in Acrobat Pro, also checked September 2026). Both of those help pages are documentation of a workflow, and neither one certifies the file you are about to send. Applying a tool is not evidence about a derivative.
Selective removal is a real decision, not a formality. Whatever you leave unchecked stays in the file on purpose, and the check record should be able to say why. Run the pass, then save under a new name — never the original's — and leave the private original untouched in a private location. Editing the only copy is the one mistake on this page with no recovery.
Rebuild from approved ingredients
A rebuild produces a file whose starting condition is emptiness. Nothing is in it that you did not put there, which means the comment, the attachment, and the panel paragraph are absent by construction rather than removed by operation. That is a genuine advantage — you cannot fail to find what was never imported.
It also means every element you add is a new decision. Track where each came from: this paragraph is approved text from page one, this still is a cleared image file, this figure is the approved range. Anything whose provenance you cannot state does not go in. And in particular, do not place a source page into the new document and crop it. Cropping hides; it does not delete. The panel paragraph and its commercial detail would still be sitting under the crop, waiting for anyone who expands the boundary or dumps the text layer.
Then attend to the small new things. A caption you wrote yesterday reads differently under a still on a different page. A hyperlink's visible label is copy, and copy with a password in it is a channel — "Sizzle reel — password nightjar26" leaks the password whether or not the URL resolves. Filenames travel: nightjar_budget_working_v3 says something even when the file behind it is gone. And a fresh document is not automatically empty of metadata; the new file's properties are whatever your tool wrote into them, which makes them a decision to check rather than a default to ignore.
The real advantage of a rebuild is easy to miss, though, so it is worth naming. Redaction removes spans of text; a rebuild lets you write replacements. In the fixture, the caveat and the name occupy the same sentence, and the redaction route can only subtract from it. The rebuild route can produce: "Access is agreed in principle with the site manager; the signed facilities release is still outstanding." No name, full caveat. That is the sentence the approved content set asked for, and only one of the two routes can type it.
Which brings the failure modes into the open. The rebuild's channel checks pass by construction. Its meaning check passes only if the person doing the rebuild keeps the caveat while dropping the name — and that is a writing decision, made by a human, invisible to every automated check you can run.
Inspect the saved derivative as a separate file
Close the document you were working in, and open the file you saved. Not the same session, not the same window — the derivative, from disk, as a file that exists independently of the work that produced it.
Then check it against the inventory. Extract the text and search for every planted string: the mobile number, the personal email address, "Dee Marchetti", the sticky-note sentence, "two-part pre-sale", nightjar_budget_working_v3, nightjar26, and nightjar_pitch_v7_FINAL_KH. Open the comment list and the attachment list. Check the layers. Read the document properties. Test the link targets, including the ones whose labels no longer suggest a link. Look at the pages, but treat looking as one check among several rather than the check.
Here is how the three candidates fare, constructed rather than executed — these are the differences the comparison turns on, and your build and your file will produce their own:
| Planted item | Covering rectangle | Applied redaction + sanitize | Clean rebuild |
|---|---|---|---|
| Personal mobile and email | Still extractable from the page | Removed when the marks were applied | Never present |
| Post-house comment | Still in the comment list, with author and timestamp | Removed in the hidden-information pass | A new file has no comments |
| Attached spreadsheet | Still attached and openable | Still attached — the box was left unchecked | Never imported |
| Panel paragraph under the shape | Still in the page content; selecting the page reveals it | Removed with the panel and the content beneath it | Never typed |
| Author and Title properties | Unchanged | Cleared | Whatever the new document wrote — check it |
| Sizzle link and password label | Still live | Removed | Omitted by default; re-adding it is new content and needs approval |
| Site manager's name, in the access sentence | Still extractable from the page | Removed, leaving a filled box where the name sat — and a mark drawn wide takes the caveat with it | Never typed |
| Depot access caveat | Still there, as is everything else | Missing — the surviving claim now overstates access | Written in by hand |
| What it is | A cover, not a removal | Two failures, one of them invisible to software | Channel-clean; meaning depends on the author |
The two failures in the middle column are worth separating. The attachment survived because a person left a checkbox alone, and the next inspection catches it. The missing caveat survived because a person removed a sentence to satisfy the removal list, and no extraction check will ever flag it — the file is cleaner and less truthful, and both things are true at once.
That is the reason the last check in the record is a re-read. Print the derivative, or read it end to end without comparing it to anything, and ask what story the shortened document tells. If a claim now reads more strongly than the approved content set allows, the file goes back. Correction, or a route change — if you find yourself making three rounds of redactions on a document whose exclusions keep multiplying, the rebuild was the answer an hour ago.
What leaves, and who says so
The deliverable is a separately saved derivative with an explicit check record and a stated review owner.
The check record is short and dull, which is the point. Fixture name and version, route taken, application and build, the date, who ran it, each planted string and where it was searched — extracted text, comment list, attachment list, layers, properties, link targets — pass or fail, and what the reviewer did not check. That last line matters more than it looks. A record that claims everything is a record nobody can audit.
The review owner is a person. Not a tool, not a checklist, not a reassuring dialog box. Adobe's own documentation is clear that sanitization is not a guarantee of anonymity or legal clearance, and no combination of settings will make it one. For anything consequential, the reviewer is someone who did not perform the removal, opening the file in a different viewer on a different machine, with the authority to send it back.
And keep the caveat in both routes. A file can pass every channel check you know how to run and still misrepresent the project — cleaner, smaller, more shareable, and wrong about what the film can actually do in week one.
Frequently asked questions
Why is a black rectangle over text not redaction?
A black rectangle is a drawing. The text underneath remains in the file, still selectable and extractable. Marking regions for redaction is also not the same as applying the redaction; a document closed with unapplied marks still contains the characters. Applying redactions handles content, while hidden-information removal is a separate operation.
What are the two questions to keep separate in a PDF disclosure task?
First, what is this recipient allowed to receive? That is a disclosure decision. Second, how do I get the excluded material out of the file? That is a removal operation. Do them in that order, and record an approved content set and a removal list before touching the file. This work assumes the upstream rights and relationship decision has already been made.
How do applied redaction and a clean rebuild fail differently?
Applied redaction keeps the layout and existing assets but inherits every channel the document accumulated: comments, attachments, layers, properties, and hidden content. A clean rebuild starts empty, so those channels are absent by construction, but its meaning depends on the author keeping caveats and adding only material whose provenance can be stated. Redaction can only subtract; a rebuild can write a replacement sentence. In the example, redaction can remove a name and take a caveat with it, while a rebuild can drop the name and keep the caveat.
How should a saved derivative be inspected?
Close the working session and open the saved file from disk as an independent file. Extract the text and search for every planted string—names, numbers, filenames, passwords, document-title fragments—and check comments, attachments, layers, properties, and link targets. Looking at pages is one check among several. The record should say what was searched, pass or fail, and what the reviewer did not check.
Does sanitization guarantee anonymity or legal clearance?
No. Sanitization is not a guarantee of anonymity or legal clearance, and applying a tool is not evidence about the derivative. For consequential material, the reviewer should be someone who did not perform the removal, opening the file in a different viewer on a different machine, with authority to send it back. Keep the caveat in both routes, because a file can pass channel checks and still misrepresent the project.