Artifact GuideGLOBALETSI EN 319 411-1

ETSI EN 319 411-1 CP vs CPS under ETSI EN 319 411-1

A focused FAQ for certification authorities separating Certificate Policy commitments from Certification Practice Statement implementation evidence under ETSI EN 319 411-1.

Use it to align certificate policy identifiers, subscriber-facing documentation, CPS ownership, and audit evidence without exposing confidential operating procedures.

Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Questions
3

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

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

Under ETSI EN 319 411-1, a Certificate Policy (CP) describes what certificate requirements and applicability rules are being adhered to; a Certification Practice Statement (CPS) describes how the certification authority implements those requirements in its own organization, procedures, facilities, and systems. A CA should keep both connected, but it should not treat them as interchangeable documents.

Side-by-side comparison

Certificate Policy vs Certification Practice Statement

Compare CP and CPS responsibilities under ETSI EN 319 411-1 by purpose, ownership, publication, certificate linkage, evidence, and update triggers.

Review all sources
First framework
Certificate Policy (CP)

Defines what certificate policy requirements, quality level, applicability, profile, and policy identifier apply to the certificate service or certificate community.

Second framework
Certification Practice Statement (CPS)

Explains how the TSP-owned certification authority service implements the CP through operational, technical, organizational, and procedural practices.

Comparison row 1

Scope

Certificate Policy (CP)

States what requirements and applicability rules are adhered to for the certificate policy, including certificate quality, profile, and intended use.

Certification Practice Statement (CPS)

States how the CA operates its service to meet those policy requirements, including implementation practices for issuing, managing, revoking, renewing, or re-keying certificates.

Operational implication

Identify whether the document is setting policy (what must be done) or procedure (how it is done) before deciding which one to create or update.

Comparison row 2

Covered actors

Certificate Policy (CP)

Can be defined by the TSP, ETSI, governments, subscribers, users of certification services, or another community that sets common rules.

Certification Practice Statement (CPS)

Is developed, implemented, enforced, updated, and owned by the TSP issuing certificates.

Operational implication

Determine whether the document is addressed to external parties (CP) or internal operators (CPS) to decide who must approve and maintain it.

Comparison row 3

Trigger

Certificate Policy (CP)

A CP review or update is triggered when the certificate policy claim changes: the policy OID, applicability rules, certificate profile requirements, assurance level, adopted ETSI policy basis, or the subscriber and relying-party community described in the CP.

Certification Practice Statement (CPS)

A CPS review or update is triggered when the TSP changes how it implements the CP: registration procedures, identity validation methods, revocation handling, repository practices, key-management controls, external support arrangements, or any practice relying parties or subscribers depend on.

Operational implication

Distinguish between a policy change (edit CP) and an implementation change (edit CPS); a policy OID change always requires a CP revision.

Comparison row 4

Core obligations

Certificate Policy (CP)

May be a standalone policy document or may be provided as part of the CPS and/or general terms and conditions.

Certification Practice Statement (CPS)

Can reference lower-level operational procedures, while the published CPS can omit confidential internal details not useful to subscribers or relying parties.

Operational implication

Check whether the publication obligation applies to the CP, the CPS, or both; some obligations may be met by publishing a combined CP/CPS document.

Comparison row 5

Evidence

Certificate Policy (CP)

Is identified through documentation for subscribers and relying parties and through certificate policy identifiers that may appear in certificates.

Certification Practice Statement (CPS)

Shows how the CA implements the identified CP, including where subscribers or relying parties can find the practices behind the policy claim.

Operational implication

Cross-reference the CP clause number in the CPS to show that each policy requirement is implemented; auditors verify the CPS against the CP.

Comparison row 6

Timing

Certificate Policy (CP)

Review when the policy basis, certificate profile, policy identifier, applicability, use restrictions, or community requirements change.

Certification Practice Statement (CPS)

Review when operational practices change, including registration, revocation, repository availability, key management, RA delegation, external support, or security controls.

Operational implication

Set separate review calendars for CP and CPS; the CPS may need more frequent updates due to operational changes.

Comparison row 7

Enforcement

Certificate Policy (CP)

A CP must be approved by a management body, assigned a policy administrator, and made available to subscribers and relying parties. EN 319 401 expects approval authority and maintenance responsibilities for each practice statement to be defined and documented.

Certification Practice Statement (CPS)

A CPS must be approved by the TSP management body, published online on a continuous basis, and updated when practices change in ways that may affect subscriber or relying-party acceptance. EN 319 401 requires notice when CPS changes could affect service acceptance.

Operational implication

Confirm that both CP and CPS are approved by the TSP management body and that the CPS references the applicable CP OID.

Comparison row 8

Overlap

Certificate Policy (CP)

Both CP and CPS require version control, management approval, and alignment with the certificate profile, policy identifier, and subscriber-facing obligations. Changes to either can affect certificate suitability assessments and audit evidence boundaries.

Certification Practice Statement (CPS)

Both CP and CPS must remain consistent with each other and with certificate profiles, RA delegation scope, and certificate lifecycle controls. The IETF RFC 3647 framework referenced by EN 319 411-1 structures both documents using a common set of headings.

Operational implication

Treat version control and certificate-profile alignment as shared obligations; maintain a traceability matrix linking CP requirements to CPS procedures.

Comparison row 9

Decision rule

Certificate Policy (CP)

Edit the CP when the certificate policy claim itself changes: the policy OID, the applicability rules, the certificate profile requirements, the assurance level, the use restrictions, or the adopted ETSI policy basis such as LCP, NCP, DVCP, OVCP, IVCP, or EVCP.

Certification Practice Statement (CPS)

Edit the CPS when the CA changes how it implements the CP: registration procedure, identity validation method, revocation handling, repository publication practice, key management control, external support arrangement, management approval process, or any practice that subscribers or relying parties depend on.

Operational implication

Use the policy OID and applicability description as the dividing line: CP owns the policy claim, CPS owns the implementation narrative.

Practical decision rule

How should a CA decide whether to edit the CP or the CPS?

  • Edit the CP when the certificate policy claim changes: policy OID, applicability, certificate profile, assurance level, use restriction, or adopted ETSI policy basis.
  • Edit the CPS when the CA implementation changes: procedure, control, repository practice, validation method, revocation handling, external support arrangement, approval, or publication practice.
  • Review both documents after new certificate profiles, RA delegation changes, CA key lifecycle changes, external support changes, or audit findings that affect either the policy or its implementation.
  • Keep the CP and CPS traceable to each other by version: the CPS should name the CP it implements, and each CP clause should map to a CPS clause or an internal procedure reference.
Search this module

Find a question or answer quickly

3 of 3 questions
Question 1

What is the practical difference between a CP and a CPS?

The CP is the policy layer. It identifies the certificate policy, quality level, profile, applicability, and requirements that apply to a certificate service or certificate community. ETSI EN 319 411-1 notes that a CP can be defined by the TSP, ETSI, a government, customers, or another community, and that it can be standalone or included within practice statements or terms and conditions.

The CPS is the implementation layer. It is owned by the TSP issuing certificates and explains how that TSP operates the service, including the technical, organizational, and procedural practices used to meet the CP. The CPS can point to lower-level operating procedures, but those detailed procedures may remain confidential when they are internal and proprietary.

  • Use the CP to state the certificate policy being followed, including policy identifiers, applicability, certificate profile expectations, and any adopted ETSI policy such as LCP, NCP, NCP+, DVCP, OVCP, IVCP, or EVCP where relevant.
  • Use the CPS to explain how the CA implements the CP through registration, issuance, revocation, repository, key-management, security, and records practices.
  • Keep subscriber and relying-party documentation clear enough to show which CP applies and where the CPS, terms, or disclosure statement explain implementation details.
Citations
Question 2

How should a CA keep CP and CPS evidence aligned?

Start with a traceability map from each applicable CP requirement to the CPS clause, operating record, or confidential procedure that implements it. This is especially important where certificates carry a CP identifier, because relying parties may use that identifier to judge certificate suitability and trustworthiness.

Do not publish sensitive operating details just to prove alignment. ETSI EN 319 411-1 allows low-level operational procedures to remain internal; the public CPS can be limited to information useful for subscribers, subjects, and relying parties, with confidential evidence available for process review.

  • Record the CP identifier, certificate type, target subscribers or subjects, relying-party use, and certificate profile assumptions.
  • Link each CP commitment to the CPS clause that explains the CA practice and to the evidence record that proves the practice operated during the review period.
  • Separate public CPS wording from internal procedures such as access lists, location details, task assignments, HSM handling steps, and audit logs.
Citations
Question 3

When should the CP or CPS be updated?

Update the CP when the policy itself changes: certificate applicability, policy OID, certificate profile requirements, assurance level, adopted ETSI policy basis, or the community rules that subscribers and relying parties rely on. Update the CPS when the CA changes how it implements the policy, such as identity validation processes, revocation handling, repository availability, RA arrangements, CA key controls, or supporting organizations.

ETSI EN 319 401 also expects a management body to approve the practice statement, responsibilities for maintaining it to be defined, and revised practice statements to be made available after approval. If a CPS change may affect acceptance of the service by subjects, subscribers, or relying parties, notice is part of the governance work.

  • Treat CP changes as policy-governance changes that may affect certificate claims, OIDs, subscriber terms, relying-party expectations, and audit scope.
  • Treat CPS changes as operational-governance changes that need approval, version control, publication handling, and evidence that the changed practice is actually in use.
  • Review CP/CPS alignment after new certificate profiles, RA delegation changes, revocation-process changes, CA key lifecycle changes, external support changes, or audit findings.
Citations
Primary sources

References and citations

rfc-editor.org
Referenced sections
  • Referenced by ETSI EN 319 411-1 for certificate policy identifiers and the CP/CPS framework used by certificate authorities.
"Certificate Policy and Certification Practices Framework"
Related guides

Explore more topics

EN 319 411-1 vs EN 319 411-2 Certificate Policy
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 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 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, 24-hour CRL or OCSP publication controls, and audit evidence.
ETSI EN 319 411-1 vs CA/B Forum Baseline Requirements
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?
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.