| Scope | States what requirements and applicability rules are adhered to for the certificate policy, including certificate quality, profile, and intended use. | States how the CA operates its service to meet those policy requirements, including implementation practices for issuing, managing, revoking, renewing, or re-keying certificates. | 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. |
|---|
| Covered actors | Can be defined by the TSP, ETSI, governments, subscribers, users of certification services, or another community that sets common rules. | Is developed, implemented, enforced, updated, and owned by the TSP issuing certificates. | Determine whether the document is addressed to external parties (CP) or internal operators (CPS) to decide who must approve and maintain it. |
|---|
| Trigger | 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. | 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. | Distinguish between a policy change (edit CP) and an implementation change (edit CPS); a policy OID change always requires a CP revision. |
|---|
| Core obligations | May be a standalone policy document or may be provided as part of the CPS and/or general terms and conditions. | Can reference lower-level operational procedures, while the published CPS can omit confidential internal details not useful to subscribers or relying parties. | 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. |
|---|
| Evidence | Is identified through documentation for subscribers and relying parties and through certificate policy identifiers that may appear in certificates. | Shows how the CA implements the identified CP, including where subscribers or relying parties can find the practices behind the policy claim. | Cross-reference the CP clause number in the CPS to show that each policy requirement is implemented; auditors verify the CPS against the CP. |
|---|
| Timing | Review when the policy basis, certificate profile, policy identifier, applicability, use restrictions, or community requirements change. | Review when operational practices change, including registration, revocation, repository availability, key management, RA delegation, external support, or security controls. | Set separate review calendars for CP and CPS; the CPS may need more frequent updates due to operational changes. |
|---|
| Enforcement | 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. | 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. | Confirm that both CP and CPS are approved by the TSP management body and that the CPS references the applicable CP OID. |
|---|
| Overlap | 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. | 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. | Treat version control and certificate-profile alignment as shared obligations; maintain a traceability matrix linking CP requirements to CPS procedures. |
|---|
| Decision rule | 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. | 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. | Use the policy OID and applicability description as the dividing line: CP owns the policy claim, CPS owns the implementation narrative. |
|---|