Information security incident management and reporting audit program.
How to audit whether security incidents are detected, classified, handled and reported to the competent bodies within the deadlines, and whether the organisation learns from them.
Last updated: 13 October 2026 · Sample, not legal advice
Download the sample as PDF 8 pages, no sign-up
Download as Excel template with columns for result and notes, no sign-up
Audit objective
The audit assesses whether the organisation runs an incident process covering reporting, assessment, classification, containment, recovery and review. It also assesses whether reporting duties towards authorities, supervisors and data subjects can be met within their deadlines, and whether responsibilities and deputies are clarified.
Scope
- Security incidents in IT, applications, networks and at service providers that affect confidentiality, integrity or availability
- Reporting paths within the organisation and to authorities, supervisors, customers and data subjects
- Functions involved: information security, IT operations, data protection, legal, communications and management
- Out of scope: case-specific technical forensics and incident handling in physical security
Audit program
| No. | Criterion | Reference | Audit procedure | Expected evidence |
|---|---|---|---|---|
| 1 | An incident handling process exists, is approved and defines roles, procedures and escalation. | ISO/IEC 27001:2022 Annex A 5.24; BSI DER.2.1; NIS2 Directive Art. 21(2)(b) | Read the process description, check approval and currency and compare roles with the organisation. | Process description with approval, role overview, escalation plan |
| 2 | Employees and providers know the reporting path for events and can report anomalies at any time. | ISO/IEC 27001:2022 Annex A 6.8 | Check the reporting channel and how it is publicised, and ask two business units how reports are made. | Reporting path on the intranet, training material, interview notes |
| 3 | Events are assessed and classified as incidents against defined criteria; classification takes account of impact, duration and affected data or services. | ISO/IEC 27001:2022 Annex A 5.25; DORA Art. 18(1) | Select ten events of the last twelve months and trace the classification against the criteria. | Classification scheme, event and incident register |
| 4 | All incidents are recorded in a register with cause, impact, measures and status. | DORA Art. 17(2); ISO/IEC 27001:2022 Annex A 5.26 | Check the register for completeness of entries and compare it with reports from monitoring and the service desk. | Incident register, analysis of service desk and monitoring |
| 5 | Response plans are available for handling, describing containment, eradication and recovery and setting decision authority. | ISO/IEC 27001:2022 Annex A 5.26; DORA Art. 17(3) | Read the response plans and check on two closed incidents whether they were applied. | Response plans, incident files, decision records |
| 6 | Evidence is preserved so that incidents remain traceable and legally usable later. | ISO/IEC 27001:2022 Annex A 5.28; BSI DER.2.2 | Check the evidence preservation procedure and its application in two incidents. | Procedure description, evidence of preservation, chain of custody record |
| 7 | The organisation can report significant security incidents within the deadlines: early warning within 24 hours, notification within 72 hours, final report after one month. | NIS2 Directive Art. 23; § 32(1) BSIG | Trace the reporting process with responsibilities, templates and availability, and check a report or an exercise against the deadlines. | Reporting process, templates, authority contact list, evidence of exercise or report |
| 8 | For financial entities: major ICT-related incidents are reported to the competent authority in an initial notification, an intermediate report and a final report. | DORA Art. 19(1) and (4) | Check whether reporting paths, templates and responsibilities for the three reporting stages are defined and have been applied. | Reporting process, templates, evidence of reports |
| 9 | Personal data breaches are assessed and, where required, reported to the supervisory authority within 72 hours; breaches are documented. | GDPR Art. 33(1) and (5) | Check the assessment procedure, clarify cooperation with data protection and review documentation and reports of the last twelve months. | Data breach procedure, documentation of breaches, reports |
| 10 | Service providers are obliged to report incidents without delay, and the reporting path is agreed. | GDPR Art. 33(2); ISO/IEC 27001:2022 Annex A 5.20 | Check the contracts of three providers for reporting deadlines and contact persons. | Contract clauses, contact lists |
| 11 | Management and affected areas are informed of significant incidents, and external communication is regulated. | NIS2 Directive Art. 20; DORA Art. 17(3) | Trace escalation and reports to management in the sampled incidents and read the communication concept. | Escalation records, reports to management, communication concept |
| 12 | A review follows significant incidents, and its results feed into measures, training and adjustment of processes. | ISO/IEC 27001:2022 Annex A 5.27; DORA Art. 17(2) | Review the post-incident reviews of the last twelve months and check implementation of the measures. | Review reports, action list, changes to plans |
| 13 | The incident process is exercised and the ability to report is tested regularly. | ISO/IEC 27001:2022 Annex A 5.24 | Review exercise records of the last twelve months and check whether the reporting path and deadlines were part of the exercise. | Exercise planning, exercise records, findings |
Documents to request
- Process description for security incident management
- Classification scheme and response plans
- Incident register of the last twelve months
- Reporting process with templates, responsibilities and authority contact lists
- Evidence of reports filed or exercises held
- Documentation of personal data breaches
- Contract clauses on incident reporting at service providers
- Post-incident review reports
Typical findings
- Incidents are recorded in several systems, and a complete register is missing.
- There are no defined classification criteria; the assessment depends on the person acting.
- Responsibility and deputies for reports to authorities are not clarified, and deadlines would not be met.
- Data protection is involved late in incidents involving personal data.
- Service providers are not obliged to report quickly.
- Post-incident reviews do not take place or do not lead to tracked measures.
Note on references
The references point to laws, regulations and standards so that you can read the requirement in the original. No normative text is reproduced. Criteria and procedures are original wording and replace neither the text of the provisions nor legal advice. Whether and to what extent a provision applies to your organisation should be clarified before the audit.
The complete package
This sample shows the objective, the audit steps and the document list on one page. For your own audit topic, ProAuditMap creates the complete package: audit plan, audit program per audit dimension, document request list, interview guides, schedule, communication and report template. You review the draft, approve it and export to Excel and Word.
Create account View a complete sample package View pricing