Suspected Security Incident Report Form Template

A suspicious message does not automatically mean a breach occurred. A reporter should be able to explain what they saw and which service was involved while the designated security team determines the next step.

Use this as an initial notification only after your security team approves the collection channel, access controls, and monitoring process. For ordinary product questions without a security concern, use a separate support request form . An active urgent incident must follow the organization's established escalation route.

Report one suspected digital security concern using general descriptions. You do not need to confirm a breach. Do not include passwords, access codes, customer data, full message contents, suspicious clickable links or files. Every field is optional. Use the organization's stated urgent reporting route if immediate attention is needed; this form alone does not guarantee a response.

Replace the escalation note with the verified, monitored route your organization actually uses. State who receives reports, the real monitoring hours, and a fallback if the usual account or device is affected. Keep no-upload instructions prominent. The form must not invite passwords or technical evidence dumps. Tell reporters that 'not sure' is acceptable, and obtain security-team review before using a survey platform for real incident notifications.

Make the approved route easy to find before an incident occurs. Encourage prompt use according to the organization's process, without asking people to investigate first. A public template demo is only a demonstration and does not notify a security team.

Treat each response as an unverified report. The authorized team should review observation time, affected service, observed behavior and actions already taken together, then use the established incident process. Do not auto-label an employee careless, infer the scale of a breach from one report, or treat a submission counter as incident prevalence. Keep case status, technical evidence and response actions in the approved incident-management system. Document how follow-up will occur when contact information is missing.

Burda, Allodi, Serebrenik, and Zannone's 2024 university case study interviewed 49 employees who had reported phishing emails and identified “13 main themes driving reporting motivations.” It highlights reporting as a human process to understand, rather than assuming a policy guarantees participation. Its reporter-only sample does not validate this form or prove it increases reporting. The study covers phishing, not every incident type listed here. Read the phishing reporting study .

Copy this suspected security incident report form prompt into an AI assistant to prepare the questionnaire. Review the result, then build and customize it in SurveyLegend. It does not automatically create or transfer a survey.