--- title: "ETSI EN 319 401 Trust Service Applicability Workflow" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-401/trust-service-applicability-workflow" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-401/trust-service-applicability-workflow" author: "Sorena AI" description: "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." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "ETSI EN 319 401 applicability" - "trust service provider scope" - "TSP practice statement" - "trust service policy" - "EN 319 401 evidence" - "ETSI EN 319 401" - "trust service applicability" - "trust service provider" - "TSP evidence" --- **[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 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. *Workflow* *GLOBAL* *ETSI 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. 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. ## 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. Sources for this answer: - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports the applicability starting point: EN 319 401 covers general policy requirements for TSP operation and management, independent of TSP type, and identifies examples of trust services and trust service tokens. ## 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. Sources for this answer: - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports the policy gate by defining trust service policy and requiring the TSP to specify policies and practices appropriate for the trust services it provides. *Recommended next step* *Placement: after practical guidance* ## Operationalize ETSI EN 319 401 scope decisions Use the applicability workflow to connect each trust service, policy, practice statement, term, supplier, and control area to owned evidence. - [Map EN 319 401 scope to controls](/solutions/assessment.md): Convert the applicability decision into accountable tasks, evidence requests, and review triggers. - [Research EN 319 401 source questions](/solutions/research-copilot.md): Use cited source material to resolve trust service policy, practice-statement, terms, supplier, and baseline-control questions. - [Review EN 319 401 applicability](/contact.md): Talk through the service boundary, evidence map, and unresolved applicability gaps with Sorena. ## 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. Sources for this answer: - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports the practice-statement evidence gate, including management approval, external-party obligations, availability to subscribers and relying parties, review responsibilities, and change notice. ## 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. Sources for this answer: - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports the terms gate by listing the minimum terms-and-conditions topics for each supported trust service policy and the timing and format expectations for making terms available. ## 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. Sources for this answer: - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports the baseline evidence map across clauses 5, 6, 7.1 through 7.14, including risk assessment, security policy, operation controls, incident handling, evidence retention, continuity, termination, compliance, and supply chain. ## 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. Sources for this answer: - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - 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. ## Primary sources - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Primary source for the page: EN 319 401 scope, trust service and TSP definitions, trust service policy and practice-statement requirements, terms and conditions, risk assessment, baseline TSP operation controls, evidence collection, continuity, termination, compliance, and supply chain responsibility. - Quote: "general policy requirements relating to Trust Service Providers" ## Related Topic Guides - [CA and RA responsibilities under ETSI EN 319 401](/artifacts/global/etsi-en-319-401/faq/ca-and-ra-responsibilities.md): 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](/artifacts/global/etsi-en-319-401/faq/eidas-articles-19-and-24.md): 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](/artifacts/global/etsi-en-319-401/audit-and-conformity-assessment.md): 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](/artifacts/global/etsi-en-319-401/audit-evidence-pack.md): 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](/artifacts/global/etsi-en-319-401/audit-evidence-pack-workflow.md): 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](/artifacts/global/etsi-en-319-401/compliance.md): 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?](/artifacts/global/etsi-en-319-401/faq/conformity-assessment-bodies.md): 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](/artifacts/global/etsi-en-319-401/faq.md): 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](/artifacts/global/etsi-en-319-401/incident-and-continuity-evidence-workflow.md): 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](/artifacts/global/etsi-en-319-401/incident-and-continuity-duties.md): 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](/artifacts/global/etsi-en-319-401/personnel-asset-and-access-controls.md): 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](/artifacts/global/etsi-en-319-401/policy-and-security-requirements.md): 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?](/artifacts/global/etsi-en-319-401/faq/policy-documentation.md): 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](/artifacts/global/etsi-en-319-401/requirements.md): 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](/artifacts/global/etsi-en-319-401/risk-management.md): 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](/artifacts/global/etsi-en-319-401/subcontractor-controls.md): 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](/artifacts/global/etsi-en-319-401/subcontractor-evidence-workflow.md): 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](/artifacts/global/etsi-en-319-401/faq/subcontractors.md): 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](/artifacts/global/etsi-en-319-401/trust-service-provider-applicability.md): 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](/artifacts/global/etsi-en-319-401/etsi-en-319-401-vs-eidas.md): 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](/artifacts/global/etsi-en-319-401/etsi-en-319-401-vs-en-319-403-1.md): 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](/artifacts/global/etsi-en-319-401/faq/security-incidents.md): 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](/artifacts/global/etsi-en-319-401/faq/trust-service-provider-scope.md): 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. --- [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/trust-service-applicability-workflow