ETSI EN 319 401 Security incident handling

Clause 7.9 of ETSI EN 319 401 V3.2.1 covers monitoring and logging, incident response, reporting, event assessment and classification, and post-incident review. It requires a documented incident handling policy with roles and procedures for timely detection, analysis, containment, response, recovery, documentation, and reporting.

The standard defines incident handling as actions and procedures to prevent, detect, analyse, contain, respond to, and recover from an incident. It also defines an information security incident as related and identified information security events that can harm assets or compromise operations, so the incident process should connect event intake, severity assessment, response, and lessons learned.

The incident policy must assign competent people and connect incident handling to business continuity and disaster recovery. Communication plans must cover the CSIRT or competent authority, internal staff, and relevant external stakeholders. V3.2.1 also calls for incident manuals, escalation charts, contact lists, and templates.

Trusted-role personnel must follow up on potentially critical alerts. The TSP must test incident-response procedures at planned intervals and review roles, responsibilities, and procedures after significant incidents or significant changes to operations or risks.

V3.2.1 says an incident is significant when any listed criterion is met. The general criteria include direct financial loss above EUR 500,000 or 5% of the preceding year's turnover, whichever is lower; exfiltration of the TSP's trade secrets; actual or potential death or considerable harm to health; malicious unauthorized access capable of severe operational disruption; and qualifying recurring incidents.

Trust-service-specific criteria include complete unavailability for more than 20 minutes; unavailability to users or relying parties for more than one hour calculated over a calendar week; limited availability affecting more than 1% or 200,000 Union users or relying parties, whichever is smaller; compromise of protected physical access; or compromise of relevant data affecting more than 0.1% or 100 users or relying parties, whichever is smaller. Scheduled interruptions and planned consequences of scheduled maintenance do not count as significant incidents under this test.

Do not treat clause 7.9.3 as the only legal reporting rule. Under NIS2 Article 23, a significant trust-service incident requires an early warning within 24 hours of awareness and, under the trust-service-provider derogation, the incident notification within that same 24-hour period. An intermediate report is due if requested. The final report is due no later than one month after the incident notification; if the incident is still ongoing, submit a progress report then and a final report within one month after handling it. eIDAS Article 19a contains a separate 24-hour rule for significant breaches or disruptions affecting non-qualified trust services. Other regimes can add reports.

An EN 319 401 incident file should show the full chain: event source, severity assessment, classification changes, response actions, stakeholder communication, vulnerability handling, continuity coordination, and post-incident review.

Post-incident work must cover technical-vulnerability awareness, exposure evaluation, appropriate measures, root cause, documented lessons, and recurrence reduction. V3.2.1 also requires a quarterly check for recurring incidents that individually fall below the threshold but share an apparent root cause and collectively exceed the financial-loss criterion.