ETSI EN 319 401 FAQ for TSPs

ETSI EN 319 401 V3.2.1 specifies general policy requirements for Trust Service Providers that are independent of the type of trust service. Its scope is TSP operation and management, including cybersecurity requirements intended to support NIS2 for qualified and non-qualified trust services.

The standard is not a service-specific rulebook for every trust service. It says other specifications refine and extend the requirements for particular forms of TSP, and it does not specify how an independent party assesses the requirements or what information assessors must receive. Use EN 319 401 as the general TSP baseline, then add the service-specific ETSI standard, legal obligation, customer requirement, or assessment scheme that applies to the actual service.

The standard defines a Trust Service Provider as an entity that provides one or more trust services. It also defines a trust service policy as rules indicating applicability to a community or class of application with common security requirements, and a trust service practice statement as the practices the TSP employs in providing a trust service.

This FAQ is for teams that run or support a trust service and need to assign EN 319 401 controls. The standard's overview gives examples of TSPs such as public-key certificate issuers, time-stamping service providers, and providers of remote electronic signature generation or validation services. If your organization only consumes a trust service, focus on supplier assurance and relying-party obligations rather than full TSP implementation.

Clause 6 makes documentation central. A TSP has to specify policies and practices appropriate for its services, maintain a practice statement covering the applicable trust service policy, identify external-organization obligations, and make the practice statement and relevant documentation available where needed to demonstrate conformance. Sensitive details need not be disclosed.

Terms and conditions are also explicit. EN 319 401 expects them to be available to subscribers and relying parties and to cover, for each supported trust service policy, items such as the policy applied, service-use limits, subscriber obligations, relying-party information, event-log retention, liability limits, applicable legal system, complaint and dispute procedures, conformity assessment status and scheme if assessed, contact information, and availability undertakings.

Clause 5 requires a risk-management framework, assessment, and monitored treatment plan. V3.2.1 adds an all-hazards approach, third-party and single-point-of-failure risks, risk appetite and tolerance, named treatment owners and dates, documented residual-risk reasons, and measures for monitoring control effectiveness.

The TSP must review and, where appropriate, update the assessment results and treatment plan at planned intervals, at least annually, and after significant incidents or significant changes to operations or risks. Management bodies, or accountable risk authorities where applicable, approve the framework and accept residual risk.

Incident evidence should cover a documented handling policy, risk-based logging scope, protected and backed-up logs, monitoring availability, event triage, response, reporting, testing, and post-incident review. V3.2.1 also requires predefined classification criteria, quarterly assessment of recurring incidents, response records, and planned incident-response tests.

Record evidence is broader than incident files. Clause 7.10 requires the TSP to record and keep accessible relevant information about data issued and received by the TSP, including after the TSP's activities cease, for legal-evidence and service-continuity purposes. It also requires confidentiality and integrity of current and archived records, UTC-synchronized audit-log time at least once a day, stated retention periods in terms and conditions, and logging that cannot be easily deleted or destroyed during the required retention period.

Continuity evidence should show that the TSP can act during disasters and recover according to its own continuity plan. EN 319 401 requires a continuity plan, restoration within the delay established in that plan after a disaster, backup copies and sufficient resources aligned with risk assessment and the business continuity plan, integrity checks on backups, documented backup recovery tests, and crisis-management processes with roles, authority communications, and security controls.

Termination and supplier evidence are part of the same assurance picture. EN 319 401 requires an up-to-date termination plan, notices before termination, subcontractor authorization termination, transfer or maintenance of evidence, private-key destruction or withdrawal where applicable, and arrangements for public keys or trust service tokens. V3.2.1 requires supplier monitoring at planned intervals at least annually and after related incidents. Contracts must address appropriate cybersecurity, staff, incident notice, audit, vulnerability, subcontracting, and termination obligations.