Publishing an FOI Disclosure

Before you start

This page assumes the disclosure decision is already made - you know what is being released, what is being withheld, and under which exemption. If you are still at that stage, our guide to redacting documents for SAR, DSAR and FOI disclosure covers scoping the request, applying exemptions, and the workflow from receipt to response.

What follows is the publication half: the steps where information most often leaks accidentally, and where public sector bodies carry duties that go beyond FOIA itself.

Record the exemption as you redact

The reason for each redaction is easiest to capture at the moment you make it, not reconstructed months later when a requester asks for an internal review. Set the document mode to FOI and the exemption code picker filters to the relevant set.

The built-in UK library covers the FOIA Part II exemptions - s.21 (accessible by other means), s.22 (intended for future publication), s.23 and s.24 (security bodies and national security), s.26 (defence), s.27 (international relations), s.29 (the economy), s.30 and s.31 (investigations and law enforcement), s.32 (court records), s.33 (audit), s.35 and s.36 (policy formulation and effective conduct of public affairs), s.38 (health and safety), s.40 including sub-parts (2), (3) and (7) for personal information, s.41 (information provided in confidence), s.42 (legal professional privilege), s.43 (commercial interests) and s.44 (statutory prohibitions) - plus EIR Reg.13 for environmental information requests. You can add your own codes if your authority uses local references.

Exemption codes are a Pro feature. See Exemption Codes for how codes appear on the redaction boxes and in the audit trail, and Compare Plans for what each tier includes.

Check the output file, not your working copy

The single most common cause of an accidental FOI disclosure is a redaction that looks applied on screen but is not applied in the file. A black rectangle drawn over text in a PDF or word processor hides it visually while leaving the text underneath selectable, searchable and recoverable - the failure behind a long line of public disclosure incidents.

The ICO's guidance on disclosing documents to the public securely (July 2025) is explicit about this, and about checking the file you are actually about to publish rather than the copy you were working in.

RedactProof removes that failure mode by construction. Redactions are burned into the page image and the exported PDF is rebuilt from those images, so the original text objects, annotations and form data are never copied into the file you publish. Every export is then automatically re-opened and checked before it downloads: if any text is found within a redacted area, the export is withheld rather than delivered. Independent recovery testing of that process - using PDF parsers and OCR tools we did not write - is published on our security page.

None of that removes your own final check. Open the published file, search it for a string you know was redacted, and try to select text inside a redaction box before it goes out.

Hidden data and metadata

Redaction addresses what is visible. Documents also carry information that never appears on the page: author names and revision history in document properties, tracked changes, comments, hidden rows, columns and worksheets in spreadsheets, and active filters that a recipient can simply switch off to reveal the underlying data.

The ICO guidance above covers each of these, and recommends converting documents to simpler formats before release rather than publishing source files. The National Archives' Redaction Toolkit makes the same point about residual data and recommends passing a redacted PDF through an image format so that leftover metadata is stripped out.

That is precisely how RedactProof exports are produced - each page is rendered to an image, the redactions are burned into the pixels, and a new PDF is built from those images with document properties sanitised. Spreadsheets and Office documents are converted to PDF before redaction on paid plans, which removes hidden sheets, formulas and filters in the same step.

Accessibility: the step most often missed

If you are a public sector body, a document you publish on your website is covered by the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (SI 2018/952). The exemption for PDFs and other office file formats applies to documents published before 23 September 2018 - anything published since is generally in scope unless another specific exemption applies. GOV.UK guidance points organisations at WCAG 2.2 level AA as the standard to meet.

This matters for redacted documents specifically. Flattening a page to an image is what makes a redaction permanent - but a PDF that is only images has no text layer, so a screen reader cannot read it, and it cannot be searched or selected. The regulations contain no carve-out for scanned or image-only documents: if the document is in scope, it needs to meet the standard like any other.

RedactProof's answer is OCR text restoration, included by default on every current plan - the one-document trial, Flex Packs, Core, and Pro. After the redactions are burned in, a text layer is rebuilt for the content that remains visible - deliberately excluding anything inside a redacted area - so the published PDF is searchable and screen-reader accessible without the redacted text returning.

Two related duties are worth checking against your own publishing policy: GOV.UK's publishing guidance requires organisations that publish PDFs to maintain an accessible documents policy explaining what they publish, how accessible it is, and how to request an alternative format. Many authorities also publish an HTML version of a response alongside the PDF, which sidesteps the question entirely for the text of the response itself.

Your decision record

If a requester asks for an internal review, or complains to the ICO, the question is rarely "what did you redact" - it is "why, and who decided". Three artefacts make that answerable months later:

The certificate answers a question the log cannot: whether the file circulating six months from now is the file you actually published. It verifies integrity and provenance - not whether the redaction decisions themselves were correct. See Verification for how recipients check one.

On retention, ICO guidance on retention and destruction of information sets no fixed period for FOI decision records - that belongs in your own retention schedule - but two points are firm. Information within the scope of a live request should be preserved rather than deleted on the normal schedule. And where information has been withheld, the ICO recommends retaining it through the complaint window, at least six months after an internal review, so the decision can still be examined if the requester escalates.

Publication and disclosure logs

Two things are often conflated here. A publication scheme is a statutory duty: section 19 of FOIA 2000 requires every public authority to adopt and maintain one, and most adopt the ICO's model scheme. A disclosure log - a published list of previous responses - is not required by FOIA. It is good practice recommended by the ICO, mainly because it reduces duplicate requests, and the ICO maintains its own log as a working example.

There is no prescribed format for entries. In practice a log entry carries a reference number, the date, a subject or category, a short description of what was asked, the outcome (disclosed, partly withheld, not held), and a link to the response itself.

Two practical habits at this step: give the file a name that will still make sense in a list of hundreds - reference, date and subject, rather than response_final_v3.pdf - and record the log entry at the moment you publish, not in a batch later, so the log and the published files cannot drift apart.

The checklist

The short version, for pinning next to the workflow:

1. Disclosure approved - the decision to release, and what is withheld, is signed off by whoever your scheme of delegation says it should be.
2. Exemptions recorded - each redaction carries the exemption it was made under, not just a black box.
3. Personal data checked - third parties, junior staff, incidental names in correspondence, signatures.
4. Output file checked - open the actual file, search it for redacted strings, try to select text inside the boxes.
5. Hidden data removed - metadata, tracked changes, comments, hidden rows and worksheets, active filters.
6. Accessibility met - a text layer for screen readers, or an accessible alternative published alongside.
7. File named sensibly - reference, date and subject.
8. Disclosure log updated - at the point of publication.
9. Decision record retained - the log, the certificate and the reasoning, kept through the internal review and complaint window.

Steps 2, 4, 5, 6 and 9 are the ones RedactProof does most of the work on. Steps 1, 3, 7 and 8 stay with your team - and step 3 is the one no software should claim to do for you.

Frequently asked questions

Sources

Every legal statement on this page is taken from a primary source. Where guidance changes - and accessibility guidance in particular does - check the original.

Last reviewed 2026-07-26. RedactProof is a redaction tool, not a legal adviser - exemption decisions, publication schemes and retention periods remain your authority's responsibility.