Artifact GuideGLOBALETSI EN 319 411-1

ETSI EN 319 411-1 Audit File Evidence

A focused evidence-file guide for certification authorities preparing ETSI EN 319 411-1 audit logging, registration, revocation, CA key lifecycle, and archival records.

This serves as implementation support for audit preparation and evidence collection. Confirm final audit scope with the applicable scheme, assessor, and CP/CPS commitments.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
2

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
Overview

An assessor should be able to start with one CP/CPS commitment and use the to reach the corresponding event record, system control, owner, and retention rule without relying on oral context. For ETSI EN 319 411-1 V1.5.1 (2025-04), organize the file around the assessed CA service and period, then separate registration, certificate and key lifecycle, revocation, security-event, archive, continuity, and termination evidence. The standard defines requirements for the service; the applicable assessment scheme and assessor determine the final evidence request.

Section 1

Start the audit file with the certificate-service scope

Define which certification authority service, certificate policies, certificate profiles, registration authority arrangements, revocation services, repositories, and assessment period the file covers. ETSI EN 319 411-1 separates requirements by functions such as registration, certificate lifecycle operations, revocation, CA key management, audit logging, and records archival, so the record should make those boundaries explicit before evidence is collected.

The scope page should link the CP, CPS, subscriber-facing terms, repository locations, applicable certificate policy identifiers, and any RA delegation or outsourced service evidence that affects the records under review. Keep unsupported assumptions out of the public claim: if an item is included because a customer contract, browser root program, or national scheme requires it, name that separate trigger instead of attributing it to ETSI EN 319 411-1.

  • Name the assessed CA service, root or subordinate CA role, certificate policy, certificate profile, and certificate status services covered by the .
  • Tie each evidence folder to the CP/CPS clause or operational procedure it proves, especially for registration, revocation, CA key lifecycle, certificate generation, and dissemination.
  • Identify the assessment period and keep it separate from certificate validity periods, archive retention periods, and future remediation dates.
  • List exclusions plainly, such as certificate types, RAs, repositories, or production environments that are outside the assessment boundary.
Section 2

What evidence belongs in the ETSI EN 319 411-1 audit file?

Build the file around the records ETSI EN 319 411-1 calls out for audit logging and archival review. For each event record, include the control that makes it reliable: the procedure, owner, timestamp source, log protection, access control, archive location, and review history.

For registration evidence, include the records needed to show how applicant information was received and validated, where supporting documents and subscriber agreements are stored, which entity accepted the application, and which TSP or RA submitted it. For operational evidence, include security-event logs, PKI access attempts, CA key lifecycle logs, certificate lifecycle events, revocation requests and resulting actions, and any subject-device preparation evidence that applies to NCP+ services.

  • Registration file: application records, identity-document references where applicable, subscriber agreement storage location, validation method, accepting entity, and submitting TSP or RA.
  • Security-event file: security policy changes, system start-up and shutdown, crashes, hardware failures, firewall and router activities, and PKI system access attempts.
  • CA key file: key lifecycle logs, key ceremony evidence when applicable, key changeover evidence, compromise response records, and backup or recovery records for CA operations.
  • Certificate and revocation file: certificate generation and dissemination records, certificate lifecycle events, revocation requests, revocation reports, and the action taken.
  • Archive-control file: retention statement in the practice statement, archive access rules, integrity and confidentiality protections, UTC synchronization evidence, and handover items for termination planning.
Section 3

Retention, integrity, and access checks for the evidence file

Apply the clause 6.4.6 seven-year minimum only to the records it names: logs for the lifecycle of keys managed by the CA, including subject key pairs generated by the CA, and the documentation identified in clause 6.3.4. The period runs until at least seven years after any certificate based on those records ceases to be valid. For registration, revocation, certificate-lifecycle, and other service records, document the retention period in the practice statement and apply the period notified in the terms and conditions, together with any longer legal, scheme, policy, or contractual rule.

Current ETSI EN 319 401 adds general controls for all relevant service-operation evidence. Keep records accessible for an appropriate period, protect the confidentiality and integrity of current and archived records, archive them completely under disclosed practices, synchronize audit-log time with UTC at least daily, and prevent easy deletion or destruction during the required holding period.

  • Document the retention period, trigger date, source of the period, and archive location for each record family; do not assign seven years to an entire folder merely because it contains one clause 6.4.6 record.
  • Show how archive confidentiality and integrity are protected, including access rights for system auditors and privileged administrators.
  • Include UTC synchronization evidence for audit-log time and preserve the timestamp source used for significant key management and environmental events.
  • Record whether logs are kept on write-only media, transferred to long-term media, backed up off-site, or stored in independent locations.
  • Keep termination-plan handover evidence for records that must remain available after the TSP stops operating the service.
Section 4

Audit-file review checklist before assessor handoff

Before handing the file to an assessor, test whether a reviewer can move from each CP/CPS commitment to the operational record without asking the CA team to reconstruct context. The record should be readable as evidence of actual operation, not just a list of policies.

This checklist covers the evidence pack only; it does not supersede the applicable assessment scheme, ETSI TR audit checklist, browser-program criteria, or legal obligations that may apply outside EN 319 411-1.

  • Traceability: every folder names the EN 319 411-1 clause, CP/CPS clause, service function, owner, and assessment period it supports.
  • Completeness: registration, CA key lifecycle, certificate lifecycle, revocation, security-event, archive, continuity, and termination-handover evidence are present or marked not applicable with a cited reason.
  • Reliability: records include timestamps, access controls, archive location, integrity protection, and review history rather than screenshots with no provenance.
  • Privacy: subject and subscriber information is disclosed only to the extent needed for audit review and remains protected according to the applicable confidentiality controls.
  • Change handling: material CP/CPS, RA, repository, revocation-service, CA key, archive, or production-environment changes are linked to a new evidence request.
Section 5

Common audit-file gaps to close early

A CA may have logs, policy documents, and tickets but still fail to show which record proves which EN 319 411-1 requirement for the assessed service and period. Close those traceability gaps before the formal evidence request starts.

Narrow claims when the cited requirement or operational evidence is narrow. For example, a revocation log for one CA hierarchy does not prove revocation operation for another hierarchy, and a registration sample does not prove every RA arrangement unless the explains why the same controlled process applies.

  • Do not mix evidence from different CAs, certificate profiles, RAs, repositories, or assessment periods without a scope note.
  • Do not rely on CP/CPS text alone where EN 319 411-1 expects logged events or retained operational records.
  • Do not publish or hand over private file names, raw extraction notes, or private working locations as if they were public sources.
  • Do not claim complete ETSI EN 319 411-1 conformity from this evidence file alone; conformity depends on the full applicable assessment scope.
  • Do not omit archive-retrieval evidence for records that must remain accessible after certificates cease to be valid or after service termination.
Primary sources

References and citations

Related guides

Explore more topics

CP vs CPS under ETSI EN 319 411-1
Understand how ETSI EN 319 411-1 separates Certificate Policy from Certification Practice Statement work for certification authorities and trust service providers.
EN 319 411-1 vs EN 319 411-2 Certificate Policy
Compare ETSI EN 319 411-1 V1.5.1 with EN 319 411-2 V2.6.1, including policy profiles, inherited controls, QSCD routes, trusted-list status, and evidence boundaries.
ETSI EN 319 411-1 CA Key Management
CA key management guidance for ETSI EN 319 411-1: CPS commitments, key ceremonies, secure cryptographic devices, backup, recovery, and lifecycle evidence.
ETSI EN 319 411-1 certificate lifecycle workflow
Workflow for EN 319 411-1 certificate application, issuance, acceptance, renewal, re-key, modification, revocation, suspension, status services, and evidence records.
ETSI EN 319 411-1 certificate re-key FAQ
What ETSI EN 319 411-1 requires when a TSP re-keys an existing certificate with a new subject public key.
ETSI EN 319 411-1 Certificate Suspension FAQ
How CAs should handle certificate suspension under ETSI EN 319 411-1: CPS disclosure, validated requests, status publication, subscriber notice, and audit evidence.
ETSI EN 319 411-1 Certification Audit Evidence FAQ
How CAs should prepare ETSI EN 319 411-1 audit evidence for CP/CPS scope, registration records, revocation records, CA key logs, and retained assessment files.
ETSI EN 319 411-1 Compliance Guide
Build an ETSI EN 319 411-1 compliance file for certificate policies, CPS commitments, certificate lifecycle controls, revocation services, CA keys, and audit evidence.
ETSI EN 319 411-1 CP and CPS template
Build a certificate policy and Certification Practice Statement template for ETSI EN 319 411-1 certificate services, with fields for policy identifiers, subscribers, relying parties, revocation, publication, and evidence.
ETSI EN 319 411-1 FAQ for Certificate Services
Answers to common ETSI EN 319 411-1 questions on certificate policies, CPS content, CA and RA boundaries, subscriber evidence, revocation, status services, and record retention.
ETSI EN 319 411-1 Identity Validation
Identity validation requirements in ETSI EN 319 411-1 for subscribers, subjects, RAs, certificate requests, registration evidence, and issuance records.
ETSI EN 319 411-1 Identity Validation Evidence Workflow
A workflow for building ETSI EN 319 411-1 identity validation evidence packs across subscriber, subject, certificate request, RA, logging, and retention controls.
ETSI EN 319 411-1 RA Delegation Guide
How to scope registration authority delegation under ETSI EN 319 411-1, including delegated RA tasks, external provider controls, registration records, and audit evidence.
ETSI EN 319 411-1 RA Delegation Review Workflow
Review delegated registration authority work under ETSI EN 319 411-1: retained CA responsibility, recognized registration service providers, secure data exchange, CPS coverage, and audit evidence.
ETSI EN 319 411-1 requirements map for certificate services
Map ETSI EN 319 411-1 requirements for certificate policies, CP/CPS content, registration, revocation, certificate status, and CA key-management evidence.
ETSI EN 319 411-1 Revocation Evidence Workflow
Build a revocation evidence workflow for ETSI EN 319 411-1 covering CPS procedures, request authentication, 24-hour status updates, CRL/OCSP publication, logs, and retention.
ETSI EN 319 411-1 Revocation, OCSP, and CRL Operations
Operate ETSI EN 319 411-1 revocation status services with CPS procedures, authenticated requests, applicable 24-hour timing, CRL and OCSP controls, exceptions, and audit evidence.
ETSI EN 319 411-1 vs CA/B Forum Baseline Requirements
Compare ETSI EN 319 411-1 V1.5.1 with the CA/Browser Forum TLS Baseline Requirements, including [WEB] controls, DVCP, OVCP, IVCP, CPS duties, and change monitoring.
How should certificate authorities handle revocation evidence under ETSI EN 319 411-1?
What ETSI EN 319 411-1 expects CAs to evidence for certificate revocation requests, status publication, CRL or OCSP updates, and archived revocation records.
RA delegation under ETSI EN 319 411-1
How certificate authorities can delegate registration authority work under ETSI EN 319 411-1 while keeping identity validation, secure data exchange, role controls, and audit evidence traceable.
Subscriber agreements under ETSI EN 319 411-1
How ETSI EN 319 411-1 expects CAs and TSPs to inform subscribers, record acceptance, handle subject consent, and retain subscriber-agreement evidence.
Subscriber identity validation under ETSI EN 319 411-1
How certificate authorities should validate subscriber and subject identity under ETSI EN 319 411-1, including evidence, authorization, subject categories, and registration records.