How to Build a Defensible FOI or ATI Redaction and Disclosure Workflow

A freedom of information or access to information request turns scattered records into a case with a deadline, a search scope, and a release decision. A defensible process connects what was requested to what was searched, reviewed, withheld, redacted, approved, and delivered. A folder of PDFs and an email saying “complete” rarely provide that chain on their own.

The workflow below follows one request from intake to release. Its control model can support FOI, ATI, and similar public-access programs, while the applicable law determines deadlines, fees, consultations, withholding grounds, and review rights.

Start with the governing access regime

Before configuring the workflow, identify the law that applies to the organization and request. The designated access officer translates that framework into approved rules for search, review, timelines, and release. Two examples illustrate why the workflow needs both operational evidence and jurisdiction-specific decisions:

• UK FOIA example — evidence of search: the ICO’s guidance on whether information is held emphasizes reasonable searches and evidence of the enquiries performed. This illustrates why a case needs a documented search plan, source coverage, and collection outcomes.
• Canadian federal ATI example — withholding decisions: the Treasury Board Access to Information Manual distinguishes mandatory and discretionary exemptions and addresses severability. This illustrates why review must record the applicable authority and passage-level decision rather than turn a sensitivity label into automatic withholding.

These examples inform two stages of the same workflow: establishing what information was found and deciding what can be released. Configure each stage for the governing regime, including provincial, state, or other applicable rules. The shared evidence model below connects those decisions without treating one jurisdiction’s legal tests as universal.

FormKiQ’s point of view: make the release reproducible

The request file should explain how the organization reached the released package. Preserve the source context, record the review decisions, and link approval to the exact renditions delivered. When a request is challenged or reopened, staff should be able to reconstruct that outcome without relying on a reviewer’s memory.

FormKiQ’s Freedom of Information and Public Access solution supports request intake, deadline tracking, review and redaction workflows, response assembly, and appeal history. Configure the applicable rules, reviewer permissions, redaction tooling, and release checks for the organization. AI-assisted review can flag potentially sensitive passages; an authorized reviewer makes the disclosure decision and validates the output.

Keep separate evidence for each decision

Create the case without losing the original request

Capture the wording as received, receipt date, requester contact information, scope, date boundaries, delivery preference, responsible team, and applicable jurisdiction. Store clarification correspondence alongside the original rather than replacing it with a normalized summary. Limit requester details to staff who need them.

Separate statutory deadlines from internal milestones for collection, review, consultation, approval, and delivery. Record the rule version and inputs used to calculate dates. A fee estimate, clarification, consultation, or internal reassignment must not silently pause the statutory clock: apply a timeline change only when the governing process permits it, with its authority and notice recorded. Require identity verification where applicable rather than treating it as a universal prerequisite for public access.

Search beyond the convenient repository

Map the request to custodians, systems, business units, record types, search terms, date ranges, and relevant attachments or versions. Save search instructions, query revisions, execution dates, source coverage, and result counts. Include systems outside FormKiQ where the scope requires them, with an owner for each collection task.

Make the search evidence reviewable: distinguish a completed zero-result search from a source that was never searched, failed indexing, or contained files the search tool could not read. Record what each outcome establishes and what still needs investigation.

Track encrypted files, failed OCR, unavailable custodians, unsupported formats, and collection errors as explicit exceptions. Search ranking or semantic retrieval can help prioritize review, but a relevance score alone should not silently exclude potentially responsive records. A document need not be formally declared a records-management “record” to require consideration under the applicable access regime.

Apply preservation measures where required, including a hold or suspension of disposition under the approved process. Preserve captured originals and provenance while reviewers work on controlled copies. Record source identifiers, versions, checksums, collection times, and relationships; configure the protection needed rather than assuming an ordinary stored file is immutable.

Reduce repeated review without erasing context

Use exact-duplicate detection to group review work while preserving every collected item’s source mapping. Identical content from two custodians may have different attachments, dates, or surrounding correspondence. Email threading and near-duplicate analysis should organize review, with exceptions checked before a reviewer treats related items as equivalent.

Record exclusions and their approved reasons, including out-of-scope material and duplicates represented by a retained item. Preserve the mapping needed to explain counts and reconstruct the reviewed set. Automation can assist triage; it should not turn a technical label into an unreviewed legal conclusion.

Separate responsiveness from withholding and redaction

First decide whether information falls within the request. Then assess applicable exemptions, exclusions, consultation, and any required discretion or public-interest analysis. Finally, translate the approved withholding decision into a release rendition. These are related decisions with different evidence.

For each withheld record or passage, retain the applicable authority, rationale, reviewer, decision date, and affected location. Use a versioned jurisdiction-specific code set. Apply the governing regime’s requirements for mandatory or discretionary withholding and release of the remaining information. Do not convert every match to an exemption category into automatic withholding of an entire document.

Keep internal legal analysis and reviewer notes separate from the requester-facing explanation. The appropriate response wording and authority for approval depend on the applicable regime. A second review can check sensitive decisions, but escalation should go to the designated decision-maker.

Verify that redaction removes the data

A black rectangle or annotation can hide text visually while leaving it recoverable. Apply actual redactions to a separate release rendition, then sanitize hidden information appropriate to the format. Adobe’s Acrobat guidance, for example, distinguishes selecting content from applying redactions and removing hidden information.

Inspect the saved output, not only the editor preview. Attempt text extraction and search, inspect images and OCR layers, and check comments, tracked changes, hidden sheets, attachments, embedded objects, form values, and properties as relevant. Inspect rotated pages and unusual formats. Visual review and automated checks complement each other; a successful export message is insufficient.

Prevent access to the original through alternate download, preview, attachment, or storage paths. Verify the complete released representation, including accessible text and tags, without reintroducing withheld content. Preserve required usability and accessibility; rasterizing every page is not a substitute for a tested redaction process. Keep the original and decision record under separate permissions.

Bind approval to the exact disclosure package

Build an internal manifest linking every reviewed item to its outcome: released, partially released, withheld, or excluded with a reason. Map released files and pages to their source records and approved renditions. Verify completeness, page numbering, file opening, correspondence, and recipient before approval.

Create the requester-facing index and decision explanation under the applicable disclosure rules. Do not automatically include internal titles, withheld descriptions, legal notes, or sensitive filenames merely because they are in the internal manifest. Even a list of records can disclose protected information.

Approve a specific package version and checksum. Changing a rendition, attachment, letter, or index after approval must trigger the required rechecks and approval before release. Generate any delivery links from that approved package, with the intended recipient, authentication, expiry, and withdrawal controls. An approval on the case generally should not authorize whichever files happen to be present later.

Worked example: a corrected redaction after approval

1. 1. Capture and review the responsive material

   A case contains correspondence from two custodians, including duplicate attachments. Preserve both source mappings, review the grouped content, and record the authorized passage-level withholding decisions.

2. 2. Verify the release copy

   A reviewer finds that a visually hidden account number remains in the PDF’s OCR text. Block release, create a corrected rendition, and repeat extraction and visual checks while preserving the original and failed verification evidence.

3. 3. Replace the approved package

   If the correction changes a previously approved package, retire that package from delivery and route the replacement through the required checks and approval. Record the new version and checksum; do not reuse an approval for different bytes.

4. 4. Retain delivery and correction history

   Record the exact package issued, recipient, method, time, and observed delivery result. If an earlier package was already released, use the incident and correction process; withdrawing a link cannot recall a downloaded copy.

Keep the evidence after dispatch

Distinguish sending, successful delivery, access, acknowledgment, and signature where relevant. A portal request or automated link check does not prove the requester read the package. Record failures and retries, and link supplemental releases or corrected responses to the original case without overwriting its history.

Track deadline events, collection gaps, review turnaround, redaction rework, overdue reasons, and appeal outcomes. Retain the request, captured sources, decisions, approvals, and issued packages under the applicable schedule and holds. Closing the task does not itself authorize disposal of the case evidence.

Demonstrate the release controls before relying on them

• Fail a search source or OCR job. Show that the exception remains visible and cannot be reported as a completed zero-result search.
• Redact a passage with a searchable OCR layer and an attachment. Verify that every released representation removes the protected information.
• Replace a file after package approval. Show that the altered package cannot be dispatched under the earlier approval.
• Open the recipient’s delivery path and attempt to retrieve the unredacted original or internal review notes. Show that access is denied.