Search every question across sub-FAQs

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.

ETSI EN 319 401 V3.2.1 specifies policy requirements for Trust Service Providers that are independent of the type of TSP. It covers management and operating practices, including cybersecurity requirements intended to support NIS2. It is not the complete rulebook for a certificate, time-stamp, validation, preservation, electronic archiving, electronic ledger, or other specific trust service.

Start with a service inventory. For each service, name the provider entity, service policy, users and relying parties, delivery systems, information flows, locations, trusted roles, external organizations, and service components. Mark anything shared across services so a control or supplier failure is not assigned to only one scope.

A generic statement that a provider follows EN 319 401 does not define scope. Clause 6 requires policies and practices appropriate to the services provided, a practice statement addressing the applicable trust service policy, and relevant documentation for subscribers and relying parties where needed to demonstrate conformance. Sensitive details need not be disclosed in the available version.

The terms and conditions carry a second scope record. For each supported trust service policy, they must cover the policy applied, use limits, subscriber obligations, relying-party information, event-log retention, liability limits, applicable legal system, complaints and disputes, assessment status and scheme if assessed, contact information, and availability undertakings.

A scope review should show which services are provided, which assets and suppliers support them, which risks were assessed, which policies and practice statements were approved, which records are retained, and who owns each boundary. V3.2.1 requires the risk assessment and treatment plan to be reviewed at planned intervals, at least annually, and after significant incidents or significant changes to operations or risks.

Do not use EN 319 401 alone to claim that a service passed an independent assessment. The standard does not define the assessment method, assessor information, or assessor requirements. It points to ETSI EN 319 403-1 for conformity assessment body requirements; the actual assessment scope and scheme still control the conclusion.