A Certificate Policy (CP) sets the rules a PKI must follow, and a Certification Practice Statement (CPS) explains exactly how the certificate authority meets those rules in daily operation. Most audit findings come from gaps between these documents and what the team really does, so a CP/CPS that passes audit is specific, current and matched to real operations.
CP vs CPS in one minute
- The CP is the “what”. The policy authority sets it. It says which certificates may be issued, to whom and under which rules. Each CP is identified by an object identifier (OID).
- The CPS is the “how”. The CA operator writes it. It describes the actual procedures, systems and controls.
Smaller PKIs often combine both in one CP/CPS document. That is fine, as long as it is clear which parts are rules and which parts are practices.
The structure auditors expect (RFC 3647)
RFC 3647, published in November 2003, is the standard framework for a CP and a CPS. It has nine sections:
- Introduction
- Publication and repository responsibilities
- Identification and authentication
- Certificate life-cycle operational requirements
- Facility, management and operational controls
- Technical security controls
- Certificate, CRL and OCSP profiles
- Compliance audit and other assessments
- Other business and legal matters
Keep the RFC 3647 numbering exactly. Auditors and root programs map their checklists to it. For publicly trusted TLS CAs, the CA/Browser Forum TLS Baseline Requirements require the CP and/or CPS to be structured according to RFC 3647 and to include all the material it requires.
Which rules apply to you?
- Publicly trusted TLS CA: the TLS Baseline Requirements, each browser root program’s policy, and WebTrust or ETSI audits.
- EU qualified trust service: eIDAS and ETSI EN 319 411-1 and EN 319 411-2. Our checklist for becoming a QTSP under eIDAS 2.0 walks through that route.
- Private enterprise PKI: your own policy. Internal audit, ISO/IEC 27001 auditors and customers may still read it, and our PKI consulting and compliance advisory covers certificate policies, practice statements and audit preparation.
10 common gaps (and how to fix them)
1. Template text that does not match reality
The CPS describes a process, system or role the organization does not actually have.
Fix: walk through each section with the people who run the CA, and change either the text or the practice.
2. Missing or empty sections
Publicly trusted CAs must include all the material RFC 3647 requires (Baseline Requirements section 2.2). A blank heading looks like an oversight.
Fix: fill every section. Where nothing applies, say so plainly instead of leaving it empty.
3. Not reviewed every year
The Baseline Requirements require a publicly trusted CA to update its CP and/or CPS at least once every 366 days. It must show this by incrementing the version number and adding a dated changelog entry, even if nothing else changed (sections 2.2 and 2.3).
Fix: put the review date in your compliance calendar.
4. Vague identity and domain validation
Auditors want to see exactly which validation methods you use. For TLS, that means naming the specific methods from Baseline Requirements section 3.2.2.4.
Fix: list each method you use and remove any you do not.
5. CAA handling not described
The Baseline Requirements say a CA’s CAA record processing must be described in section 4.2 of its CP and/or CPS, including the issuer domain names it recognizes in CAA records.
Fix: add the exact domain names and your processing rules.
6. Revocation promises the team cannot keep
The Baseline Requirements set revocation deadlines of 24 hours or 5 days, depending on the reason (section 4.9.1.1). They also require clear instructions for reporting suspected key compromise or misuse, published online and in section 1.5.2 of the CPS.
Fix: publish a working problem-reporting contact, and test the revocation process out of hours.
7. Thin key management and ceremony detail
Section 6 says “keys are protected in an HSM” but not how keys are generated, backed up, activated and destroyed, or who must be present.
Fix: describe key ceremonies, roles and multi-person control, and keep signed ceremony records.
8. Certificate profiles that do not match issued certificates
Section 7 says one thing, but real certificates show different extensions, lifetimes or key sizes. Since 15 March 2025, the Baseline Requirements have required publicly trusted CAs to lint certificate content before issuance (section 4.3.1.2).
Fix: run issued certificates through a linter such as zlint or pkilint and compare the results with section 7. If you run DictaLabs CA, which supports multiple certificate profiles and tailored security policies, check each configured profile against what section 7 says.
9. Audit section too general
RFC 3647 section 8 covers how often assessments happen, who the assessor is and what qualifications they hold, their relationship to the CA, the topics covered and what happens after a deficiency.
Fix: match the section to the audit scheme and contract you actually have.
10. Legal section out of step with agreements
Section 9 (liability, warranties, privacy) contradicts the subscriber agreement or the relying party agreement.
Fix: have your legal team review all three documents together.
A pre-audit checklist
Run through this list a few weeks before the auditors see your CP/CPS documentation, so there is still time to fix what it finds.
- Every RFC 3647 section is present and filled.
- Version number, date and changelog are up to date.
- Each process in the CPS has evidence: logs, tickets or ceremony records.
- Sample issued certificates match section 7.
- Contacts, URLs, CRL and OCSP addresses all work.
- Legal documents agree with section 9.
How DictaLabs helps
Our CP/CPS development and audit readiness service develops Certificate Policies and Certification Practice Statements aligned with RFC 3647, eIDAS requirements, the CA/Browser Forum Baseline Requirements and industry and regulatory expectations. The documentation is written to be auditor-ready, implementable and consistent with real operations.
The same service covers pre-audit gap analysis, evidence preparation, technical and procedural clarifications, and remediation planning and implementation support.
Next step
If an audit is coming up, contact us to discuss a pre-audit gap analysis of your CP/CPS and the evidence behind it.
