A cipher suite inventory template for PCI DSS 12.3.3 (and why yours is already stale)
All articlesIf you searched for a cipher suite inventory template, you probably have a QSA waiting on one. Here is a template that satisfies what assessors look for under PCI DSS 12.3.3, followed by the honest part: why the template is the easy 10 percent of the job.
The template
One row per cipher suite or protocol, with these columns:
| Column | What goes in it | Example |
|---|---|---|
| Algorithm / suite | The exact suite or algorithm name | TLS_AES_128_GCM_SHA256 |
| Protocol and version | Where it is negotiated | TLS 1.3 |
| Location | System, service, or endpoint using it | api.example.com load balancer |
| Purpose | What it protects | Cardholder data in transit, client to edge |
| Data classification | What flows under it | PAN, authentication data |
| Owner | Team accountable for the config | Platform engineering |
| Source of truth | Where the setting lives | terraform/modules/alb/tls.tf |
| Quantum exposure | Vulnerable, hybrid, or post-quantum | Vulnerable (classical ECDHE) |
| Last verified | Date this row was confirmed against reality | 2026-10-24 |
The last two columns are not in most templates. Add them anyway. Quantum exposure answers the part of 12.3.3 that requires monitoring industry trends and planning for algorithm change, and a per-row verification date turns the annual review from an assertion into evidence.
Keys and certificates belong in a parallel table for requirement 4.2.1.1: certificate or key identifier, issuer, algorithm, expiry, location, and what transmission path it protects.
Why your filled-in template is already stale
The template fails in a predictable way. Someone spends a week filling it from code searches, config reads, and interviews. The document is accurate for roughly a day. Then a dependency upgrade changes a default, a new service ships, a certificate rotates, and the inventory quietly diverges from reality. Next year's assessment starts with the same week of excavation, and in between, the one document that is supposed to tell you your cryptographic posture tells you last year's.
The failure is not discipline. It is that hand-maintained inventories of machine state always diverge. The fix is the same one the industry applied to software dependencies: generate the inventory from the systems, in a machine-readable format, and regenerate it on demand. For cryptography that format now exists, the CycloneDX 1.6 CBOM.
Generate it instead
We ship a free scanner that walks your code and configuration and emits the inventory as a CycloneDX 1.6 CBOM, each finding classified, including its quantum exposure, with a terminal summary you can read in a minute. It runs entirely inside your environment; nothing is uploaded. Regenerating next quarter is one command, and the diff is your change history.
When the assessment needs a document a QSA can rely on, we turn your scanner output plus a short guided questionnaire, which covers what no scanner can see, like key custody and HSM usage, into a signed report mapped to 12.3.3 and 4.2.1.1. Scanned findings and attested answers are labeled distinctly, scope is stated on the face of the report, and the signature verifies offline with our open-source verifier, so the evidence does not depend on trusting anyone.
Free scanner at scrutari.ai/pci. Signed report, $990, delivered within one business day of complete inputs.