ETSI EN 319 401 Requirements

Build your program around the standard structure: risk assessment in clause 5, policies and practices in clause 6, and TSP management and operation in clause 7. The current release is ETSI EN 319 401 V3.1.1 (2024-06), adopted on 30 May 2024, with national endorsement by 28 February 2025.

For every REQ you claim, attach: control owner, operating procedure, verification method, and evidence location. Make evidence generation part of normal operations (monitoring, change management, releases, and incident response).

ETSI EN 319 401 requires the TSP to carry out a risk assessment covering business and technical issues, select risk treatment measures, determine security requirements and operational procedures to implement those measures, review and revise the risk assessment regularly, and have management approve and accept residual risk.

Operationally, clause 5 is your control generator: it drives the minimum security baseline, the priorities, and the justification for why specific controls exist (or why certain controls are proportionate).

Clause 6 expects your policy layer to exist, be approved by management, published or communicated appropriately, and to be usable by subscribers and relying parties where required. This includes your Trust Service Practice Statement and your Terms and Conditions.

A strong implementation turns these documents into operational interfaces: they describe how your service works, what relying parties can expect, and what evidence you can provide without exposing sensitive details.

ETSI EN 319 401 requires an information security policy approved by management, communicated to relevant third parties where applicable, documented/implemented/maintained with controls and operating procedures, and reviewed at planned intervals or after significant changes.

The standard also expects configuration checks for policy violations with a documented maximum interval (in your practice statement), and approval for security-impacting changes by the management body.

Clause 7.8 is unusually concrete for a policy standard: it covers segmentation into zones, restricting zone communications, disabling unneeded connections/services, separating production from dev/test, trusted channels between trustworthy systems, and security testing expectations.

Two audit magnets: evidence of regular vulnerability scans (including independence/competence) and penetration tests after significant upgrades or modifications.

ETSI EN 319 401 expects continuous monitoring and logging, detection and alarming on abnormal activities, and regular review of logs with automatic processing and alerting for critical events.

It also sets expectations for incident response procedures, communication plans, documentation, testing of roles/procedures, and specific time-bound handling such as addressing critical vulnerabilities within 48 hours after discovery and establishing notification procedures to appropriate parties within 24 hours for significant breaches.

Clause 7.10 requires recording and keeping accessible relevant information for an appropriate period (including after TSP activities cease) to provide evidence and continuity, while maintaining confidentiality and integrity of records and ensuring availability for legal proceedings.

A key detail: the time used to record events in the audit log must be synchronized with UTC at least once a day.

The 2024 release gives more weight to supplier and third-party governance than many older EN 319 401 summaries show. When a TSP uses subcontracting, outsourcing, cloud providers, or external trust service components, the TSP keeps overall responsibility for conformance with its policy and security requirements.

This is where many programs are too light. Contracts alone are not enough. You need review cycles, security expectations, and evidence that supplier cybersecurity practices are monitored and re-evaluated.