EquanimGRC ships a built-in library of compliance frameworks and their controls. Framework definitions are versioned as YAML in a dedicated repository and loaded into the database during setup. Each definition declares the framework's metadata, its domain hierarchy, every control, and the mappings that connect one control to its equivalents in other frameworks. A tenant turns on the frameworks it needs; the controls and their cross-framework relationships come with them.
Supported frameworks
Six frameworks are defined and loaded today:
- SOC 2 — Trust Services Criteria, 2017 (AICPA). Criteria
CC1–CC9plus availability, confidentiality, processing integrity, and privacy. - ISO 27001 — 2022. Annex A controls.
- HIPAA — 2013 Omnibus. Administrative, physical, and technical safeguards.
- GDPR — 2016/679. Processing principles, data-subject rights, and controller obligations.
- PCI DSS — 4.0. The twelve requirements and their sub-requirements.
- NIST CSF — 2.0. The six functions: Govern, Identify, Protect, Detect, Respond, Recover.
Each framework record carries a name, slug, version, and issuing authority (AICPA, ISO, HHS, the EU, the PCI SSC, NIST). Additional frameworks are added by contributing a new definition file — no code change is required, because the loader reads whatever framework files are present.
The definition format
A framework definition is a YAML file with three levels. The top-level framework block holds the metadata: name, short_name (used as the slug), version,organization, description, and a reference url. Below it,domains groups controls — for SOC 2, a domain is a criterion family such asCC1 (Control Environment). Within each domain, controls lists the individual controls.
Each control declares:
id— the control identifier, unique within the framework (for exampleCC1.1).nameanddescription— the title and the requirement text.guidance— implementation notes.evidence_types— the kinds of artifact that satisfy the control, such as a policy, training records, or a configuration snapshot.mappings— equivalent control IDs in the other frameworks, keyed by framework slug.tasks— an ordered set of remediation steps with a prompt and an evidence hint.
The control and requirement model
Loading a definition produces two parallel representations. The first is the control library: each control becomes a Control record belonging to its framework, with the identifier, title, description, its domain as a category, and the guidance, evidence types, and mappings retained as metadata. A control's identifier is unique within its framework, so the same string can appear in two frameworks without collision.
The second is the requirement hierarchy: every domain and every control also becomes a RequirementNode. Domain nodes are typed category; control nodes are typed control and point to their parent domain. The hierarchy supports deeper nesting — sub-controls and points of focus — for frameworks that need it. This tree is what the crosswalk layer maps against, which keeps cross-framework relationships at the requirement level rather than tangled into the control records themselves.
Cross-framework crosswalks
A crosswalk links one requirement node to another — for example, SOC 2 CC6.1 to ISO 27001 A.8.20, or PCI DSS 1.1.1 to its SOC 2 and ISO equivalents. Crosswalks come directly from the mappings block in each definition. After every framework is loaded, the importer walks those mappings and creates a ControlCrosswalkbetween the source control's node and each target control's node, in whichever frameworks the target lives.
Each crosswalk records a mapping strength — identical, partial, orrelated — describing how closely the two requirements correspond. A target named in a mapping but not yet present in the database is skipped rather than guessed at, so the crosswalk set only ever contains links between controls that both exist. The result is a graph: one control can be connected to several controls across several frameworks, in both directions.
Activating frameworks for a tenant
The framework library is shared and read-only — tenants do not edit framework or control definitions. A tenant chooses which frameworks apply to it by activating them. Activation is aTenantFramework record joining the tenant to the framework with an active flag; a tenant can have at most one such record per framework. Activating a framework seeds its remediation tasks for that tenant from the definition's tasks, so the tenant starts with a concrete to-do list rather than a bare control list.
Coverage is then measured per tenant: the share of the framework's controls that the tenant's policies and evidence address. Deactivating a framework leaves the shared definitions untouched — it only changes which frameworks that tenant is working against.
Multi-framework coverage
Because crosswalks connect equivalent controls, work done for one framework is visible against the others. An evidence item is attached to a specific control, but that control's requirement node is linked by crosswalk to its equivalents elsewhere — so the access-control snapshot you collect for SOC 2 CC6.1 is the same artifact an auditor would expect for the mapped ISO 27001 and PCI DSS requirements. You collect once and reuse across the frameworks you have activated, instead of re-gathering the same evidence for each.
This is where the framework model meets the rest of the platform. Policiesmap to the controls they implement; evidence-as-codedefinitions name the control an artifact satisfies and run on a schedule; andPosturizer reads the resulting coverage to report posture across every activated framework at once.