Skip to content

Privacy Redaction & Investigations

PolicyClue masks sensitive cleartext content in the portal UI and in API responses by default. Cleartext access is gated by a Four-Eyes workflow: an admin requests an investigation, a second admin approves, and both can see the cleartext of the listed records for up to 24 hours.

This document covers the operational view from the Privacy tab in the tenant settings.

What is masked

By default, the cleartext content of these fields is shown as [REDACTED] everywhere except inside an active, approved investigation:

  • Recorded prompts — text users typed into monitored sites, for example GenAI tools.
  • DLP match values — the exact substring that triggered a Data Loss Prevention rule.
  • DLP match context — the surrounding characters of a DLP hit.

Other fields (timestamps, URLs, hostnames, alert types, severity, and so on) remain visible to all admins.

Disabling redaction per tenant

A toggle on the Privacy settings tab lets an admin disable redaction entirely. This is intended for setups where redaction is unnecessary, for example an internal test tenant or a single-user evaluation. Disabling makes all sensitive content visible to every tenant admin immediately. A confirmation dialog appears before the change takes effect.

Starting an investigation

When a redacted value appears in the UI, an Investigate link is shown next to it. Clicking the link opens a dialog with two paths:

  1. Add to existing pending investigation: appended to one of the admin's own pending investigations.
  2. Create new investigation: starts a fresh investigation. Requires a written comment explaining the compliance reason for accessing the cleartext.

The record is added to the investigation in the pending state. While pending, the initiator can add more records via additional Investigate clicks, or remove a record from the Investigation Inbox.

Approving an investigation

A second tenant admin (not the initiator) must approve. The Investigation Inbox under the Privacy tab has three views, each with a counter badge:

  • To approve: pending investigations opened by other admins.
  • Mine: investigations the current admin initiated.
  • All: full history of every investigation for the tenant.

When a new investigation is opened, an email is sent to every tenant admin except the initiator. The email includes the initiator, the number of records requested, the initiator's compliance reason and a direct link to the Privacy tab. Global admins are not notified.

Approving requires a written justification confirming that the cleartext access is proportionate: it is necessary for the stated compliance purpose, no less-intrusive means would suffice, and the record scope stays limited to what the case requires. The reviewer sees the complete record list at approval time. The list is locked from there on, and no further records can be added.

Rejection also requires a written reason (minimum 5 characters). The initiator sees this comment in the Investigation Inbox.

The reveal window

After approval, the initiator and the reviewer both see cleartext for the listed records for the next 24 hours. The reveal applies wherever the records are rendered in the portal: Triage view, Document Inspector, search results.

A confirmation email is sent to the initiator at approval time. It includes the reviewer's comment, the number of records covered, the exact expiry time of the reveal window and a direct link back to the Privacy tab.

Either the initiator or the reviewer can close the investigation early via the Close action in the Investigation Inbox. Closing ends the reveal window immediately; the audit trail is preserved.

Pending investigations expire after 24 hours

If a pending investigation is neither approved nor rejected within 24 hours, it expires automatically. The initiator can close it earlier or start a fresh request.

What gets audited

The audit log captures the investigation lifecycle:

  • create: when a request is opened.
  • add_record / remove_record: while pending.
  • approve / reject: with comment.
  • close: when the initiator or reviewer closes the request, or it expires naturally.

The audit entries persist after the investigation is closed and are visible under the All tab of the Investigation Inbox.

Per-render reveal accesses are intentionally not logged separately. The approved investigation itself, with its frozen record list, initiator, reviewer, comments and timestamps, already documents who could see what, when. Adding a per-page-load audit entry would only inflate the log without strengthening the compliance trail.

Scope and limits

  • One record at a time. Records are added individually via the Investigate button; there is no bulk-select. Pending investigations can grow to many records this way, and the reviewer sees the final list before approving.
  • No user-scope investigations. An investigation refers to specific record IDs, not "all events from user X". For larger compliance cases, the initiator builds the list by adding records explicitly. Blanket user-level disclosure conflicts with the proportionality principle.
  • Single-tenant. Each investigation lives in a single tenant. Cross-tenant access (for example a partner reviewing a customer's records) is not modelled.