WorkflowGLOBALETSI EN 319 401

ETSI EN 319 401 Trust Service Applicability Workflow

A practical workflow for deciding whether EN 319 401 belongs in a trust service scope review.

Grounded in ETSI EN 319 401 V3.1.1. Use it as implementation guidance, not for legal interpretation.

Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Sections
6

Structured answer sets in this page tree.

Primary sources
1

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated May 9, 2026
Overview

Use this workflow when a product, component, certificate service, time-stamp service, validation service, preservation service, or delivery service may be operated as part of a trust service. EN 319 401 is the general TSP policy baseline: it applies to operation and management practices of trust service providers, while other ETSI specifications refine the baseline for particular trust service types.

Section 1

Start with the trust service, not the control list

The first applicability question is whether the organization is providing one or more trust services. EN 319 401 defines a TSP as an entity that provides one or more trust services, and its examples include public key certificates, time-stamps, remote electronic signature generation, validation services, preservation services, and registered delivery services.

Do not start by copying every clause into a generic checklist. Create a short scope record that names the service, the trust service token or output, the subscribers and relying parties, the systems used to provide the service, and any trust service components supplied by another party.

  • In scope: a service that creates, verifies, validates, delivers, preserves, or supports trust service tokens such as certificates, CRLs, time-stamp tokens, or OCSP responses.
  • Needs more mapping: a component, platform, cloud service, identity-proofing function, or support process used by a TSP but not itself offered as a public trust service.
  • Out of this page's scope: a general software product or internal security process with no connection to a trust service offered to subscribers or relying parties.
  • Always record the service-specific standard or policy that refines EN 319 401, because EN 319 401 is the general baseline rather than a complete service-specific rulebook.
Section 2

Workflow gate 1: identify the trust service policy

Once a service appears to be in scope, identify the trust service policy that explains where the service is intended to apply. EN 319 401 treats the trust service policy as the set of rules indicating the applicability of a trust service to a community or class of application with common security requirements.

The output of this gate is a policy mapping, not a conclusion sentence. The mapping should show the policy name, service type, customer or relying-party community, use limitations, and any service-specific ETSI standard that adds requirements beyond EN 319 401.

  • Name the trust service policy and the community or class of application it covers.
  • Identify whether the service is qualified, non-qualified, or not yet classified in the available source material.
  • Separate EN 319 401 baseline controls from requirements introduced by certificate, time-stamp, validation, preservation, delivery, or component standards.
  • Flag any missing policy document as an applicability gap because the practice statement depends on the applicable trust service policy.
Section 3

Workflow gate 2: tie policy to the practice statement

The practice statement is where applicability becomes operational. EN 319 401 requires the TSP to specify policies and practices appropriate for the trust services it provides, approve and communicate those policies, and maintain a practice statement that addresses all requirements of the applicable trust service policy.

For an applicability review, the practice statement evidence should show which service is covered, which external organizations support the service, how subscribers and relying parties can obtain relevant documentation, who approves the statement, and how changes are reviewed.

  • Create a practice-statement cross-reference from each applicable trust service policy requirement to the procedure or control that implements it.
  • List external organizations that support the service, including the applicable policies and practices they must follow.
  • Record the management body or final approver for the practice statement.
  • Define the review process and change-notice trigger for changes that may affect acceptance by subjects, subscribers, or relying parties.
Section 4

Workflow gate 3: verify subscriber and relying-party terms

Applicability is not complete until the public-facing service terms match the policy decision. EN 319 401 requires terms and conditions for services to be available to subscribers and relying parties, and it lists specific items that should be covered for each trust service policy supported by the TSP.

Use this gate to prevent hidden scope. The terms should identify the policy being applied, limitations on service use, subscriber obligations, relying-party information, event-log retention, liability limits, legal system, complaint and dispute procedures, conformity assessment scheme if one is claimed, contact information, and any availability undertaking.

  • Check that terms are available before the contractual relationship starts and through a durable means of communication.
  • Use the terms to expose limitations on use instead of burying them inside internal policy notes.
  • Do not claim conformity assessment in the terms unless the scheme is named and supported by evidence.
  • Keep the terms aligned with the event-log retention period and the evidence-retention decision in the TSP evidence file.
Section 5

Workflow gate 4: map baseline controls to evidence

If the service remains in scope after the policy, practice-statement, and terms gates, map EN 319 401 baseline areas to concrete evidence. The standard covers risk assessment, information security policy, internal organization, segregation of duties, personnel, assets, access control, cryptographic controls, physical security, operation security, network security, vulnerabilities and incidents, evidence collection, continuity, termination, compliance, and supply chain.

A useful evidence map should avoid vague labels such as compliant or implemented. For each baseline area, name the owner, control, evidence artifact, review trigger, and source requirement. Where a control is conditional, state the condition that made it applicable or not applicable.

  • Risk: keep the approved risk assessment, selected risk treatments, necessary security requirements, operational procedures, review date, and residual-risk acceptance.
  • Security operations: retain change-control records, configuration reviews, vulnerability scans, penetration-test triggers, monitoring logs, incident classifications, and post-incident reviews.
  • Evidence collection: keep service operation records confidential, complete, available for legal evidence when required, time-synchronized where relevant, and retained for the period notified in the terms.
  • Continuity and termination: maintain backup, recovery, crisis-management, termination, subscriber-notice, key-destruction, and evidence-transfer records where they apply to the service.
  • Supply chain: keep supplier criteria, security requirements, component information, validation methods, service agreements, monitoring reviews, and the supplier-agreement register.
Section 6

Markdown workflow table for applicability reviews

Use this table in an independent review note, procurement intake, or audit-prep file. Keep the assigned role and evidence linkage explicit for every gate so scope decisions are auditable and reproducible.

Step | Owner | Evidence | Decision

1. Service identification | Product Security Lead (service owner) | service-boundary diagram + evidence record ID for token, subscribers, relying parties, supporting systems | Is the activity a trust service or a supporting component?

2. Policy applicability | Compliance/Policy Lead (TSP policy owner) | trust-service-policy mapping, scope definition, and service-specific standard list | Which policy and application community/class defines the service?

3. Practice statement mapping | TSP Operations Lead | practice-statement version + external-organization obligation matrix + approval evidence | Does the practice statement cover every requirement in the selected policy?

4. Terms review | Legal Counsel and Customer Terms Owner | published terms artifact ID, terms-change history, complaint channel, assessment-scheme reference, liability and retention clauses | Are public terms aligned with the chosen policy and scope?

5. Baseline evidence map | CISO and Internal Audit Leads | control-level evidence map IDs, review dates, control owners, and retention decision for each EN 319 401 clause group | Can EN 319 401 baseline controls be demonstrated for this exact service boundary?

6. Change trigger | Change Manager and Policy Owner | change-impact log, reclassification notes, notification evidence, evidence-retention adjustments | Does a service, policy, supplier, component, or security change require reassessment or external notice?

  • Treat uncertain service classification as an open applicability gap, not as a silent yes or no.
  • Do not use EN 319 401 alone to claim independent assessment; the standard says it does not specify how independent-party assessment is performed and points readers to EN 319 403-1 for conformity assessment body requirements.
  • When a supplier or trust service component provider performs part of the service, keep the TSP's overall responsibility visible in the evidence map.
Primary sources

References and citations

etsi.org
Referenced sections
  • Supports the review-table structure by grounding the service boundary, trust service policy, practice statement, terms, baseline evidence, change review, assessment limitation, and third-party responsibility checkpoints.
"does not specify how the requirements identified can be assessed"
Related guides

Explore more topics

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 in ETSI EN 319 401
See how ETSI EN 319 401 V3.1.1 Annex B maps eIDAS Article 19 security duties and selected Article 24 qualified trust service duties to concrete policy evidence.
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
source-linked ETSI EN 319 401 compliance guidance for trust service providers: legal operation, evidence, accessibility, privacy, records, incidents, continuity, and suppliers.
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 FAQ for trust service providers
source-linked ETSI EN 319 401 FAQ for TSP scope, trust service practice statements, risk assessment, incidents, records, continuity, and supplier evidence.
ETSI EN 319 401 Incident Evidence Workflow
Build an EN 319 401 incident and continuity evidence workflow for TSP monitoring, response, reporting, records, backup recovery, and crisis review.
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
source-linked ETSI EN 319 401 guidance for TSP policy and security requirements: risk assessment, practice statements, terms, security policy, controls, incidents, and evidence.
ETSI EN 319 401 policy documentation: what is required?
How ETSI EN 319 401 treats policy documentation: practice statements, terms and conditions, information security policy, evidence records, and change review.
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-grounded 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 Subcontractor Requirements FAQ
How ETSI EN 319 401 treats subcontractors, outsourcing, supplier agreements, SLAs, monitoring, evidence, and retained TSP responsibility.
ETSI EN 319 401 Trust Service Provider Applicability
Use ETSI EN 319 401 to decide whether a trust service provider activity falls in the standard's type-independent baseline and what service, policy, risk, supplier, and evidence boundaries to document.
ETSI EN 319 401 vs eIDAS Article 19 and 24
Compare ETSI EN 319 401 V3.1.1 with the eIDAS provisions mapped in Annex B: trust service risk management, incident handling, records, staff, terms, and termination planning.
ETSI EN 319 401 vs EN 319 403-1: TSP Policy vs CAB Assessment
Compare ETSI EN 319 401 and ETSI EN 319 403-1 for trust service providers: TSP operating controls, conformity assessment context, evidence boundaries, and reuse limits.
Security Incidents in ETSI EN 319 401
How ETSI EN 319 401 V3.1.1 expects trust service providers to detect, respond to, report, classify, document, 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.