PKI Audit Checklist: The Certificate and Key Evidence Auditors Actually Ask For
A PKI audit verifies conformance — can you prove your certificate and key management matches your stated controls — whereas a PKI assessment methodology measures maturity. Auditors don't score you on the PKIMM; they ask for artefacts. This page lists the artefacts, maps them to SOC 2, PCI DSS 4.0, DORA, NIS2, HIPAA and FedRAMP, and gives the 90-day preparation sequence that avoids producing evidence in the week before fieldwork.
AxelSpire's position: Most PKI audit findings are not control failures. They are evidence failures — the control exists, informally, in one person's head, and nothing written or logged proves it operated during the audit period. Fixing evidence is cheaper than fixing controls, and it is almost always what the finding actually requires.
Part of: PKI Assessment Guidelines. The assessment scorecard's Governance and Management modules generate most of the evidence below as a by-product — run the assessment first and audit prep becomes an export, not a project.
The evidence checklist
Organised by what the request will say, not by framework. Evidence must cover the audit period, not the audit date — a dashboard screenshot from last week doesn't evidence a control for the trailing twelve months.
Governance artefacts
| Evidence | What "good" looks like | Common failure |
|---|---|---|
| Certificate Policy / CPS | Current version, review date within cycle, approver named | Last reviewed three CA migrations ago |
| PKI ownership & RACI | Named owner, documented split across security/infra/DevOps | "The team" owns it — i.e. nobody does |
| Certificate issuance policy | Approved key algorithms, sizes, validity caps, SAN rules | Policy exists; no enforcement mechanism referenced |
| Exception register | Time-boxed exceptions with owners and expiry | Permanent "temporary" exceptions |
Key management artefacts
| Evidence | What "good" looks like | Common failure |
|---|---|---|
| Root/intermediate key storage | HSM or cloud-KMS attestation (FIPS 140-2/140-3 level stated) | Private CA keys in software on the CA server |
| Key ceremony records | Scripted, witnessed, signed ceremony log per root/intermediate | Root created years ago by a person who has left; no record |
| Key recovery test | Dated evidence a backup was restored and used | Backups exist, restore never exercised |
| Rotation schedule | Documented lifetimes for CA keys with next-rotation dates | No schedule; rotation triggered only by expiry panic |
Operations artefacts
| Evidence | What "good" looks like | Common failure |
|---|---|---|
| Certificate inventory | Reconciled, cross-CA, with ownership per certificate | Per-CA console exports that disagree with each other — the cross-CA inventory problem |
| Expiry monitoring & alerting | Alert config + a fired-alert example + the ticket it produced | Alerting configured; no evidence it ever fired or was actioned |
| Revocation capability | Documented CRL/OCSP SLAs + a test or real revocation event within period | Revocation never exercised; OCSP responder health unmonitored |
| Access control to CA functions | Role list, joiner/leaver evidence, privileged-access review | Shared admin credentials on the CA |
| Incident records | Post-mortems for certificate-caused incidents with actions closed | Outages happened; nothing written down |
Framework mapping: where certificates and keys appear
Framework-specific emphasis, so the same evidence pack can be indexed per audit. Requirement references are the certificate/key-relevant anchors, not exhaustive control lists — confirm scope with your auditor.
| Framework | Where PKI lives | What gets probed hardest |
|---|---|---|
| SOC 2 (Security TSC) | CC6.1/CC6.6-adjacent logical access and encryption controls | Key storage, access to issuance functions, evidence monitoring operated all period |
| PCI DSS 4.0 | Req. 3.6–3.7 (key management lifecycle), 4.2 (strong cryptography in transit), 12.3.3 (cryptographic inventory) | Documented key lifecycle, and — since 4.0 — the cryptographic inventory requirement, which most organisations cannot produce without the cross-CA work |
| DORA (EU financial entities) | ICT risk management (Art. 9) and the RTS on ICT risk, encryption & cryptographic controls | Cryptographic policy, key management procedures, and crypto-agility expectations — regulator-facing, not just auditor-facing |
| NIS2 (EU essential/important entities) | Art. 21(2) cryptography and encryption measures | Policy on cryptography use plus evidence of implementation; national transpositions vary in prescriptiveness |
| HIPAA Security Rule | Transmission security & encryption (addressable) | Risk-analysis trail justifying certificate/TLS decisions |
| FedRAMP / NIST 800-53 | SC-12/SC-13/SC-17 (key establishment, cryptographic protection, PKI certificates) | Formal certificate policy and CA operation evidence at Moderate/High |
Two 2026-specific probes appearing in fieldwork with increasing frequency: validity-period posture (auditors reading SC-081v3 headlines now ask how the estate handles 200-day maximums — scope the answer precisely: it binds publicly trusted TLS only) and PQC planning (DORA's crypto-agility framing and PCI's cryptographic inventory both give auditors a hook to ask for an algorithm inventory — which is the estate analytics output, and feeds the PQC readiness assessment).
The findings that recur
From AxelSpire's assessment and remediation work, the same findings appear regardless of framework, in roughly this frequency order:
- No demonstrable certificate inventory. The finding is rarely "no inventory"; it is "management could not evidence completeness of the certificate population" — an auditor-proof phrasing of the same gap.
- Untested key recovery. Backup procedures documented, restore never performed. One catastrophic failure mode, zero visibility until it fires.
- Monitoring without operation evidence. Alerts configured; no fired-alert-to-ticket trail across the period.
- Shared or stale privileged access to CA functions. Leavers with issuance rights; break-glass accounts without review.
- Policy/practice divergence. The CPS says 90-day internal certificates; the estate contains five-year ones. The inventory exposes this — which is why organisations without one often feel more compliant than they are.
These findings are the audit-facing expression of a maturity gap: they cluster in the same Operations and Management categories where enterprises score lowest. The peer distributions behind that pattern are in AxelSpire's PKI maturity benchmarks.
The 90-day audit-prep sequence
Assumes fieldwork in ~90 days; compresses if the assessment has already been run.
Days 1–14 — Baseline. Run the discovery + reconciliation pass (Sprint 1 of the assessment). Produce the cross-CA inventory and the ownership map. This single artefact retires the most common finding and feeds half the checklist.
Days 15–40 — Evidence sweep. Walk the three tables above; for each row mark have / have-but-stale / missing. Refresh stale governance documents (CPS review, RACI sign-off). Schedule the two exercisable controls that need dated evidence: a key-recovery test and a revocation test.
Days 41–70 — Close the operational gaps. Fired-alert trail: if no genuine alert fired in period, generate a controlled test alert and ticket it. Privileged-access review on CA functions with leaver reconciliation. Time-box or close every exception in the register.
Days 71–90 — Assemble and index. One evidence pack, indexed per framework using the mapping table. Write the one-page narrative per module (auditors read narratives; they sample evidence). Brief the three people who will sit interviews — divergent answers between interviewees generate follow-up requests.
FAQ
What is the difference between a PKI audit and a PKI assessment?
An audit verifies conformance against a framework and demands evidence; an assessment measures maturity against a model like the PKIMM and produces an improvement roadmap. Run the assessment first: its Governance and Management evidence collection produces most of the audit pack as a by-product.
What PKI evidence does SOC 2 require?
SOC 2 has no PKI-specific control list; certificates and keys surface under logical access and encryption criteria. In practice auditors ask for key storage attestation, access control to issuance functions, expiry monitoring with operation evidence, and an inventory demonstrating population completeness.
Does PCI DSS 4.0 require a certificate inventory?
PCI DSS 4.0 requires an inventory of cryptographic cipher suites and protocols in use (12.3.3) and full key lifecycle management (3.6–3.7). Evidencing either at estate scale without a reconciled cross-CA certificate inventory is, in AxelSpire's experience, not realistic.
What do DORA and NIS2 mean for certificate management?
DORA's ICT risk framework and its technical standards make cryptographic controls and key management regulator-inspectable for EU financial entities, with explicit crypto-agility expectations; NIS2 Art. 21 requires policies on cryptography with evidence of implementation for essential and important entities. Both convert PKI from an internal control into a supervisory topic.
How long does PKI audit preparation take?
Around 90 days from a standing start, dominated by inventory reconciliation and the two exercisable tests (key recovery, revocation) that need dated in-period evidence. With a maintained inventory and a prior assessment, preparation compresses to an indexing exercise of two to three weeks.
Dan Cvrcek, AxelSpire. Based on assessment and audit-remediation engagements. Updated July 2026.