Securing Financial Data: The Offline Approach to PCI-DSS Credit Card Redaction

A Primary Account Number in an internal PDF is a scope problem. The tool you use to remove it should not be a second one.

A support agent pastes a customer's full card number into a ticket to "help the finance team trace a chargeback." An operations manager exports a settlement report to PDF and drops it in a shared drive. A developer attaches a log file to a bug so QA can reproduce a failed payment.

None of these people work in your cardholder data environment. All three have just put a Primary Account Number somewhere it was never supposed to be — and every one of those locations is now, by definition, in scope for PCI-DSS.

This is the quiet way card data spreads. Not through the payment gateway, which is hardened and audited, but through the ordinary documents that flow around it. And the reflex fix — search for a redaction tool and upload the file — takes a scope problem and adds a data-transmission problem on top of it.

Where Card Numbers End Up That They Shouldn't

The PAN is the 16-digit (for most networks) number on the front of the card. Under PCI-DSS it is the defining element of cardholder data, and any system component that stores, processes or transmits it falls inside the Cardholder Data Environment (CDE) and inherits the full weight of the standard.

The trouble is that a PAN does not stay where your architecture put it. It leaks sideways into systems that were never scoped, designed or secured to hold it:

• Support tickets and CRM notes, where an agent or a customer pastes a full card number in plain text.
• Exported reports — settlement files, reconciliation reports, dispute packets — saved as PDF or spreadsheet and shared internally.
• Email attachments forwarded to accounting, a processor, or an auditor.
• Application logs and debugging artifacts, where a request body containing a PAN is written to disk and attached to a ticket.

Each of these drags an out-of-band system into your assessment scope, which is why "how does card data reach places it shouldn't, and how do we get it back out" is a question every QSA eventually asks. Removing a PAN from a document that should never have contained it is remediation, and it needs to happen without spreading the number further.

What PCI-DSS Requires of a Stored PAN

Requirement 3 of PCI-DSS governs the protection of stored account data, and two provisions matter directly here.

A stored PAN must be rendered unreadable. Requirement 3.5.1 states that wherever a PAN is stored, it must be made unreadable — through one-way hashing of the entire PAN, truncation, tokenization, or strong cryptography. A PAN sitting in cleartext inside a shared PDF meets none of these.

When displayed, a PAN must be masked. Requirement 3.4.1 limits what may be shown to, at most, the first six and last four digits, and only for personnel with a documented business need. The default everywhere else is to reveal no more than the last four.

For a document that is being remediated rather than displayed in an application, the practical goal is stronger than masking: the PAN should be destroyed in the file, not merely hidden. Which is exactly where most redaction goes wrong.

Why a Black Box Is Not a Redaction

Drawing a black rectangle over a card number in a standard PDF editor does not remove it. It appends a drawing instruction that paints over the digits, while the underlying text operators, character codes and fonts remain in the file at known coordinates.

The PAN is still there, and it comes straight back out through select-and-copy, through pdftotext, or through any format converter. A truncation or masking control that leaves the full number recoverable underneath is not truncation at all. This is the mechanism behind essentially every publicized redaction failure, and we took it apart in The Black Box Flaw.

The only method that genuinely removes the number is rasterization: flattening each page to an image and burning the redaction into the pixels, so the rebuilt PDF contains no text layer to recover.

The Upload Problem: Your Redaction Tool Is Now In Scope

So you need real redaction, and the obvious move is a free online tool that begins with upload your file. Stop there. The file you are about to upload is the one with the live PAN in it.

Transmitting cardholder data to a third-party web service makes that service a component that processes your CHD. Under PCI-DSS a third-party service provider handling cardholder data is expected to be PCI-DSS compliant in its own right and to be governed by written agreements and monitoring under Requirement 12.8. A redaction site you found through a search engine is none of those things, and using it does three concrete things at once:

• It transmits a PAN outside your environment to a party with no agreement, no documented compliance and, often, no identifiable jurisdiction.
• It expands your scope rather than shrinking it, pulling an uncontrolled external service into the story you have to tell an assessor.
• It inherits their breach. If that service is compromised, the card numbers you sent it are in the blast radius.

The clean resolution is to make sure the transmission never happens. If the file is redacted on the same machine that opened it, there is no third party, no new scope, and no PAN on the wire.

Local-First: Keep the PAN Off the Wire

RedactLocal is a PDF redactor that runs entirely in the browser. The file is read into the tab's memory by the browser's own file API, rendered locally, and exported by the browser's download mechanism. There is no upload endpoint, because there is no backend that accepts files.

You can verify it in about ten seconds, and this is the test no cloud tool passes: open the tool, disconnect from the internet, and redact the document. It keeps working, because the card number has nowhere to go. That property is what keeps the redaction step from ever becoming a transmission of cardholder data.

How the "Global Finance: PCI-DSS" Preset Works

Selecting 💳 Global Finance: PCI-DSS from the compliance preset selector configures the scanner to find Primary Account Numbers. Everything below runs against text already in the browser's memory, with nothing transmitted and full support for working offline.

Structured matching, then checksum validation

The scanner looks for the canonical PAN shape — four groups of four digits, with spaces or hyphens between the blocks optional — so 4111 1111 1111 1111, 4111-1111-1111-1111 and 4111111111111111 are all recognized. A structural match is not enough on its own, so each candidate is then run through the Luhn checksum (the mod-10 algorithm every issuer uses as the PAN's final digit). Only numbers that pass are reported. That validation step is what separates a real card-number sweep from one that flags every sixteen-digit string in the document.

Review, then permanent removal

Every match is listed with the surrounding line of text, and nothing is covered until you confirm it. On export, each page is rasterized and the redaction boxes are burned into the pixels; the PDF is rebuilt from images alone. The file is then re-opened and inspected before the download appears, reporting the flattened page count alongside the number of selectable characters, text operators, font objects and annotations found. On a correct export those counts are zero — a verifiable artifact you can keep with the remediation record.

A PCI-Minded Redaction Workflow

1. Treat the source file as in-scope. Until the PAN is destroyed, the document is cardholder data. Handle and store it accordingly, and never transmit it to an outside tool to be cleaned.
2. Redact on a machine you control. A tool that uploads the file has become a system component processing your CHD. A browser-native tool never receives it.
3. Scan for the PAN. Let the preset find Luhn-valid card numbers, including those broken into spaced or hyphenated blocks.
4. Flatten the output so the number is destroyed in the pixels rather than hidden behind a box.
5. Verify before the file moves. Confirm the post-export report shows zero recoverable text, or run pdftotext and search for the last four digits. If they appear, do not release it.
6. Fix the source, not just the copy. A PAN in a support ticket means a process is capturing card data where it should not. Redacting the export is remediation; closing the intake path is the fix.

What This Does Not Do

Three limits to be precise about, because an audit-minded reader should know exactly where the tool's edges are.

It targets 16-digit PANs. The four-by-four pattern matches the common 16-digit networks. American Express (15 digits) and Diners Club (14) do not fit that shape and are not caught by this preset — review those by eye or with a manual box.

It scrubs the PAN, not the rest of the record. Cardholder name, expiry date and any authentication data are not pattern-detected. PCI-DSS covers those too, and they remain your review.

Scanned and photographed documents have no text layer. The scanner reads a PDF's text; an imaged statement or a screenshot of a terminal has nothing to match against. Redact those by hand and flatten as normal. Note that a scan run through OCR does contain recoverable text, which is exactly the file people assume is safe because "it's only a picture."

And for completeness: loading redactlocal.org records a page view, as most sites do. It has no access to your documents, which never leave the tab's memory. We say so plainly, because a tool asking you to trust it with data you cannot see should be candid about the data you can.