ETSI EN 319 401 requirements map

Start the register with the trust service, trust service policy, practice statement, trust service tokens, subscriber and relying-party audiences, and every component used to provide the service. EN 319 401 applies across trust services such as certificates, time-stamps, registered delivery, signature validation, preservation, and related service components, while other ETSI standards can refine the requirements for a specific service type.

Do not map requirements to a generic compliance program. Map them to the TSP entity, the services it provides, the systems and facilities supporting those services, the external organizations supporting them, and the public statements made to subscribers and relying parties.

The first requirement group is governance, not tooling. Clause 5 requires risk assessment, risk treatment, security requirements, operational procedures, regular review, and management approval of residual risk. Clause 6 then turns those decisions into the practice statement, terms and conditions, and information security policy.

A useful requirements map should show which document or record proves each obligation: the risk assessment, management approval, trust service practice statement, published terms, notice process for material practice-statement changes, information security policy, asset inventory linkage, and configuration-check interval.

Clause 7 is best handled as a set of control families with owners and evidence, not as one long checklist. The map should cover organization reliability, segregation of duties, human resources, asset inventory, storage media, access control, cryptographic controls, physical security, operational security, and network security.

The evidence needs to match the control family. For example, trusted roles require appointment and acceptance records; assets require inventory fields such as owner, location, classification, version or patch state, and end of life; privileged access requires review records; network security requires segmentation, zone rules, vulnerability-scan evidence, malware update evidence, and significant-change penetration-test evidence.

EN 319 401 places incident handling and audit evidence inside the requirement set. The map should therefore include continuous monitoring and logging, incident response, reporting, event classification, post-incident review, evidence collection, business continuity, backup, crisis management, and termination planning.

This part of the map should be concrete because it is often inspected after a problem. Include log categories, alert follow-up roles, reporting paths, documented incident records, root-cause reviews, UTC time synchronization for audit logs, record retention tied to terms and conditions, backup integrity checks, recovery-test results, crisis-management reviews, and termination steps for subscribers, relying parties, authorities, subcontractors, private keys, and evidence transfer.

The register is incomplete if it stops at internal systems. Clause 7.13 requires evidence of applicable legal requirements, feasible accessibility for trust services and end-user products, and personal-data protection measures. Clause 7.14 adds supplier, ICT supply-chain, cloud-service, outsourcing, subcontractor, SLA, monitoring, and supplier-register requirements.

For supplier-dependent services, keep the TSP accountable in the map. EN 319 401 says a TSP using other parties to provide parts of its service maintains overall responsibility for conformance with the supply-chain policy, information security policy, and trust service policy requirements.

Before using the map in an assessment or procurement response, test whether every row can be understood without hidden context. Each row should identify the clause or requirement, service boundary, applicability decision, owner, control, evidence artifact, review trigger, and source.

Flag gaps instead of filling them with broad compliance claims. A TSP may need service-specific ETSI requirements, an eIDAS qualification context, a conformity-assessment scheme, or customer contract terms before a requirement can be interpreted precisely.