Audit, evidence, and compliance package
Trust Architecture Playbook: Governance pillar
Evidence records
Evidence is the difference between a claim and a control. A mature governance program does not merely say that certificate issuance was authorized; it can prove the profile, requester, approver, CA source, certificate, deployment target, owner, validation result, and exception status. DigiCert® Trust Lifecycle Manager audit logs provide the event backbone for this evidence model, but governance must define retention, correlation, export, and review obligations. A complete evidence model captures the following:
Profile approval: profile owner, policy owner, CA source, business unit, enrollment/authentication method, and approved constraints.
Request approval: requester, service owner, namespace/domain proof, approval path, and business justification.
Issuance event: timestamp, requester identity, profile, CA source, serial number, SANs, EKUs, validity, and key parameters.
Deployment target: endpoint, service, platform, environment, connector/agent/sensor/pipeline, and install location.
Validation result: live endpoint presentation, chain, SAN match, health check, or platform-specific validation evidence.
Owner and metadata: certificate owner, business unit, application/service, criticality, exposure, platform, trust domain, and tags.
Lifecycle actions: renewal, rekey, reissue, revoke, suspend, resume, recover, or retire, with approver and reason.
Exception or break-glass: risk acceptance, compensating controls, expiry date, retirement plan, and closure evidence.
Evidence pack checklist
The following checklist organizes evidence by audit category, with the minimum artifacts each category should include.
Evidence category | Minimum artifacts |
|---|---|
Policy and profile | Approved policy, approved profile, profile version/change record, CA source approval. |
Identity and authorization | Requester identity, approver identity, delegated authority, business-unit scope, service user/ACME account scope. |
Certificate identity | Subject, SANs, issuer, serial, validity, EKUs, algorithm/key size, trust domain. |
Deployment and validation | Deployment target, installed location, live presentation, chain validation, application/service health evidence. |
Monitoring and notification | Owner notification, alert routing, CT finding where public, renewal/deployment monitoring status. |
Exception/risk | Exception approval, compensating controls, review date, closure or extension decision. |
Incident linkage | Incident ticket, timeline, root cause, corrective actions, follow-up governance changes. |
Example evidence pack
Evidence packs should be small enough to assemble consistently and complete enough to prove the control chain. The following example is a practical minimum for a high-impact renewal event.
Evidence element | Example artifact |
|---|---|
Lifecycle event | Tier 1 public TLS renewal for customer portal. |
Policy and profile | Approved Public TLS - production web - ACME profile, profile version, CA-source approval, and business-unit mapping. |
Identity and authorization | ACME/service user scope, domain authorization, delegated approval record, and certificate owner assignment. |
Certificate identity | Issuer, serial number, subject, SANs, EKUs, validity period, algorithm, and key size. |
Deployment and validation | Deployment target, listener binding, live endpoint TLS presentation, chain validation, SAN validation, and service health check. |
Monitoring and notification | Owner notification, CT reconciliation, renewal alert status, and deployment-success record. |
Exception/risk | No open exception; if present, link to exception ID, compensating controls, and review date. |
Closure evidence | Change ticket closed, Trust Lifecycle Manager audit events retained, and post-renewal dashboard status green. |
What a mature program can answer
For any certificate, profile, CA source, business unit, trust domain, or automation identity, a mature PKI governance program can answer:
Who owns it and who is accountable for risk?
What policy allowed it and which profile enforced that policy?
Which CA issued it and why that CA was approved for the use case?
Which identity requested or renewed it and under what authorization?
Where is it deployed and what relying systems trust it?
Was it deployed successfully or merely issued?
What evidence proves approval, issuance, deployment, validation, and monitoring?
What exception or break-glass path was used, if any?
How quickly can it be replaced if the key, algorithm, CA, profile, or relying-party trust changes?