Asking the reporter to investigate
A report that asks staff to check logs or run a scan sends them into work they are not trained for, and it can disturb evidence. Keep the form to what they saw and did.
Security incident report: the facts to record before anyone investigates
A security incident report records a suspected event, such as a phishing email, a lost device or an account that signed in from an unexpected place, along with what the reporter saw and did. It should capture facts in order and the time they were first noticed, without copying a password or the sensitive data itself. The security lead decides what happens next, and the report is the starting record for that decision.
What people search
Security incident report: 320 average monthly searches.Google Ads Keyword Planner · 2026-10-09 · United States
A filled example
A completed report for a suspicious email, as a fictional example
Example only, not a real submission
- Kind of event
- Suspicious email or phishing
- First noticed
- Tuesday, October 6, around 8:40 a.m. Eastern
- Systems or accounts involved
- One staff member's work email. No sign-in was attempted.
- What was seen
- An email from an unfamiliar address asked the reader to confirm a shared document password through a link. The link was not opened.
- Actions taken
- The reporter forwarded the email to the security mailbox as received, deleted nothing and did not reply.
- Personal or customer data possibly involved
- Not sure. The email contained no attachments and no data was entered anywhere.
- Others affected
- Not sure. A colleague reported a similar email about an hour later.
Field blueprint
What the security lead needs in the first report
| Field | Type | Required | Why you ask it |
|---|---|---|---|
Reporter name | Short text | Required | Lets the security lead ask for detail and confirm who first saw the event. |
Reporter work email | Required | The main route for follow-up. It should be an address you can read while the incident is open. | |
Reporter phone | Phone | Optional | Lets the security lead call you when email is too slow for the question in hand. |
Kind of eventSuspicious email or phishingLost or stolen deviceSuspected account compromiseAccess to data you should not seeMalware or ransomware warningData sent to the wrong personOther suspected security event | Dropdown | Required | Tells the security lead which kind of event the report covers. |
Date first noticed | Date | Required | Starts the timeline. Estimate if you are not sure, and say so in the description. |
Time first noticed, with time zone | Short text | Optional | Narrows the timeline when more than one event happened on the same day. |
Systems, devices or accounts involvedDo not include passwords, codes or recovery answers. | Long text | Required | Names what the security team must check. Use names and identifiers, never the secret itself. |
What you sawFor example: a message asked me to confirm my login on a page that was not our sign-in site. | Long text | Required | Records observable facts, such as a message, a sign-in prompt or a missing file, rather than your conclusion. |
Actions taken so far | Long text | Optional | Shows what has already changed, such as a password reset or a disconnected device, so the team does not repeat or undo it. |
Could personal, customer or financial data be involved?YesNoNot sure | Single choice | Required | Tells the privacy or security lead whether a data review is needed. Answer without copying the data itself. |
Is anyone else affected right now?Yes, others may be affectedNo, only my account or deviceNot sure | Single choice | Required | Shows whether the event is spreading or still contained. |
Evidence you keepThe form cannot hold the original email or log, so tell the security team where it is kept. | Section header | Separates the facts you describe from material that stays where it is. |
Mistakes to avoid
Four things that slow down a security report
Collecting the secret itself
If the form asks for the password that may have leaked, you have created a second copy of it. Ask for the account name and the time of the change instead.
Waiting for certainty before reporting
Early reports are more useful than perfect ones. Tell staff to report a suspicion and say they are not sure, rather than waiting until they are certain.
Expecting the report to close the incident
A report does not contain the incident. The security lead decides containment, and any notice to customers or regulators follows the process your organization has set up for that.
After a response arrives
How the report moves after it is submitted
The creator is notified after the schedule runs
Attain OS stores the report, and a scheduled job processes it hourly in production. The creator is notified after that processing, so also message the security lead directly through your own channel.
Do not wait for the grid to start containment
If an account is still signed in under someone else's control, the security lead acts from the source system. The grid is the record of the report, not the response to it.
Name an owner for each report
When Customer Care case creation is on in the form settings, each report becomes a case with the priority, tags and assignees you set. Assign it to the security lead rather than a general queue.
Export CSV for the incident log
Export CSV from the grid to copy the intake list into your incident log, and keep each original submission as it was received.
Working checklist
Steps after the report is in
First ten minutes
- Stop sharing the suspicious message or file with others
- Do not delete the email, file or message to clean up
- Write down the time you first noticed it
- Submit this report, then follow the security team's instructions
Inside the security team
- Confirm the account or device owner
- Decide whether access should be reset or suspended
- Record each action with its time
- Ask the privacy or legal lead whether any notice duty applies
After closure
- Write the account of events in plain language
- Note which control or habit would have caught it earlier
- Share the lesson with the people who were targeted
Frequently asked questions
What should an IT security incident report include?
The kind of event, when it was first noticed, what was seen, which systems or accounts are involved and what was already done. Leave out the secret or the data itself. The security team can ask for more detail after the first report.
What does a good security incident report example look like?
A good example separates facts from guesses and lists them in the order they happened. The example on this page is fictional and uses no real names, systems or addresses.
How is a cyber security incident report different from an IT incident report?
An IT incident report usually covers outages and failures. A security report covers suspected misuse, compromise or exposure. Use this form for the second group, and send service outages to the system outage notification.
Does a lost laptop need a security incident report?
Yes, when the device may hold company data or give access to company accounts. Report it as soon as it is missing, even if you think it may turn up. The security team decides whether to lock or wipe it.
Browse by category
More reports in IT & Technical Support
Reports
System Outage Notification
Reports
Internal Bug Report
Requests
Software Access Request
Requests
VPN/Remote Access Request
Requests
Website Update Request
Checklists
Asset Checkout/Return
How to build it
Choose a category and a form type in the wizard. Answer three Atty Suggestions questions, then give the form a title. Atty builds the fields in the background. Edit the fields and ask Atty to refine them, then publish and share the /f/ link.
