# Enterprise Cryptographic Exposure & Control Readiness Checklist

GC Solutions LLC — Independent Cryptographic Assurance & Security Advisory  
Evidence before assumptions. Confidence before change.  
Version: October 19, 2026 · https://gcsolutions.us.com

## How to use this working resource

Review the questions with the accountable technical, risk and operating owners. For each question, record **Evidenced**, **Partially evidenced**, **Unknown**, or **Not applicable with rationale**. Record the evidence reference, review date, owner and next action. Keep your completed copy inside an approved private workspace; never place credentials, private keys, recovery shares, card data or customer evidence into a public website.

A count of positive answers is not a compliance or maturity score. Missing evidence is not proof of a failing control, and it is not a passing assessment either. This educational checklist does not replace a professional assessment, a PCI DSS assessor determination, certification, legal advice or production change approval.

## 1. Business scope & ownership

- Can you name the business services that rely on cryptography?
- Is there an accountable owner for each system and key domain?
- Are assessment boundaries, permitted evidence and exclusions agreed?
- Are business impact, data retention and recovery needs documented?

**Evidence to consider:** service catalog, responsibility matrix, approved scope statement, business continuity requirements.  
**Next decision:** Which service or trust boundary needs independent review first?

## 2. Inventory & evidence quality

- Are algorithms, purposes, platform versions and dependencies inventoried?
- Can each material assertion be traced to a source and review date?
- Are advertised, supported, enabled and observed-used capabilities separated?
- Are missing, stale or conflicting records labeled as unresolved?

**Evidence to consider:** permitted metadata inventory, provenance register, architecture documents, version-specific vendor documentation.  
**Next decision:** Which assumptions need evidence before they can support a migration or investment?

## 3. HSM & key lifecycle controls

- Are access rights and separation of duties reviewed?
- Are dual control and split knowledge verified for the actual procedure?
- Are generation, import, rotation and retirement documented?
- Is recovery evidence current, with tested owners and authorization paths?

**Evidence to consider:** access reviews, approved ceremony records, key lifecycle policies, recovery-exercise results. Do not copy key material into this checklist.  
**Next decision:** Do ordinary, exceptional and recovery paths have demonstrable operating controls?

## 4. Payment & tokenization boundaries

- Are sensitive-data and token flows mapped across applications and APIs?
- Are detokenization privileges and exception paths explicit?
- Have logs, backups and downstream copies been considered?
- Are PCI DSS scope assumptions distinguished from assessor determinations?

**Evidence to consider:** data-flow diagrams, detokenization access matrix, segmentation evidence, application and reporting boundaries.  
**Next decision:** Can a supposedly token-only system retrieve or affect the protection of sensitive data?

Tokenization does not automatically eliminate PCI DSS obligations or place systems outside assessment scope. The implementation, applicable standard and relevant assessment authority determine scope.

## 5. Post-quantum & crypto-agility

- Are quantum-vulnerable public-key dependencies identified?
- Are target algorithms matched to key-establishment or signature purpose?
- Are vendor capability claims tied to exact-version evidence?
- Does prioritization include validation, change windows and rollback?

**Evidence to consider:** cryptographic inventory, dependency map, capability evidence, compatibility test plans and migration prerequisites.  
**Next decision:** Which dependency needs validation before its target-state migration can be scheduled?

NIST FIPS 203 specifies ML-KEM for key establishment; FIPS 204 specifies ML-DSA signatures; FIPS 205 specifies SLH-DSA signatures. Algorithm recognition does not prove module validation or end-to-end compatibility.

## 6. Governance & executive decisions

- Does every material finding have an owner and a next action?
- Are limitations and residual risks visible in executive reporting?
- Are remediation plans separate from production authorization?
- Can leadership explain why each investment or change is prioritized?

**Evidence to consider:** risk register, findings and evidence matrix, change governance, executive briefing and ownership assignments.  
**Next decision:** What can leadership approve now, and what remains conditional on evidence?

## Working record template

For each question, copy this record into your private working document:

**Question:**  
**State and rationale:**  
**Evidence reference / source:**  
**Evidence date and limitation:**  
**Accountable owner:**  
**Business consequence:**  
**Next action / decision / target date:**

Do not fill this record with secret values, customer records or privileged system configuration.

## When to request independent review

Consider a scoped discussion when the review identifies unclear key custody, an untested recovery path, detokenization privileges crossing a trust boundary, unsupported vendor readiness claims, or a migration decision without an evidence-backed rationale. Describe the business question first; secure evidence exchange is agreed separately.

Contact: marquez.greenhill@gcsolutionsllc.co  
Website: https://gcsolutions.us.com/contact

## References

[NIST approval of FIPS 203, 204 and 205](https://csrc.nist.gov/news/2024/postquantum-cryptography-fips-approved)

[PCI SSC supplementary Tokenization Guidelines](https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf)

These publications inform the questions; they do not supersede applicable current standards or an assessor’s determination.