Privacy and preparation
The redaction log: documenting what was removed and how
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
A redaction log is the written record of which personal and confidential details were removed from a dataset, by which method, with which tools and versions, and what quality checks found. For licensed data it forms the privacy record that counsel on both sides review. It documents rules and results, never the removed values themselves.
Key takeaways
- A licensing redaction log documents methods across a dataset, unlike a litigation log that lists each redacted document.
- Record tool names, versions, sources and custom rules, because automated detectors change between releases.
- Log quality checks with the sample design, reviewers, findings and fixes.
- Exceptions, such as public business names kept on purpose, belong in the log with a reason and an approver.
- The log must never contain removed values or the mapping from tokens back to people.
How a licensing redaction log differs from a litigation log#
A licensing redaction log differs from the redaction log lawyers know from litigation. A litigation log usually lists each redacted document and the basis for each redaction, so the other side can challenge it. A licensing log documents the method applied across a whole dataset and the evidence that the method worked.
The readers differ too. The supplier's counsel uses the log to approve release, the buyer's counsel uses it to confirm what the dataset contains, and the preparation team uses it to repeat the work on the next delivery. Each reader needs rules, versions, results and exceptions, not a list of individual edits.
Start the log before the first scan, not after delivery. Decisions made while writing rules, such as which customer names count as personal details and which are business identifiers, are hard to reconstruct later, and the reasons behind them are exactly what reviewers ask about.
The fields every redaction log should contain#
The fields below make a log reviewable and repeatable. Keep one log per dataset version, so a later delivery with changed rules gets its own entry rather than an edit to the old one.
| Field | What to record | Example entry |
|---|---|---|
| Dataset and version | Dataset name, version and preparation date | Support tickets, second version, prepared in October |
| Source and scope | Systems, record types and date range covered | Help desk tickets and comments, closed tickets only |
| Categories targeted | Each personal or confidential category in scope | Names, emails, phone numbers, street addresses, customer company names |
| Method per category | Remove, replace with token, generalize or keep | Emails replaced with per-person tokens |
| Tools and versions | Software, version, package source, model and configuration file | Open-source detector at a pinned release with custom recognizers |
| Custom rules | Dictionaries, patterns and allow lists added | Customer name dictionary from the CRM; product names allow-listed |
| Human review | Scope of manual review and who performed it | Sampled tickets per category, checked by two reviewers |
| QA results | Residual findings by category and the fixes made | Signatures missed in forwarded emails; rule added and rerun |
| Exceptions | Items kept or excluded on purpose, with a reason | Attachments excluded; published office addresses kept |
| Approvals | Names, roles and dates of sign-off | Privacy lead and general counsel |
Recording the method: remove, replace, generalize or keep#
Recording the method precisely matters because each choice affects both privacy and usefulness. Removing a value is simplest, replacing it with a token preserves who did what across records, generalizing keeps a coarser signal such as a state instead of a street, and keeping a value is a deliberate decision that needs a reason.
A shared vocabulary helps buyers read the method column. The Data & Trust Alliance's Data Provenance Standards list privacy-enhancing techniques that include masking, minimization, redaction, pseudonymization and tokenization, which are reasonable labels to use.
| Method | Typical use | What the log must state |
|---|---|---|
| Remove | Identifiers with no analytic value, such as phone numbers in signatures | Category and the pattern or rule used |
| Replace with token | People and companies whose activity must stay linked | Token type, scope of consistency, and where any mapping is held or when it was destroyed |
| Generalize | Locations, dates and job titles | The level kept, such as month instead of day |
| Keep | Product names, error codes, published business details | Why the value was kept and who approved it |
Why tool names and versions belong in the log#
Tool names and versions belong in the log because automated detectors behave differently across releases, models and configurations. A rerun months later with an updated library can find more or less, and only a pinned version explains the difference.
Tools also change hands. Presidio, a widely used open-source detector, moved from a Microsoft-owned project to an independent community organization, recorded in a release dated June 28, 2026. Record the package source as well as the version, so a reviewer can find the exact code that ran.
Pair each tool entry with its known limits. Presidio's own documentation says there is no guarantee it will find all sensitive information and that additional protections should be used, so the log should show the human review and custom rules that ran alongside it.
Logging QA results and exceptions#
QA results show whether the method worked, and exceptions show where judgment was applied. Both are what reviewers read most closely.
Write findings honestly. A log that reports no residual findings at all invites more scrutiny than one that shows a miss, the fix and a clean rerun.
- Sample design: how records were chosen, per category and per source system.
- Reviewers: names or roles, and whether they were independent of the people who wrote the rules.
- Findings: residual identifiers found, grouped by category and record type.
- Fixes: rule changes made, followed by a rerun and a fresh sample.
- Exceptions: values kept or record types excluded, each with a reason and an approver.
- Open items: known limits the buyer should hear about, such as scanned images left out.
Illustrative: a consulting firm logs its proposal archive#
Illustrative: a fictional operations consulting firm is preparing a decade of proposals and project reviews stored in SharePoint, with engagement records in Salesforce. Client names, partner names and client staff appear throughout.
The log records client names replaced with sector tokens such as regional grocer A, partner names replaced with role tokens, and street addresses removed. Published case studies are an exception and kept as written, with the marketing approval cited. QA finds client logos embedded in slide images, so the team excludes image content and lists it as an open item. The general counsel signs the log before release.
Because the firm expects a second delivery covering later years, the token scheme is documented by type, and the mapping of tokens to real client names is held under access control by the general counsel's office. The log records the mapping's location and custodian, never its contents.
How the log fits the SourceX Evidence Packet#
The redaction log is the core of the privacy record, one of the five parts of the SourceX Evidence Packet alongside provenance, licensing rights, permitted use and release authorization. It is produced in the Preparation step of the SourceX five-step transaction and reviewed in the Approval step.
SourceX ties each release authorization to a specific log version, so the approved dataset and the documented method always match. The buyer receives the method and results; keys, mappings and removed values stay with the supplier or are destroyed.
Frequently asked questions
Should the redaction log contain the values that were removed?
No. Listing removed names or emails would recreate the personal data the process was meant to remove. Log categories, rules, counts by category if you track them, and examples written with synthetic values. Keep any token mapping separate, access-controlled or destroyed.
Who should own the redaction log?
The preparation lead usually maintains it, with the privacy lead or general counsel approving it. If a vendor performs the redaction, require the vendor to supply its part of the log, including tool versions and QA results, as a contract deliverable.
Does the buyer receive the full log?
A buyer usually receives the log or a summary covering categories, methods, tool versions, QA results and exceptions. Internal details such as reviewer names or rule files can stay with the supplier when they are not needed to assess the dataset.
How long should the log be kept?
At least for the life of the license and any period in which questions about the dataset could arise, such as audits, customer requests or disputes. Your retention schedule and counsel should set the exact period.
Can one log cover several deliveries?
Use one log per dataset version. When a later delivery adds records or changes rules, create a new version that references the earlier one, so each delivered dataset maps to exactly one documented method.
Is a spreadsheet good enough for a redaction log?
For most datasets, yes. What matters is that the log is versioned, access-controlled and complete, with the QA sample sheet and approvals attached. A short narrative document plus a structured table of categories, methods and results works well for counsel on both sides.
Sources
- The Data Provenance Standards' Privacy Enhancing Tools code list includes data anonymization, encryption, masking, minimization, redaction, pseudonymization and tokenization, among others. Source
- Presidio moved from a Microsoft-owned project to an independent, community-governed open-source project under the Data Privacy Stack GitHub organization, recorded in release 2.2.363 dated 2026-06-28. Source
- Presidio's documentation warns that there is no guarantee it will find all sensitive information and that additional systems and protections should be employed. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.