ETSI EN 319 401 requirements map

Start the register with the trust service, trust service policy, practice statement, each trust service token type, 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 begins with internal organization. Map organization reliability, non-discriminatory practices, applicable financial-resource or liability-insurance duties, financial stability, complaint and dispute procedures, and segregation of conflicting duties before moving to human resources, assets, access, cryptography, physical security, operations, and networks.

Evidence must match both the requirement and its modality. Trusted roles require appointment and acceptance records; assets require applicable inventory fields; privileged access requires review records. V3.1.1 requires regular vulnerability scans, says they should occur quarterly, requires daily updates for the specified malware detection and removal software, and requires penetration testing after changes the TSP determines are significant.

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.