NIS2 Art.23.11: Incident Reporting Procedures and Technical Means

Keep a close eye on NIS2 implementing acts as they are published. Track requirements from the European Commission, ENISA guidance, your national competent authority, and any sector-specific regulators.

Set up the technical infrastructure for reporting. At minimum, this means access to your national CSIRT's reporting portal, secure email capabilities (S/MIME or PGP), structured data formats for incident information (be ready for STIX, TAXII, or IODEF), automated data collection from your security tools to pre-populate notification fields, and a document management approach for keeping notification records.

Create and maintain notification templates that meet the specified format requirements. Version-control them and update whenever regulatory requirements change. Every mandatory data field should be present, with clear guidance on how to complete each one.

Build a notification workflow that covers the full lifecycle: incident detection triggers the process, deadlines are automatically calculated and tracked, templates are pre-populated with available data, review and approval happen within defined SLAs, submission goes through approved channels, acknowledgements are tracked, and follow-up updates are managed.

Test the whole chain regularly. Run end-to-end drills from incident detection through to notification submission and verify you can hit the required timelines using your actual tools and procedures.

Maintain a complete audit trail: drafts, approvals, submission confirmations, and CSIRT responses. If a regulator asks whether you reported on time, you want to show them the evidence immediately.

Plan for failure. If your primary reporting channel goes down (portal outage, for instance), have a backup method ready - phone, encrypted email, whatever your CSIRT accepts. Technical problems are not an acceptable excuse for late notification.