Reporting channels, case handling & public reporting

The Whistleblowing module is off by default and is enabled per organization. Once on, admins manage reporting channels and incoming cases under Settings → Whistleblowing, and external reporters (employees and others) can submit anonymous reports via a standalone public page.

Reporting channels. A channel is a named destination for reports — e.g. “HR concerns” or “Legal matters” — with a name, an optional description, and a status (active or archived). Create a new channel, archive one that should no longer accept reports (confirmation required), and unarchive an archived channel at any time (reversible, no confirmation needed).

Channel Administrator gives a person the same ability to manage channels as an Admin, without needing the full Admin role — a Channel Administrator can be an entirely ordinary Employee. The grant can be broad (all channels) or scoped to one specific channel, in which case that person only sees and handles cases within that channel. A Channel Administrator cannot grant the same standing to anyone else — only an Admin can appoint more Channel Administrators. If the person you’re granting isn’t already a member of the organization, an account is auto-provisioned for them and an invite email is sent — the same as when an Admin invites an ordinary user.

Public anonymous reporting. Every organization has a standalone, public reporting page (no login required) where anyone can submit a report: free text, a chosen channel, and optional evidence uploads (documents/images). On submission, the reporter gets a case ID and a PIN — these are the ONLY way back into the case; nothing is ever linked to the reporter’s identity (no name, email, or IP is ever stored on the case). With the case ID + PIN, the reporter can later, still fully anonymously: check the case’s status, send a message to the handler and read replies, and upload further evidence. The page’s look (intro text, logo, links) can be admin-customized both org-wide and per individual channel (the channel’s own setting wins when set).

Protecting the reporter’s identity. The PIN is stored only as a salted hash — it is shown to the reporter once and can never be read back, not even from an organisation GDPR export (which also never contains the reporter’s email address). Uploaded images (JPG/PNG) are automatically cleaned of hidden metadata such as GPS location and camera details before they are stored; PDF files are stored as-is, and the upload form warns that such files can contain metadata. The public pages load no third-party fonts; the protection against automated abuse (Google reCAPTCHA) is explained to the reporter on the page.

Case handling (Admin/Channel Administrator). Every incoming case can be listed, opened, and worked: change status, add internal notes (never visible to the reporter), acknowledge receipt (to demonstrate statutory deadlines were met), reply to the reporter (visible to them via their PIN), and download attached evidence files. Assigning case managers lets an Admin or Channel Administrator designate one or more specific people as responsible for ONE case — the “impartial person” model the law requires. Assigning managers is itself a channel-administration action; an already-assigned manager cannot add further managers to that case themselves.

Retention. A nightly job scans every closed case and, once the organization’s (or a specific channel’s own, if set) configured retention period in years has elapsed since the case closed, redacts (not deletes) the case’s title, description, notes, and messages down to a blank placeholder — the case stays as a statistics record, but its content is gone. Retention can therefore be configured differently per channel, not just once for the whole organization.

Audit log. Admins and Channel Administrators can see their own, scoped audit log of whistleblowing-related events (channel creation, status changes, manager assignments, and more) — separate from the organization’s general audit log, which deliberately excludes these entries.

Statutory deadlines (Art. 9). The Directive sets two deadlines per case, and they run in sequence: acknowledgement of receipt within 7 days, then feedback on the action envisaged or taken within 3 months. The public reporting page already promises the reporter both.

The case list’s “Next deadline” column shows whichever one actually applies right now — the 7-day one while the case is unacknowledged, the 3-month one after that, and nothing at all once the case is resolved or closed. A small label next to the date says which it is. An overdue deadline is marked with ⚠ in red, and the column is sortable, so the most urgent case can be brought to the top. The case detail view shows both deadlines, since there is room there and a handler opening a case benefits from seeing the whole clock.

The deadlines are indicators only, never gates — they never block a status change, a note, or anything else.

A case closed without ever being acknowledged keeps showing ⚠. That is deliberate: the deadline was missed, and closing a case does not retroactively acknowledge it. An acknowledgement given late, on the other hand, counts as given — it is not marked overdue, because the duty has been discharged.

Acknowledgement-deadline reminders (off by default). This optional feature is enabled per organization. A daily job (07:00) then scans every open, still-unacknowledged case and emails the channel’s administrators as the 7-day deadline approaches — two days before it runs out.

The email contains nothing about the case. Not the title, the description, the category, or even the case ID. It says only that a report is waiting to be acknowledged, and links to the login. Email sits outside the confidential channel, so nothing about the case is sent there — the handler logs in to see which one.

Each case produces exactly one email per recipient, not one per day. The reminder has its own entry in the delivery ledger, so it neither blocks nor is blocked by the original “new report” mail.

Recipients are the channel’s administrators, and authorization is re-read before every send attempt — an administrator whose grant has been revoked receives nothing, even if the revocation lands mid-run.

Good to know: when the feature is switched on, every older, still-unacknowledged case gets one reminder email on the first run. Reminders are only sent automatically — there is no button to send them manually.