Artifact GuideGLOBALETSI EN 319 401

ETSI EN 319 401 policy and security requirements

A practical guide to the policy, practice, risk, security, incident, continuity, and supplier evidence expected by ETSI EN 319 401 V3.1.1.

Use it to build source-linked trust service provider evidence without turning EN 319 401 into an unsupported compliance claim.

Author
Sorena AI
Published
May 9, 2026
Updated
May 27, 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 27, 2026
Overview

ETSI EN 319 401 policy and security work starts with the trust service boundary, then connects risk assessment, practice statements, terms and conditions, information security policy, operational security controls, incident handling, evidence retention, continuity, termination, and supplier controls. The standard is a baseline for trust service provider operation and management practices; service-specific ETSI standards can refine or extend it for particular trust services.

Section 1

Start with the EN 319 401 scope and risk assessment

The standard applies general policy requirements to Trust Service Providers independent of the type of trust service. It covers operation and management practices, while noting that other specifications can refine and extend the requirements for particular trust services. That makes scope the first decision: name the trust service, service policy, systems, facilities, people, suppliers, and external organizations that support the service.

Clause 5 then requires the TSP to identify, analyse, and evaluate trust service risks, choose risk treatment measures, document the security requirements and operational procedures needed for those treatments, review the risk assessment regularly, and have management approve the assessment and accept residual risk. Policy text that is not traceable to this risk work is weak evidence.

  • Define the trust service and any service-specific ETSI standard that refines the EN 319 401 baseline.
  • Keep the risk assessment, risk treatment decisions, security requirements, operational procedures, review history, management approval, and residual-risk acceptance together.
  • Separate requirements created by EN 319 401 from extra requirements created by law, customer contracts, supervisory expectations, procurement terms, or internal policy.
  • Do not claim qualified-service status, conformity assessment, or legal compliance unless the page also identifies the applicable policy, assessment scheme, and evidence boundary.
Section 2

Turn policies and practices into public and internal evidence

Clause 6.1 requires the TSP to specify the policies and practices appropriate for the trust services it provides, have them approved by management, publish and communicate them as relevant, and maintain a trust service practice statement that addresses the requirements of the applicable trust service policy. The practice statement also has to identify obligations of external organizations supporting the service.

The same clause requires relevant documentation to be made available to subscribers and relying parties as necessary to demonstrate conformance to the trust service policy, while allowing sensitive aspects to remain undisclosed. When practice-statement changes might affect acceptance by subjects, subscribers, or relying parties, EN 319 401 requires due notice and immediate availability of the revised practice statement after approval.

  • Use the trust service practice statement to show how each applicable trust service policy requirement is addressed.
  • Identify external organizations that support the service and the policy or practice obligations assigned to them.
  • Maintain a public-facing evidence set for subscribers and relying parties, plus a controlled internal set for sensitive implementation detail.
  • Record practice-statement ownership, review responsibilities, management approval, change notices, and publication dates.
Section 3

Make terms, conditions, and security policy specific

Clause 6.2 requires terms and conditions to be available to subscribers and relying parties, made available before entering a contractual relationship, provided through a durable means of communication, and written in readily understandable language. Those terms need to specify, for each supported trust service policy, items such as the policy applied, service limitations, subscriber obligations, relying-party information, event-log retention, liability limits, applicable legal system, complaints and dispute procedures, conformity-assessment status and scheme where applicable, contact information, and availability undertakings.

Clause 6.3 requires an information security policy approved by management and setting out the organization's approach to information security. It must be documented, implemented, and maintained, include controls and operating procedures for facilities, systems, and information assets, communicate changes to third parties where applicable, notify important service-provision changes to appropriate parties, and review the policy and asset inventory at planned intervals or after significant changes.

  • Check every customer-facing term against the exact trust service policy and avoid promises broader than the assessed service.
  • State log-retention periods, relying-party verification information, limitation language, contact routes, and availability undertakings in one place.
  • Maintain the information security policy as a managed control document, not a generic security statement.
  • Document the maximum interval between configuration checks that look for changes violating the TSP's security policies.
Section 4

Connect security policy to operational controls

EN 319 401 security policy only becomes useful when it is tied to operational controls. The standard requires reliable organization practices, segregation of conflicting duties, personnel and contractors who apply information security according to TSP policies, documented security roles and responsibilities, identified trusted roles, asset inventory and classification, controlled storage media handling, least-privilege access administration, privileged-account controls, and authentication before critical applications are used.

The technical side continues through cryptographic key lifecycle controls, physical protection for critical service components, secure design analysis for systems development, change control for operational software and configurations, malware protection, configuration monitoring, network segmentation, zone-based controls, separation of administration and production networks, trusted channels between trustworthy systems, vulnerability scanning, and penetration testing after significant infrastructure or application changes.

  • Keep role appointment records, role acceptance, screening completion, training, disciplinary processes, and remote-work policy evidence for personnel in trusted or administrative roles.
  • Build the asset inventory with owner, location, type, information handled, update or patch version, classification level, and end-of-life data where applicable.
  • Retain access reviews, privileged-account approvals, termination or role-change access updates, authentication evidence, and administrator activity logs.
  • Tie vulnerability scans, penetration tests, configuration reviews, change tickets, malware updates, and network rule reviews to the service boundary.
Section 5

Treat incidents, evidence, and continuity as policy requirements

Clause 7.9 requires monitoring and logging mechanisms, detection of abnormal activities as alarms, regular review of logs, incident response procedures for containment, eradication, and recovery, communication plans, incident documentation, interfaces between incident handling and business continuity, reporting procedures, severity assessment, reclassification as new inputs arrive, and post-incident reviews that identify root cause and reduce recurrence risk.

Clause 7.10 requires the TSP to record and keep accessible relevant information about data issued and received by the TSP for an appropriate period, including after the TSP's activities cease, for legal evidence and continuity. Clauses 7.11 and 7.12 add continuity, backup, crisis management, and termination planning, including subscriber and relying-party notices, subcontractor authorization termination, evidence-transfer arrangements, private-key destruction or withdrawal, and continued access to public keys or trust service tokens for a reasonable period.

  • Log network traffic, user administration, permission changes, privileged access, administrator activity, critical configuration and backup changes, security events, resource use, physical access where appropriate, and network equipment access.
  • Preserve incident detection records, classification, escalation, stakeholder communications, regulatory reporting decisions, containment, eradication, recovery, root cause, and corrective actions.
  • Keep archived operational records complete, confidential, integrity-protected, UTC-synchronized where required, and aligned with the retention period disclosed in terms and conditions.
  • Test backup recovery and crisis plans at planned intervals or through post-incident review, then document findings and corrective actions.
Section 6

Include supplier and cloud dependencies in the security file

Clause 7.14 requires the TSP to address security risks from supplier products and services, including the ICT supply chain. The supply-chain policy has to identify and communicate the TSP's role, define criteria for selecting and contracting suppliers or service providers, and consider cybersecurity specifications, risk and classification levels, diversification and vendor lock-in, and critical-supply-chain risk assessment results.

When other parties provide parts of the service through subcontracting, outsourcing, or other arrangements, EN 319 401 requires the TSP to maintain overall responsibility for conformance with the supply chain policy, information security policy, and trust service policy requirements. Supplier agreements, SLAs, audit mechanisms, critical-component traceability, cloud shared-responsibility expectations, supplier registers, and supplier-change reviews should therefore sit in the same evidence file as the policy and security requirements.

  • Define information security requirements for ICT product or service acquisition before procurement decisions are finalized.
  • Request supplier information about software components, implemented security functions, and secure-configuration requirements where products support the trust service.
  • Use contracts, SLAs, and auditing mechanisms to bind suppliers to the TSP's information security requirements.
  • Maintain and regularly review a supplier and agreement register showing where TSP information is managed or archived.
Primary sources

References and citations

etsi.org
Referenced sections
  • Grounds clause 7.14 supply-chain policy, supplier procedures, subcontracting, outsourcing, SLAs, cloud responsibility, and supplier registers.
"Supply chain policy"
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 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 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 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.