PKIaaS Governance Framework: Roles, Policies, Audit Logs, and Certificate Profiles

Most organizations that deploy PKIaaS treat it as an infrastructure decision, not a governance decision. They pick a CA provider, configure a root hierarchy, stand up an ACME endpoint, and call it done. Six months later, the security team runs a certificate inventory scan and finds 300 certificates issued with wildcard SANs, 50 expired certificates from a decommissioned environment that nobody revoked, and no audit trail showing who requested any of them. The PKI is functional. The governance is absent.

PKI governance is not about adding bureaucracy to certificate issuance. It is about making the PKI program auditable, defensible, and manageable as the certificate estate grows. A PKI governance framework defines who owns the CA hierarchy, who can change the certificate profiles, who audits issuance events, how naming policy is enforced, what documentation exists to support compliance audits, and how the program improves over time. This post builds that framework, layer by layer, in terms that enterprise PKI program owners, compliance leads, and infrastructure architects can use directly.

Quick Answer: What Is a PKIaaS Governance Framework?

A PKIaaS governance framework is the operating model that makes certificate authority infrastructure auditable and compliant. It has five components: the organizational structure (who owns the CA hierarchy and what roles handle issuance, administration, and audit); the policy documentation (Certificate Policy and Certification Practice Statement); the technical controls (certificate profiles, SAN allowlists, enrollment workflow configurations); the audit trail (comprehensive logs of every certificate event across all enrollment channels); and the improvement process (regular reviews, maturity assessment, and policy-as-code change management). Together these components produce a PKI program that can survive a SOC 2 audit, a WebTrust assessment, or a regulatory examination without scrambling to reconstruct records that should have been maintained all along.

Key Takeaways

• PKI governance is distinct from PKI infrastructure. Infrastructure decisions (CA provider, HSM model, enrollment protocol) are one-time choices. Governance decisions (who owns the CA, what the certificate policy says, how audit logs are retained) recur continuously and determine whether the PKI program is auditable, compliant, and improvable over time.
• Role separation is the structural foundation of PKI governance. The person who defines certificate profiles must not be the same person who issues certificates under those profiles. The person who issues certificates must not be the same person who reviews the audit log of those issuances. These separations are not procedural suggestions; they are the structural controls that compliance frameworks verify during PKI audits.
• A Certificate Policy (CP) and Certification Practice Statement (CPS) are required for any PKI program subject to external audit. The CP defines what is required; the CPS describes how the PKIaaS CA implements those requirements. Without these documents, the PKI program cannot be audited, and the organization cannot demonstrate compliance to auditors, regulators, or relying parties.
• Certificate profiles are the technical enforcement of certificate policy. A well-designed profile set makes it technically impossible to issue a certificate that violates the policy, regardless of which enrollment interface the requester uses. Profiles are more reliable than policy documents alone because they enforce constraints at the CA rather than relying on requester compliance.
• Policy-as-code is the mature implementation of PKI governance change management. Certificate profile definitions, SAN allowlists, and role assignments stored in version-controlled repositories and deployed through a reviewed CI/CD pipeline produce the change management audit trail that compliance frameworks require, without generating paper-based approval workflows that are difficult to maintain at scale.

Layer 1: Organizational Structure and Role Ownership

The PKIaaS governance framework begins with people, not technology. Who owns the CA hierarchy? Who can change it? Who cannot? Most PKI governance failures trace back to an ownership gap: the CA was deployed by someone who left the organization, no successor was named, and the CA configuration has not been reviewed in two years. Formal role assignment eliminates this gap.

CA Owner (PKI Program Lead)

The CA Owner holds overall accountability for the PKI program. This individual is responsible for: the CA hierarchy design and the Certificate Policy that governs it; approving changes to certificate profiles and SAN allowlists; reviewing and publishing the CPS; managing the change control process for CA configuration; ensuring that role assignments are current and that the joiner/mover/leaver process includes certificate-related access; and presenting the PKI program’s governance posture to auditors, legal counsel, and executive stakeholders.

The CA Owner must not be the Certificate Administrator who handles routine issuance. Combining these roles in one person eliminates the separation between policy definition and policy execution that compliance frameworks require. In practice, the CA Owner is typically the PKI Architect, the CISO, or the Head of Security Engineering, depending on the organization’s security function structure.

Certificate Administrator

Certificate Administrators issue, renew, and revoke certificates within the profiles and SAN allowlists that the CA Owner has configured. For automated enrollment paths (ACME, SCEP, MDM, WSTEP), the Certificate Administrator role is held functionally by the service accounts or API credentials that the enrollment automation uses. For manual enrollment paths (eForm approval workflows, CSR-based issuance for external partners), named individuals hold the Certificate Administrator role and review requests before approving issuance.

Certificate Administrators cannot modify profiles, SAN allowlists, CA configuration, or role assignments. They can issue certificates that conform to the configured policy; they cannot change what the policy permits. This constraint is enforced by the PKIaaS CA’s role-based access control, not by policy alone.

CA Auditor

The CA Auditor has read-only access to all certificate issuance records, enrollment workflow events, and audit logs across all enrollment channels and CA partitions. The Auditor cannot issue certificates, cannot revoke certificates, and cannot modify any CA configuration. The Auditor role is independent: it should be held by someone in the security operations team, the compliance team, or an external auditor, not by anyone with Certificate Administrator or CA Administrator access.

The independence of the CA Auditor role is the property that makes the audit trail meaningful. An audit log that the issuing team can modify is not an audit log; it is a record of what the issuing team chose to record. The CA Auditor role, configured in the PKIaaS CA and enforced by the CA’s access control model, ensures that the audit trail is visible to an independent observer who cannot be prevented from seeing it by anyone with operational access.

Enrollment Workflow Administrators and Auditors

Enrollment Workflow Administrators configure the automated enrollment workflows (ACME endpoints, SCEP profiles, MDM integrations, WSTEP agents) that platform teams and device management systems use to obtain certificates. They do not have direct certificate issuance authority; they configure the automation paths through which issuance happens. Separating Enrollment Workflow Administration from CA Administration means the team that builds the automation integration cannot modify the profiles or allowlists that govern what the automation can request.

Enrollment Workflow Auditors have read-only access to enrollment workflow event logs, providing per-channel audit visibility for teams that need to monitor specific enrollment automation without broader CA access.

All role assignments should be managed through the organization’s identity provider (Entra ID, Okta, or equivalent) rather than through local PKIaaS user accounts. IdP-managed assignments produce a role assignment audit trail in the IdP’s access log, are governed by the organization’s joiner/mover/leaver process, and are visible to the IAM team alongside all other access assignments.

Layer 2: Certificate Policy and Certification Practice Statement

The Certificate Policy (CP) and Certification Practice Statement (CPS) are the governance documents that make the PKI program auditable to external parties. Without them, an auditor looking at the PKI program has no document to compare actual practice against; they cannot determine whether the program is operating as intended because there is no stated intention to compare against.

What the Certificate Policy Contains

The Certificate Policy is a requirements document, not an implementation document. It states what must be true about certificates issued by the PKIaaS CA for each certificate type the organization issues. A well-structured CP for an enterprise PKIaaS deployment addresses:

• Certificate types and their purposes: Each named certificate type (internal service TLS, user authentication, S/MIME, smart card logon, code signing, device identity) is defined with its intended use cases, the relying parties that will trust it, and the requirements for issuance (who can request, how identity is verified, what approval is required);
• Key algorithm requirements: Minimum key sizes and algorithms for each certificate type, aligned to current NIST guidance (RSA-2048 minimum currently; RSA-3072 or ECDSA P-256 preferred for new issuance; PQC algorithm migration roadmap referenced);
• Certificate validity periods: Maximum validity periods for each certificate type, with rationale (shorter validity for high-privilege types like smart card logon and code signing; longer for infrastructure certificates where automated renewal is guaranteed);
• Subscriber obligations: What certificate holders must do (protect the private key, report key compromise promptly, use the certificate only for its specified purpose, request revocation when the certificate is no longer needed);
• Revocation requirements: When certificates must be revoked (key compromise, subscriber departure, end of use case, CA compromise) and the maximum time from revocation decision to CRL/OCSP update.

What the CPS Contains

The Certification Practice Statement describes how the PKIaaS CA implements the requirements stated in the CP. The CPS is the implementation document that auditors review to confirm that the CA’s practices match the CP’s requirements. Key sections include:

• CA hierarchy description: The structure of the root CA, intermediate CAs, and issuing CAs; their key algorithms, validity periods, and HSM protection model (FIPS 140-2 Level 3 or FIPS 140-3 certified HSMs for CA signing keys);
• Enrollment procedures: How each certificate type is requested, how the requester’s identity and authorization is verified, what approval is required before issuance, and which enrollment protocol is used;
• Certificate profile specification: The technical parameters of each certificate profile (key algorithm, EKU OIDs, SAN types, validity period, subject field rules), showing how each profile implements the CP’s certificate type definition;
• Audit log description: What events are logged, what fields are recorded per event, how logs are protected from tampering, how logs are retained, and who has access;
• Change management process: How changes to certificate profiles, SAN allowlists, CA configuration, and role assignments are proposed, reviewed, approved, and deployed;
• Key ceremony procedures: How CA key pairs are generated, how M-of-N split key custody is implemented, how the root CA is kept offline, and how key ceremony records are maintained.

For PKIaaS deployments, the PKIaaS provider maintains a CPS for the shared CA platform infrastructure (HSM management, physical security, availability SLAs). The customer must maintain a CPS section covering the certificate profiles and policies they configure, the enrollment procedures they implement, and the organizational controls (role assignments, change management, subscriber agreements) they operate.

Layer 3: Certificate Profiles and SAN Allowlists

Certificate profiles and SAN allowlists are the technical controls that make the CP’s requirements self-enforcing at the CA. A CP that says “code signing certificates require a minimum RSA-4096 key” and a profile that enforces this constraint produce a CA that technically cannot issue a code signing certificate with an RSA-2048 key, regardless of what the requester specifies. This is more reliable than a policy document that relies on requesters reading and following the policy.

Certificate Profile Governance

Each certificate profile in the PKIaaS CA should map to exactly one certificate type definition in the CP. The profile’s technical constraints should implement the CP’s requirements for that certificate type. The profile set for a mature PKIaaS deployment typically includes the following named categories, each with specific constraints:

• Internal service TLS: ECDSA P-256 or RSA-2048, 90-day maximum validity, TLS Server Auth EKU (OID 1.3.6.1.5.5.7.3.1), DNS SAN only, CN must be a fully qualified domain name;
• mTLS client identity: ECDSA P-256, 24 to 48 hour validity, TLS Client Auth EKU (OID 1.3.6.1.5.5.7.3.2), URI SAN (SPIFFE ID format) or DNS SAN, no private key export permitted;
• User VPN and 802.1X authentication: ECDSA P-256 or RSA-2048, 1-year maximum validity, TLS Client Auth EKU, UPN SAN populated from IdP at enrollment time;
• S/MIME: RSA-2048 or ECDSA P-256, 2-year maximum validity, Email Protection EKU (OID 1.3.6.1.5.5.7.3.4), RFC 822 Name SAN (email address), no key export if stored in hardware;
• Smart card logon: RSA-2048 minimum, 1 to 3 year validity, Smart Card Logon EKU (OID 1.3.6.1.4.1.311.20.2.2) and TLS Client Auth EKU, UPN SAN, hardware key storage required, eForm manual approval workflow;
• Code signing: RSA-4096 or ECDSA P-384, 1 to 4 hour validity for pipeline certificates or 1 year for organizational code signing certificates, Code Signing EKU (OID 1.3.6.1.5.7.3.3), hardware key storage required for organizational certificates, eForm manual approval workflow.

Profile changes require CA Administrator approval and must go through the change management process described in the CPS. The change management record (pull request in the policy-as-code repository, or formal change approval record) constitutes the audit evidence that the profile change was authorized.

SAN Allowlist Governance

SAN allowlists enforce naming policy at the CA layer. The allowlist governance process defines how new names are added to the allowlist, how names are removed when services are decommissioned, and how cross-team naming conflicts are resolved.

A mature SAN allowlist governance process includes:

• Name ownership registry: A record mapping each allowed SAN pattern to the team that owns it, the approver who authorized it, and the date it was added. This registry is the audit trail for name authorization decisions;
• Addition process: New SAN patterns require approval from the CA Administrator and from the team that owns the domain or namespace the pattern falls within. The approval is documented in the name ownership registry;
• Removal process: When a service is decommissioned or a team’s domain changes, the corresponding SAN pattern should be removed from the allowlist to prevent future issuance under that pattern. The removal is documented in the registry with the decommission date;
• Conflict resolution: When two teams request overlapping SAN patterns, the CA Administrator resolves the conflict based on domain ownership records (DNS registrar records, internal naming convention documentation) and documents the resolution.

Layer 4: Audit Logs and Evidence Collection

The audit log is the primary evidence source for PKI compliance assessments. An auditor reviewing the PKI program will ask for records of specific events: which certificates were issued during the audit period, who requested them, what profile was used, whether the request went through a manual approval workflow, and what the approval decision was. If the PKIaaS audit log does not record all of these fields for all enrollment channels, the audit cannot be completed satisfactorily.

What the Audit Log Must Record

For each certificate event (issuance, renewal, revocation, administrative action), the audit log should record at minimum:

• Event type: Certificate issued, certificate renewed, certificate revoked, profile created, profile modified, role assignment changed, CA configuration changed, enrollment workflow created or modified;
• Certificate identity: The serial number of the affected certificate, the subject DN, all SAN values, the certificate profile used, the issuing CA, and the certificate’s validity period;
• Requesting identity: For automated enrollment, the ACME account identifier, the SCEP challenge identifier, the MDM enrollment credential, or the API credential used; for manual enrollment, the name and role of the approving Certificate Administrator;
• Timestamp: The UTC timestamp of the event, at sufficient precision to reconstruct the sequence of events within a short time window;
• Approval decision: For requests that went through a manual approval workflow, the approver’s identity, the timestamp of the approval decision, and any notes the approver recorded.

Log Protection and Retention

Audit logs must be protected against tampering and retained for the applicable compliance period. The requirements vary by framework:

• SOC 2: The SOC 2 Trust Service Criteria do not specify a minimum log retention period, but typical SOC 2 audit periods cover 6 to 12 months, and auditors expect logs to be available for the full audit period. Retaining PKI audit logs for at least 12 months is the standard baseline;
• WebTrust for CAs: WebTrust requires that CA audit events be retained and available for review by the WebTrust auditor. The CA’s CPS should specify the retention period; 7 years is a common CPS-stated retention period for CA audit records in WebTrust-audited programs;
• FedRAMP and FISMA: NIST SP 800-53 requires audit log retention aligned to the system’s security categorization; typically 3 years for moderate-impact systems;
• DORA (Digital Operational Resilience Act): DORA requires ICT-related incident logging and record-keeping; the PKI audit log is part of this scope for financial entities and their ICT providers in the EU.

Log protection requires exporting PKIaaS audit logs to a SIEM or tamper-evident log archive that is separate from the PKIaaS platform. A log that exists only within the PKIaaS management console is not independently tamper-evident and may not be available if the PKIaaS account is compromised or misconfigured. Exporting to a separate log archive ensures that the audit record is preserved independently of the PKIaaS platform’s availability and access control.

Building the Evidence Package for Auditors

A PKI compliance audit requires more than just the audit log. The evidence package typically includes:

• CP and CPS documents: Current versions with publication dates and version numbers, plus prior versions covering the audit period if the CP/CPS was updated during the period;
• Role assignment evidence: Screenshots or exports from the IdP showing the current role assignments (CA Owner, Certificate Administrators, CA Auditors), with the assignment history showing who held each role during the audit period;
• HSM certification evidence: The FIPS 140-2 Level 3 or FIPS 140-3 validation certificate for the HSM model used to protect CA signing keys, or the PKIaaS provider’s evidence that the platform uses validated HSMs;
• CA certificate chain: The complete certificate chain from root CA to issuing CA, showing the key algorithms, validity periods, and subject information for each CA certificate;
• Certificate profile configurations: The current profile configurations exported from the PKIaaS management interface or the policy-as-code repository, showing the technical parameters of each defined profile;
• Change management records: The change log for all CA configuration changes during the audit period, showing the change description, the requester, the reviewer, the approval decision, and the implementation timestamp;
• Audit log samples: Samples of issuance, renewal, revocation, and administrative event log records demonstrating that the required fields are captured for each event type.

Layer 5: Policy-as-Code and Change Management

The most operationally mature PKI governance programs manage certificate profiles, SAN allowlists, role assignments, and enrollment workflow configurations as version-controlled code rather than as manual console configurations. Policy-as-code produces governance artifacts that are otherwise difficult to generate: a complete history of every configuration change, the identity of the reviewer who approved each change, and the ability to retrieve the exact configuration that was in effect on any past date.

The policy-as-code architecture for PKIaaS governance works as follows:

• Profile definitions in version control: Certificate profile configurations are stored as JSON or YAML files in a version-controlled repository. The repository is the authoritative source for what the PKIaaS CA should be configured to enforce. Changes to profile configurations are proposed as pull requests, reviewed by the CA Administrator (and, for significant changes, the CA Owner), and merged only after approval;
• Automated deployment via PKIaaS REST API: A CI/CD pipeline monitors the repository for merged changes and deploys approved configurations to the PKIaaS CA through the management REST API. The deployment is logged in the CI/CD pipeline’s audit log, which records the commit hash, the deploying service account, and the deployment timestamp;
• Drift detection as a continuous compliance check: A scheduled job compares the live PKIaaS CA configuration against the repository’s expected configuration. Any divergence (a profile modified outside the IaC process, a role assigned without a corresponding repository change) is flagged as an alert to the CA Owner and the CA Auditor;
• Branch protection and required reviews: The repository’s main branch is protected so that direct commits are not permitted; all changes must go through a pull request with at least one required reviewer. The repository’s pull request history is the change management audit trail that auditors review.

PKI Governance Maturity Model

PKI governance maturity describes how systematically and consistently an organization applies the governance framework described above. The four maturity levels provide a common language for enterprise PKI maturity assessments and for planning the roadmap from current state to target state.

Level 1: Informal. The PKI program has no documented Certificate Policy or CPS. Certificate profiles exist but are applied inconsistently; some certificate requests receive custom parameters not reflected in any defined profile. Audit logs exist within the PKIaaS console but are not exported or retained beyond the default retention period. Role assignments are informal; the same person who issues certificates also administers the CA configuration. There is no formal change management process for CA configuration changes.

Level 2: Defined. The PKI program has a documented CP and CPS, published to the relevant stakeholders (IT security team, legal, compliance). Certificate profiles are defined for each certificate category and applied consistently through the PKIaaS CA’s profile enforcement. Roles are formally assigned, though the CA Owner and Certificate Administrator roles may still be held by overlapping individuals. Audit logs are exported to a SIEM but reviewed only reactively (in response to incidents, not proactively). Change management is documented but applied inconsistently.

Level 3: Managed. The governance framework is fully implemented: CP and CPS are current and reviewed annually, certificate profiles are governed and version-controlled, role separation is enforced through the IdP with no overlaps, audit logs are exported with configured retention and reviewed proactively by the CA Auditor on a defined cadence, and change management is consistently applied with a complete change log. CLM monitoring provides continuous visibility into the certificate estate’s compliance with the defined profiles. The program has been assessed against at least one external compliance framework (SOC 2, WebTrust, FedRAMP, or industry-specific).

Level 4: Continuously Improving. The program operates at Level 3 and additionally: certificate profiles and the CP/CPS are reviewed on a defined cadence aligned to NIST, CA/B Forum, and ETSI algorithm requirement updates; policy-as-code change management is fully implemented with drift detection; a cryptographic inventory (CBOM) is maintained continuously and feeds the annual algorithm policy review; the program has a defined PQC migration roadmap with measurable progress metrics; and governance maturity is assessed annually with a published gap analysis and improvement roadmap.

How Encryption Consulting Can Help

• PKI Services (CP/CPS Development): Encryption Consulting’s PKI Services include Certificate Policy and Certification Practice Statement development for enterprise PKIaaS deployments. The CP/CPS documents the certificate types, key algorithm requirements, validity periods, enrollment procedures, audit log practices, and change management processes required by SOC 2, WebTrust, FedRAMP, DORA, NIS2, and other compliance frameworks. Encryption Consulting has developed CP/CPS documentation for PKI programs ranging from single-organization internal CAs to multi-CA hierarchies with hundreds of thousands of active certificates. Contact us at Encryption Consulting.
• PKI as a Service: Encryption Consulting’s PKIaaS offering provides the governed CA infrastructure that the governance framework operates on top of: certificate profiles with the full constraint set described in this post (key algorithms, EKU OIDs, maximum validity, SAN types), role-based access control (CA Owner/Administrator, Certificate Administrator, CA Auditor, Enrollment Workflow Administrator, Enrollment Workflow Auditor), SAN allowlist management, audit log export with per-enrollment-channel event capture, and REST API access for policy-as-code deployment of profile and configuration changes.
• CertSecure Manager: Encryption Consulting’s CertSecure Manager provides the CLM visibility layer that the Level 3 and Level 4 governance model requires: continuous certificate inventory across all PKIaaS-issued certificates, profile compliance monitoring (flagging certificates that violate current profile constraints, indicating profile drift or legacy certificates from before governance controls were implemented), expiry monitoring with configurable alert routing, SIEM integration for audit log export and event correlation, and compliance reporting dashboards for the quarterly and annual governance reviews.
• PKI Assessment Service: For organizations assessing their current PKI governance maturity or preparing for a compliance audit, Encryption Consulting’s PKI Assessment Service evaluates the current state against the four maturity levels, identifies governance gaps in the CP/CPS documentation, role separation, profile configurations, audit log coverage, and change management practices, and produces a prioritized remediation roadmap. The assessment report can be used directly as evidence in compliance audit preparations.
• Compliance Advisory Services: For organizations subject to DORA, NIS2, FedRAMP, CMMC, HIPAA, PCI DSS, or other frameworks with specific PKI governance requirements, Encryption Consulting’s Compliance Advisory Services map the PKIaaS governance framework to each applicable compliance standard’s specific requirements for certificate policy documentation, audit log retention, role separation evidence, key protection standards, and change management records, and produce the compliance evidence package ready for regulatory examination.
• CBOM Secure: For organizations at Level 4 maturity that maintain a continuous cryptographic inventory as part of their governance program, Encryption Consulting’s CBOM Secure provides the automated cryptographic discovery and CBOM generation that feeds the annual algorithm policy review, identifies certificates from unregistered issuers (indicating ungoverned PKI activity outside the governance framework), and surfaces algorithm compliance gaps before the NIST IR 8547 deprecation deadlines require emergency action.

Conclusion

PKI governance is not a compliance checkbox. It is the operating model that makes a PKI program trustworthy, auditable, and improvable over time. The six layers described in this post (organizational structure, policy documentation, certificate profiles, SAN allowlists, audit log evidence, and policy-as-code change management) address the governance gaps that produce the outcomes organizations actually face in PKI programs: certificates that nobody owns, profiles that nobody enforces, audit trails that nobody reviews, and compliance assessments that cannot be completed because the required documentation does not exist.

The maturity model gives PKI program owners a common language for assessing where their program is and what the next step looks like. Most organizations that discover their PKI governance gaps discover them during a compliance audit or after a certificate-related incident, at which point the remediation is urgent and disruptive. Applying the governance framework proactively, even at Level 2 (defined policies and consistent profiles), provides the foundation for reaching Level 3 through incremental improvement rather than emergency remediation.

If your organization is assessing its PKI governance maturity or preparing for a compliance audit that includes PKI program review, reach out to Encryption Consulting.

This post is reviewed on a six-month cadence and when CA/B Forum Baseline Requirements, NIST SP 800-57, WebTrust for CA criteria, or major compliance frameworks publish updates that affect PKI governance documentation or audit evidence requirements.

Frequently Asked Questions

What is the difference between a Certificate Policy and a Certification Practice Statement?

A Certificate Policy (CP) defines what is required: the rules that certificates must meet to serve a specific purpose. A Certification Practice Statement (CPS) describes how the CA implements those requirements in practice. The CP answers “what must be true?”; the CPS answers “how do we make it true?” For PKIaaS deployments, the provider maintains a CPS for the shared platform infrastructure; the customer must maintain a CPS for the certificate profiles, enrollment procedures, and organizational controls they configure on top of the platform.

What roles are required in a PKIaaS governance model and what are their responsibilities?

Five roles are required: the CA Owner (defines policy, approves profile changes, must not routinely issue certificates); the Certificate Administrator (issues within defined profiles, cannot modify profiles); the CA Auditor (read-only access to all issuance records and audit logs, independent of the operational team); the Enrollment Workflow Administrator (configures automated enrollment paths, no direct issuance authority); and the Enrollment Workflow Auditor (read-only access to enrollment event logs). No individual should hold both the CA Administrator and CA Auditor roles, as this eliminates the independent review the audit trail is meant to provide.

What evidence does a PKI audit require and how does PKIaaS provide it?

A PKI compliance audit requires: the CP and CPS documents; audit logs of all certificate events (issuance, renewal, revocation) with requester identity, timestamp, profile used, and approval decision; role separation evidence from the IdP; HSM FIPS certification evidence; the CA certificate chain; profile configuration exports; and change management records for all CA configuration changes during the audit period. PKIaaS provides the audit log, HSM key protection, and CA hierarchy. The customer must produce the CP/CPS, role assignment evidence, and change management records.

What is PKI maturity and how is it assessed?

PKI maturity describes how systematically a PKI program applies governance controls. Level 1 (Informal) has ad hoc processes, no CP/CPS, inconsistent profiles, and no formal audit trail. Level 2 (Defined) has documented policies and consistent profiles but inconsistent application. Level 3 (Managed) has fully implemented controls, active CLM monitoring, and at least one external compliance assessment. Level 4 (Continuously Improving) adds policy-as-code change management, continuous CBOM, annual algorithm policy reviews, and a PQC migration roadmap. Assessment compares current controls against each level’s requirements.

How does policy-as-code work for PKI governance and what are its benefits?

Policy-as-code stores certificate profile definitions, SAN allowlists, and role assignments as version-controlled files. Changes go through pull request review before being deployed to the PKIaaS CA via REST API. Benefits: every change has a documented reviewer and approval timestamp (the pull request); the configuration at any past date is retrievable from version history; a drift detection job compares live configuration to expected configuration and alerts on unauthorized changes; and the pull request history is the change management record auditors need, without a separate paper-based process.