A practical workflow for deciding whether EN 319 401 belongs in a trust service scope review.
Based on ETSI EN 319 401 V3.1.1. Use it as implementation guidance, not for legal interpretation.
Structured answer sets in this page tree.
Cited legal and guidance references.
Use this workflow to decide whether an organization is a Trust Service Provider () for the service being reviewed, which applies, and which supporting components and suppliers belong inside the evidence boundary. ETSI EN 319 401 V3.1.1 (2024-06) sets a general policy baseline for TSP operation and management. It does not make every software product, cloud platform, or component a trust service, and service-specific ETSI standards can add requirements.
First decide whether the organization provides one or more trust services. EN 319 401 defines a as an entity that provides one or more trust services. Its overview gives examples including public key certificate issuance, registration, time-stamping, long-term preservation, e-delivery, and signature validation. A is only one part of the TSP's overall service.
Create a scope record that names the service and output, the subscribers and relying parties, the operating entity, the systems and locations used to provide the service, and every or supplier inside that boundary. A component provider may have contractual control duties without becoming the for the complete service; document who offers the service and who retains overall responsibility.
The first gate has four outcomes. Continue as a when the entity offers the complete trust service. Continue as a supporting dependency when it provides a component, product, or service inside another TSP's boundary. Record the activity as outside this baseline when it is ordinary software or security work with no trust-service connection. Leave the gate open when the service output, offering entity, subscriber or relying-party relationship, or governing policy cannot yet be established.
Once a service appears to be in scope, identify the 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 is a policy mapping, not a bare yes-or-no conclusion. Show the policy name or identifier, service type, customer or relying-party community, service level, use limitations, and any service-specific ETSI standard that adds requirements beyond EN 319 401. The policy may be defined by the , a standards body, a government, an international organization, or customers; EN 319 401 says it is not necessarily part of the TSP's own documentation.
Use the applicability workflow to connect each trust service, policy, practice statement, term, supplier, and control area to owned evidence.
Convert the applicability decision into accountable tasks, evidence requests, and review triggers.
Use cited source material to resolve trust service policy, practice-statement, terms, supplier, and baseline-control questions.
Talk through the service boundary, evidence map, and unresolved applicability gaps with Sorena.
The explains the practices the uses to provide the service. EN 319 401 requires the TSP to specify appropriate policies and practices, obtain management approval, publish and communicate them as relevant, and maintain a statement addressing all requirements of the applicable . The standard does not prescribe the statement's structure.
The evidence should show which service and policy are covered, which external organizations support the service, how subscribers and relying parties can obtain the statement and other relevant non-sensitive documentation, who has final approval authority, and how revisions and change notices are controlled.
Check subscriber and relying-party service terms against the policy decision. EN 319 401 requires terms and conditions to be available to subscribers and relying parties and requires specific items for each supported by the .
This gate helps 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.
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 requirement identifier ending in X marks a requirement added, changed, renumbered, or moved since V2.3.1; it does not make the requirement optional.
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.
Use this table in an independent review note, procurement intake, or audit-prep file. Assign a role and evidence reference at every gate so another reviewer can follow the scope decision.
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 ( 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 | 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?
7. Decision release | Service Owner and Compliance Lead | signed scope decision, effective date, exclusions, open gaps, next-review trigger, and evidence-map reference | Is the result in scope, supporting dependency, out of scope, or unresolved?
Not automatically. EN 319 401 defines a as one part of the overall service. Determine which entity offers the complete trust service to subscribers or relying parties, then document the component provider's contractual and security obligations. If a TSP outsources part of its service, REQ-7.14.3-01X keeps overall responsibility with the TSP for the stated policy areas.
No. EN 319 401 is a general policy standard and does not grant qualified status, trusted-list inclusion, or supervisory approval. An EU qualified-service claim needs the applicable eIDAS process, conformity assessment, supervisory decision, trusted-list evidence, and service-specific requirements.