Unified Framework Registry — 14 frameworks, one canonical source

The Unified Framework Registry(RFC-027) lands as a shared Go module that defines every compliance framework vCISO Lite supports — SOC 2, ISO 27001, PCI DSS, HIPAA, NIST CSF, GDPR, FedRAMP, CIS Controls, and the rest of the fourteen — with canonical IDs, display metadata, and alias resolution. Every service now imports from the same registry instead of maintaining its own hardcoded framework map.

What changed

• Fourteen frameworks, one canonical source. Each framework has a single canonical ID (e.g. soc2, iso27001, nistcsf) that every service in the platform uses. No more “did compliance-service call it SOC2 or soc_2 or SOC 2?” debates in code review.
• Alias resolution.The registry accepts any known alias — case-insensitive, punctuation-tolerant, common misspellings — and returns the canonical framework. Data imported from customer spreadsheets, CSV uploads, and legacy integrations resolves cleanly without a normalization pass every service has to write on its own.
• Frontend-backend parity via codegen. A codegen script produces a TypeScript equivalent from the Go source, so the frontend uses the same registry as the backend. Adding a new framework or updating display metadata is a one-file change that propagates everywhere.
• Migration completed across every service. Every scattered framework map, normalizer function, and pattern-matching block that used to live inside a service is gone. The registry is the source of truth.

Why this matters

Every subsequent product improvement that touches a framework — adding a control, mapping a policy to a requirement, generating a compliance report, wiring evidence to an audit cycle — inherits the Registry. What used to be a stealth cost every service paid on every framework change is now a single Go type. And when the framework list grows in a future release, the growth is a data change, not a code change.