Zum Hauptinhalt springen
Starter Kit · Register

Incident Register

Updated on 2 min Reviewed by: Cenedril-Redaktion
A.5.24A.5.25A.5.26 ISO 27001NIS2 Art. 23BSI IT-Grundschutz

The incident register is the central record of every information security incident your organisation experiences. Each incident — from a phishing attack to a lost USB drive to a ransomware infection — is captured, classified, and tracked here.

ISO 27001 dedicates three controls to the topic: A.5.24 (planning and preparation), A.5.25 (assessment and decision), and A.5.26 (response to incidents). NIS2 tightens reporting deadlines toward national authorities in Art. 23. The register ensures that every incident follows the defined process.

What does it contain?

The CSV template covers the full lifecycle of an incident:

  • Incident ID and title — unique identifier and brief description
  • Classification and severity — low, medium, high, critical
  • Timestamps — detection, reporting, containment, closure
  • Affected assets and systems — link to the asset register
  • Incident coordinator — who manages the response?
  • Immediate and long-term actions — what was done?
  • Reporting obligations — was the incident reported to authorities, affected individuals, or customers?
  • Lessons learned — what findings feed back into the risk analysis?

How to use it

Establish a reporting channel. Before the register works, everyone in the organisation must know where to report incidents. A dedicated channel (email alias, ticket category, intranet form) lowers the barrier. Communicate the reporting channel during onboarding and in annual awareness training.

Classification and escalation. Every reported incident is classified by severity. The classification determines the escalation level: low-severity incidents are handled by the IT team independently; critical incidents escalate to senior management and — depending on NIS2 applicability — trigger a report to the relevant authority.

Post-incident review and feedback into risk analysis. Every closed incident is reviewed. What happened? Why did the existing control fail or succeed? What changes to the risk register or risk treatment plan result from this? This feedback loop closes the PDCA cycle.

Register Template

Incident Register

IDTitleTypeSeverityAffected AssetsReported ByReported AtDetected ByDetection MethodResponse TeamContainment AtResolved AtMTTR (h)Data BreachAuthority NotificationRoot CauseCorrective ActionStatus
INC-2026-001Phishing email with credential linkPhishingMediumUser account k.mueller@nwlIT Helpdesk2026-01-22 09:14SOCSIEM alertSecOps2026-01-22 09:452026-01-22 14:004.8NoNoBypassed filter (newly registered domain)Enable NRD rule + CAPA-2026-003Closed
INC-2026-002EDR alert on developer laptop (Cobalt Strike beacon)MalwareHighAST-006 (1 laptop)EDR2026-02-03 23:41EDRBehavioural detectionSecOps2026-02-03 23:552026-02-05 12:0037.0NoNoFalse positive - red team exercise not coordinatedUpdate exclusion + coordinate exercisesClosed
INC-2026-003Lost company laptopLost deviceMediumAST-006 (1 laptop)Employee2026-02-15 08:30User reportSelf-reportIT Operations2026-02-15 08:452026-02-15 10:001.5NoNoLeft in taxiRemote wipe triggered + replacement issuedClosed
INC-2026-004Targeted phishing against finance (BEC attempt)PhishingHighFinance teamFinance Lead2026-02-22 11:20User reportRecipientSecOps2026-02-22 11:252026-02-22 16:004.6NoNoAttempt blocked by awareness - no clicksTargeted finance trainingClosed
INC-2026-005Unauthorised access attempts to VPNBrute forceLowAST-011SOC2026-03-01 02:14SIEM alertLog correlationSecOps2026-03-01 02:202026-03-01 09:006.8NoNoAutomated scanningBlocked source IPs + geo filterClosed
INC-2026-006Accidental email with customer list to wrong recipientData leakHighCustomer data (45 records)DPO2026-03-12 14:30User reportSelf-reportDPO + SecOps2026-03-12 14:352026-03-12 18:003.5YesYes (BfDI 72h + data subjects)Autocomplete selected wrong addressEnable email send confirmation + DLP (CAPA-2026-005)Closed
INC-2026-007DDoS on customer portalDoSMediumAST-002Monitoring2026-03-20 19:15Availability monitoringSynthetic checkSecOps + Vendor2026-03-20 19:452026-03-20 22:303.3NoNoVolumetric attack via vendorActivated CDN Layer 7 protectionClosed
INC-2026-008S3 bucket temporarily public after manual changeMisconfigurationHighAST-012IT Operations2026-03-25 10:00IaC scanAutomatedSecOps2026-03-25 10:122026-03-25 11:001.0No (no sensitive data accessed)NoEngineer bypassed IaCReinforce IaC + S3 public access blockClosed
INC-2026-009Ransomware attempt blockedMalwareHighAST-006 (1 laptop)EDR2026-04-02 15:30EDRBehavioural detectionSecOps2026-04-02 15:312026-04-03 12:0020.5NoNoUser opened malicious attachmentAwareness session + attachment filter tuningClosed
INC-2026-010Insider - failed access attempt to payrollUnauthorised accessMediumAST-017SIEM2026-04-08 16:20SIEM alertAccess log correlationISO + HR2026-04-08 16:302026-04-09 10:0017.7NoNoCuriosity (not malicious)Reminder of AUP + access reviewClosed

Sources

ISO 27001 Controls Covered

A.5.24 Information security incident management planning and preparation A.5.25 Assessment and decision on information security events A.5.26 Response to information security incidents

Frequently asked questions

What counts as a security incident?

Any event that actually or potentially compromises the confidentiality, integrity, or availability of information. This includes malware infections, data breaches, unauthorised access, successful phishing attacks, and physical events like laptop theft. A security event (e.g. a failed login attempt) only becomes an incident when it causes measurable harm or requires a response.

Who can report incidents?

Anyone in the organisation — employees, contractors, external partners. The barrier to reporting should be as low as possible. Many organisations set up a dedicated reporting channel (email alias, ticket category, intranet form). ISO 27001 A.6.8 requires that all personnel know how and where to report incidents.

How long must incidents be retained?

ISO 27001 does not prescribe a fixed retention period. The duration depends on your document control policy and applicable legal requirements. In practice, at least three years is recommended — this covers typical certification cycles and regulatory enquiries.