Decide when EN 319 401 is the right baseline for a trust service provider and what service boundary, policy, risk assessment, and supplier evidence belongs in scope.
This page maps V3.1.1. ETSI published V3.2.1 in January 2026, so confirm the required edition and then validate the boundary against the applicable service policy, service-specific standard, assessment scheme, contracts, and current law.
Structured answer sets in this page tree.
Cited legal and guidance references.
Use this page before writing an EN 319 401 control map, practice statement, or assessment pack. Apply the V3.1.1 baseline when the entity is the (TSP) for one or more trust services within that edition's scope. Ordinary product security is outside TSP activity unless the product or component forms part of providing such a service.
EN 319 401 V3.1.1 applies as a general policy baseline for Trust Service Providers (TSPs). It defines a TSP as an entity that provides one or more trust services, and its requirements are independent of TSP type. Start by naming the service, then select the certificate, time-stamp, validation, preservation, registered-delivery, or other service-specific standard that refines the baseline.
V3.1.1 does not answer every trust-service question and does not specify how an independent party performs an assessment. ETSI published V3.2.1 in January 2026. A current project should record why V3.1.1, V3.2.1, or another referenced edition controls, rather than silently mixing requirement numbers or text from different editions.
Apply the decision in order. First identify the electronic service and its output. Second identify the entity that offers that service to subscribers or relying parties. Third decide whether other parties provide only products or components, or provide part of the service. Fourth record the policy, edition, service-specific standard, legal status, and assessment scheme. The result should be one of four documented outcomes: TSP baseline in scope, supporting component or supplier in the TSP boundary, ordinary product activity outside this baseline, or unresolved pending service or policy evidence.
The applicability record should name the service, the , the , and the operating environment covered by the decision. EN 319 401 defines a trust service policy as rules indicating applicability to a community or class of application with common security requirements, and a practice statement as the practices a TSP uses to provide the service.
This boundary matters because EN 319 401 requirements attach to the TSP's actual service: risk assessment, terms and conditions, information security policy, personnel, assets, access controls, incident handling, continuity, termination planning, legal compliance, and supply chain controls. A vague statement that a platform is a TSP is not enough.
The record should also state its effective date and review trigger. Reassess when the service output, offering entity, , subscriber or relying-party terms, , referenced edition, service-specific standard, system boundary, location, supplier, or component materially changes. EN 319 401 also requires regular risk-assessment review and planned or significant-change review of the information security policy and asset inventory.
Once the trust service is in scope, EN 319 401 triggers more than a policy title. The TSP shall carry out and regularly review a risk assessment, select risk treatment measures, document the necessary security requirements and operational procedures, and obtain management approval of the risk assessment and acceptance of the residual risk.
The standard also requires the TSP to specify policies and practices for the trust services it provides, make relevant documentation available to subscribers and relying parties where needed to demonstrate conformance, and make terms and conditions available before the contractual relationship. Those terms and conditions shall cover the , limitations on use, subscriber obligations, relying-party information, log-retention period, liability limits, legal system, complaints, assessment status, contact information, and availability undertakings.
Use the applicability boundary to decide which trust service, policy, components, suppliers, and service-specific standards belong in the assessment.
Convert the scoped TSP baseline into owners, evidence requests, and assessment-ready control work.
Resolve whether EN 319 401, eIDAS, or a service-specific ETSI standard supports a planned trust-service claim.
Walk through the trust service, policy boundary, supplier dependencies, and evidence gaps with Sorena.
Applicability should include third parties when they provide part of the trust service or a . EN 319 401 says a TSP that uses other parties, including trust service component providers, remains responsible for conformance with the supply chain policy, information security policy, and requirements.
The source material supports a practical test: if the supplier, cloud service, subcontractor, or component can affect the trust service's security, functionality, availability, or policy conformance, it belongs in the applicability record. That does not make the supplier the TSP, but it does mean the TSP needs contractual, security, monitoring, lifecycle, and assurance evidence for the dependency.
This checklist helps decide whether the page, assessment, or procurement request is really about EN 319 401. A complete applicability answer should be specific enough for an assessor, customer, or internal owner to tell what service is covered and where the baseline stops.
"does not specify how the requirements identified can be assessed"
"does not imply that the TSP"
"electronic identification and trust services"