Sign in Subscribe
compliance

Mid-Market PQC Readiness Self-Assessment: A Compliance-Mapped Checklist

Mid-market organizations have a specific compliance problem: the regulatory frameworks driving post-quantum cryptography (PQC) migration were written for federal agencies and large financial institutions, but the deadlines apply regardless of organizational size. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024.[NIST] NIST IR 8547 sets 2030 as the federal deprecation target for RSA and elliptic curve cryptography, with a hard disallow date of 2035.[NIST IR 8547] Enterprise migrations historically take three to five years end-to-end. An organization that has not completed a cryptographic inventory today cannot credibly claim it will meet 2030 obligations.

The regulatory pressure is no longer confined to the federal sector. The OCC's July 2025 Semiannual Risk Perspective identifies quantum risk and crypto-agile architecture as supervisory expectations for supervised financial institutions — examiner-facing language that signals audit scrutiny is active, not prospective.[OCC] NIS2 enforcement began in October 2024 for EU essential and important entities.[ENISA] DORA became applicable to EU financial entities in January 2025.[ENISA] This checklist gives mid-market CISOs a structured self-assessment mapped to those specific frameworks, with outputs that constitute regulatory evidence.

Mid-Market Is the Compliance Blind Spot in PQC Migration

Federal agencies and large financial institutions have dedicated resources tracking NIST milestones. Mid-market organizations — those with security teams of five to fifty people, no dedicated cryptography function, and infrastructure spread across legacy on-premises systems and multi-cloud environments — are accumulating compliance debt without a clear diagnostic. Most remain at an awareness or basic inventory stage with no funded migration roadmap as of 2025. The consequence is not abstract: OCC examiners are already asking supervised institutions about crypto-agility plans,[OCC] and NIS2 national competent authorities have enforcement powers that include fines and binding remediation orders.[ENISA]

The gap is structural, not attitudinal. Mid-market teams typically lack a cryptographic bill of materials (CBOM), have no vendor quantum-readiness tracking process, and have not mapped their data sensitivity lifetimes against the NIST IR 8547 deprecation schedule. The self-assessment below is designed to surface exactly those gaps in a format that produces usable compliance artefacts, not just a score.

The Five Maturity Stages: Where Does Your Organisation Actually Stand?

Before engaging with the checklist, locate your organisation honestly on this five-stage ladder. The stages are descriptive, not aspirational.

  • Stage 1 — Unaware: No cryptographic inventory exists. PQC has not been discussed at the security leadership level. No budget has been allocated.
  • Stage 2 — Aware but not inventoried: Leadership is aware of NIST's finalized standards and regulatory timelines, but no formal cryptographic inventory has been completed. No CBOM exists.
  • Stage 3 — Inventoried but not prioritised: A cryptographic inventory exists — at least partially — but systems have not been risk-tiered by data sensitivity lifetime, and no migration roadmap is funded.
  • Stage 4 — Prioritised and planning: High-risk systems are identified, a migration roadmap exists, vendor quantum-readiness assessments are underway, and at least one system is in active transition to FIPS 203, 204, or 205 algorithms.[NIST]
  • Stage 5 — Crypto-agile: The organisation can replace cryptographic algorithms across its estate in a defined, repeatable process. CBOM is maintained in machine-readable form (CycloneDX JSON or equivalent), and PQC migration is embedded in the standard change management lifecycle.

Stages 1 and 2 carry active regulatory exposure. Stages 3 and 4 require acceleration. Stage 5 is the compliance-sustainable state. Most mid-market organisations will honestly score at Stage 2 or Stage 3.

The Compliance-Mapped Checklist: 30 Questions Across Six Control Domains

Answer each question Yes, Partial, or No. A "Partial" answer scores half credit for scoring purposes. Map each finding to the relevant regulatory framework using the annotations provided.

Domain 1: Cryptographic Inventory (Questions 1–6)

  1. Have you completed a full inventory of all asymmetric cryptographic algorithms in use across production systems? [Maps to: NIST IR 8547 baseline requirement; OCC crypto-agility expectation][NIST IR 8547]
  2. Does your inventory include TLS versions and cipher suites in use across all externally facing services?
  3. Does your inventory include certificate key types and expiry dates for all PKI certificates under your management?
  4. Does your inventory include VPN and remote access protocol encryption specifications?
  5. Does your inventory include code-signing and firmware-signing mechanisms?
  6. Is your inventory maintained in a machine-readable format (CSV minimum; CycloneDX JSON preferred)? [Maps to: CISA CBOM guidance][CISA]

Domain 2: Risk Tiering and Data Sensitivity Lifetime (Questions 7–11)

  1. Have you classified each inventoried system by the sensitivity of data it processes or transmits?
  2. Have you estimated the sensitivity lifetime of data protected by each system — the period during which exposure would cause material harm? [This is the key input for harvest-now-decrypt-later risk assessment.]
  3. Have you identified systems whose data sensitivity lifetime extends beyond 2030? These require priority migration. [Maps to: NIST IR 8547 federal deprecation target][NIST IR 8547]
  4. Have you identified systems whose data sensitivity lifetime extends beyond 2035? These represent hard-deadline exposure. [Maps to: NIST IR 8547 disallow date]
  5. Have you documented this risk tier mapping in a formal PQC risk register entry?

Domain 3: Vendor and Supply Chain Readiness (Questions 12–16)

  1. Have you issued quantum-readiness questionnaires to all Tier 1 technology vendors?
  2. Have you received documented PQC migration roadmaps from critical software and hardware vendors?
  3. Have you identified which vendor components — TLS libraries, HSMs, PKI infrastructure — will require replacement or upgrade to support FIPS 203, 204, or 205?[NIST]
  4. Do your cloud service provider contracts include commitments to PQC-ready service delivery timelines?
  5. Have you verified whether your HSM vendor has published a PQC firmware roadmap and whether existing hardware will support new algorithm parameter sets?

Domain 4: Policy and Governance (Questions 17–21)

  1. Does your cryptographic policy reference FIPS 203, 204, and 205 as approved algorithms for new systems? [Maps to: NIST standards; NSA CNSA 2.0 preference by 2025 for NSS environments][NSA CNSA 2.0]
  2. Does your cryptographic policy specify a sunset date for RSA and ECC in new deployments?
  3. Has PQC migration been added to your board or senior management risk reporting?
  4. Is there a named owner responsible for PQC migration programme delivery?
  5. For EU entities: does your governance framework address NIS2 Article 21 technical measures and DORA ICT risk management requirements as they relate to cryptographic controls?[ENISA]

Domain 5: Technical Migration Planning (Questions 22–26)

  1. Have you identified which systems will adopt hybrid classical/PQC key exchange as a transition mechanism?
  2. Do you have a tested plan to deploy ML-KEM (FIPS 203) for key encapsulation on your highest-risk systems?[NIST FIPS 203]
  3. Do you have a tested plan to deploy ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) for digital signatures on code-signing and authentication systems?[NIST FIPS 204]
  4. Have you assessed crypto-agility in your existing systems — specifically whether algorithms can be replaced without redesigning the application?
  5. Have you tested PQC algorithm performance impacts on latency-sensitive or resource-constrained systems (IoT, embedded devices, high-throughput services)?

Domain 6: Regulatory Documentation (Questions 27–30)

  1. For OCC-supervised institutions: have you documented your PQC migration planning in a form that could be presented to examiners?[OCC]
  2. For NIS2-scoped entities: have you mapped PQC migration progress to your NIS2 incident and risk reporting obligations?[ENISA]
  3. For DORA-scoped entities: is PQC migration represented in your ICT risk management framework documentation?
  4. Do you maintain a log of vendor quantum-readiness responses, updated at least annually?

Scoring Your Results and Prioritising Remediation

Assign 1 point for Yes, 0.5 for Partial, and 0 for No. Maximum score: 30 points.

  • 0–10 (Stage 1–2): Active compliance exposure. Prioritise Domain 1 (cryptographic inventory) immediately. Without inventory data, no other domain can be addressed credibly.
  • 11–18 (Stage 2–3): Inventory exists but risk tiering and vendor readiness are incomplete. Prioritise Domain 2 (risk tiering) and Domain 3 (vendor readiness) in parallel. Systems with data sensitivity lifetimes extending beyond 2030 require funded migration plans now, given the three-to-five year migration horizon.
  • 19–24 (Stage 3–4): Planning is underway but governance and documentation gaps create regulatory exposure. Prioritise Domains 4 and 6 to convert operational progress into auditable evidence.
  • 25–30 (Stage 4–5): The focus shifts to sustainment — maintaining the CBOM, integrating PQC into the SDLC, and tracking the evolving regulatory readiness benchmarks as NIST IR 8547 milestones approach.

Remediation sequencing should be driven by two factors: regulatory deadline proximity and data sensitivity lifetime. A system processing long-lived sensitive data that falls under OCC examination or NIS2 scope takes precedence over a lower-sensitivity system with no imminent audit exposure. NSA CNSA 2.0 mandates PQC as the exclusive algorithm suite for National Security Systems by 2033,[NSA CNSA 2.0] which sets the outer boundary for any defense-adjacent supply chain participant.

Compliance Artefacts Your Assessment Should Produce

A checklist exercise that produces only a score has limited compliance value. The assessment should generate four concrete artefacts:

  1. CBOM (Cryptographic Bill of Materials): A structured inventory of all cryptographic dependencies, maintained in CycloneDX JSON or equivalent machine-readable format. This satisfies CISA guidance and provides the foundational input for every subsequent compliance conversation.[CISA]
  2. PQC risk register entries: Formal entries for each high-risk system, documenting current algorithm, data sensitivity classification, estimated sensitivity lifetime, applicable regulatory deadline, and assigned remediation owner.
  3. Executive summary aligned to regulatory milestones: A one-page document mapping your organisation's current maturity stage against NIST IR 8547 deprecation dates, OCC supervisory expectations, and NIS2/DORA obligations. This is the board-level reporting artefact.[NIST IR 8547]
  4. Vendor quantum-readiness log: A dated record of all vendor questionnaires issued, responses received, and follow-up actions. This log demonstrates due diligence in supply chain risk management — an explicit expectation under both DORA and NIS2.

Self-assessment scores create a record. Before sharing results beyond the security team, apply the following discipline:

  • Internal reporting: Frame results as a gap analysis against specific regulatory requirements, not as a pass/fail compliance determination. "We have completed 60% of the cryptographic inventory required to satisfy NIST IR 8547 baseline expectations" is more defensible than "we are partially compliant."
  • Regulator-facing disclosure: Do not voluntarily submit self-assessment scores to regulators unless specifically requested. If an OCC examiner asks about PQC planning, present the risk register entries and migration roadmap — structured evidence of action, not a maturity score that an examiner may interpret differently than intended.
  • Third-party and contractual disclosure: Treat CBOM contents with the same sensitivity as a network diagram. Vendor quantum-readiness logs may be shared with vendors to drive accountability, but should not be disclosed to parties with no need-to-know.
  • Board reporting: The executive summary artefact described above is appropriate for board-level reporting. It should describe the regulatory landscape factually, present the organisation's current maturity stage honestly, and specify the funded actions and owners responsible for remediation. Avoid language that characterises the organisation as non-compliant without legal review, as the compliance status of PQC obligations varies by framework, sector, and jurisdiction.

Security architects broadly recommend separating the technical assessment (the checklist and CBOM) from the compliance determination (which requires legal and regulatory input) when preparing any externally facing communication.

This Week: Run a 60-Minute Cryptographic Inventory Sprint

The single highest-value action available to a mid-market CISO this week is a structured, time-boxed inventory sprint on the three systems most likely to carry data with sensitivity lifetimes beyond 2030. For each system, document: the algorithms currently in use (TLS version and cipher suite, certificate key type, VPN protocol, code-signing mechanism), the data sensitivity classification, the estimated data sensitivity lifetime, and the nearest applicable regulatory deadline. Record results in a spreadsheet with those five columns. This exercise will locate your organisation on the maturity scale and generate the foundational input for every subsequent checklist item, vendor conversation, and risk register entry. Reference NIST IR 8547 as the deprecation timeline anchor when assigning deadline columns.

Key Takeaways

  • NIST finalized FIPS 203, 204, and 205 in August 2024. NIST IR 8547 sets 2030 as the federal RSA/ECC deprecation target and 2035 as the hard disallow date — mid-market organisations are subject to these timelines regardless of size.
  • The OCC's July 2025 Semiannual Risk Perspective identifies crypto-agile architecture as a supervisory expectation for supervised financial institutions. NIS2 enforcement and DORA applicability are already active for EU entities.
  • A 30-question, six-domain checklist covering cryptographic inventory, risk tiering, vendor readiness, policy, technical planning, and regulatory documentation provides the structure needed to convert awareness into auditable evidence.
  • Scoring below 11 out of 30 indicates active compliance exposure. Priority action is completing Domain 1 (cryptographic inventory) before addressing any other domain.
  • The minimum compliance artefacts from this exercise are: a machine-readable CBOM, PQC risk register entries, a regulator-aligned executive summary, and a vendor quantum-readiness log.
  • Self-assessment scores should be kept internal until reviewed by legal counsel. Regulator-facing communications should present structured evidence of action, not maturity scores.

On this site:

Primary sources:

This article draws on primary documentation from NIST (FIPS 203, FIPS 204, FIPS 205, NIST IR 8547), the OCC Semiannual Risk Perspective (July 2025), NSA CNSA 2.0, CISA's Post-Quantum Cryptography Initiative, and ENISA NIS2 implementation guidance. All claims verified against official sources as of April 2026.

Disclaimer: This content is for informational purposes only and does not constitute legal, regulatory, or compliance advice. Consult a qualified professional before making compliance decisions. pqcinformation.com is independent and not affiliated with any vendor or standards body.

Read next