PDF Redaction Checklist: A NIST-Aligned Guide to De-Identification

By the SladdPDF team · Published August 27, 2026 · Updated August 27, 2026

Most redaction checklists stop at "draw a box over the name." That catches the obvious failure — a black rectangle with the text still underneath — but it misses a quieter one: a document where every name is gone and the person is still identifiable from what's left. NIST's guidance on de-identifying datasets gives a more rigorous way to think about that second failure, and its core idea — separate direct identifiers from quasi-identifiers, then assess what the combination still reveals — translates directly to redacting a single PDF, not just a government dataset.

Redaction vs. de-identification: why the distinction matters

Redaction and de-identification get used interchangeably, but they answer slightly different questions. Redaction asks: what specific content in this document needs to disappear before it goes out the door? De-identification, as the National Institute of Standards and Technology frames it for datasets, asks a broader question: once this information leaves our control, could it still be linked back to a specific person — through what we removed, or through what we left behind?

That second question is the one most redaction checklists skip. They check that the name is gone and the box is opaque. They don't check whether a job title, a start date, and a department together still point to exactly one employee. Borrowing the de-identification mindset — think about the residual risk in the whole document, not just the presence or absence of a name — closes that gap.

What NIST SP 800-188 actually says

NIST Special Publication 800-188, De-Identifying Government Datasets: Techniques and Governance, was written to guide US federal agencies through de-identifying data before it is shared or published. It is aimed at datasets and statistical releases, not individual PDF documents — so it isn't a redaction manual. But its structure is directly useful for redaction because it treats de-identification as a process with distinct stages, not a single deletion step:

1. Identify the data's re-identification risk profile — who could plausibly try to re-identify it, and what other data could they combine it with?
2. Classify identifiers — separate direct identifiers from quasi-identifiers that only become risky in combination.
3. Apply disclosure-limitation techniques proportionate to how the data will be released and to whom.
4. Review before release — SP 800-188 recommends a formal disclosure review step, which for an agency is a Disclosure Review Board.
5. Monitor after release, since re-identification risk can change as more external data becomes available.

Applied to a single PDF instead of a dataset, that sequence becomes: know who might read this file and what else they know; find both the names and the quasi-identifying details; remove them properly rather than covering them; have someone check the result before it goes out; and don't assume a document redacted safely last year is still safe if the surrounding context has changed.

Direct identifiers vs. quasi-identifiers

This split is the single most useful idea to carry from de-identification practice into ordinary PDF redaction. A direct identifier points to one person on its own. A quasi-identifier only becomes a problem in combination with others — but in a short document, it often doesn't take many.

The risk isn't hypothetical. In a document with only a handful of people in scope — a small team, a specific office, a named project — "the finance director who joined in March" is frequently just as identifying as a name, because there's only one person the description fits. This is the same mosaic-identification problem that data protection regulators flag when reviewing subject access responses: removing the label without reviewing what's left doesn't remove the identifiability.

The PDF redaction checklist

A practical checklist for a real document, organized around what NIST's process implies: know the content, apply the right technique, then check what's left.

Before you start

• Decide who the plausible reader is, and what other information they already have — a stranger's risk of re-identifying someone is different from a colleague's.
• List every direct identifier that appears: names, ID and case numbers, emails, phone numbers, physical addresses.
• List quasi-identifiers that recur near the direct identifiers: job titles, dates, departments, locations, ages.

While redacting

• Redact the identified content — don't just draw a rectangle over it; the underlying text needs to be removed, not merely covered.
• Rasterize (flatten to pixels) the pages you've redacted so no extractable text layer survives underneath.
• Re-read the surviving text for combinations of quasi-identifiers that could still narrow the document down to one person.
• Where a quasi-identifier isn't essential to the document's purpose, generalize it instead of leaving it exact — "a manager" instead of a specific title, "early 2026" instead of an exact date.

Before you send it

• Strip document metadata — author name, company, tracked-change history, and any OCR text layer from a scan.
• Copy-paste test the finished file: select all, copy, paste into a plain text editor, and confirm nothing redacted comes out.
• Have a second person review it if the document is high-sensitivity — SP 800-188's disclosure-review step exists because a single author reliably misses their own blind spots.
• Log what was redacted and why, briefly — useful if anyone later asks how the release decision was made.

You can run the technique steps — redact, rasterize, and strip metadata — in one pass with SladdPDF: draw over what needs to disappear, switch on Secure mode so each page is rasterized on export, and tick the metadata-removal option before you download. Everything runs locally in your browser; the file is never uploaded. See how rasterization works and why a drawn-on black box isn't enough for the mechanics behind those two steps.

Sizing the effort: confidentiality impact level

Not every document needs the same rigor. NIST SP 800-122 gives federal agencies a way to think about this: classify the potential impact of a confidentiality breach — low, moderate, or high — based on factors like how identifiable the information is, how many people are affected, the sensitivity of the data itself, and the context it will be used in. The same logic scales down to a single document.

Where redaction checklists usually fail

Stopping at the direct identifiers. Removing every name and number feels complete, but it answers only half of NIST's framing — it says nothing about what the surviving quasi-identifiers still reveal in combination.

Treating the checklist as a one-time gate. SP 800-188's monitoring stage exists because context changes — a detail that was safely generic when a document was first redacted can become identifying later, once other information about the same event becomes public.

Skipping the technique check. A checklist that only covers content, not technique, still ships documents where the "removed" text is recoverable with a simple copy-paste, because the redaction was drawn on top rather than deleted and rasterized.