A field-by-field template for separating Certificate Policy commitments from Certification Practice Statement implementation details under ETSI EN 319 411-1.
Use it to draft public-facing certificate-service documentation and the internal evidence map that supports it.
Structured answer sets in this page tree.
Cited legal and guidance references.
ETSI EN 319 411-1 treats the Certificate Policy (CP) and Certification Practice Statement (CPS) as connected but different documents. The CP states what certificate policy, quality, applicability, profile, and rules apply. The CPS states how the Trust Service Provider operates its certificate service to meet those rules. This template helps CA teams draft both documents without mixing public disclosures with confidential operating procedures.
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: Field | Fill with | Evidence. Policy name | LCP, NCP, NCP+, DVCP, OVCP, IVCP, EVCP, or custom policy | approved CP document. Policy OID | object identifier used in certificates | certificate profile and issuance record. Certificate type | natural person, legal person, website, device, or other subject class | certificate profile reference. Intended use | permitted certificate usage and relying-party audience | subscriber terms and PKI disclosure statement.
The CP section should read like a policy promise that subscribers and relying parties can understand. It should not describe 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.
Use this CP table as the core template: Field | Fill with | Evidence. Applicability | who can receive certificates and which applications may rely on them | policy approval record. Certificate profile | X.509 profile requirements and ETSI EN 319 412 part used where appropriate | profile specification. Validation basis | identity or domain validation level and source of attributes | registration evidence. Subscriber obligations | duties before and after acceptance | terms and conditions. Relying-party notice | status-checking and usage limits | PKI disclosure statement.
The CPS section should explain how the TSP implements the CP in its actual organization, facilities, systems, and procedures. EN 319 411-1 notes that lower-level operating procedures may remain internal when they contain private or proprietary detail, so the CPS template should expose enough for subscribers, subjects, relying parties, and auditors without publishing sensitive runbooks.
Use this CPS table for implementation mapping: Field | Fill with | Evidence. Registration service | identity proofing, proof of possession, RA handoff, attribute validation | registration records. Certificate generation | approval checks, profile selection, signing controls | issuance logs. Dissemination | certificate delivery and publication handling | repository records. Revocation management | authorized request intake, decision criteria, subscriber notice | revocation case file. Revocation status service | CRL or OCSP operation and integrity controls | status-service monitoring.
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.
Use this disclosure table: Field | Fill with | Evidence. TSP contact | legal name, location, support, revocation contact | published disclosure. Certificate type and validation | class of certificate and validation procedure | CP/CPS clause. Subscriber obligations | key protection, information accuracy, acceptance, notification duties | subscriber agreement. Relying-party obligations | certificate-status checking and reliance limits | relying-party notice. Audit and trust marks | conformity scheme, audit reference, trusted-list link where applicable | assessment record.
Treat the template as a controlled document set. EN 319 401 expects the practice statement to have management-body approval, defined maintenance responsibilities, a review process, availability to subscribers and relying parties where needed, and notice for changes that may affect service acceptance.
Use this maintenance table: Field | Fill with | Evidence. Owner | policy authority, CPS maintainer, service owner | responsibility matrix. Review trigger | CP profile change, certificate profile change, RA change, revocation process change, CA key change, supplier change, audit finding | change-impact record. Publication | effective date, public URL, redaction rationale | publication log. Traceability | CP clause to CPS clause to evidence artifact | evidence register.
Use this ETSI EN 319 411-1 template to assign policy owners, draft subscriber-facing text, and map each CP/CPS clause to implementation evidence.
Convert CP/CPS template fields into accountable tasks, evidence requests, and review milestones.
Use cited ETSI source material to resolve CP, CPS, disclosure, revocation, and publication questions before implementation.
Review certificate policy scope, CPS wording, disclosure boundaries, and evidence mapping with Sorena.
"final authority for approving"
"defined review process"