--- title: "ETSI EN 319 411-1 Audit File Evidence" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/audit-file-evidence" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/audit-file-evidence" author: "Sorena AI" description: "Build an ETSI EN 319 411-1 audit evidence file for CA logging, registration records, revocation records, CA key lifecycle evidence, and records archival." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "ETSI EN 319 411-1 audit evidence" - "CA audit logging" - "records archival" - "certificate authority evidence" - "ETSI EN 319 411-1" - "audit evidence" - "audit logging" - "certificate authority" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 411-1 Audit File Evidence Build an ETSI EN 319 411-1 audit evidence file for CA logging, registration records, revocation records, CA key lifecycle evidence, and records archival. *Artifact Guide* *GLOBAL* *ETSI 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. Use this as implementation support for audit preparation and evidence collection. Confirm final audit scope with the applicable scheme, assessor, and CP/CPS commitments. An ETSI EN 319 411-1 audit file should let an assessor trace certificate-service operation from policy commitments to actual records. For this topic, the core file is not a generic compliance binder: it is the set of logs, registration records, revocation records, CA key lifecycle evidence, archival controls, and CP/CPS references that show how the certification authority operated during the assessment period. ## 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 file 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 audit file. - 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. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports using CP/CPS, certificate policy, CA, RA, subscriber, revocation, audit logging, and records archival boundaries as the audit-file structure. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports the broader trust service provider controls behind logging, evidence collection, continuity, access control, and system monitoring. ## 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. The strongest audit file shows both the event record and the control that made the record 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. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the specific EN 319 411-1 evidence categories for registration information, security events, CA key lifecycle events, certificate lifecycle events, revocation records, and subject-device preparation. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports keeping service-operation records accessible, confidential, complete, and available as evidence of correct service operation. *Recommended next step* *Placement: after audit evidence guidance* ## Prepare CA audit evidence Use this ETSI EN 319 411-1 page to organize registration records, CA key lifecycle logs, certificate lifecycle evidence, revocation records, and archive controls before assessor review. - [Open Assessment Autopilot for ETSI EN 319 411-1](/solutions/assessment.md): Convert audit evidence gaps into assigned evidence requests and review-ready CA records. - [Research ETSI EN 319 411-1 source questions](/solutions/research-copilot.md): Resolve clause, scope, archive, and evidence questions against the cited ETSI source material. - [Talk through EN 319 411-1 audit evidence](/contact.md): Review CA audit-file scope, missing records, archive controls, and assessor handoff steps with Sorena. ## Retention, integrity, and access checks for the evidence file ETSI EN 319 411-1 gives a concrete retention rule for the records named in clause 6.4.6: retain them for at least seven years after any certificate based on those records ceases to be valid. The audit file should therefore show both the rule and the mechanism: where the records are archived, how they are protected, who can retrieve them, and how the CA prevents easy deletion or destruction during the required retention period. ETSI EN 319 401 adds general evidence controls that matter when the audit file is challenged later. Current and archived service-operation records need confidentiality and integrity protection, records should be archived according to disclosed business practices, event times should be recorded precisely for significant environmental, key management, and clock synchronization events, and audit-log time should be synchronized with UTC at least once a day. - Document the retention period in the practice statement and point to the archive location for each record family. - 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. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the seven-year retention rule for clause 6.4.6 records and the requirement to state retention and handover treatment in the practice statement. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports confidentiality, integrity, archive completeness, evidence availability, UTC synchronization, and protection against easy deletion or destruction of event records. ## 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 file should be readable as evidence of actual operation, not just a list of policies. Use this checklist for 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 source-linked 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. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the review focus on CP/CPS consistency, audit logging, registration records, revocation records, CA key lifecycle records, records archival, and compliance assessment. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports the general trust service provider expectation that records remain accessible and useful as evidence of correct service operation. ## Common audit-file gaps to close early Most audit-file problems are traceability problems. 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 gaps before the formal evidence request starts. Narrow claims when the grounding or 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 audit file 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 local file names, raw extraction notes, or internal working paths 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. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports avoiding overbroad claims by tying evidence to specific CA services, certificate lifecycle events, revocation actions, registration records, and archive duties. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports the need for protected, complete, retrievable records and monitoring or regular review of audit logs. ## Primary sources - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Primary source for the page's EN 319 411-1 audit logging, registration record, CA key lifecycle, certificate lifecycle, revocation, and records archival claims. - Quote: "Policy and security requirements" - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Primary source for the general TSP evidence collection, monitoring, audit-log review, archive integrity, continuity, and UTC synchronization controls used on this page. - Quote: "General Policy Requirements" ## Related Topic Guides - [CP vs CPS under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/cp-vs-cps.md): 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](/artifacts/global/etsi-en-319-411-1/en-319-411-1-vs-en-319-411-2.md): Compare ETSI EN 319 411-1 general certificate-service requirements with EN 319 411-2 EU qualified certificate requirements, including policy scope, CP/CPS evidence, and audit boundaries. - [ETSI EN 319 411-1 CA Key Management](/artifacts/global/etsi-en-319-411-1/ca-key-management.md): 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](/artifacts/global/etsi-en-319-411-1/certificate-lifecycle-workflow.md): 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](/artifacts/global/etsi-en-319-411-1/faq/re-key.md): 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](/artifacts/global/etsi-en-319-411-1/faq/suspension.md): 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](/artifacts/global/etsi-en-319-411-1/faq/certification-audit-evidence.md): 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](/artifacts/global/etsi-en-319-411-1/compliance.md): 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](/artifacts/global/etsi-en-319-411-1/cp-and-cps-template.md): 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](/artifacts/global/etsi-en-319-411-1/faq.md): 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](/artifacts/global/etsi-en-319-411-1/identity-validation.md): 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](/artifacts/global/etsi-en-319-411-1/identity-validation-evidence-workflow.md): 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](/artifacts/global/etsi-en-319-411-1/ra-delegation.md): 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](/artifacts/global/etsi-en-319-411-1/ra-delegation-review-workflow.md): 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](/artifacts/global/etsi-en-319-411-1/requirements.md): 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](/artifacts/global/etsi-en-319-411-1/revocation-evidence-workflow.md): 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](/artifacts/global/etsi-en-319-411-1/revocation-ocsp-and-crl-operations.md): Operate ETSI EN 319 411-1 revocation status services with CPS procedures, authenticated requests, 24-hour CRL or OCSP publication controls, and audit evidence. - [ETSI EN 319 411-1 vs CA/B Forum Baseline Requirements](/artifacts/global/etsi-en-319-411-1/en-319-411-1-vs-ca-browser-forum-baseline-requirements.md): Compare how EN 319 411-1 incorporates CA/B Forum BRG concepts for DVCP, OVCP, IVCP, [WEB] requirements, CPS disclosure, domain validation, and conflict handling. - [How should certificate authorities handle revocation evidence under ETSI EN 319 411-1?](/artifacts/global/etsi-en-319-411-1/faq/revocation-evidence.md): 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](/artifacts/global/etsi-en-319-411-1/faq/ra-delegation.md): 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](/artifacts/global/etsi-en-319-411-1/faq/subscriber-agreements.md): 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](/artifacts/global/etsi-en-319-411-1/faq/subscriber-identity-validation.md): How certificate authorities should validate subscriber and subject identity under ETSI EN 319 411-1, including evidence, authorization, subject categories, and registration records. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-411-1/audit-file-evidence