Purpose of the Template
You can't protect what you can't see. When your QSA asks where all your cryptographic keys are, or when an expired certificate brings down your payment gateway at 2 a.m., you'll wish you had built this inventory months ago.
This template provides a structured spreadsheet to track every certificate and private key in your cardholder data environment. It's designed for PCI DSS Requirement 3.6.4 compliance (key custodian documentation) and Requirement 4.2 (certificate management for transmission security). It's also useful for incident response, rotation planning, and preventing outages caused by expired certificates.
Building a certificate and key inventory is one of the most valuable steps your security team can take. This template gets you started.
Prerequisites
Before you populate this inventory:
Identify your scope boundaries. Determine which systems store, process, or transmit cardholder data. Your inventory should cover every system in that environment, plus any system that terminates TLS connections carrying Primary Account Numbers.
Establish access controls. This spreadsheet will contain sensitive data about your cryptographic material. Store it in a restricted directory with Role-Based Access Control. Only key custodians and security personnel should have read access.
Define your key custodians. PCI DSS requires documentation of who has access to cryptographic keys. Decide who owns each certificate domain (payment gateway team, web operations, API platform) and who can authorize changes.
Gather your scanning tools. You'll need network discovery to find certificates on servers, plus access to your HSM documentation, cloud KMS consoles, and any certificate management platforms you use.
Template Structure
Create a spreadsheet with these columns:
Certificate/Key Identifier, A unique reference you assign (CERT-001, GATEWAY-TLS-01, etc.).
Type, TLS/SSL certificate, code signing certificate, Key Encryption Key, Data Encryption Key, root CA, intermediate CA, or private key.
Subject/Common Name, For certificates, the CN field; for keys, a descriptive label.
Location, Server hostname, HSM slot identifier, cloud KMS resource name, or file path.
Owner/Custodian, Name and team of the person responsible for this asset.
Access Level, Who can read/use this material (application service account, operations team, specific individuals).
Purpose, What this protects (payment gateway TLS, cardholder data at rest, API authentication, etc.).
Issuer, For certificates, who signed it; for keys, how it was generated.
Issue Date, When the certificate was issued or the key was created.
Expiration Date, When it expires (leave blank for keys that don't expire).
Days Until Expiration, Formula: =EXPIRATION_DATE - TODAY().
Key Length/Algorithm, RSA 2048, RSA 4096, ECDSA P-256, AES-256, etc.
Storage Method, HSM (specify FIPS 140-3 level), cloud KMS, encrypted file, TPM, software keystore.
Rotation Schedule, Every 90 days, annually, on compromise, etc.
Last Rotated, Date of last key rotation or certificate renewal.
Compliance Scope, PCI DSS CDE, PCI DSS SAQ A-EP, out of scope, etc.
Backup Location, Where encrypted backups of this material are stored.
Revocation Tested, Date you last verified you can revoke this certificate.
Notes, Dependencies, special handling requirements, vendor contacts.
Customizing the Template
Add environment tags if you manage multiple cardholder data environments. A "Production/Staging/Development" column helps track which certificates protect live payment flows versus test systems.
Include renewal workflow status if your team struggles with certificate expiration. Add columns for "Renewal Requested," "Approval Status," and "Deployed" to track certificate progress.
Link to monitoring by adding a column for your monitoring tool's check ID. If you use Nagios, Prometheus, or a commercial certificate monitor, record which alert corresponds to each certificate.
Track Multi-Factor Authentication requirements for key access. If certain keys require MFA to retrieve, document that in an "Access Controls" column.
Document your Key Encryption Key hierarchy. If you use KEKs to wrap Data Encryption Keys, add a "Wrapped By" column that references the KEK identifier.
Add compliance checkboxes for your specific requirements. If you need to verify that every certificate uses SHA-256 or stronger, or that no RSA key is shorter than 2048 bits, add validation columns with formulas that flag violations.
Validation Steps
Run a discovery scan and compare results to your inventory. Use openssl s_client against every HTTPS endpoint in your CDE. Check your HSM audit logs for undocumented key material.
Test your expiration alerts. Pick a certificate that expires in 45 days and verify that your monitoring system warns you. If you don't have monitoring, use your inventory's "Days Until Expiration" column as a manual check.
Verify custodian accuracy. Send each key custodian their assigned rows and ask them to confirm they still own those assets and know how to rotate them.
Validate your rotation schedule by checking "Last Rotated" dates. Any key overdue for rotation is a finding waiting to happen during your next audit.
Confirm backup recoverability. Pick one backed-up key and attempt to restore it in a test environment. If you can't restore it, your backup location documentation is incomplete or your backup process is broken.
Check for orphaned certificates. Any certificate in your inventory without a corresponding server or application should be revoked.
Cross-reference with your firewall rules. Every certificate that terminates external TLS connections should have a corresponding firewall rule. If you find a certificate without a rule, you've either documented something that isn't deployed or discovered an undocumented connection path.
Update this inventory every time you provision a new certificate, rotate a key, or decommission a system. An inventory that's six months out of date is worse than no inventory at all, as it gives you false confidence about what you're protecting.
