Governance bodies, policy hierarchy, and decision rights
Trust Architecture Playbook: Governance pillar
PKI governance board
The PKI governance board owns the cross-functional decisions that individual platform teams should not make alone. It should include PKI/security, identity, cloud/platform, infrastructure, application/service ownership, compliance/GRC, and audit representation. Legal and privacy should be consulted when certificates affect external commitments, regulated data, user identity, employee certificates, partner connectivity, or public trust obligations.
Approve trust-domain registry entries and changes.
Approve new CA sources, root/intermediate CAs, cross-certification, and CA decommissioning.
Approve profile standards, profile exceptions, naming rules, and key protection requirements.
Approve delegation models, enterprise RA scope, and business-unit boundaries.
Review exceptions, audit findings, crypto-agility readiness, CA distrust exposure, and unresolved governance risks.
Escalate risk acceptance when controls cannot be met within the approved tolerance.
Policy authority role
The PKI governance board may exercise policy authority directly, or charter a delegated sub-body to do so. Policy authority owns Certificate Policy (CP) and Certification Practice Statement (CPS) alignment, certificate type standards, CA issuance constraints, relying-party statements, and evidence obligations — the documentation and standards layer that the governance board's decisions operationalize. RFC 3647 provides the standard framework for organizing CP and CPS content, including the policy topics that a PKI participant or relying community should consider.
Policy library
A PKI governance program should maintain a small, deliberate policy library. The point is not to create more documents. The point is to map authoritative decisions to enforceable controls. Every policy artifact should have an owner, review cadence, approval authority, and control mapping.
Enterprise PKI policy: Defines scope, authority, trust domains, obligations, and exception model.
Certificate Policy / Certification Practice Statement: Defines certificate classes, identity proofing, issuance practices, CA operations, audit expectations, and relying-party context.
Certificate profile standard: Defines allowed algorithms, key sizes, EKUs, SAN rules, validity, renewal windows, CA sources, and enrollment methods.
Key management standard: Defines key generation, storage, escrow/recovery, protection, rotation, compromise response, and destruction requirements aligned to NIST key management guidance.
Access and delegation standard: Defines roles, service users, business units, approval scope, separation of duties (SoD), and access reviews.
Audit and evidence standard: Defines retention, SIEM/log export, evidence packaging, and review obligations.
Exception and risk acceptance standard: Defines qualification criteria, approval authority, compensating controls, maximum term, and retirement expectations.
CP/CPS alignment
The CP/CPS is where the enterprise declares what a certificate means and how the issuing ecosystem operates. For public-trust CAs, the CA maintains CP/CPS documents aligned to Web PKI requirements. For internal private PKI, the enterprise may need its own CP/CPS or equivalent internal policy standard, particularly when certificates authenticate high-risk systems, users, devices, or regulated workloads.
Governance should avoid two extremes: treating every private certificate as if it required a full public CA audit package, and treating private PKI as exempt from policy documentation. The right level depends on reliance, blast radius, identity sensitivity, and regulatory context. At minimum, every private trust domain should have a documented purpose, relying-party population, issuing authority, validation process, certificate profile constraints, revocation posture, key protection requirement, and lifecycle evidence model.
DigiCert publishes CP/CPS documents, including the Private PKI CP/CPS, in the DigiCert Legal Repository. If your organization needs custom internal policy documentation for DigiCert® Private CA, ensure it does not conflict with DigiCert's CP/CPS.
Note
DigiCert offers services to help with developing custom CA policy documentation. Contact your account representative with questions or to discuss whether a custom policy is appropriate for your organization.
Decision-rights matrix
Decision | Accountable owner | Required evidence | Review cadence |
|---|---|---|---|
Create a new trust domain | PKI governance board | Use case, relying-party population, CA source, risk tier, policy owner, evidence model | As needed; annual validation |
Approve new issuing CA source | PKI governance board / central PKI | CA source registry entry, due diligence, connector pattern, chain/revocation behavior, exit plan | Before onboarding; quarterly operational review; annual formal re-approval |
Create or materially change profile | Policy authority / profile owner | Profile intake form, approved use case, CA source, BU, enrollment/authentication method, crypto settings | Before change; quarterly catalog review |
Delegate RA authority | Policy authority | Named delegate, namespace/population, profile scope, expiry, access mapping | Quarterly for Tier 0/1; semiannual otherwise |
Approve Tier 0/1 exception | PKI governance board | Risk rationale, compensating controls, expiry date, retirement plan | At approval and before expiry |
Decommission a CA source | PKI governance board / central PKI | CA source registry update, impact assessment, migration plan, evidence retention plan | As needed; tracked to completion |
Retire a profile | Policy authority / profile owner / platform owner | Impact assessment, migration plan, evidence retention plan | As needed; tracked to completion |