ETSI EN 319 401 Incident and Continuity Evidence Workflow

EN 319 401 connects incident handling and business continuity. Clause 7.9 requires mechanisms to detect potential security incidents, procedures for containment, eradication and recovery, communication plans, documentation throughout detection and response, and clear interfaces between incident handling and business continuity management.

Define the workflow boundary around the trust service, network and information systems, critical assets, logs, trusted-role owners, reporting obligations, continuity plan, backup resources, and crisis-management process. Evidence should show how an event moves from detection to classification, response, reporting, recovery, review, and continuity improvement.

Use four explicit branches. An alarm that is not an incident still needs a triage record. An incident that does not meet a legal reporting threshold still needs response and review records. A significant incident follows the applicable notification path as well as operational response. An incident that exceeds the service's restoration assumptions activates the continuity or crisis process and produces recovery evidence.

The workflow starts before an incident is confirmed. EN 319 401 requires tools and processes for continuous monitoring and logging of network and information system activities, detection and reporting of abnormal activities as alarms, documented and regularly reviewed logs, and automatic processing that alerts personnel to possible critical security events.

Turn those duties into a compact evidence set: monitoring architecture, log-source inventory, alarm rules, log-review procedure, privileged-access and administrator activity logs, network traffic records, security-relevant logs, physical or environmental logs where appropriate, and a record of trusted-role personnel following up on alerts.

For each confirmed or potentially critical event, the evidence packet should show containment, eradication and recovery; categorisation; escalation; reporting protocols; assigned competent personnel; documentation throughout detection and response; and regular and post-incident review of roles, responsibilities, and procedures. A previously unaddressed critical vulnerability has a separate EN 319 401 deadline: REQ-7.9.2-09X says the TSP shall address it within 48 hours after discovery.

Keep the standards requirement and EU legal analysis separate. REQ-7.9.3-01X requires procedures to notify appropriate parties, under applicable regulatory rules, within 24 hours after identifying a breach of security or loss of integrity that significantly affects the trust service and personal data maintained there. Its note cites the former eIDAS Article 19.2 numbering. In the amended consolidated eIDAS text, Article 19a covers non-qualified providers and Article 24(2)(fb) covers qualified providers. Article 19a uses no later than 24 hours after awareness, while Article 24(2)(fb) uses within 24 hours of the incident. The provisions also name different public-notice conditions. Record which text controls instead of normalizing both into one clock.

A reviewable workflow needs a visible decision point between event intake and incident closure. EN 319 401 requires the TSP to analyse reported events, assess severity, and be capable of reassessing and reclassifying events based on new inputs.

Closure also needs evidence. The standard requires the TSP to stay informed about technical vulnerabilities in every information system it uses, evaluate exposure, take appropriate measures, identify the incident's root cause, conduct a post-incident review that may produce recurrence controls, and ensure every past incident led to a review.

Clause 7.10 is the evidence-retention anchor for this workflow. EN 319 401 requires the TSP to record and keep accessible relevant information concerning data issued and received by the TSP for an appropriate period, including after TSP activities have ceased, for legal evidence and continuity of service.

The workflow should prove record integrity and usability. Include controls for confidentiality and integrity of current and archived records, complete and confidential archiving under disclosed business practices, availability for evidence of correct service operation in legal proceedings, precise timing of significant environmental, key-management and clock-synchronization events, UTC synchronization for audit-log event time at least once a day, and protection against easy deletion or destruction during required retention.

Keep this operating table in the evidence pack so each incident or continuity item has an owner, artifact, and decision point.

1 | Detect and triage | Monitoring owner | Log-source inventory, alarm record, alert follow-up note | Is this an abnormal event, possible critical security event, or confirmed incident?

2 | Classify and escalate | Incident manager | Severity assessment, reclassification history, escalation record | Which communication and reporting path applies?

3 | Respond and document | Security and operations owners | Containment, eradication, recovery, and decision records | Is damage minimized and is the response fully documented?

4 | Report and notify | Legal or compliance owner | Reporting analysis, authority or CSIRT notice if applicable, stakeholder notice if applicable | Does a significant-impact breach or adverse effect trigger notification?

5 | Recover and preserve evidence | Continuity owner | Continuity-plan activation, backup recovery evidence, record-retention controls | Was service restored within the continuity-plan delay and are records protected?

6 | Review and correct | Risk and control owners | Root-cause review, corrective actions, updated roles or procedures | Did the incident lead to a post-incident review and recurrence-risk measures?

7 | Close and reassess | Incident manager and service owner | closure approval, unresolved risk, notification follow-up, updated risk assessment and plan versions | Are all actions owned, and did the incident change service scope, suppliers, restoration assumptions, or reporting procedures?

Continuity evidence extends beyond the incident ticket. The TSP must define and maintain a continuity plan for disasters, restore operations within the delay established in that plan after addressing recurring causes, and maintain backup copies and sufficient resources in accordance with the risk assessment and business continuity plan.

For continuity evidence, include backup plans that address recovery times, completeness and accuracy of backup copies, safe off-network and sufficiently distant storage, controls based on classification level, restore processes and approvals, integrity checks, planned recovery tests, corrective actions for findings, and documented test results. Crisis-management evidence should cover roles and responsibilities, communications with competent authorities, security controls in crisis situations, use of information from National CSIRTs or competent authorities where applicable, and planned or post-incident tests and reviews.

A generic incident-response checklist with no trust-service boundary, clause mapping, or retained evidence is not enough. Show which record supports detection, response, reporting analysis, recovery, review, and continuity changes.

Avoid broad eIDAS statements. The amended regulation separates non-qualified and qualified provider duties, and the recipient and timing language is not identical. Preserve the applicable threshold and provider status instead of claiming every event creates the same notice duty.