Overview
Public records are supposed to be seen; the personal data inside them is supposed to be protected. A release process that only decides between public and secret fails both goals — what a modern process needs is controlled disclosure: the right portions, to the right audience, with a record of every view.
The contradiction every transparency office knows
An access request lands on the desk. The file behind it contains a decision, a budget line, and the names, signatures, and health details of private citizens. Release it whole and the office creates a data breach with a tracking number; redact it into a blank page and the office defeats the law it is applying.
This is not an edge case. Access-to-information regimes and privacy regimes are both mandatory, and they overlap on almost every document a public body produces. FOIA offices work this tension every week: exemptions exist, but they have to be applied to specific content, not to whole files.
Then comes the part most workflows ignore: the release itself. A PDF sent by email is a copy that the institution no longer controls, and a copy with a redaction layer is worse — the text is often still underneath, waiting for the first person who knows how to select it.
- Disclose by portions, not by files — the unit of decision is a passage, a page, or a field.
- Track every release — who received which version, when, and under which request.
- Assume reuse — anything published will be copied, scraped, and reposted.
Redaction is a process, not an edit
The classic failure is the redaction that looks complete. Black rectangles are drawn over a PDF, the file is exported, and the underlying text remains in the content stream. It has happened to courts, police departments, and ministries, and it will keep happening while redaction is treated as a visual operation. Redaction software has to remove the underlying text, not just cover it.
A safer approach is to never produce the sensitive content in the first place: redact at the source, render the release from a policy, and verify by extracting the text from the output before it leaves. If the extract still contains the exempted name, the redaction failed.
Versioning belongs here too. Requests get clarified, exemptions get reconsidered, and the same record may be released in more than one form. Each release needs its own identifier and its own decision record, not an email thread.
Delivering records under custody
Open data should be published as files — that is the point of open data. But a record released to a specific requester, containing third-party personal information, is a different product: it needs per-recipient delivery, a watermark tied to that release, and access that expires.
The mechanism is the same one used for forensic watermarking: render the page for the session, stamp the identity, and log the view. If the file later appears where it should not, the institution can say which release it came from — and the recipient knows it can.
- Per-request releases — a delivery record for each requester, not a public link for everyone.
- Expiring access — links that stop working after the request is closed.
- Pixel-level redaction — the hidden text never reaches the recipient.
- Disclosure logs — every view attributable to a request and a recipient. Pair it with rasterization when the original must stay server-side.
The workload problem: doing this at scale
Transparency teams are usually small, and requests arrive faster than they close. A process that depends on a specialist for every file breaks in the first busy month. The workflow has to be boring: a triage step, a decision template, a repeatable redaction path, and a delivery step that produces the log automatically. The DOJ Office of Information Policy publishes guidance on processing requests; the technical part is yours.
Automation helps with mechanics, not with judgment. Deciding whether a name is exempt is legal work. Deciding whether the released PDF still contains that name is mechanical, and it should be tested on every release.
Measure the two numbers that matter: time from request to release, and the rework caused by redaction mistakes. Both go down when the release is produced from a controlled source instead of from a copy of a copy.
- One intake for every request, with a visible queue.
- Decision templates for the exemptions that repeat most.
- A redaction test that extracts text and searches for the exempted terms.
- A quarterly sample of past releases, reviewed before a journalist reviews them.
A practical release checklist
Before the next release cycle, pick one real request and walk it end to end. The gaps you find will be more useful than any policy rewrite.
- Identify the exemptions first — names, third-party data, investigative material — and write down the decision.
- Redact at the source and test the output by extracting its text.
- Choose the delivery mode based on the content: open file, or watermarked view under custody.
- Log the release — requester, version, date, decision, and the person who approved it.
A release is a promise the institution has to be able to keep: what was disclosed, to whom, and under which decision. When that record exists, a challenge becomes a lookup instead of a debate. If your team is redesigning its access-request workflow, request a demo and we will run a real release through redaction, watermarked delivery, and audit export. If you want the wider public-sector context, the starting point is document security for government; and when a released record has to be traced later, see digital chain of custody.