The Agentic Post-Quantum Conversion Standards Mapping

How the discipline composes existing standards rather than competing with them. Each engine sits atop, and unifies, a body of established practice.

• Document: APQC-STANDARDS-009 — Standards Mapping
• Status: Draft 0.1
• Version: 0.1
• Date: 2026-07-02
• Editor / Authoring body: H33.ai, Inc.

APQC does not replace NIST, Zero Trust, IAM, audit practice, or compliance frameworks. It composes them. This document maps each of the five engines (APQC-ARCH-005) to the standards it builds on, and shows where APQC evidence satisfies existing compliance obligations. The position is deliberate: a discipline that composes standards is adopted; one that competes with them is resisted.

RFC 2119 keywords apply where used.

0. Front Matter

0.1 Normative References

• APQC-CORE-001; APQC-ARCH-005 (the five engines); APQC-GLOSSARY-000.

0.2 Informative References

• All external standards cited below (NIST, ISO, PCI-SSC, HHS, FedRAMP, IETF, ITU-T/ANSI X9, ISO/IEC, EU regulators, etc.). Citations are informative; APQC asserts composition, not endorsement by those bodies.

0.3 Related Specifications

• APQC-AUTH-006; APQC-EVIDENCE-007; APQC-MATURITY-008; APQC-REFERENCE-010.

0.4 Conformance Dependencies

• Depends on: APQC-CORE-001, APQC-ARCH-005, APQC-GLOSSARY-000.
• Referenced by: APQC-REFERENCE-010.

1. Purpose

Enterprises already run asset management, Zero Trust, IAM, cryptographic-migration, audit, and compliance programs. APQC's value is not to supplant them but to connect them into one governed, proven operating model. This document states, engine by engine, which standards each composes — so that adopting APQC is experienced as unifying existing investments, not discarding them.

The intended readers are three, and the document is written to serve all three at once. The architect needs to know which standard each engine builds on, so that an APQC deployment reuses controls already in place rather than duplicating them. The auditor needs to know which existing control an APQC artifact satisfies or strengthens, so that an assessment already framed in ISO 27001, PCI-DSS, or FedRAMP language can absorb APQC evidence without a new vocabulary. The regulator or risk owner needs to know which mandate obligation APQC evidence discharges, so that a post-quantum program can be shown to satisfy CNSA 2.0, NSM-10, or DORA rather than to invent a parallel regime. Each of the three reads the same crosswalk (§8) from a different direction.

2. The composition thesis

Each engine of APQC-ARCH-005 formalizes and automates a domain that already has standards, and adds the three things those standards individually lack: agency (autonomous operation), authority (delegated, provable permission), and evidence (independent, portable proof). APQC is the layer that makes existing standards interoperate under governance.

The thesis is falsifiable, and stating it precisely matters. It is not the claim that existing standards are deficient — SP 800-207, ISO/IEC 27001, and RFC 3161 each do their job well within their scope. It is the narrower, structural claim that no single existing standard specifies the seams between the others, and that the seams are exactly where autonomous transformation goes wrong. Asset management (Knowledge) does not carry a permission model; Zero Trust (Authority) does not leave behind a decade-durable proof of the right that governed a past action; PQC-migration guidance (Transformation) does not specify how execution is gated by delegated authority; non-repudiation and timestamping (Evidence) do not bind a signature to a rooted, revocable right to act; compliance frameworks (Governance) attest periodically rather than prove continuously. APQC contributes the missing connective tissue — the hand-off invariants of APQC-ARCH-005 §7 — and each engine boundary is a seam along which the discipline stitches two previously-separate standards together.

Three properties recur as the APQC contribution across every engine, and the reader should watch for them:

• Agency — the domain is operated by agents (GLOSSARY-000) running the twelve-stage lifecycle, not by humans executing a runbook or by static scripts. Standards that assume a human operator or a scheduled job leave the machine-speed, machine-scale case unaddressed; APQC addresses it.
• Authority — every action an agent takes is gated by a rooted, scoped, time-bounded, revocable, replayable authority (APQC-AUTH-006). The adjacent standards answer identity and instantaneous authorization; none of them keeps the reasoning as a durable, portable object.
• Evidence — every material change emits portable, independently-verifiable, replayable proof (APQC-EVIDENCE-007) that survives the producer. The adjacent standards say "log it," or specify a timestamp, or define non-repudiation of a message — none requires per-change, completeness-provable, offline-verifiable proof of a governed transformation.

APQC adds these three without redefining a single cryptographic primitive, access-control model, or audit obligation. It composes; it does not compete.

3. Engine-to-standard mapping

Each subsection follows one shape: the standards the engine composes, precisely what those standards do not provide, and the composition point — the concrete place the existing control feeds into, or is fed by, the engine.

3.1 Knowledge Engine — composes the asset-and-inventory disciplines

Builds the Knowledge Graph — what is known (APQC-ARCH-005 §5.1).

Standards it composes. - NIST SP 1800-38 (Migration to Post-Quantum Cryptography) — the NCCoE practice guide whose first movement is discovery and inventory of cryptographic assets (keys, certificates, protocols, libraries). APQC's Knowledge Engine automates exactly this discovery movement and carries its output forward as a live graph. - NIST SP 800-53 Rev. 5, control family CM-8 (System Component Inventory), with CM-8(1) (updates during installation/removal), CM-8(2) (automated maintenance), and the adjacent CM-2 (Baseline Configuration). CM-8 mandates an accurate, complete inventory; APQC's Knowledge Engine is a cryptography-specialized, dependency-aware realization of that control. - CISA cryptographic-inventory guidance (the "prioritized inventory" and quantum-readiness roadmap expectation that organizations enumerate where and how they use vulnerable cryptography). - CBOM (Cryptography Bill of Materials) and the broader SBOM lineage (e.g., CycloneDX cryptographic assets) — a machine-readable enumeration of cryptographic dependencies. The Knowledge Graph is a CBOM with dependency edges and blast radius made first-class. - ISO/IEC 19770 / CMDB practice — IT asset-management and configuration-management-database disciplines that the Knowledge Engine MAY be built atop.

What those standards do not provide. CM-8 and CMDB practice produce an inventory — a list, refreshed periodically, of what exists. A CBOM produces a snapshot enumeration of cryptographic dependencies. None of them, by design, produces: dependency edges (which service depends on which certificate, which certificate chains to which root), blast radius (what breaks if this asset changes), or continuous liveness (the estate as a changing population rather than a point-in-time list). Nor do they connect the inventory to a permission model or an evidence model — an inventory knows what exists but nothing about what may be done to it or what was proven about it.

What APQC adds. Continuous, dependency-aware discovery as a live graph rather than a periodic snapshot — with blast radius on every node and coverage accounting stated explicitly (never assumed complete). Crucially, the Knowledge Graph is one of three graphs: the same asset node that CM-8 would merely list is, in APQC, the anchor for an Authority edge (what may be done to it) and an Evidence edge (what was proven about it). Inventory becomes the known corner of a governed triangle.

Composition point. An existing CMDB or CM-8 inventory is a sensing input to the Knowledge Engine (APQC-ARCH-005 §5.1, "Estate Sensing"). An existing CBOM is directly ingestible as a starting asset population. The Knowledge Engine enriches these with dependency resolution and blast radius, and hands the result to the Transformation Engine (for planning) and the Governance Engine (as the drift baseline). Adopting APQC does not discard the CMDB; it promotes it from a list to the reality-corner of the three-graph core.

3.2 Authority Engine — composes the identity, access, and trust disciplines

Builds the Authority Graph — what is permitted (APQC-ARCH-005 §5.2; APQC-AUTH-006).

Standards it composes. - NIST SP 800-207 (Zero Trust Architecture) — never trust, always verify; per-request authorization against live policy and signals via a policy decision point / policy enforcement point (PDP/PEP). APQC extends the Zero Trust posture from human/service requests to autonomous cryptographic change. - NIST SP 800-162 (Attribute-Based Access Control, ABAC) and SP 800-53 AC-2/AC-3/AC-6 (Account Management, Access Enforcement, Least Privilege), plus RBAC practice — the models that decide whether a principal's role or attributes permit an action at an instant. - OAuth 2.0 (RFC 6749) / OpenID Connect — delegated authorization and federated authentication for tokens and scopes. - SPIFFE/SPIRE — cryptographic workload identity (the SVID): a strong, attestable name for a non-human actor. - X.509 / PKIX (RFC 5280) — the certificate trust-chain model whose rooted-path intuition the Authority Root generalizes from identity to authority.

What those standards do not provide. Every standard in this list answers an adjacent question and stops short of authority as APQC defines it (the five distinctions of APQC-AUTH-006 §2 are the normative account; the short form follows). SP 800-207 answers "should this request, from this authenticated principal, be allowed right now?" — a runtime posture that verifies each request and then discards the reasoning. ABAC/RBAC evaluate permissions against roles/attributes held in a live directory; that state is system-bound and role-shaped, which is why it suffers scope creep and permission drift and dies with the vendor. OAuth2/OIDC and SPIFFE establish authentication and token scope — they prove who and carry a momentary grant, but they are prerequisites to authority, not authority: none provides a transferable, sub-delegable, rooted right that an agent carries, and none provides durable, offline, after-the-fact proof of the right that governed a past action. A perfectly authenticated identity (SPIFFE), holding a valid token (OAuth2), passing a Zero Trust check (SP 800-207), against an ABAC policy that returned true — has, in the APQC sense, zero authority, because none of that is a rooted, revocable, replayable right that can be reconstructed years later (APQC-AUTH-006 §2.5: "a party that generates its own keys has valid signatures and zero authority").

What APQC adds. Delegated, rooted, revocable, replayable authority as a first-class graph — the dimension none of the above provide. Specifically: an Authority Root (§3 of AUTH-006) that terminates the "who authorized them?" regress; monotonic-decreasing delegation with scope-intersection / lifetime-intersection / constraint-union inheritance (AUTH-006 §7); mandatory expiry (no standing authority, A3); immediate, propagating, evidenced revocation over a subtree (A6); and deterministic offline Authority Replay (A8) that reconstructs the exact permission state at any past instant. Where Zero Trust leaves a momentary allow, APQC leaves a replayable record of the right.

Composition point. Zero Trust remains the runtime posture and its PDP/PEP the enforcement mechanism; APQC makes the "verify" step leave behind a replayable authority record instead of a discarded decision. SPIFFE/OAuth identities are the holder field of an authority object (AUTH-006 §5) — APQC does not re-invent workload identity, it consumes it and then answers the further question ("by what right does this identity act?") that identity alone cannot. An existing ABAC policy engine can supply delegation constraints (AUTH-006 §8) that ride down the delegation chain. In short: keep your IdP, your token service, your PDP; add the Authority Graph above them as the layer that makes each grant rooted, revocable, and provable.

3.3 Transformation Engine — composes the cryptographic-migration disciplines

Acts at the core — plan, simulate, execute, roll back (APQC-ARCH-005 §5.3).

Standards it composes. - NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) — the standardized post-quantum primitives that are the targets of conversion. APQC selects none and defines none (that is NIST's role, APQC-CORE-001 §3); it executes conversions to them. - NIST SP 1800-38 (Migration to PQC) — the NCCoE migration practice guide, whose later movements (interoperability, hybrid deployment, performance) the Transformation Engine automates under authority. - NIST IR 8547 (Transition to Post-Quantum Cryptography Standards) — the transition timelines and deprecation schedule for classical primitives that inform what to convert and when. - Crypto-agility practice (e.g., the direction of NIST/IETF work on making algorithms substitutable) and hybrid classical+PQ deployment (concurrent classical and PQ primitives to de-risk transition; a valid conversion target per GLOSSARY-000 Hybrid). - FIPS 140-3 / Common Criteria — the validation context for the cryptographic modules the conversion produces or consumes (the correctness-of-module backdrop against which Stage-8 validation runs).

What those standards do not provide. FIPS 203/204/205 specify algorithms; they say nothing about how a migration is sequenced, gated, executed, or reversed across a live estate. SP 1800-38 and IR 8547 describe migration as a human-led project — practice guides and timelines, not an autonomous operation gated by permission. Crypto-agility describes the property of being able to substitute an algorithm; it does not specify the governed act of doing so, nor prove it happened. None of these specifies least exposure (transforming key material the actor cannot read, GLOSSARY-000), simulation (predicting blast radius and failure before touching production), authority-gated execution (an out-of-scope change failing closed with no effect and no evidence), or reversibility as a first-class property of each change.

What APQC adds. Autonomous, simulated, reversible execution under authority — migration as a governed operation, not a project. The Transformation Engine reads the Knowledge Graph for blast radius, is gated at planning and again at the instant of each change by the Authority Graph's fail-closed Gating Interface, applies the change under least exposure, and hands each per-change record plus its Authority Reference to the Evidence Engine. Crypto-agility stops being a static architectural property and becomes a repeatable, governed, proven operation (APQC-CORE-001 T7: "inability to re-convert when an algorithm is later deprecated" is mitigated because the lifecycle is continuous by design).

Composition point. The primitives are chosen from FIPS 203/204/205 and remain entirely NIST's domain; APQC converts to them. SP 1800-38's migration sequence becomes the plan the Transformation Engine generates and simulates rather than a document a team follows by hand. IR 8547's deprecation timeline becomes an input to prioritization (which classical primitives to convert first — reinforced by the harvest-now-decrypt-later weighting of APQC-CORE-001 T6). FIPS 140-3 module validation is a validation technique employed during verification (GLOSSARY-000 Validation), sealed into evidence by the Evidence Engine. APQC is the governance-and-execution layer around the NIST cryptography, never a substitute for it.

3.4 Evidence Engine — composes the audit and non-repudiation disciplines

Builds the Evidence Graph — what is proven (APQC-ARCH-005 §5.4; APQC-EVIDENCE-007).

Standards it composes. - ISO/IEC 13888 (Non-repudiation, Parts 1–3) — non-repudiation of origin, delivery, and the use of trusted third parties. The canonical standard for "this party cannot later deny having produced this." - IETF RFC 3161 (Time-Stamp Protocol) and RFC 5816 (ESSCertIDv2) — trusted timestamping: a signed token binding data to a time from a Time Stamping Authority. Related: RFC 4998 / RFC 6283 (Evidence Record Syntax, ERS) for long-term archival of timestamped evidence. - ANSI/ISO X9 financial-audit norms (e.g., X9.95 trusted timestamp; the X9 family's evidentiary and key-management expectations for financial records). - Chain-of-custody and WORM/immutable-record practice — the evidentiary discipline (legal and records-management) that a record's provenance and integrity be demonstrable, and write-once-read-many storage that resists post-hoc alteration. - ISO/IEC 27037 (identification, collection, and preservation of digital evidence) — the handling discipline for evidence intended to be admissible.

What those standards do not provide. ISO/IEC 13888 provides non-repudiation of a message or transaction — it binds a signature to an originator, but it does not bind that signature to a rooted, revocable authority (a self-generated key yields perfect non-repudiation of a meaningless act; APQC-EVIDENCE-007 §12.5, "valid and meaningless"). RFC 3161 provides a timestamp but no notion of what was permitted, no completeness proof over a population, and no replay. WORM and chain-of-custody rely on custodial testimony and access control — "trust the operator and their controls that the record was not altered" — which is precisely the trust model APQC-EVIDENCE-007 §2 refuses (access-control-as-integrity is an anti-pattern, §12.6). None of these standards, alone or together, delivers: authority binding (proof the actor was permitted), provable completeness over a pre-committed scope (the ability to demonstrate nothing is missing, §6.2), survivability independent of the producer (the "delete the producer" test, §6.5), post-quantum-durable multi-family integrity (§13.2), or deterministic offline replay of an incident (§9).

What APQC adds. Portable, independently-verifiable, replayable, post-quantum evidence — proof that survives the producer, versus logs (and even signed, timestamped records) that do not. Each Evidence Object binds what (commitment, not copy) / when (backdate-resistant, optionally anchored) / who-and-under-what-authority / integrity (multi-family post-quantum signatures), links into a tamper-evident Chain of Evidence, and supports the offline verification procedure of EVIDENCE-007 §7.2. APQC turns non-repudiation-of-a-message into non-repudiation-of-a-governed-transformation, and turns a timestamp into an existence-at-a-time that no party can alter.

Composition point. RFC 3161 / X9.95 trusted timestamping is one concrete way to realize the Evidence Object's independent-time requirement (existence-at-a-time; EVIDENCE-007 §7 and §13.3), and public-ledger anchoring is another — APQC specifies the property, and RFC 3161 is one standards-based mechanism that satisfies it. ISO/IEC 13888's non-repudiation becomes a component of the authority-bound Evidence Object rather than the whole story. WORM storage is welcome but demoted from the seat of trust: in APQC integrity is intrinsic (signatures over canonical content), so WORM protects availability, not authenticity. An existing evidence-preservation program (27037/ERS) can retain APQC Evidence Objects directly — they are self-describing and verify offline, so they slot into any archival regime without vendor lock.

3.5 Governance Engine — composes the compliance and risk frameworks

Encloses and adapts — continuous compliance, drift, risk (APQC-ARCH-005 §5.5).

Standards it composes. - NIST Cybersecurity Framework (CSF) 2.0 — the Govern / Identify / Protect / Detect / Respond / Recover functions, and in particular the new Govern function that CSF 2.0 elevated. - ISO/IEC 27001 / 27002 — the Information Security Management System (ISMS): a risk-driven control set, subject to periodic internal and external audit and continual improvement (Plan-Do-Check-Act). - PCI-DSS v4.0 — cardholder-data protection, including strong cryptography and key-management requirements (Requirement 3 for stored data, Requirement 4 for transmission, and the Requirement 12 governance/risk expectations). - HIPAA Security Rule (45 CFR §164, the Administrative/Technical/Physical safeguards) — including the addressable encryption and integrity-control implementation specifications for electronic protected health information. - SOC 2 (AICPA Trust Services Criteria) — the Security/Availability/Confidentiality/Processing-Integrity/Privacy criteria assessed over a period. - FedRAMP / FISMA (SP 800-53 baselines, SP 800-137 ISCM) — federal authorization and continuous monitoring expectations.

What those standards do not provide. Every framework here specifies what controls must exist and that they be assessed — but the assessment is fundamentally periodic attestation: an auditor samples, an assessor forms an opinion over a window, an authorizing official grants an ATO on a point-in-time package. Even SP 800-137 "continuous monitoring" is, in practice, frequent monitoring plus human judgment, not continuous cryptographic proof over the whole population. None of these frameworks provides: evidence that proves rather than attests (a control that demonstrates itself against the Authority and Evidence graphs, not a checkbox an assessor signs), whole-population coverage (the framework samples; APQC governs every asset), drift detection with automatic re-entry (the reappearance of a classical primitive re-opening the lifecycle, GLOSSARY-000 Drift), or the ability for an independent external party to run its own governance pass from the graphs and public parameters alone (APQC-ARCH-005 §5.5). Governance in these frameworks is opinion informed by evidence; APQC governance is verification against state (APQC-ARCH-005 §5.5 failure case: "governance as opinion, not verification").

What APQC adds. Continuous, evidence-backed compliance and drift/risk adaptation — controls proven continuously rather than attested periodically. The Governance Engine continuously replays the Evidence Graph against the Authority Graph over the whole population, proves that no action exceeded its authority, detects drift against the post-transformation baseline, and emits a re-entry signal that reopens the lifecycle. Because it consumes only graphs and public parameters, an auditor, regulator, or insurer can run an equivalent governance pass independently — the deepest expression of "independently verifiable" applied to oversight itself.

Composition point. APQC does not certify conformance to CSF, ISO 27001, PCI, HIPAA, SOC 2, or FedRAMP — that remains each body's role (§9, Not In Scope). What it does is feed those assessments with evidence that is stronger than what they usually receive: an ISO 27001 auditor sampling Annex A cryptographic controls can be handed a completeness-provable Evidence Graph instead of a spreadsheet; a FedRAMP continuous-monitoring feed can carry per-change proof instead of scan summaries; a PCI-DSS key-management review can replay the exact authority under which each key was rotated. The framework's control objective is unchanged; the evidence answering it is upgraded from attestation to proof. This is the sense in which "APQC composes, does not compete" is most operationally concrete: APQC is the evidence-and-authority layer the existing frameworks assume but do not specify.

4. Mandate and regulatory alignment

The engine mappings above concern voluntary standards an enterprise adopts. This section concerns mandates — obligations an enterprise must satisfy — and shows, obligation by obligation, how APQC evidence and authority discharge the specific requirement. In every case the pattern is the same and is worth stating once: APQC introduces no new obligation; it produces the proof the existing obligation already requires. A mandate that says "migrate to post-quantum cryptography and be able to demonstrate it" is answered by the Transformation Engine (which migrates) and the Evidence Engine (which demonstrates it, provably, offline, for the retention horizon).

4.1 U.S. CNSA 2.0 (Commercial National Security Algorithm Suite 2.0)

The obligation. National-security systems must transition to the CNSA 2.0 algorithm suite (ML-KEM, ML-DSA, and — for firmware/software signing — SLH-DSA / stateful hash-based signatures) on a published timeline, with an expectation of demonstrable progress and completion.

How APQC satisfies it. The Transformation Engine converts classical primitives to the CNSA 2.0 target algorithms (which are exactly FIPS 203/204/205, §3.3). The Evidence Engine produces per-change, completeness-provable proof of what was converted, when, and under whose authority — turning "we are on track" from an assertion into a replayable demonstration against a pre-committed population (EVIDENCE-007 §6.2). Where CNSA 2.0 demands a suite, APQC proves the suite was applied.

4.2 NSM-10 (National Security Memorandum 10)

The obligation. U.S. federal agencies must inventory their cryptographic systems, prioritize migration for high-value and long-lived data, and report progress toward quantum-resistant cryptography.

How APQC satisfies it. The inventory obligation maps to the Knowledge Engine (§3.1) — a dependency-aware, continuously-current cryptographic inventory that exceeds a static CBOM. The prioritization obligation maps to Knowledge-Engine classification and Transformation-Engine planning, weighting long-lived confidential data highest (the harvest-now-decrypt-later threat, APQC-CORE-001 T6). The reporting obligation maps to the Evidence and Governance Engines — progress is not narrated in a status deck but proven against the committed inventory and replayable by an oversight body.

4.3 OMB M-23-02 (Migrating to Post-Quantum Cryptography)

The obligation. Agencies must produce and maintain a prioritized inventory of cryptographic systems and report it on a schedule, as the operational instrument of NSM-10.

How APQC satisfies it. The prioritized inventory is the classified Knowledge Graph; its maintenance is continuous discovery (the estate as a live population, GLOSSARY-000 Estate). Because the inventory, the authority to change it, and the proof of each change are three views cross-linked at the asset node, an M-23-02 submission ceases to be a hand-maintained spreadsheet and becomes a queryable, evidence-backed artifact whose currency is a property of the system, not of a reporting cycle.

4.4 EU DORA (Digital Operational Resilience Act)

The obligation. Financial entities must manage ICT risk, maintain operational resilience, and evidence it to regulators — including control over ICT changes and demonstrable assurance of critical systems.

How APQC satisfies it. DORA's change-control and resilience-evidence obligations map to the Governance + Evidence Engines: every cryptographic change is authority-gated (control) and produces portable proof (evidence), and the whole-population governance pass demonstrates resilience continuously rather than at audit time. The reversibility of transformations (APQC-CORE-001 P5) and the drift/re-entry loop directly serve the operational-resilience posture DORA requires.

4.5 EU NIS2 Directive

The obligation. Essential and important entities must adopt risk-management measures and be able to demonstrate the effectiveness of their cybersecurity controls, with accountability at the management level.

How APQC satisfies it. NIS2's "demonstrate effectiveness" obligation is answered by continuous, evidence-backed governance (§3.5): controls are proven against state over the whole population, and the proof is independently verifiable by a supervisory authority. Management accountability is served by the Authority Graph's rooted provenance — every governed change traces to a human-authorized intent (APQC-AUTH-006 §1; APQC-CORE-001 §7, human authorizers).

4.6 GDPR and sector retention rules

The obligation. Personal-data processing decisions must remain accountable, and records demonstrating lawful processing and security-of-processing measures must be retainable and producible — potentially for long horizons — without leaking the underlying data.

How APQC satisfies it. Evidence retention and survivability (EVIDENCE-007 §6.4–6.5) provide long-horizon verifiability of what security-of-processing changes were made and under whose authority — verifiable years later, offline, after the producing system is gone. Critically, the commitment-not-copy design (EVIDENCE-007 §3.2, §13.1) proves a change occurred without revealing the protected data: an Evidence Object is safe to hand to a regulator because it leaks nothing (least exposure, APQC-CORE-001 P4). GDPR's accountability principle is met by proof that carries no privacy cost.

4.7 FedRAMP / FISMA continuous monitoring

The obligation. Federal systems must maintain authorization through continuous monitoring (SP 800-137 ISCM) and produce authorization evidence (SP 800-53 control satisfaction).

How APQC satisfies it. The Governance Engine's continuous, whole-population verification is a superset of ISCM's monitoring expectation, and the Evidence Graph is a stronger authorization-evidence artifact than the usual scan-and-assess package — it proves control satisfaction for cryptographic change rather than attesting it. An authorizing official reviewing an ATO can be offered replayable proof of the cryptographic-migration control family, verifiable without trusting the vendor.

5. The stance

Zero Trust told the industry to stop trusting the network. APQC tells it to stop trusting assertions — about inventory, about permission, about completion — and to compose the standards it already runs into a system that is agentic, governed, and proven. APQC is not a competing framework; it is the governance-and-evidence layer the existing frameworks assume but do not provide.

Read against the five engines, the stance is a precise instruction. Stop trusting the inventory assertion — the Knowledge Engine proves coverage against a committed population instead of asserting "that's all of them." Stop trusting the permission assertion — the Authority Engine roots, bounds, and replays every right instead of accepting "the agent was allowed to." Stop trusting the completion assertion — the Evidence Engine proves each change and the completeness of the set instead of accepting "we migrated everything." Zero Trust removed the network from the trust base; APQC removes the word — of the operator, the vendor, the tool — and replaces it with rooted authority and portable proof. That is not a rival to Zero Trust; it is Zero Trust's logic carried to its conclusion for autonomous cryptographic change.

6. Presenting APQC to an auditor who knows ISO 27001 / PCI / FedRAMP

An auditor does not need to learn a new framework to assess an APQC deployment; they need to know which of their existing control objectives each engine already answers, and answers more strongly. The following is the recommended way to frame APQC inside an assessment already conducted in ISO 27001, PCI-DSS, or FedRAMP terms.

Lead with the control they already test, not with the engine. An auditor testing ISO/IEC 27001 Annex A cryptographic and access controls (or PCI-DSS Requirements 3/4/8, or the SP 800-53 CM/AC/AU families) is looking for evidence of control operation. Present the Evidence Graph as the artifact that answers those exact objectives — and note that it does so with a property their usual evidence lacks: it is verifiable offline, without trusting the assessed party. The auditor's habitual question — "how do I know this record wasn't altered?" — is answered not by custodial testimony but by intrinsic integrity (EVIDENCE-007 §6.1); the auditor can verify it themselves.

Translate the three additions into their vocabulary. - Agency → "the control operates continuously and autonomously over the whole population, not on a sample." This strengthens coverage assertions an auditor normally has to qualify with sampling language. - Authority → "least privilege and access enforcement (AC-6/AC-3, PCI Req. 7/8) are not just configured but rooted, time-bounded, and replayable — you can reconstruct the exact permission that governed any past change." This answers the "who could do this, and were they allowed?" question that access reviews approximate. - Evidence → "audit records (AU family, PCI Req. 10) are non-repudiable, complete against a committed scope, and independently verifiable — logging's usual gaps (backdating, silent deletion, vendor lock) are closed structurally."

Offer the auditor the independent governance pass. The strongest move is to hand the auditor the graphs and public parameters and invite them to run their own verification (APQC-ARCH-005 §5.5). An auditor who can independently replay an incident and confirm completeness is no longer dependent on the assessed organization's assertions — which is the ideal an assessment aims at and rarely reaches. This reframes APQC evidence from "another thing to assess" into "the thing that makes the assessment easier and more defensible."

Be explicit about what APQC does not do. APQC does not issue an ISO 27001 certificate, a PCI Attestation of Compliance, or a FedRAMP ATO. It produces the evidence those processes consume. Say so plainly (§9); an auditor trusts a vendor more, not less, for drawing that boundary clearly.

7. What APQC does not claim

To keep the composition thesis honest, the boundaries are stated as explicitly as the claims:

• APQC does not define or evaluate cryptographic algorithms. FIPS 203/204/205 are NIST's; APQC converts to them and validates against them.
• APQC does not certify conformance to any external standard. It maps to them and produces evidence they can consume; the certifying bodies retain their role.
• APQC does not replace an IdP, a PDP/PEP, a CMDB, a SIEM, a timestamp authority, or a WORM archive. It composes each into a governed whole and adds the seam none of them specifies.
• APQC does not assert endorsement by any cited body. Citations are informative (§0.2).

The discipline earns adoption precisely by not over-claiming. A layer that composes what an enterprise already runs — and adds only agency, authority, and evidence — is a layer an enterprise can adopt incrementally, audit against its existing frameworks, and defend to its regulators.

8. Crosswalk table (APQC requirement/engine ↔ external control it composes or satisfies)

The table is the document in one view: for each APQC element, the external control(s) it composes or satisfies, and the precise APQC contribution (the agency / authority / evidence the external control lacks). It is informative; the mappings above are the authoritative account.

9. Not In Scope

This specification does not: certify conformance to any external standard (that is each body's role); define cryptographic algorithms; or endorse specific products. It maps how the discipline composes existing standards — a reference for architects and auditors, not a compliance attestation.

In particular, the crosswalk (§8) and the mandate alignment (§4) are mappings of composition and satisfaction, not legal or certification opinions. Whether a given deployment satisfies a given mandate or passes a given audit is determined by the certifying body, the assessor, or the regulator against their own criteria — APQC supplies the evidence and the authority record those parties consume, and nothing in this document substitutes for their judgment. The mappings identify where an APQC engine composes an existing standard and what it adds; they do not, and are not intended to, declare conformance on any body's behalf.