Features that protect you when it matters

Redaktr is built around a simple premise:
most disclosure failures do not happen because someone acted recklessly. They happen because the tooling allowed a mistake to pass unnoticed.

This page explains how Redaktr addresses the common traps that organisations encounter when handling DSARs, FOI requests, and regulated disclosure.

Irreversible, secure redaction

One of the most common and serious failures in disclosure work is reversible redaction.

Many tools provide a way to visually obscure text without permanently removing the underlying data. The result looks correct on screen, but the original content can be recovered by copying, searching, or inspecting the file structure.

Redaktr applies true, irreversible redaction at the document level. Once redacted, the underlying data is removed from the output entirely. There is no hidden layer, no recoverable text, and no reliance on visual masking.

This eliminates the risk of accidental disclosure through file inspection, copy-paste, or format conversion.

Filenames treated as disclosure content

Another common oversight is the filename itself.

In practice, filenames often contain personal data, sensitive identifiers, or contextual information that undermines the redaction applied inside the document. In some cases, filenames have been the source of the disclosure breach.

Redaktr treats filenames as part of the disclosure surface, not as neutral metadata. Outputs are generated without carrying forward original filenames that could reveal information inconsistent with the redacted content.

This prevents the situation where a recipient asks:

“Why does the filename say X when the document no longer contains X?”

Structured reasons for non-inclusion

A frequent challenge arises after disclosure, not during it:

“Why were these documents not included?”

Many tools allow items to be excluded without recording the basis for that decision. When questioned later, organisations are forced to reconstruct reasoning after the fact.

Redaktr requires non-included documents to be associated with explicit, structured reasons, aligned to the type of case being handled. Where appropriate, additional notes can be required to explain the decision.

This creates a contemporaneous record of why material was excluded, not a retrospective justification.

Regime-specific decision logic

DSARs, FOI requests, and disclosure exercises are governed by different legal and procedural frameworks. Treating them as interchangeable leads to subtle but serious errors.

Redaktr separates workflows by case type and ensures that decision options reflect the regime in question. This prevents, for example, FOI-style reasoning being applied to DSAR material, or vice versa.

The result is a workflow that supports correct judgement rather than encouraging category mistakes.

Full audit trail of review activity

When a disclosure is challenged, it is rarely enough to show the final output. Regulators and courts want to understand the process that led to it.

Redaktr maintains a complete audit trail of review activity, including:

document access,
review actions,
redaction steps,
and decision points.

This allows organisations to demonstrate that disclosure was handled through a controlled, accountable process rather than ad-hoc file editing.

No silent changes, no hidden overwrites

In many document tools, changes are applied silently. It is not always clear who last touched a file or what was altered.

Redaktr avoids this by treating disclosure as a case-based workflow rather than a collection of mutable files. Actions are recorded against the case context, not buried inside document history.

This reduces ambiguity and supports internal assurance.

Designed for realistic volumes

Many redaction tools impose document or page limits that appear reasonable until applied to real-world DSARs, which often involve thousands of items.

Redaktr is designed for case-scale review, not small-batch editing. This avoids the trap of tools that technically work, but collapse operationally when volumes increase.

Outputs you can explain

A recurring theme in disclosure challenges is inconsistency:

redactions that don’t align with stated reasons,
exclusions that are not reflected in outputs,
documents that raise more questions than they answer.

Redaktr is designed to minimise these inconsistencies by keeping decisions, actions, and outputs aligned within a single workflow.

This makes it far easier to explain what was done and why.

Built to reduce hindsight risk

Most disclosure failures are identified after the work is done.

Redaktr is designed to reduce hindsight risk by:

making decisions explicit at the point they are made,
recording context while it is still fresh,
and preventing common technical mistakes before they leave the system.

This does not replace professional judgement. It supports it..

Why these features matter

Disclosure work is not judged by intent. It is judged by outcome and evidence.

Redaktr’s features are not designed to impress in a demo. They are designed to hold up when a decision is examined weeks, months, or years later.

That is the difference between redacting documents and handling disclosure properly.