Most incidents are first noticed by someone outside the security team, and the facts they hold in the first hour are lost if nobody writes them down in a consistent way. A security incident report form is the intake record an employee, contractor or service desk analyst completes when something looks wrong: a suspicious email that was clicked, a lost laptop, a strange sign-in prompt, data sent to the wrong person. This template gives [Organisation] a ready-to-use form, laid out so each section feeds the next stage of response: triage, containment, eradication, recovery and notification. It is written for security managers, service desk leads and privacy teams who need one form that works for a frightened end user and for the analyst who picks it up. The form sits under the Incident Response Plan Template, which defines what happens once a report is accepted. Replace every [placeholder] before use.
How to use this template
- Split the form into two parts. Part A (sections 1 to 4) is short and is filled in by the reporter in plain language. Part B (sections 3 to 8, marked SD or IR) is completed by the service desk and the incident handler. Do not make a reporter answer Part B questions: long forms delay reports.
- Offer more than one channel. Publish the form on the intranet and in the IT service portal, and keep a phone line and a named mailbox such as [[email protected]] for people who cannot reach either. The NCSC advises planning secure alternative channels for when email or phone systems are themselves affected.
- Record times with a time zone. Ask for the time in local time and store it in UTC in the ticket. Regulators measure deadlines from when the organisation became aware, so the time the report arrived matters.
- Make "I don't know" a valid answer for every reporter field. A partial report in ten minutes is worth more than a complete one tomorrow.
- Tell staff what happens next. The form ends with a reference number and a plain statement that reporting is welcomed and that mistakes reported quickly are not punished.
1. Scope and triggers
1.1 Use this form to report any actual or suspected event that could affect the confidentiality, integrity or availability of [Organisation] information, systems or accounts, including those run by suppliers on [Organisation]'s behalf. CISA's own reporting form uses the same test: was confidentiality, integrity or availability potentially compromised.
1.2 Report now, without waiting for certainty, if any of these happen:
| Trigger (what the reporter sees) | Incident category for triage | Usual first owner |
|---|---|---|
| Clicked a link, opened an attachment or entered a password after a suspicious email, text or call | Phishing, possible credential theft (ATT&CK T1566 Phishing) | Service desk, then SOC |
| MFA prompt or sign-in alert the person did not start | Account compromise (T1621 Multi-Factor Authentication Request Generation, T1078 Valid Accounts) | SOC, identity team |
| Lost or stolen laptop, phone, token or badge | Lost asset, possible data breach | Service desk, endpoint team |
| Personal or confidential data sent, shared or published to the wrong place | Data breach (possible personal data breach) | Privacy lead |
| Ransom note, files renamed or unreadable, systems slowing or locking | Malware or ransomware | SOC, major incident manager |
| A password, API key, token or private key pasted into a ticket, chat, repository or public site | Leaked credential | SOC, owning engineering team |
| Someone asking for access, payments or MFA resets in an unusual way | Social engineering or fraud attempt | SOC, finance or help desk lead |
| Supplier tells [Organisation] it has had an incident | Third-party incident (T1199 Trusted Relationship) | Supplier manager, SOC |
1.3 Out of scope: routine IT faults with no security angle (a printer jam, a forgotten password with no suspicious activity). If unsure, report it: the service desk will reclassify.
2. Roles and contacts
2.1 Reporter details (Part A, required):
- Name, job title, team and location: [ ]
- Best contact number that is not the device involved: [ ]
- Are you reporting for yourself or on behalf of someone else (customer, supplier, colleague)? [ ]
2.2 Who receives the form:
| Role | Named contact | What they do with the report |
|---|---|---|
| Service desk analyst (first line) | [Rota, queue name] | Acknowledges within [15] minutes, completes Part B triage fields, opens the security ticket |
| SOC or on-call security analyst | [Rota, phone] | Validates the report, rates severity, decides whether to declare an incident |
| Incident lead | [Name, deputy] | Owns declared incidents, the decision log and escalation |
| Privacy lead or DPO | [Name, mailbox] | Assesses any personal data element and the regulatory clock |
| Legal, HR, communications | [Names] | Joined by the incident lead when the facts require it |
2.3 List at least two people and two contact methods for every role, as the NCSC recommends for incident contact lists, and review the list each quarter.
3. Detection and triage
3.1 What happened (Part A, reporter):
- Describe in your own words what you saw or did: [ ]
- When did it start, roughly? Date, time and time zone: [ ] (optional, "unknown" is fine)
- When did you notice it? Date, time and time zone: [ ] (required)
- How did you notice it (email, pop-up, alert, a colleague, a customer)? [ ]
- Which device, system, application or account is involved? Asset tag or hostname if you know it: [ ]
- Is it still happening? Yes / No / Don't know
- Could information have been seen, changed or lost? Which kind: customer data, staff data, financial, health, credentials, confidential business data, none, don't know: [ ]
- Roughly how many people or records could be affected? [ ]
- Have you kept the evidence (the email, screenshot, URL, file name, message)? Do not delete it. [ ]
3.2 Triage (Part B, SD then IR): NIST CSF 2.0 RS.MA-02 expects incident reports to be triaged and validated, and RS.MA-03 expects incidents to be categorised and prioritised. Record:
| Field | Options or format | Why it matters |
|---|---|---|
| Ticket reference and received time (UTC) | [SEC-YYYY-NNNN], ISO 8601 timestamp | Starts the response timeline and any regulatory clock |
| Category | Phishing, malware, unauthorised access, account compromise, data breach, lost asset, denial of service, insider, third party, other | Selects the playbook |
| Impact on confidentiality, integrity, availability | None / suspected / confirmed for each | Drives severity, following the NCSC triage approach |
| Severity | [Critical / High / Medium / Low] from the severity matrix | Sets response time and escalation |
| Personal data involved | Yes / No / Unknown, with data categories | Brings in the privacy lead at once |
| Validated by and time | Analyst name, UTC time | Separates reports from declared incidents |
| Decision | Declare incident / handle as security event / close as false positive (with reason) | Every closure needs a recorded reason |
3.3 Use the Incident Severity Classification Matrix Template for the severity field so that a service desk analyst and a SOC analyst reach the same rating.
4. Containment
4.1 Actions already taken (Part A, reporter): tick all that apply and add the time.
- Disconnected the device from the network (Wi-Fi off, cable out), but left it powered on: [ ]
- Changed a password, and from which device: [ ]
- Deleted, forwarded or replied to the message: [ ]
- Told a colleague, customer or supplier: [ ]
- Nothing yet: [ ]
4.2 Guidance printed on the form for reporters: do not switch the device off, do not try to investigate or "clean" it yourself, do not forward suspicious attachments to colleagues, and keep the original message. Switching off destroys memory evidence; forwarding spreads the lure.
4.3 First containment record (Part B, IR): for each action record what, who, when (UTC) and the approval. Typical first actions: isolate the endpoint through EDR, disable the account and revoke its sessions, block the sender or URL, revoke a leaked key. Each action links to the matching playbook, for example the Account Takeover Response Playbook or the Leaked Credential Response Playbook.
5. Eradication
5.1 Evidence collected (Part B, IR): list each item with its location, hash where relevant, who collected it and when. CSF 2.0 RS.AN-07 asks for incident data and metadata to be collected with integrity and provenance preserved, and RS.AN-06 asks for investigation actions to be recorded the same way.
| Evidence type | How to preserve it |
|---|---|
| Suspicious email | Export as .eml or .msg with full headers; do not just forward the body |
| URL or website | Copy the text of the link without clicking it; screenshot with visible time |
| Endpoint | Isolate, keep powered on, collect memory and triage image per the forensic procedure |
| Account activity | Export identity provider sign-in and audit logs for the account, at least [30] days back |
| Chat, ticket or document where a secret was pasted | Record location and time, then restrict access; do not delete until the secret is revoked |
5.2 Record the root cause once known and the eradication steps taken (malware removed, rogue accounts or rules deleted, credentials rotated). See the Evidence Handling and Chain of Custody Guide.
6. Recovery
6.1 Recovery record (Part B, IR): systems restored, accounts re-enabled, verification performed and the date normal operation resumed. Note any monitoring kept in place and for how long.
6.2 Reporter follow-up: confirm to the reporter that their device or account is safe to use again and whether they need to do anything (re-enrol MFA, collect a replacement laptop).
7. Communication and notification
7.1 Notification assessment (Part B, privacy lead and legal):
| Question | Record |
|---|---|
| When did [Organisation] become aware of a personal data breach? | Date and time (UTC). Under UK GDPR and EU GDPR Article 33(1), notification to the supervisory authority is due without undue delay and, where feasible, not later than 72 hours after becoming aware, unless the breach is unlikely to result in a risk to individuals |
| Is [Organisation] the controller or a processor? | Under Article 33(2) a processor notifies the controller without undue delay |
| Nature, categories and approximate numbers | Data subjects and records, as Article 33(3)(a) requires in a notification |
| Likely consequences and measures taken | Article 33(3)(c) and (d) |
| Other duties | Sector or national incident reporting (for example NIS, DORA, CIRCIA), contracts, insurers, law enforcement: [ ] |
| Decision and approver | Notify / do not notify, reason, approver, time |
7.2 Keep the form even when the decision is not to notify. Article 33(5) requires the controller to document every personal data breach, its effects and the remedial action, so the regulator can verify compliance. The ICO asks for the same facts when a breach is reported: what happened, when and how it was found, who is or may be affected, what is being done and who else has been told. Building those questions into this form means the notification can be drafted from it. For the deadlines in other jurisdictions see the Cyber Incident Reporting Requirements Map and the Data Breach Notification Checklist.
7.3 External reporting routes to publish next to the form (adjust by country): in the UK, suspicious emails can be forwarded to [email protected]; in the US, CISA accepts incident reports through its online form and 24/7 on (888) 282-0870.
8. Post-incident review
8.1 Closure fields (Part B, incident lead): final category and severity, root cause, time from first event to report, time from report to triage, time to containment, whether notification was made, lessons learned and the actions raised with owners and due dates.
8.2 Feedback to the reporter: thank them and, where appropriate, tell them what their report prevented. Reports rise when people see that reporting made a difference.
8.3 Trend review: each month, review the reports by category, by channel and by business unit. The NCSC recommends using the record of decisions and actions in post-incident reviews to find missing data and lessons learned; missing fields in this form are a lesson too.
Implementation guidance
- Build it into the service desk tool first. Create a "Security incident" request type with Part A as the public form and Part B as internal fields, so every report gets a ticket number and timestamps automatically. NIST SP 800-53 IR-6(1) covers automated reporting mechanisms.
- Add a one-click route for phishing. A report button in the mail client that sends the message with headers into the same queue removes the most common reason for incomplete reports. See the How to Spot a Phishing Email Guide.
- Pilot with the service desk. Run five past incidents through the form in a tabletop and check that the analyst could triage from Part A alone. Remove any reporter question nobody could answer.
- Train and remind. Put the reporting route in induction, security awareness training and on lock screens. NIST SP 800-53 AT-2 covers literacy training and awareness, and its enhancement AT-2(2) covers recognising and reporting potential indicators of insider threat.
- Size it. A small organisation can run this as a shared mailbox and a spreadsheet log, as long as times and decisions are recorded. A large one should route reports by category to queues, integrate with the SOC case tool and report metrics monthly.
- Measure it: median time from detection to report, median time from report to triage decision, percentage of reports with Part A complete, proportion of incidents first reported by staff, and reports per 100 staff per quarter.
| Form section | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Reporting route and Part A | DE.AE-06 | IR-6, AT-2 | A.6.8 Information security event reporting |
| 3. Triage | RS.MA-02, RS.MA-03 | IR-4, IR-5 | A.5.25 Assessment and decision on information security events |
| 4. to 6. Containment, eradication, recovery | RS.MA-01, RC.RP-01 | IR-4 | A.5.26 Response to information security incidents |
| 5. Evidence | RS.AN-06, RS.AN-07 | IR-4 | A.5.28 Collection of evidence |
| 7. Notification | RS.CO-02, RS.CO-03 | IR-6, IR-7 | A.5.24, A.5.26 |
| 8. Review | RS.AN-03 | IR-4, IR-8 | A.5.27 Learning from information security incidents |
CIS Controls v8.1 Safeguard 17.3 asks organisations to establish and maintain a process for workforce members to report security incidents, including the timeframe, personnel to report to and the minimum information to be reported; this form is that minimum information. See the NIST SP 800-61 Incident Response Guide for the wider response life cycle.
References: NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management · CISA: Incident Reporting Form · NCSC: Cyber incident response processes · ICO: Report a personal data breach · EUR-Lex: Regulation (EU) 2016/679 (GDPR), Article 33 · NCSC: Report a scam email
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Incident Response Plan Template · Incident Response Guide · Forensic Readiness Guide · Breach Notification Laws by Country Guide · Security Awareness and Human Risk Management Guide