We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Artifact GuideGLOBALETSI EN 319 411-1

ETSI EN 319 411-1 CP and CPS template

A field-by-field template for separating Certificate Policy commitments from implementation details under ETSI EN 319 411-1.

Use it to draft public-facing certificate-service documentation and the non-public evidence map that supports it.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
5 sections2 primary sources
Overview

Use the Certificate Policy (CP) to state the certificate's quality, profile, applicability, and governing rules. Use the (CPS) to explain how the TSP meets those rules in its organization, facilities, systems, and procedures. This unofficial drafting aid applies ETSI EN 319 411-1 V1.5.1 (2025-04). It separates public material from confidential low-level procedures and flags policy-specific fields that cannot be completed until the certificate profile and service boundary are known.

Section 1

Template header: identify the certificate policy

Start the template with the policy identity, not with generic compliance language. EN 319 411-1 explains that certificate policy identification is communicated through subscriber and relying-party documentation, and certificates can include a CP identifier that relying parties use to assess suitability and trustworthiness.

Use these fields at the top of the CP and mirror them in the CPS traceability table.

Write out the selected policy name in the header: Lightweight Certificate Policy (LCP), Normalized Certificate Policy (NCP), Extended Normalized Certificate Policy (NCP+), Domain Validation Certificate Policy (DVCP), Organizational Validation Certificate Policy (OVCP), Individual Validation Certificate Policy (IVCP), or Extended Validation Certificate Policy (EVCP).

  • Policy name: LCP, NCP, NCP+, DVCP, OVCP, IVCP, EVCP, or custom policy. Evidence: approved CP document.
  • Policy OID: object identifier used in certificates. Evidence: certificate profile and issuance record.
  • Certificate type: natural person, legal person, website, device, or other subject class. Evidence: certificate profile reference.
  • Intended use: permitted certificate usage, relying-party audience, and whether certificates are issued to the public. Evidence: subscriber terms and PKI disclosure statement.
  • State whether the CP uses one of the EN 319 411-1 reference policies or a custom policy defined under clause 7.
  • Identify the policy authority or approving body for the CP, especially when the policy extends or constrains an EN 319 411-1 reference policy.
  • Keep the CPS version, effective date, approval record, publication location, and confidential-procedure references separate from the CP identifier.
Section 2

Certificate Policy fields: state what applies

The CP should state rules that subscribers and relying parties can understand without describing every internal CA procedure. EN 319 411-1 describes a CP as the document that defines certificate quality, applicability, profile, and the common rules for a certificate community.

  • Applicability: who can receive certificates and which applications may rely on them. Evidence: policy approval record.
  • Certificate profile: X.509 profile requirements and ETSI EN 319 412 part used where appropriate. Evidence: profile specification.
  • Validation basis: identity or domain validation level and source of attributes. Evidence: registration evidence.
  • Subscriber obligations: duties before and after acceptance. Evidence: terms and conditions.
  • Relying-party notice: status-checking and usage limits. Evidence: PKI disclosure statement.
  • For LCP, NCP, NCP+, DVCP, OVCP, IVCP, or EVCP, preserve EN 319 411-1 profile markings instead of flattening them into one checklist.
  • For a custom CP, identify the adopted EN 319 411-1 base policy, added constraints, variances, approving authority, risk assessment basis, and review process.
  • Include the certificate profile requirements and unique object identifier when the policy is used in issued certificates.
  • For a custom CP under clause 7, make revisions available to subscribers and relying parties when the CP changes.
Section 3

Certification Practice Statement fields: explain how the CA operates

The CPS should explain how the TSP implements the CP in its organization, facilities, systems, and procedures. EN 319 411-1 allows sensitive or proprietary low-level procedures to remain internal, but requires the CPS to be publicly disclosed online on a 24x7 basis; sensitive aspects need not be disclosed. The public CPS still needs enough information for subscribers, subjects, and relying parties to understand the service, while controlled internal documents supply the detail an assessor needs.

  • Registration service: identity proofing, proof of possession, RA handoff, attribute validation. Evidence: registration records.
  • Certificate generation: approval checks, profile selection, signing controls. Evidence: issuance logs.
  • Dissemination: certificate delivery and publication handling. Evidence: repository records.
  • Revocation management: authorized request intake, decision criteria, subscriber notice. Evidence: revocation case file.
  • Revocation status service: CRL or OCSP operation and integrity controls. Evidence: status-service monitoring.
  • Link each CP commitment to a CPS clause and to the operating evidence that proves the practice was followed.
  • Name external organizations that support the certificate service and identify the applicable policies and practices that govern their work.
  • Keep confidential procedure names, access lists, locations, and detailed key-ceremony steps in non-public evidence, not in public CPS text.
  • Show how the CPS covers registration, certificate generation, dissemination, revocation management, revocation status, and optional subject device provisioning where used.
  • State the signature algorithms and parameters used, and the practice for using CA keys to sign certificates, CRLs, and OCSP responses.
Section 4

Terms, conditions, and PKI disclosure statement fields

The CP/CPS package should include subscriber and relying-party material, not just a technical policy. EN 319 411-1 requires terms and conditions and describes the PKI disclosure statement as the part of those terms that relates to PKI operation. Annex A also makes clear that a disclosure statement helps users make trust decisions but does not supersede the CP or CPS.

  • TSP contact: legal name, location, support, revocation contact. Evidence: published disclosure.
  • Certificate type and validation: class of certificate and validation procedure. Evidence: CP/CPS clause.
  • Subscriber obligations: key protection, information accuracy, acceptance, notification duties. Evidence: subscriber agreement.
  • Relying-party obligations: certificate-status checking and reliance limits. Evidence: relying-party notice.
  • Audit and trust marks: conformity scheme, audit reference, trusted-list link where applicable. Evidence: assessment record.
  • Include what constitutes certificate acceptance, records retention period, subscriber obligations, subject obligations where applicable, and notices to relying parties.
  • Publicly disclose the CPS online on a 24x7 basis while withholding sensitive aspects; make the applicable CP, terms, and disclosure material available as required for the selected policy and audience.
  • Do not use the PKI disclosure statement as a substitute for the governing CP or CPS; use it as a readable index to the obligations and limitations.
  • Keep legal, complaint, dispute-resolution, privacy, refund, liability, audit, and repository information aligned with the terms and CPS.
Section 5

Maintenance controls for the CP/CPS template

Treat the template as a controlled document set. EN 319 401 requires management-body approval of the practice statement, defined maintenance responsibilities, a review process, availability to subscribers and relying parties, and due notice for changes that might affect service acceptance. EN 319 411-1 separately requires public online CPS disclosure and sets review and approval expectations for a custom CP.

  • Owner: policy authority, CPS maintainer, service owner. Evidence: responsibility matrix.
  • Review trigger: CP profile change, certificate profile change, RA change, revocation process change, CA key change, supplier change, audit finding. Evidence: change-impact record.
  • Publication: effective date, public URL, redaction rationale. Evidence: publication log.
  • Traceability: CP clause to CPS clause to evidence artifact. Evidence: evidence register.
  • Review CP and CPS alignment after changes to policy OIDs, certificate profiles, registration methods, RA delegation, revocation handling, repository operation, CA key controls, or external support.
  • Give notice when a practice-statement change may affect acceptance of the service by a subject, subscriber, or relying party.
  • Keep a source-to-clause map so an assessor can see which EN 319 411-1 or EN 319 401 requirement supports each public statement.
  • Version public documents and non-public evidence separately so sensitive implementation evidence can be reviewed without leaking it into subscriber-facing text.
Recommended next step

Draft CP and CPS documentation

This ETSI EN 319 411-1 template helps assign policy owners, draft subscriber-facing text, and map each CP/CPS clause to implementation evidence.

Assessment workflow
Open Assessment Autopilot for ETSI EN 319 411-1

Convert CP/CPS template fields into accountable tasks, evidence requests, and review milestones.

Explore next step
Research workflow
Research ETSI EN 319 411-1 source questions

Use cited ETSI source material to resolve CP, CPS, disclosure, revocation, and publication questions before implementation.

Explore next step
Talk to Sorena
Talk through CP/CPS implementation

Review certificate policy scope, CPS wording, disclosure boundaries, and evidence mapping with Sorena.

Explore next step
Primary sources

References and citations

ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements
etsi.org6 citations
Referenced sections
  • Grounds the CP/CPS distinction, reference certificate policies, custom CP framework, certification-service components, terms and conditions, PKI disclosure statement, and CP/CPS maintenance expectations.
  • Grounds the CP/CPS distinction, policy identifier role, supported certificate-policy profiles, and clause 7 requirements for custom CPs.
  • Grounds the contents of a Certificate Policy, the reference CP profiles, custom policy framework, certificate-profile requirements, OID expectation, and subscriber/relying-party availability.
Show 3 more
  • Grounds the CPS role, mandatory online disclosure with a sensitive-information exception, required algorithm and CA-key-use content, the public-versus-confidential boundary, and the certification-service components.
  • Grounds the minimum terms-and-conditions elements and Annex A's model PKI disclosure statement fields for subscriber and relying-party communication.
  • Grounds CP review duties, custom policy maintenance, CP support by CPS, and availability of revisions to subscribers and relying parties.
"Policy and security requirements for Trust Service Providers issuing certificates"
More quoted passages
"what is to be adhered to"
"Certificate Policy"
"how it is adhered to"
"PKI disclosure statement"
"defined review process"
ETSI EN 319 401 V3.2.1 general policy requirements for TSPs
etsi.org4 citations
Referenced sections
  • Current source for the general trust-service practice-statement duties that EN 319 411-1 builds on, including approval, availability, maintenance, external support, risk assessment, and change notice.
  • Current source for practice-statement approval, availability, maintenance responsibilities, external support, and change notice.
  • Grounds the practice statement requirements for identifying external supporting organizations, approval by a management body, maintenance responsibilities, availability, and change notice.
Show 1 more
  • Grounds practice-statement approval, maintenance responsibilities, publication after approval, and notice when changes affect service acceptance.
"General Policy Requirements for Trust Service Providers"
More quoted passages
"trust service practice statement"
"make available to subscribers"
"final authority for approving"

Related guides

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 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.

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 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 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.

Show all related guides (22)

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.

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.

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.

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.