Replying to an anonymous report

An anonymous channel that only collects is half a channel. Someone reports a problem, and then silence: they cannot be told it was read, cannot be asked the one clarifying question that would make it actionable, and cannot be given an outcome. This page explains how InviziPoll closes that loop without ever learning who wrote the report.

What the reporter does

On a poll with replies turned on, the response page offers a checkbox before submit: Get a return code so we can reply. It is ticked by default, and unticking it submits exactly as before, with no way to write back.

1. The browser draws a code. Twenty-six characters in five groups, from a random draw that happens on the reporter's device. The last character is a checksum, so a mistyped code fails locally instead of looking like silence.
2. The code becomes a keypair. It is expanded with HKDF-SHA-256 into the seed for an X-Wing keypair. Nothing is stored: the same code re-derives the same keys on any device, months later.
3. The identifier travels inside the ciphertext. A short block naming the mailbox and its public key is sealed together with the answers, so it reaches us only as part of the encrypted response.
4. The code is shown once. On the confirmation screen, with copy, download and print. There is no second chance, and the screen says so.

Later, the reporter opens the reply page, types the code, and sees the status of their report plus anything the admin has written back. They can send a follow-up from there.

What the admin sees

Replies unlock with results. Written answers only appear once the poll clears its minimum group size, so below that threshold there is nothing to reply to, and the server refuses a reply attempt as well.

Above it, two surfaces:

• On a written answer. Any answer whose reporter took a code gets a Reply control and a status selector. Answers from people who declined a code show nothing at all, which is also how you can tell the two apart.
• The Speak-up inbox. One row per report that carries a code, on Business and Enterprise plans, and on workspaces trying the Business features preview during a trial. Each row shows the status, how many weeks old the report is, the conversation so far, and a composer. A chip at the top counts reports still awaiting acknowledgement and names the oldest week.

Status is one of four coarse values: received, acknowledged, under review, closed. Sending a reply marks a report acknowledged on its own, so there is no state where you have answered someone but the record says you have not.

If a poll asks more than one written question, a single person's answers appear in more than one list and share one conversation. A reply sent from any of them arrives in the same place, and the page says so where it matters.

What we can and cannot know

This is the part worth reading before you write a policy around it.

We hold	We do not hold
Ciphertext of every response	Any response in readable form
A coarse status per report	The text of any reply or follow-up
An opaque mailbox identifier	Any link from it to a person
The week a reporter declared	The time a response was submitted

Two consequences follow, and both are load-bearing.

We cannot recover a lost code. Not for the reporter, not for you, not for a regulator. The code is the key, and we never see it.

We hold no submission time for a report. Response records deliberately carry no timestamp. The age you see in the inbox comes from a week the reporter's own browser recorded and sealed inside their response, which is why the inbox says "3 weeks ago" and never a date. A reporter could set it wrong, and only weakens their own position by doing so.

Replies you write are encrypted to the reporter's key, not to the poll key. Someone you have given a shared results link to can decrypt responses, and still cannot read what you wrote back.

Directive (EU) 2019/1937

Organisations in the EU above a size threshold must run an internal reporting channel that acknowledges receipt within seven days and gives the reporter feedback within a reasonable period not exceeding three months. The obligations are in Article 9 of Directive (EU) 2019/1937.

What the product does, stated as plainly as we can:

The Directive asks for	What InviziPoll provides
Acknowledgement within 7 days	Status plus a readable reply
Feedback within 3 months	A thread that outlives the poll
Anonymous reporting where permitted	No identity collected
A record of handling	Coarse status per report

Three gaps you have to close yourself. Acknowledgement only reaches a reporter who kept their code and comes back to check. The seven-day and three-month clocks are yours to run, because we hold no submission time to run them from. And handling records beyond a coarse status, such as who investigated and what was decided, live in whatever case system you already use.

Known limits

The reporter has to check in. There is no notification, and there cannot be one: a notification needs an address, and collecting an address would undo the anonymity the channel exists for. Tell people this when you publish the channel, and give them a reason to come back, for example "we answer within a week, so check on Monday".

Follow-ups are not authenticated. A mailbox identifier is unguessable, but it is not a password, and it sits inside the response ciphertext. Anyone who can decrypt that poll's responses can read it. That includes you, and it includes anyone holding a shared results link for the same poll. Such a person could post a follow-up into a conversation you have opened.

What that does and does not mean:

• They cannot read your replies, which are encrypted to the reporter's key alone.
• They can read the reporter's follow-ups, which are encrypted to the poll key like any response.
• They can add a message that will appear to come from the reporter.

So treat a follow-up as text, not as proof of who sent it. If you share results publicly on a poll that also runs a reply channel, understand that you are widening who can read follow-ups and post into threads. The safest arrangement is to keep the two apart: a speak-up poll does not need a public results link.

No case management. No assignment, no due dates, no evidence uploads, no export for counsel. A conversation caps at forty messages, and each message caps at roughly twenty-four kilobytes of text.

Replies end when responses do. A conversation is deleted with the poll's responses under the same retention setting. If a three-month feedback obligation applies, set retention long enough to cover it.

Turning it on

Replies need an active paid plan or trial. The wizard shows the toggle on the Distribution step for any poll with a written question, and the always-on speak-up template turns it on for you. On a live poll, the toggle also sits at the top of the Speak-up inbox, which is the usual moment to reach for it: you have read the first written answers and realised one of them needs an answer back.

Turning replies on affects responses submitted from that point onward. Answers already collected have no return code and cannot be given one, because the code never existed anywhere we could reach.