Executive Order 14412 mandates federal agencies to inventory cryptographic systems by a specific deadline. If you're a contractor, subcontractor, or supplier to the federal government, you're on the same timeline. Even if you're not directly involved, this order indicates a shift in compliance frameworks: post-quantum cryptography (PQC) readiness is moving from theory to an auditable requirement.
The immediate challenge isn't implementing quantum-resistant algorithms; it's knowing what you have. You can't migrate what you haven't mapped.
This template offers a structured inventory format that links cryptographic asset discovery to risk assessment and compliance evidence. Use it to identify where you're using cryptography today, assess exposure to "Harvest Now, Decrypt Later" scenarios, and build a defensible roadmap that auditors will recognize as credible planning.
Purpose of the Template
This inventory documents every instance where your organization uses cryptographic controls to protect data confidentiality, integrity, or authenticity. It maps each cryptographic implementation to:
- The data it protects
- The algorithm and key length in use
- The expected lifespan of that data's sensitivity
- The migration complexity and dependency chain
- The risk if that data were harvested today and decrypted in 10-15 years
You'll use this inventory to answer three questions auditors and executives will ask:
- Where are we vulnerable to quantum decryption threats?
- What's our migration sequence and timeline?
- How does this align with ISO/IEC 27001 Annex A 8.24 (use of cryptography) and SOC 2 CC6.7 (encryption of data at rest and in transit)?
Prerequisites
Before you start filling in the template, you need:
- Asset inventory access: Your CMDB, cloud resource tags, or asset register
- Architecture diagrams: Network topology, data flow maps, and integration points
- Data classification schema: Know which data is public, internal, confidential, or restricted
- Retention policies: Legal hold requirements, regulatory retention periods, and archival timelines
- Vendor documentation: SaaS provider security specs, HSM datasheets, and third-party encryption specifications
If you're working toward ISO/IEC 27001 certification, you already maintain a risk register and asset inventory (Clause 8.2 and 8.3). This template extends that work with cryptographic specificity.
The Template
Create a spreadsheet or database with these columns:
System/Asset Identifier | Cryptographic Function | Algorithm & Key Length | Data Protected | Data Sensitivity Lifespan | Current Standard | PQC Readiness | Migration Complexity | Dependencies | HNDL Risk Score | Target Migration Date | Owner
Column Definitions
System/Asset Identifier: Unique name or ID from your asset register. Examples: "Customer DB Prod", "TLS termination - ALB", "S3 bucket: financial-archives".
Cryptographic Function: What the crypto does. Options: encryption at rest, encryption in transit, digital signatures, key exchange, hashing, certificate issuance.
Algorithm & Key Length: Be specific. "AES-256" or "RSA-2048" or "ECDSA P-256". If you don't know, mark "[AUDIT REQUIRED]".
Data Protected: What information this cryptography secures. Examples: "PII for EU customers", "API authentication tokens", "financial transaction logs 2019-2024".
Data Sensitivity Lifespan: How long this data must remain confidential. If you're protecting trade secrets, the answer might be "15+ years". If it's session tokens, "minutes". This determines your exposure window.
Current Standard: Does this meet FIPS 140-2 validation? Is it a NIST-approved algorithm? Mark "FIPS-Validated", "NIST-approved", or "proprietary/legacy".
PQC Readiness: Current state. Options: "quantum-vulnerable", "hybrid-ready" (supports both classical and PQC), "PQC-native", "unknown".
Migration Complexity: Your judgment call. "Low" (config change), "Medium" (vendor upgrade required), "High" (custom code rewrite), "Critical" (hardware replacement, multi-year project).
Dependencies: What breaks if you change this? Examples: "Mobile app v2.x requires RSA", "Legacy partner API", "Hardware HSM firmware".
HNDL Risk Score: Harvest Now, Decrypt Later risk. Score 1-5 based on sensitivity lifespan and data value. A score of 5 means "high-value data with 10+ year sensitivity using quantum-vulnerable algorithms".
Target Migration Date: Your planned cutover. Align this with EO 14412 timelines if you're in scope, or with your own risk tolerance if you're not.
Owner: Who's accountable for this migration? Name a person, not a team.
Customizing the Template
This template is a starting point. Adapt it to your environment:
If you're a SaaS provider, add a column for "Customer-Managed Keys (CMK) Support" to track where customers control key material and may delay your migration.
If you're subject to GDPR or CCPA, add "Data Subject Geography" to identify cross-border data flows where quantum-safe encryption might affect adequacy decisions.
If you're managing OT or IoT devices, add "Device Lifecycle End Date" because you can't patch a 15-year-old building controller, you plan for replacement.
If you're preparing for ISO/IEC 27001 surveillance audits, map each row to your risk register. Reference the cryptographic asset ID in your risk treatment plan so auditors can trace from control (Annex A 8.24) to implementation to risk mitigation.
For SOC 2 Type II, this inventory becomes evidence for CC6.1 (logical and physical access controls) and CC6.7 (encryption). Your auditor will ask how you determined which data requires encryption and how you validate that encryption remains effective. This template answers both.
Validation Steps
Once you've populated the inventory:
1. Cross-check against your data flow diagrams. Every place data crosses a trust boundary should have a corresponding cryptographic control. If you find unencrypted flows, add them or document the risk acceptance.
2. Validate algorithm details with vendor documentation. Don't assume. Confirm the actual algorithm and key length with the vendor's security white paper or configuration export.
3. Score your HNDL risk consistently. Use a rubric:
- Score 5: Confidential data, 10+ year sensitivity, RSA/ECC/DH
- Score 4: Confidential data, 5-10 year sensitivity, quantum-vulnerable
- Score 3: Internal data, 3-5 year sensitivity
- Score 2: Internal data, <3 year sensitivity
- Score 1: Public data or ephemeral secrets
4. Review migration dates with your architecture team. If three systems share a dependency and you've scheduled them for different quarters, you'll create integration breakage. Sequence migrations in dependency order.
5. Present high-risk items (HNDL score 4-5) to your risk committee. These are candidates for immediate hybrid crypto deployment or accelerated migration, even before your broader PQC roadmap is funded.
6. Schedule quarterly updates. Your cryptographic landscape changes as you deploy new services, onboard vendors, and sunset legacy systems. Treat this inventory like your asset register: it's never "done."
This template won't implement post-quantum algorithms for you. But it will give you the visibility to make informed decisions about where to start, what to prioritize, and how to demonstrate to auditors and executives that you're managing cryptographic risk with the same rigor you apply to access controls and vulnerability management.
