Publishing a Redacted PDF: Which File Has Actually Been Approved?

Before adding document publication to a website or portal, decide how a sensitive original becomes a separately checked public copy. A reviewer marking passages for removal is not the same as approving the resulting downloadable file. The project needs a release procedure tied to that exact output.

This question differs from choosing PDF versus HTML or deciding who may download a private document. Here, the intended reader may legitimately receive the published file, but must not receive particular information inside it. Access controls alone cannot make that distinction.

Commission a release copy, not an appearance

In a fictional association, staff publish a meeting summary after removing personal contact information. The original remains available only to the authorised records team. The public version needs its own identity and review history rather than inheriting approval merely because it resembles the original.

Define the approved removal method. Do not accept “it looks covered on screen” as the outcome. If the workflow uses a redaction tool, ask the operator to complete its removal procedure and save the resulting file before review. Ordinary review marks and a completed release copy should have different labels.

Adobe's official Acrobat tutorial separates selection from applying redactions and then saving a new PDF. It also describes an option to remove hidden information such as metadata, embedded content and hidden layers. Its example saves a new version with a redacted suffix while leaving the original unaltered. These are documented Acrobat steps, not proof that an arbitrary black rectangle in another editor removes underlying information.

Review hidden information as well as visible passages

Tell the developer which kinds of documents the team publishes. A simple native PDF and a scanned packet with recognised text need appropriate checks, not one unexplained “sanitised” checkbox. Decide who knows the document well enough to identify material that must not leave the organisation.

Hidden information requires a deliberate decision. Do not assume selecting visible names automatically reviews metadata or embedded material. Equally, do not describe a vendor's removal option as an independent security certification. The team's final file still needs a competent review appropriate to its sensitivity.

For test documents, include invented identifying text in visible content and in the specific hidden locations your chosen tool supports checking. Ask the reviewer to verify the saved result, not merely the editor's preview. Search and copy checks can reveal some mistakes, but cannot establish by themselves that every kind of sensitive content is absent.

Bind approval to the saved output

A useful custom workflow records the private original, the generated release copy, the responsible reviewer and the particular file they approved. If someone edits or regenerates the release copy, require a new review instead of carrying the old approval forward.

For a portal, that can mean a pending output becomes publishable only after an authorised decision for its current version. A filename saying “final” is not enough. Ask the developer to demonstrate that replacing the stored content cannot leave an unrelated previous approval attached to it.

Keep the private source out of public download paths, thumbnail generation and previews intended for visitors. This is a requirement for your implementation, not an assertion about every document management product. Avoid using real confidential documents in demonstrations or support tickets.

Publish and verify the file visitors receive

The editor may have the right copy while the website still links to an earlier one. Include the public route, preview and any downloadable alternative in the release check. Confirm that each intended public path serves the approved release copy, not the original or a draft.

When a correction is needed, specify who can withdraw the current public version and who approves its replacement. Previously downloaded ordinary files cannot simply be recalled by changing a website link. Have a response procedure for accidental disclosure rather than promising that a replacement erases every earlier copy.

Retention of originals, legal disclosure duties and the grounds for removing information need suitable professional advice. This is a software commissioning guide, not a legal redaction policy.

Ask for a failed-release demonstration

Bring an invented document to a web-app project discussion. Have staff mark removals without applying them and confirm that this does not pass the agreed release gate. Then complete the removal, save the output and review that actual file.

After approval, change one part of the output and check that approval no longer authorises publication of the changed version. Attempt to access the original through the public download and preview routes using an unauthorised test session. Finally verify the bytes served by the public route against the approved artifact. These tests are proposed requirements; they have not been exercised on your future portal.

Source: Adobe, How to remove sensitive information from PDFs. The tutorial supports apply/save separation, the optional removal of the listed hidden information and a separate saved copy. Version-bound approval, routing checks and failed-release tests are recommendations for the custom workflow, not guarantees supplied by that tutorial.