Regulations and Control Frameworks

Controls are how "compliant" becomes checkable. You state which regulations apply to a package; the organization's control catalog supplies the concrete controls behind them; and from then on, every design is scored against those controls, control by control, on the Assurance tab.

Applicable Regulations

On Design Inputs, select the regulations that govern this solution (for example HIPAA, PCI DSS, SOC 2). The selection scopes which controls evaluate the design and frames the design review and generated documents like the SSP.

The Control Catalog

The catalog is organization-level, managed once and used by every package:

• New organizations start seeded with a NIST 800-53 pack, so scoring works on day one.
• Frameworks can be imported as packs, edited control by control, and extended with your own controls; each control carries its reference, requirement text, severity, and tags.
• Controls do double duty: they constrain generation (the design is built to satisfy them) and they evaluate results (pass, fail, review, or not applicable, with reasons).

Framework Versioning

On the Large plan and above, control frameworks keep an auditable revision history: what changed, when, and the catalog fingerprint each design was evaluated against, which is what makes "evaluated against which version of the rules?" answerable later.

After Approval

Controls keep working after the design is approved: drift detection watches for control regressions (passing at approval, failing now), and catalog changes mark affected packages for re-evaluation, so a rule change ripples to every design it touches instead of aging silently.