--- title: "ETSI EN 319 401 FAQ for Trust Service Providers (TSPs)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-401/faq" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-401/faq" author: "Sorena AI" description: "Frequently asked questions about ETSI EN 319 401 for Trust Service Providers: what a Trust Service Practice Statement is, how risk assessment drives controls." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 319 401 FAQ" - "trust service provider requirements" - "trust service practice statement" - "information security policy REQ-6.3" - "risk assessment REQ-5" - "quarterly vulnerability scanning REQ-7.8-14" - "vulnerability scan independence REQ-7.8-13" - "penetration testing REQ-7.8-17" - "monitoring and logging REQ-7.9.1" - "incident response REQ-7.9.2" - "incident notification within 24 hours REQ-7.9.3" - "evidence collection REQ-7.10" - "UTC sync audit logs REQ-7.10-06" - "Trust Service Provider" - "Audit readiness" - "Incident reporting" - "Evidence retention" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 401 FAQ for Trust Service Providers (TSPs) Frequently asked questions about ETSI EN 319 401 for Trust Service Providers: what a Trust Service Practice Statement is, how risk assessment drives controls. *Artifact Guide* *GLOBAL* ## ETSI EN 319 401 FAQ Fast, operational answers for TSP security, engineering, and audit teams. Focused on what you need to build, how to prove it, and what auditors sample most often. This FAQ focuses on practical implementation and evidence. It's written for teams responsible for trust service operations, security controls, incident handling, and audit readiness. ## What is ETSI EN 319 401 (in plain language)? ETSI EN 319 401 is a European Standard that defines general policy requirements for Trust Service Providers. It covers how a TSP should manage risk, define policies and practices, run secure operations, detect/respond/report incidents, and retain evidence. It's often used as an operational blueprint under legal frameworks like eIDAS and as a baseline for conformity assessment and procurement assurance. - Think of it as how a TSP should operate securely, not only what to document - Operational proof (scans, logs, incident records) matters more than paper policies ## What changed in the current V3.1.1 release? The current release is ETSI EN 319 401 V3.1.1 (2024-06), adopted on 30 May 2024, with national endorsement and withdrawal milestones falling on 28 February 2025. The standard also states that the 2024 revision updates the document to take NIS2 into account and refreshes references such as ISO/IEC 27002:2022. In practice, teams using older internal mappings should review requirement numbering, monitoring and incident-management language, and supply-chain expectations before reusing older audit packs. - Confirm that internal control matrices reference the current REQ numbering - Refresh legacy evidence packs that were built against older V2.x summaries - Make sure NIS2-aware incident and risk management language is reflected in procedures and reporting plans ## What is a Trust Service Practice Statement and why do auditors care? EN 319 401 requires the TSP to have a statement of practices and procedures addressing applicable trust service policy requirements and to make relevant documentation available to subscribers and relying parties as necessary to demonstrate conformance. Auditors care because it's the bridge between requirements and reality: it explains how your service is operated and what evidence exists (without exposing sensitive details). - Keep it versioned with a review cadence and change control - Tie it to operational procedures and evidence index links ## How should we use risk assessment (REQ-5) in practice? REQ-5 requires risk assessment and risk treatment measures commensurate to risk, with management approval and regular review. The common failure is treating risk as a standalone document. Make risk outputs drive control changes: monitoring coverage, scan cadence, segmentation changes, and incident response capacity. - Risk register -> risk treatment plan -> control implementation -> evidence generation - Use risk reviews to justify cadence changes (but document and defend them) ## Do we really need quarterly vulnerability scans? EN 319 401 requires regular vulnerability scans and evidence that scans were performed by a competent and independent party. It also recommends that the scan should be performed once per quarter. If you choose a different cadence, be prepared to justify it via risk assessment, exposure, and compensating controls. Quarterly is the defensible default for most TSP scopes. - Keep scan scope inventory (public/private IPs) and evidence of competence/independence - Track remediation outcomes and risk acceptance decisions when applicable ## When do we need penetration tests? EN 319 401 requires penetration testing after infrastructure or application upgrades/modifications that the TSP determines are significant. The key is to define significance in your program, for example new trust service components, major network changes, or privileged access redesign, and prove you applied the trigger consistently. - Define a change classification that triggers pen tests - Keep evidence: change ticket -> trigger decision -> pen test report -> remediation proof ## What does 24 hour reporting readiness mean here? EN 319 401 includes requirements to establish procedures to notify appropriate parties of significant-impact breaches within 24 hours of breach identification and to comply with reporting obligations in relevant legislative frameworks. Operationally: you need detection, categorization, escalation, and a prepared communication and reporting workflow that can execute within the time window. - Practice: tabletop exercises and post-incident reviews to prove the workflow works - Evidence: incident records, timestamps, stakeholder notifications, and supervisory reporting logs ## Why does UTC time synchronization matter for audit logs? EN 319 401 requires synchronizing the time used to record audit log events with UTC at least once per day. This is about legal defensibility and incident reconstruction. If time integrity is weak, your incident timelines and audit evidence can be challenged. - Keep daily UTC sync evidence and monitor for drift - Ensure time is consistent across systems, logs, and retained evidence archives ## How should we handle outsourcing and cloud providers? EN 319 401 does not let a TSP outsource responsibility. When suppliers, cloud providers, or external trust service components are used, the TSP remains responsible for conformance with the supply-chain policy, information security policy, and the applicable trust service policy. Operationally, that means contracts, service levels, review cycles, and incident-response interfaces must all be part of the evidence system. - Keep documented agreements and named security obligations for each relevant supplier - Review supplier cybersecurity practices at planned intervals and after relevant incidents - Record which controls are implemented by the TSP and which are implemented by the supplier *Recommended next step* *Placement: after the FAQ section* ## Use ETSI EN 319 401 FAQ as a cited research workflow Research Copilot can take ETSI EN 319 401 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on ETSI EN 319 401 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ETSI EN 319 401 FAQ](/solutions/research-copilot.md): Start from ETSI EN 319 401 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ETSI EN 319 401](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 319 401 FAQ. ## Primary sources - [ETSI EN 319 401 V3.1.1 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Primary source for REQ-5/6/7 obligations referenced in this FAQ. - [ETSI Coordinated Vulnerability Disclosure Program](https://www.etsi.org/standards/coordinated-vulnerability-disclosure?ref=sorena.io) - ETSI's reporting channel referenced in the standard's front matter. ## Related Topic Guides - [ETSI EN 319 401 Audit & Conformity Assessment (Evidence Pack + Checklist)](/artifacts/global/etsi-en-319-401/audit-and-conformity-assessment.md): Audit readiness guide for ETSI EN 319 401 Trust Service Providers: how conformity assessment works in practice, what auditors sample. - [ETSI EN 319 401 Compliance Playbook for Trust Service Providers (TSPs)](/artifacts/global/etsi-en-319-401/compliance.md): How to operationalize ETSI EN 319 401 compliance for Trust Service Providers: scope definition, governance, risk assessment to control mapping. - [ETSI EN 319 401 Requirements (REQ-5/6/7 Map for Trust Service Providers)](/artifacts/global/etsi-en-319-401/requirements.md): Clause-by-clause ETSI EN 319 401 requirements mapping for Trust Service Providers (TSPs): risk assessment (REQ-5). - [ETSI EN 319 401 vs eIDAS (Mapping to Article 19 & 24 TSP Obligations)](/artifacts/global/etsi-en-319-401/etsi-en-319-401-vs-eidas.md): Practical mapping of ETSI EN 319 401 requirements to the EU eIDAS Regulation (EU) No 910/2014. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-401/faq