We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Applicability GuideGLOBALETSI EN 319 401

ETSI EN 319 401 Trust Service Provider Applicability

Decide when EN 319 401 is the right baseline for a 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.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
5 sections6 primary sources
Overview

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. For the qualified signature/seal certificate reference route in Implementing Regulation (EU) 2025/1943, retain the cited EN 319 401 V3.1.1 and the applicable adaptations. Publication of V3.2.1 does not replace that legally cited edition.

Section 1

When does ETSI EN 319 401 apply?

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.

  • Treat the TSP baseline as in scope for an entity that provides a trust service, such as public key certificate issuance, time-stamping, remote electronic signature generation, signature validation, long-term preservation, or registered delivery. If an organization only operates a component for another provider, record it as a supporting dependency inside that provider's boundary unless the facts show that it separately provides a trust service.
  • Use it as the common baseline for TSP operation and management practices, then add the service-specific ETSI standard that matches the actual service.
  • Separate qualified and non-qualified trust-service claims; EN 319 401 addresses general security-management requirements, while eIDAS status and qualified-service obligations need the relevant legal and service-specific evidence.
  • Exclude ordinary product security, SaaS, or cryptographic-library work unless that work is part of providing a defined trust service or a .
  • Do not force a borderline activity into a yes-or-no answer when the service output, offering entity, subscriber or relying-party relationship, or governing policy is unknown. Record the missing fact, owner, and evidence needed to close the decision.
Section 2

What boundary should the applicability record define?

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.

  • Identify the trust service and token type involved, such as certificates, CRLs, time-stamp tokens, OCSP responses, validation outputs, or preservation records.
  • List the community or class of application served by the , including subscriber and relying-party assumptions.
  • Name the systems, facilities, personnel roles, repositories, external organizations, and trust service components that support the service.
  • Record which claims are EN 319 401 baseline claims and which claims depend on eIDAS, EN 319 411, EN 319 421, or another service-specific rule set.
  • Record exclusions with reasons. An exclusion should identify the activity, the fact that keeps it outside the boundary, the decision owner, and the event that would require reconsideration.
Section 3

Which EN 319 401 requirements are triggered once the service is in scope?

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.

  • Create a risk-assessment record for the trust service, including business and technical issues, chosen treatment measures, residual risk acceptance, and review triggers.
  • Maintain a practice statement that explains how the TSP addresses the requirements of the applicable .
  • Publish or make available the documentation that subscribers and relying parties need, while withholding sensitive detail where the standard allows that distinction.
  • Check that terms and conditions disclose service limitations, relying-party verification information, log retention, liability limits, the applicable legal system, complaints process, and conformity-assessment status.
Recommended next step

Scope ETSI EN 319 401 before mapping controls

Use the applicability boundary to decide which trust service, policy, components, suppliers, and service-specific standards belong in the assessment.

Assessment workflow
Open Assessment Autopilot for ETSI EN 319 401

Convert the scoped TSP baseline into owners, evidence requests, and assessment-ready control work.

Explore next step
Research workflow
Research trust service source questions

Resolve whether EN 319 401, eIDAS, or a service-specific ETSI standard supports a planned trust-service claim.

Explore next step
Talk to Sorena
Review EN 319 401 applicability

Walk through the trust service, policy boundary, supplier dependencies, and evidence gaps with Sorena.

Explore next step
Section 4

How should components, suppliers, and outsourced work affect applicability?

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.

  • List every provided by another party and map it to the policy and practice-statement requirement it supports.
  • Document supplier-selection criteria for cybersecurity specifications, risk and classification levels, source diversification, vendor lock-in, and critical supply-chain risk assessment.
  • Require supplier contracts to include applicable information-security requirements and service agreements to include service-level agreements, auditing mechanisms, or both, aligned with the TSP's risk assessment.
  • Keep evidence that ICT products and services conform to stated cybersecurity requirements, including the origin of critical components, genuine and unaltered delivery, lifecycle management, and change monitoring.
Section 5

Applicability checklist for a TSP using EN 319 401

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.

  • Service named: the decision identifies the exact trust service and any trust service tokens, components, repositories, or relying-party use cases.
  • Policy named: the decision identifies the and the community or application class it applies to.
  • Baseline separated: EN 319 401 baseline requirements are separated from eIDAS legal obligations and service-specific ETSI standards.
  • Evidence named: the record points to a risk assessment, practice statement, terms and conditions, information security policy, asset inventory, personnel role records, incident procedures, continuity plans, termination provisions, and supplier controls where applicable.
  • Assessment limits stated: the record does not claim that EN 319 401 alone proves , certificate-policy conformance, or independent assessment outcomes.
  • Decision lifecycle stated: the record has an effective date, decision owner, unresolved facts, next review date where one is set, and event-driven reassessment triggers.
Primary sources

References and citations

ETSI EN 319 401 V3.1.1 general policy requirements for TSPs
etsi.org6 citations
Referenced sections
  • Primary source for the page's applicability test, including scope, TSP definitions, risk assessment, practice statements, terms and conditions, and supply-chain responsibilities.
  • Supports the applicability boundary: EN 319 401 specifies type-independent general policy requirements for TSP operation and management, while other specifications refine requirements for particular trust services.
  • Defines TSP, trust service policy, trust service practice statement, and trust service token, which are the core inputs for a defensible applicability boundary.
Show 3 more
  • Supports the triggered evidence list by clauses 5, 6.1, and 6.2 on risk assessment, practice statements, and terms and conditions.
  • Supports including subcontractors, cloud services, ICT products, and trust service components in the applicability boundary where they affect the TSP service.
  • Supports the checklist scope by combining EN 319 401's type-independent baseline, policy/practice-statement requirements, and explicit statement that independent assessment requirements are outside this document.
"General Policy Requirements for Trust Service Providers"
More quoted passages
"independent of the type of TSP"
"entity which provides one or more trust services"
"The TSP shall carry out a risk assessment"
"maintain overall responsibility for conformance"
"does not specify how the requirements identified can be assessed"
ETSI EN 319 401 V3.2.1 (2026-01)
etsi.org2 citations
Referenced sections
  • Published successor edition used only to establish that this page is an edition-specific V3.1.1 map, not a current-edition claim.
  • Published successor edition; compare its scope and requirements before using this V3.1.1 applicability map for current work.
ETSI EN 319 411-2 V2.6.1 qualified certificate requirements
etsi.org2 citations
Referenced sections
  • Supports the distinction between the EN 319 401 baseline and service-specific qualified-certificate requirements.
  • Shows how a service-specific ETSI standard can incorporate EN 319 401 and add qualified-certificate requirements; it also cautions that conformance to that document alone does not make a TSP or certificate qualified under eIDAS.
"policy and security requirements for the issuance"
More quoted passages
"does not imply that the TSP"
Regulation (EU) No 910/2014 (eIDAS)
eur-lex.europa.eu2 citations
Referenced sections
  • Legal context referenced by EN 319 401 for EU trust services and qualified trust service provider obligations.
  • Provides the EU legal context for electronic identification and trust services referenced by EN 319 401.
"electronic identification and trust services"
Commission Implementing Regulation (EU) 2025/1943
eur-lex.europa.eu
Referenced sections
  • Article 1 and the Annex specify the adapted qualified signature/seal certificate reference route, including EN 319 401 V3.1.1. Recital 3 preserves other practices for demonstrating compliance; the reference route does not itself grant qualified status.
Consolidated Regulation (EU) No 910/2014, Articles 3 and 21
eur-lex.europa.eu
Referenced sections
  • Supports the current EU distinction between qualified and non-qualified providers and the conformity-assessment, supervisory-verification, qualified-status, and trusted-list steps for beginning a qualified trust service.

Related guides

ETSI EN 319 401 Audit and Conformity Assessment Evidence

How to prepare ETSI EN 319 401 evidence for audit and conformity assessment without overstating what the standard itself assesses.

ETSI EN 319 401 Audit Evidence Pack

Build an ETSI EN 319 401 audit evidence pack around records, logs, policies, risk assessment, incident handling, continuity, and supplier evidence.

ETSI EN 319 401 Audit Evidence Pack Workflow

Build an ETSI EN 319 401 audit evidence pack for trust service providers: risk assessment, practice statement, policies, records, logs, continuity, and supplier evidence.

ETSI EN 319 401 compliance duties for TSPs

ETSI EN 319 401 compliance guidance for trust service providers covering legal operation, evidence, accessibility, privacy, records, incidents, continuity, and suppliers.

ETSI EN 319 401 FAQ for trust service providers

Plain-language ETSI EN 319 401 answers covering TSP scope, trust service practice statements, risk assessment, incidents, records, continuity, and supplier evidence.

ETSI EN 319 401 Incident and Continuity Workflow

Build an EN 319 401 incident and continuity evidence workflow for TSP monitoring, response, reporting, records, backup recovery, and crisis review.

Show all related guides (23)

ETSI EN 319 401 Incident Reporting and Continuity Duties

Practical ETSI EN 319 401 V3.1.1 guidance for trust service incident response, reporting, evidence retention, business continuity, and termination planning.

ETSI EN 319 401 Personnel, Asset, and Access Controls

Clause-focused EN 319 401 V3.1.1 guide to TSP personnel duties, trusted roles, asset inventories, classification, and access-control evidence.

ETSI EN 319 401 policy and security requirements

ETSI EN 319 401 guidance for TSP policy and security requirements covering risk assessment, practice statements, terms, security controls, incidents, and evidence.

ETSI EN 319 401 requirements map

Map ETSI EN 319 401 V3.1.1 requirements for trust service providers across risk assessment, policies, TSP operations, incidents, evidence, continuity, termination, and supply chain controls.

ETSI EN 319 401 Risk Assessment and Treatment

Clause-cited ETSI EN 319 401 V3.1.1 guidance for trust service risk assessment, risk treatment, residual-risk approval, and evidence planning.

ETSI EN 319 401 Subcontractor Controls

Practical EN 319 401 guidance for TSP subcontractor controls: retained responsibility, agreements, SLAs, supplier registers, monitoring, and audit evidence.

ETSI EN 319 401 Subcontractor Evidence Workflow

Build an EN 319 401 subcontractor evidence workflow for TSP supplier agreements, SLAs, audit mechanisms, risk reviews, supplier registers, and archived records.

ETSI EN 319 401 Trust Service Applicability Workflow

A scoped workflow for deciding when ETSI EN 319 401 applies to a trust service and what TSP policy, risk, terms, operations, and supplier evidence to collect.

ETSI EN 319 401 vs eIDAS: Controls and Legal Duties

Compare ETSI EN 319 401 V3.2.1 with current eIDAS duties for qualified and non-qualified trust service providers, including risk, incidents, audits, records, and termination.

ETSI EN 319 401 vs EN 319 403-1: TSP Policy vs CAB Assessment

Compare ETSI EN 319 401 V3.2.1 provider controls with EN 319 403-1 V2.3.1 CAB requirements for audit scope, evidence, sampling, reports, corrective action, and reassessment.

CA and RA responsibilities under ETSI EN 319 401

How ETSI EN 319 401 frames CA and RA responsibility: TSP practice statements, management approval, role segregation, subcontractor control, and evidence boundaries.

eIDAS Articles 19 and 24: current ETSI mapping

Understand why old EN 319 401 editions mapped eIDAS Article 19, what replaced it, and how V3.2.1 maps current Article 24 duties.

ETSI EN 319 401 conformity assessment bodies: what is covered?

Understand what ETSI EN 319 401 says, and does not say, about conformity assessment bodies, independent assessment, and TSP evidence preparation.

ETSI EN 319 401 policy documentation: what is required?

How ETSI EN 319 401 treats practice statements, terms, network and information systems security policy, evidence records, and change review.

ETSI EN 319 401 Subcontractor Requirements FAQ

How ETSI EN 319 401 treats subcontractors, outsourcing, supplier agreements, SLAs, monitoring, evidence, and retained TSP responsibility.

Security Incidents in ETSI EN 319 401

How ETSI EN 319 401 V3.2.1 expects TSPs to detect, classify, respond to, report, document, test, and review security incidents.

Trust service provider scope under ETSI EN 319 401

How to scope ETSI EN 319 401 for a trust service provider: service boundaries, trust service policy, practice statement, terms, risks, and third-party components.