One control, many frameworks: the case for a control registry

An enterprise of moderate complexity typically operates under several overlapping frameworks: an information security standard such as ISO/IEC 27001, a service assurance report such as SOC 2, a cybersecurity framework such as NIST CSF, and now AI-specific frameworks such as NIST AI RMF and ISO/IEC 42001, alongside regulatory obligations such as the EU AI Act and a body of internal policy.

Each of these describes obligations in its own vocabulary. But the controls that satisfy them overlap heavily. Access to systems is approved and reviewed. Changes are authorized and logged. Vendors are assessed. Incidents are handled and recorded. Data is classified and protected. An organization that manages each framework in its own spreadsheet or tool implements, evidences, and assesses these controls several times over.

The registry model

A control registry inverts the relationship. Instead of frameworks owning controls, controls become first-class objects with:

• a stable identifier and a plain-language statement,
• an owner and a scope,
• an implementation description and a test procedure,
• a set of mappings to the requirements, across all frameworks, that the control satisfies,
• evidence items with provenance, freshness, and review status,
• an assessment history.

Frameworks then become views over the registry. Coverage for ISO/IEC 42001 is the set of its requirements that are mapped to operating controls with current evidence. A gap is a requirement with no mapped control, a control that is not operating, or evidence that has gone stale.

What changes in practice

Evidence is collected once. A quarterly access review produces one evidence item that satisfies requirements in several frameworks simultaneously.

Assessments become comparable. Because controls are tested against their own procedures rather than framework-specific interpretations, results can be compared across time and across business units.

Reporting becomes a query. Posture by framework, by system, or by business unit is derived from the same underlying data rather than reconstructed for each audience.

AI-specific obligations slot into existing practice. Many requirements in NIST AI RMF and ISO/IEC 42001 are satisfied by controls the security program already runs, once the mapping is made explicit. The genuinely new controls, such as AI use inventories and model risk assessments, are added to the registry and mapped in the same way.

Evidence from operations

A registry is only as good as the evidence attached to it. The highest-value evidence is generated by operations rather than compiled by hand: exports from identity systems, logs of control outcomes, records of governance decisions. This is where AI visibility platforms and compliance platforms meet. When observed AI activity and enforcement outcomes flow into the registry as evidence, the chain from an individual interaction to a framework requirement is complete and continuously refreshed.

A note on claims

A control registry supports a compliance program. It does not make an organization compliant, and no software does. Compliance is an outcome of how controls are designed, operated, and attested, and of the judgment of the people accountable for them. QComp is built to make that work consistent, reusable, and evidenced.