The first hour after a security problem decides how bad it gets. People wait because they feel foolish, or they are unsure whether it counts. I want them to report anyway. A short form with plain questions is easier than writing an email to IT.
Before something happens
I put the link in the staff handbook and the welcome email, and I tell people: report, even if unsure, and nobody is blamed. I also name who reads the CSV and who gets a phone call. A form is not an alarm bell for an attack that is happening now.
While someone reports
The reporter gives the date, the kind of problem, what they saw, and whether personal data may be involved. Optional boxes cover what was affected and what they have done. Their AI might ask: "What did you notice?" Then "Which systems could be affected?" Then "Have you told IT?" It shows the answers and sends them only after a yes. See agent-fillable forms.
After the report
Someone reads each row the same day and decides the next step outside the form. People also search for a data breach report form. This covers the first report only. It does not stop an attack or tell any authority.
This is a form, not legal advice. Breach notice rules differ by place, so have a professional check your wording and your duties.
For a general workplace event, use an incident report. Close calls fit a near miss report. More tools are in IT and operations forms.
Questions
What if someone is not sure it counts as an incident?
They should report it anyway. The data question has a not sure choice, and the form never asks anyone to decide how serious it is. You triage the rows.
Why does the form not ask for logins or codes?
It must never collect them. The help text says so, and the API rejects fields that ask for secrets. Reporters describe what they saw, and IT handles access.
How do I handle reports quickly?
Turn on `notify_email` for a notice on each new report, and read the `still_happening` column first. A signed webhook can also pass reports to your ticket tool.