The Compliance Redaction Process: Step by Step
A compliance redaction process has eight steps: classify the sensitive data, define the detection rules, mark the content for redaction, have a reviewer approve the marks, apply the redaction so the content is permanently removed, verify nothing recoverable remains, record the audit trail, and release the document. The marking step is reversible; the apply step is not.
The Eight Steps
Steps 1 to 4 remove nothing from the file. Step 5 destroys the marked content, and steps 6 to 8 exist because that cannot be undone.
Step 1: Classify the Sensitive Data in Scope
Start with a written list of what counts as sensitive. Your compliance team sets the classes: personal identifiers, account numbers, health details, privileged legal content, or anything else your policy names. Financial services, healthcare, government and legal teams each draw this line differently, so the list is yours to define.
The Apryse Redaction add-on, a PDF redaction library for the Apryse Web SDK and the Apryse Server SDK, enforces that list in the later steps. It does not decide what belongs on it. For examples by regulated industry, see redaction use cases by industry.
Step 2: Define the Detection Rules
Turn each class into a rule a machine can apply. Keyword rules match exact text strings, such as a client name or a case number. Pattern rules match recurring formats. Ambient string, wildcard and regular expression (RegEx) matching find Social Security numbers, credit card numbers and other personally identifiable information (PII).
Rules built on pattern-based detection are repeatable, and they leave a written record of what you looked for, which step 7 needs. Test each rule on sample documents before it touches a live file. A loose pattern marks harmless text, and a tight one misses sensitive data. The search-and-redact documentation covers the detection options.
Step 3: Mark the Content for Redaction
Marking tells the SDK which content to remove later. A mark is an instruction, not a deletion, and nothing leaves the file until step 5.
Reviewers can mark regions or text by hand in the Web SDK WebViewer. Your application can also mark every match for a rule through search and redact, on the Web SDK or the Server SDK. A wrong mark at this stage costs nothing to fix.
Step 4: Reviewer Approval
A person confirms every mark before anything is destroyed. The reviewer looks for two errors: sensitive data left unmarked, and harmless content marked by mistake. Automated detection does not replace this step in a regulated workflow, because only a person reading the page catches a pattern that missed.
Your application owns the approval. It routes the file to the reviewer, records who approved what, and holds step 5 until approval exists. Reviewers can work in the browser through the Web SDK WebViewer. Keep marking, review and apply on one document version, so an unredacted copy never circulates beside the approved one.
Step 5: Apply the Redaction
Applying the redaction is the point of no return. Apply removes the text and image content inside every approved mark from the file, and on the Server SDK it also removes vector content. Unlike a black box drawn over text, true redaction removes the content permanently. The output is a file with the content destroyed, not hidden.
Apply only approved marks and apply to a copy so the original stays in storage you control. The redacted file cannot return the content. Redaction documentation is available for the Server SDK and the Web SDK.
Step 6: Verify Nothing Recoverable Remains
Check the output file, not the screen. A redacted page can look clean while data remains underneath. Search the output for each redacted string and expect no matches. Extract the text layer and read it for the same strings. Open the file in a second viewer before it leaves the review team.
Then check what redaction does not touch. Redaction removes visible content from the page. Metadata, embedded scripts, form data and hidden layers are hidden content, and removing them is Sanitization, a separate Server SDK capability. A compliant external release usually needs both, and the page on redaction versus sanitization explains the split. On the Server SDK, the base Search and Extraction capabilities can run the string and text-layer checks in code.
Step 7: Record the Audit Trail
Record what happened so the release can be explained later. The redacted content is gone by design, so your record is the only account of what was removed. Capture what was detected and by which rule, what the reviewer approved or rejected, when the redaction was applied, and the verification result.
Your application stores that record with the file. Apryse removes the content, and your systems keep the history. For the capability side, read about our enterprise-grade redaction capability.
Step 8: Release the Document
Release only the verified output. For external release, run PDF sanitization first, because applying redactions does not strip hidden data. Sanitization is part of the base Server SDK package and needs no add-on license. It runs on the Server SDK only, so a browser-based process hands the file to your backend for that step.
Redaction is also different from encryption and access control. Those restrict who can open content that is still present in the file. Redaction removes the content. Your application owns who receives the released file.
Where This Process Runs: Browser or Server
All eight steps run on either surface, and the surfaces split the work differently. The Web SDK processes documents in the browser, which suits the reviewer-facing steps. The Server SDK runs in your backend, which suits rule-based detection, apply and verification.
The Server SDK runs self-hosted and makes no calls to Apryse at runtime, so you can keep documents on your own infrastructure. For volume, your code owns the loop: the Server SDK ships no work queue, scheduler or batch orchestration. See redacting documents in bulk for the volume pattern.
Common Failures in the Compliance Redaction Process
Treating the Mark as the Removal
A black box or a marked region hides content without removing it. Anyone who copies the text or opens the file in another tool can read what was underneath.
Checking the Screen Instead of the File
A page that looks clean proves nothing. Verification means searching the output and reading its text layer.
Releasing Hidden Data
Metadata and hidden layers can carry timestamps, author names and revision history. Redaction does not remove them, so sanitize before external release.
Letting Unredacted Versions Circulate
Every extra copy is another chance to send the wrong one. Keep review and apply on a single version.
Skipping Review After Automated Detection
A rule finds the formats you thought of. Only a reviewer catches the data you did not.
This process supports your compliance obligations. It does not certify compliance, and your compliance program defines the standard each document must meet. For a legal operations view of the same process.
Frequently Asked Questions About the Compliance Redaction Process
Classify the sensitive data, define the detection rules, mark the content, have a reviewer approve the marks, apply the redaction, verify nothing recoverable remains, record the audit trail, then release. Steps one to four are reversible. Applying the redaction is not.
At the apply step. Until then, marks only identify content and nothing is removed from the file. Once the apply step runs, the text and image content inside those regions is destroyed, along with vector content on the Server SDK, and it cannot be recovered from the output file.
Check that the marked content is absent from the output rather than hidden: search the output for the redacted strings, inspect the extracted text layer, and confirm metadata and hidden structures were handled. Metadata and hidden layers are Sanitization, a separate Server SDK capability, not something redaction removes.
What was detected and by which rule, what a reviewer approved or rejected, when the redaction was applied, and the verification result. Your application stores the record. It lets your team account for the release after the fact, since the redacted content itself is gone by design.
Usually yes. Redaction removes visible content from the page. Sanitization removes hidden, non-visual content such as metadata, embedded scripts, form data and hidden layers. A document with redactions applied can still carry extractable hidden data if it has not been sanitized.
Yes. Content can be found programmatically through text search, and pattern matching supports ambient string, wildcards and regular expressions, with SSNs, credit card numbers and other PII as documented examples. Automated detection does not remove the need for the review step in a regulated workflow.
