What is the Compliance-to-Architecture Framework?

An open, Apache-2.0-licensed specification that defines the data shapes, mappings, and conformance levels for translating regulations (EU AI Act, ISO 27001, SOC 2, GDPR, HIPAA, PCI DSS, DORA, NIS2 and more) into machine-readable controls, runtime policies, evidence objects, and audit-ready reports.

Is the framework free to use?

Yes — the entire specification, ontology and conformance suite are released under Apache-2.0. Anyone can implement it. ReguNav™ publishes the spec; ReguNav™ is one of many possible implementations.

How does it relate to other compliance standards?

Existing standards (ISO, SOC, NIST) describe WHAT controls need to exist. The Compliance-to-Architecture Framework describes HOW those controls map to running software — the data shapes, the policies, the evidence objects, the audit trail. It's the missing layer between policy text and production code.

Compliance-to-Architecture™ · open methodology

Three steps to know if Compliance-to-Architecture™ fits.

A methodology + open specification + reference engine. Read the spec, see the maturity model, run the platform that implements it.

Read the spec →Book a POC walkthrough

Open specification · Version 0.1 · Apache-2.0

Turn regulations into software architecture.

The Compliance-to-Architecture Framework™ translates the EU AI Act, ISO 27001, ISO 42001, SOC 2, PCI DSS, HIPAA, GDPR, DORA, NIST, HAARF, CCPA and more into controls, evidence, policies, workflows, and software-architecture patterns.

Stop managing compliance as spreadsheets. Build systems that prove compliance by design.

Download Framework v0.1 →Explore the ontology Star on GitHub

Published by ReguNav™ — the compliance-to-architecture engine for regulated AI, data and software systems.

License

Apache-2.0

Permissive, audit-friendly, forkable.

Spec status

v0.1 · Public

Versioned, RFC-amendable, open.

Conformance

Suite available

Run the validator yourself.

§1 · Manifesto

What is Compliance-to-Architecture?

Compliance-to-Architecture (CtA) is an open framework that translates regulatory text into the four artefacts a production software organisation actually needs: machine-readable obligations, reusable controls, runtime-enforceable policies, and cryptographically-sealed evidence. It is published as a versioned specification + a reference open-source implementation. Adopting it does not require buying anything — the framework is licensed Apache-2.0 and the full ontology is in a public Git repository.

The framework exists because the way most organisations handle compliance today does not scale to the regulatory surface area of 2026. A single SaaS now needs to satisfy 25+ frameworks across 12+ jurisdictions, and the spreadsheet-and-PDF operating model produces audit-time scrambles, duplicate work across teams, and controls that have no relationship to the systems they purport to govern. CtA replaces that with a single graph: every clause maps to an obligation, every obligation to a reusable control, every control to a system capability, every capability to a runtime policy, and every policy emits typed evidence.

The framework is organised as an 8-Layer Spine: Profile (conformance), Rule Pack (behaviour), Dictionary (vocabulary), Manifest (deployable unit), Gateway (runtime checkpoint), Engine (deterministic execution), Rail (operating-line organisation), and Evidence Pack (cryptographic proof). Every artefact in the framework lives at exactly one of these eight layers. If a proposed artefact does not fit, the rule is to stop and propose a specification amendment — never invent a ninth layer.

CtA is deliberately framework-neutral. It does not replace the EU AI Act, ISO 27001, SOC 2, GDPR, or any other authority — it provides the canonical graph that lets a single control satisfy clauses across all of them simultaneously. An auditor reading an evidence pack can trace every claim back to its source clause; an engineer reading a control can see exactly which system capabilities it requires; a regulator querying the graph can independently verify both. The framework's success criterion is simple: adding a new regulation to an implementation should be a configuration change, not a project.

Read the spec →

SPEC.md

Read the methodology →

METHODOLOGY.md

Run conformance suite →

conformance/

Architectural commitment

Event-driven by spec. No batch jobs. No post-facto.

Every event a conforming implementation produces — verdict, evidence pack, audit-trail row, log line, doc rebuild, index update, reconciler tick — fires within 30 seconds of its triggering event. Cron-only ingestion is forbidden as a primary trigger. Every event is also written to a typed, queryable index — auditors can query by time, tenant, source, kind, phase, severity, actor, entity, action. The contract is verifiable by registry: any implementation must publish the shape, the categories, and the violation count so auditors can check conformance without seeing the internals.

↗ event-driven dictionary ↗ CONSTITUTION.md

Interactive · live numbers

Build your compliance stack.

Pick your sector, region, and AI risk tier. The framework shows you which standards apply, which sector packs to activate, and how many controls you're committing to. Live — no API call, no sign-up.

Industry sector

Region

AI risk tier

Frameworks

788

Total controls

Sector pack

5 AI overlay

Your stack (12 frameworks)

ISO/IEC 2700193

core

ISO/IEC 2770149

core

SOC 264

core

GDPR32

core

PCI DSS 4.0247

core

DORA64

core

NIS227

core

EU AI Act (Annex III high-risk)113

AI overlay

ISO/IEC 4200138

AI overlay

NIST AI RMF 1.023

AI overlay

FRIA (Art. 27)24

AI overlay

Annex IV technical doc14

AI overlay

core (region-filtered) sector pack AI overlay

Control counts are from the framework manifests on github.com/Compliance-to-Architecture. The framework crosswalks the controls — one control can satisfy clauses in multiple frameworks, so the actual instrumentation count is lower than the sum above.

Why this exists

Every team writes the same crosswalk. Compliance-to-Architecture™ writes it once.

Regulations issue obligations. Auditors expect controls. Architects build systems. Auditees produce evidence. Today, each role maintains its own private ontology — and reconciles by email. The Compliance-to-Architecture Framework is the machine-readable bridge between the four ontologies.

Status quo

Regulator publishes obligation X. Three trade bodies publish a mapping spreadsheet. Each maps differently.
Auditor's working paper uses a different control taxonomy than the platform's evidence registry.
Architect's system diagram does not reference any control. Mapping happens at audit time.
Policy-as-code, when it exists, ignores the framework graph; rules drift from obligations.
Audit trail is event-shaped, not control-shaped. Sampling auditors must translate.

With Compliance-to-Architecture Framework™

One canonical layer per concept: Authority → Obligation → Control → Mitigation → Architecture → Policy-as-Code → Workflow → Evidence → Audit-Trail → Audit-Pack.
Crosswalks are typed edges in the graph. Adding a new framework is one PR.
Architecture references control IDs. Diagrams generated from the same graph the auditor reads.
Policy-as-code (Cerbos / OPA / Cedar) compiles from the same control catalogue.
Audit-trail is control-shaped — the auditor walks the graph, not the events.

Six roles

Each compliance role uses the framework differently. The graph is the same.

Regulator / Standards body

Publish obligations as JSON-LD nodes that machines can read. Issue updates as graph deltas.

Compliance team

Maintain ONE crosswalk graph. Re-use it across every audit, every framework, every quarter.

Auditor (internal + external)

Walk the framework graph instead of sampling spreadsheets. Tamper-evident audit-trail by construction.

Security architect

Diagrams reference control IDs. Auto-generated from the same source the auditor reads.

Platform engineer

Policy-as-code (Cerbos, OPA, Cedar) compiles from the same control catalogue. No drift between docs and runtime.

Executive / Board

One risk register, multiple authorities. Composite index drills down to obligation → control → evidence.

Compliance is written for lawyers. Software is built by engineers. The gap is where risk lives.

Most organisations still translate compliance manually through spreadsheets, disconnected control libraries, scattered policies, and inconsistent evidence collection. The result is slow delivery, duplicated work, weak audit readiness, and systems that are difficult to prove compliant.

Five vocabularies, no shared graph

Legalneeds obligations
Complianceneeds controls
Engineeringneeds architecture
Auditorsneeds evidence
Regulatorsneeds accountability

The Compliance-to-Architecture Framework™ is the shared graph that connects all five.

Status quo vs Compliance-to-Architecture™

Seven aspects of compliance — two ways.

Click any aspect to see the difference. The framework reshapes each one so it is machine-readable, versioned, and verifiable — without inventing a new control vocabulary.

Status quo

Word docs + spreadsheets, per framework, per team

Compliance-to-Architecture™

JSON-LD graph nodes with stable IDs, machine-readable

Concrete shape

ISO 27001 A.5.7 ↔ control_iri ➜ urn:cta:control:iso27001:A.5.7

1 of 7

Why this framework exists

Regulatory surface area, 2018 → 2026.

Eight years ago a global SaaS could plausibly cover GDPR + CCPA + ISO 27001 with a shared control set. Today the same SaaS needs to satisfy 25+ frameworks across 12+ jurisdictions — without 25 parallel programs. Click any year for what landed.

Newly in force in 2026

32 cumulative · +4 this year

EUEU AI Act high-risk obligations in force
EUePrivacy Regulation (anticipated)
USMultiple US state AI laws
GlobalNew regional AI frameworks (LATAM, ME)

Counts reflect frameworks tracked by the framework registry. Source: each framework's official gazette + commencement date. The trajectory is consistent across multiple industry trackers (IAPP, ISACA, ENISA).

Compliance-to-Architecture changes the operating model.

A common language between legal, compliance, security, product, engineering, AI governance, and audit teams. Compliance is no longer bolted on after the system is built — it is designed into the system from the start.

→canonical obligations
→common controls
→evidence objects
→software-architecture requirements
→policy-as-code rules
→audit trails
→control ownership
→AI-governance requirements
→vendor + third-party assessment patterns
→board-ready reporting structures

vs adjacent ontologies

Compliance-to-Architecture Framework™ vs OSCAL vs ATT&CK vs proprietary GRC.

OSCAL is a control catalogue. MITRE ATT&CK is a threat taxonomy. Proprietary GRC libraries are vendor-specific. None bridges regulation to architecture end-to-end — that's the gap the framework closes.

Capability	CTA Framework™	OSCAL (NIST)	MITRE ATT&CK	Proprietary GRC
Open-source under Apache-2.0	yes	yes (NIST)	yes (CC0)	no
Covers regulation → architecture	yes	controls only	threats	varies
Multi-framework crosswalk graph	yes (typed edges)	yes (catalog)	ATT&CK	varies
Policy-as-code compile target	Cerbos · OPA · Cedar	no	no	vendor-specific
Auditor-shaped audit-trail	yes (control-shaped)	n/a	n/a	no
Sector packs (maritime, etc.)	yes	no	no	few
Live ontology updates as PRs	yes	yes	yes	no
Production SDK + dictionaries	@regunav/sdk	schemas	STIX	varies

Sectors

Eight sectors, one framework graph.

Each sector below is a pre-bundled subgraph of the Compliance-to-Architecture Framework™ — the regulator-authored frameworks, the cross-framework controls, and the typical evidence templates a tenant in that sector needs.

AI / SaaS

EU AI Act + ISO 42001 + NIST AI RMF

Fintech / banking

DORA + PCI DSS + SOC 2

Healthcare

HIPAA + ISO 13485 + EU MDR

Maritime

IMO SOLAS + MARPOL + IACS UR E26/E27

Legal / professional

SRA Code + ABA Model Rules + AML

Oil & gas

OSHA PSM + Seveso III + EU CBAM

Public sector

FedRAMP + DORA + NIS2

Retail / e-commerce

PCI DSS + GDPR + CCPA

Maritime / legal / oil-and-gas ship today as sector packs in packages/sector-packs-core. AI/SaaS, fintech, healthcare, public sector, retail are next.

Test your knowledge · 6 questions · ~2 minutes · pool of 15 · randomised every visit

How well do you know the framework?

1
What's at Layer 0 — the ROOT of the dependency chain?
2
Why are framework engines DETERMINISTIC (not LLM-backed)?
3
What's at L12 — the TOP of the chain?
4
What does a crosswalk in the framework represent?
5
Which policy-as-code engines does the framework compile to?
6
What is a 'manifest' in the framework?

Canonical model · 8 layers

The 8-Layer Spine.

Every artefact across the framework is built as a composition of these eight layers — and nothing else. Click a layer to inspect its definition, canonical packages, and concrete examples.

Layer 4

Manifest

A Manifest is a single signed JSON document binding identity → spine layer → authority → controls → evidence → conformance. Manifests are the marketplace unit — what gets installed, certified, billed, audited.

Canonical packages

@cta/manifests-engine-core

Concrete examples

▸Control Manifest (e.g. IAM Access Review)
▸Evidence Template Manifest
▸Audit Pack Manifest
▸Bank Connector Manifest
▸Sector Pack Manifest

New capability? Identify which layer it lives at. If it doesn't fit one of the eight, stop and propose a spec amendment — never invent a ninth layer. Ship at the lowest layer that admits it: a Rule Pack is preferable to a Profile; a Manifest is preferable to a Rail.

From legal obligation to runtime evidence.

Each requirement is mapped to: what applies, why it applies, who owns it, what system components are needed, what policies must be enforced, what evidence must be collected, how audit readiness is proven.

§1 · Regulation

Authority document — EU AI Act, GDPR, ISO 27001…

Canonical model · 13 layers · 2 cross-cutting

The 13-layer Compliance-to-Architecture Graph™.

L0 → L12. Each layer depends on the layers below it. Click any layer to expand its definition + the example you'd see in a real pack.

Foundation (what + who + where)Structure (mapped controls)Implementation (running software)Evidence (auditor-pullable)

Risk / Harm

foundation

What could go wrong — to whom, how likely, how bad. Likelihood × Impact = inherent score; mitigations bring it to residual.

In a real evidence pack

RISK-AI-HIRING-DISCRIMINATION · likelihood 4 · impact 4 · residual 8

1 of 13

cross-cutting

AI / System Governance

spans L0–L12

EU AI Act risk class · ISO 42001 actor role · model-card + data-card · human-oversight model · post-market monitoring.

cross-cutting

Runtime Monitoring

spans L7–L12

Drift detectors, performance trackers, evidence-staleness alerts that emit evidence on event.

Spec: SPEC.md· Methodology: METHODOLOGY.md· Conformance test: conformance/· Machine-readable: spec.json

Same manifest · 5 representations

Language-agnostic by design.

The canonical shape is JSON. Every host language is just a serialisation. Below is the same Access-Review manifest in TypeScript, JSON, YAML, Python, and the public validation endpoint — byte-identical semantics.

typescript

import type { CanonicalManifest } from "@cta/manifests-engine-core";
import { validateManifest } from "@cta/manifests-engine-core";

const manifest: CanonicalManifest = {
  schemaVersion: "0.1",
  id: "urn:cta:control:iam:access-review:001",
  name: "Periodic identity and access review",
  version: "1.0.0",
  kind: "control",
  spineLayer: 5,
  authorities: [
    { framework: "ISO_27001", version: "2022", clauseRefs: ["A.5.18"] },
    { framework: "SOC_2",     version: "TSC-2017", clauseRefs: ["CC6.3"] },
    { framework: "PCI_DSS",   version: "4.0.1", clauseRefs: ["7.2.5"] },
    { framework: "NIST_CSF",  version: "2.0", clauseRefs: ["PR.AA-05"] },
  ],
  evidenceKinds: ["access-review-attestation", "revocation-log"],
  provenance: {
    author: "urn:org:example-corp",
    createdAt: "2026-05-18T00:00:00Z",
    license: "Apache-2.0",
  },
};

const result = validateManifest(manifest);
if (!result.valid) throw new Error(JSON.stringify(result.issues, null, 2));

Schema-first

Validator output is itself a versioned schema — pipelines can fail-closed on issues[].severity === "error".

Deterministic

Pure function. Same input ⇒ same output. No network, no clock, no LLM. Auditable.

Apache-2.0

The reference validator (~250 LOC, zero deps) is open-source. Fork, embed, run offline.

6 questions · ~90 seconds · scored locally

Where does your organisation sit on the maturity model?

Answer six questions about how you handle compliance today. We'll show you the maturity tier that matches and what moving up looks like.

Progress · 0 of 60%

Q1
Where does your control library live?
Q2
How is evidence captured?
Q3
How do you crosswalk between frameworks (e.g. SOC 2 ↔ ISO 27001)?
Q4
Where do your controls actually run?
Q5
How are audit packs assembled?
Q6
Adding a new regulation to your scope today would require:

Live · Runs in your browser · No data leaves this page

Validate a manifest.

Paste any Compliance-to-Architecture manifest. The validator runs the canonical v0.1 schema check and shows exactly which fields fail and why — in structured JSON, the same format an automated pipeline would consume.

Input · application/manifest+json

{
  "schemaVersion": "0.1",
  "id": "urn:cta:control:iam:access-review:001",
  "name": "Periodic identity and access review",
  "version": "1.0.0",
  "kind": "control",
  "spineLayer": 5,
  "authorities": [
    {
      "framework": "ISO_27001",
      "version": "2022",
      "clauseRefs": [
        "A.5.18",
        "A.8.2",
        "A.8.3"
      ]
    },
    {
      "framework": "SOC_2",
      "version": "TSC-2017",
      "clauseRefs": [
        "CC6.1",
        "CC6.2",
        "CC6.3"
      ]
    },
    {
      "framework": "PCI_DSS",
      "version": "4.0.1",
      "clauseRefs": [
        "7.2.4",
        "7.2.5",
        "8.2.4"
      ]
    },
    {
      "framework": "NIST_CSF",
      "version": "2.0",
      "clauseRefs": [
        "PR.AA-01",
        "PR.AA-05"
      ]
    }
  ],
  "controls": [
    "CTRL-IAM-ACCESS-REVIEW-001"
  ],
  "evidenceKinds": [
    "access-review-attestation",
    "revocation-log",
    "reviewer-roster"
  ],
  "conformance": {
    "maturityLevel": 3,
    "assertedBy": "urn:org:example-corp",
    "assertedAt": "2026-05-18T00:00:00Z",
    "evidenceRetentionDays": 2555
  },
  "provenance": {
    "author": "urn:org:regunav-inc",
    "createdAt": "2026-05-18T00:00:00Z",
    "license": "Apache-2.0",
    "digestSha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
  }
}

Validation resultVALID

0 error · 0 warn

{
  "valid": true,
  "schemaVersion": "0.1",
  "issues": []
}

The validator is validateManifest(input) — a pure TypeScript function with zero runtime dependencies. Source: apps/cta/src/lib/manifest-schema.ts. Adopt as-is or fork.

Worked crosswalks

Map a control once. Cover every framework that asks for it.

Six real capability ↔ clause crosswalks. Each shows the architecture the capability requires and the evidence it emits — the same pattern repeated across the framework.

Capability · single reusable control

Periodic identity and access review

Satisfies — 6 clause refs across 6 authorities

ISO 27001A.5.18Access rights

SOC 2CC6.3Logical access removal

PCI DSS7.2.5Access reviewed every 6 months

NIST CSFPR.AA-05Access permissions, entitlements, and authorisations

HIPAA§164.308(a)(4)Information access management

GDPRArt. 32Security of processing — confidentiality and integrity

Architecture this capability needs

▸RBAC / ABAC policy engine (Cerbos / OPA / Cedar)
▸Centralised identity event log (immutable, 7y retention)
▸Quarterly review workflow (four-eyes approval)
▸Joiner-mover-leaver automation

Evidence this capability emits

▸Access-review attestation (PDF / JSON, signed)
▸Revocation log (delta between reviews)
▸Reviewer + approver identities (with timestamps)

Authority coverage — what's open, what's mapped, what's on the roadmap.

No headline framework-count claim without qualification. Three states — declared / mapped / on roadmap — never conflated.

Implemented (open)

Live in the v0.1 ontology seed. Conformance validator passes. Anyone can fork.

EU AI Act 2024/1689
ISO/IEC 42001:2023 · ISO/IEC 27001:2022 · ISO/IEC 27701:2019
GDPR 2016/679 · UK GDPR / DPA 2018 · HIPAA
SOC 2 TSC 2017 · NIST AI RMF · NIST CSF 2.0
DORA 2022/2554 · NIS2 2022/2555 · EU CRA 2024/2847
PCI DSS 4.0.1

+ private

Mapped in ReguNav™

Authoritative crosswalks live in the commercial graph; not yet open-sourced. Promotions to the open seed land in v0.2 / v0.3.

See regunav.com for SaaS access.

Public roadmap target

All authorities targeted for `implemented` status by v1.0.0.

UK GDPR + DPA 2018
CCPA / CPRA · DPDP India · LGPD Brazil
PIPL China · APPI Japan · AU Privacy Act
SOC 1

Roadmap: ROADMAP.md · Methodology for promotion `mapped → implemented`: METHODOLOGY.md

Cross-walks across 20 regulations.

Click any framework to see which obligations, controls, and architecture components ReguNav maps it to. Map a control once. Cover every framework that uses it.

Framework

EU AI Act

EU · 113 controls

Sample obligations

▸Art. 9 risk-management system
▸Art. 10 data governance + bias testing
▸Art. 12 event logging
▸Art. 14 human oversight
▸Art. 27 FRIA
▸Art. 73 serious-incident reporting

Architecture impact

▸AI system registry
▸Model-card publisher
▸Drift detector
▸Immutable WORM audit log
▸Approval workflow

Live · pulled from @regunav/frameworks

Browse the open ontology.

The same data the spec uses. Search any framework, clause, or control. Click a framework to expand sample clauses + controls. Open the full repo for the complete tree.

24/24

Sample clauses
- Art. 3Definitions
- Art. 4AI literacy
- Art. 5(1)(a)Prohibited — subliminal techniques distorting behaviour
- Art. 5(1)(b)Prohibited — exploitation of vulnerabilities
- Art. 5(1)(c)Prohibited — social scoring by public authorities
- Art. 5(1)(d)Prohibited — predictive policing based solely on profiling
Sample controls
- EUAI-RM-001Continuous risk-management lifecycle
- EUAI-DG-001Data governance for training, validation and testing
- EUAI-DOC-001Annex IV technical documentation pack
- EUAI-LOG-001Automated event logging
- EUAI-TRANS-001Deployer-facing transparency information
- EUAI-HO-001Effective human oversight

This is a navigable preview. The full ontology — every clause, every control, every crosswalk edge — is in the open Git repository. Clone, read, fork.

Know what applies, where, and why.

The Jurisdiction Mapping Model™ maps obligations across four orthogonal facets. Click each to drill in.

Facet 1 · examples

Geography

country · region · state · economic bloc · regulator territory

EU 🇪🇺

US 🇺🇸

UK 🇬🇧

California

Singapore

Frankfurt eu-central-1

Convert controls into buildable system requirements.

A privacy, security, resilience, or AI-governance control may require concrete capabilities the system must have. The framework makes those requirements explicit.

🔐

Identity & access

⚖️

RBAC / ABAC engine

📝

Consent registry

📨

DSAR workflow

📜

Audit logging

📋

Model inventory

👁️

Human oversight

🚨

Incident management

🗄️

Data retention

🤝

Vendor risk register

📤

Evidence export

🔑

Encryption + KMS

Designed for the AI-regulation era.

AI systems require governance over intended purpose, risk classification, data governance, model monitoring, human oversight, transparency, incident reporting, post-market monitoring, provider/deployer responsibilities, and change management. The framework maps each into operational workflows and software-architecture components.

EU AI Act

Annex III high-risk · Art. 27 FRIA · Art. 4 AI literacy · Art. 12 logging · Art. 14 oversight · Art. 53 GPAI

ISO/IEC 42001

AI management system · §6.1 risk · §7.4 communication · §8.2 impact assessment · §9.1 monitoring

NIST AI RMF

GOVERN · MAP · MEASURE · MANAGE — mapped to control + evidence objects

Layer 8 · Evidence Pack

Evidence pack lifecycle — 5 immutable states.

Every state-changing decision produces an Evidence Pack. It is signed, sealed in write-once storage, and reproducible on demand for the full retention window. Click any state for invariants.

Step 3 · Seal

Written to WORM storage (S3 Object Lock COMPLIANCE mode).

Invariants enforced at this stage

▸Append-only — UPDATE and DELETE rejected at storage layer
▸Retention timer started (per-domain × jurisdiction)
▸Cross-region replicated within RPO
▸Tamper-detection chain verifiable end-to-end

Retention floor

7 years (financial / payment / consent) or 10 years (fatwa / audit / policy) — per-domain × jurisdiction, max of all in-scope rules.

Storage model

WORM (S3 Object Lock COMPLIANCE), append-only Postgres partitions, per-row hash chain, AWS Backup Vault Lock for the cold tier.

Legal hold

Retention timer pauses for the affected scope until the hold is released. Hold operations are themselves audit entries.

5-tier maturity model

From ad-hoc to generative.

Most organisations land at L2 (Documented) today. The reachable ceiling within 12-18 months of CtA adoption is L4 (Enforced). L5 (Generative) is the long-term target.

Ad-hoc

Compliance lives in PDFs and people's heads.

▸No central control library
▸Evidence collected only for audits, not continuously
▸Each framework treated as a separate project

Documented

Controls are written down but disconnected from systems.

▸Central control library exists (often in a GRC tool)
▸Each control has a written description and an owner
▸Crosswalks between frameworks are manual and partial

Mapped

Controls are crosswalked and tied to system capabilities.

▸Every control maps to one or more authority clauses
▸Every control maps to a system capability (architecture)
▸Evidence kinds are defined per control

Enforced

Policies are enforced at runtime; evidence is captured continuously.

▸Policy-as-code (Cerbos / OPA / Cedar) enforces controls in production
▸Evidence is emitted as a byproduct of normal operations
▸Drift / staleness alerts wake an on-call engineer, not an auditor

Generative

Compliance is a derived property — adding a regulation is a config change.

▸New regulation? Map to existing reusable controls. No code change.
▸New jurisdiction? Compose existing Rule Packs + dictionaries.
▸Audit packs are differential — show only what changed since last cycle

Full maturity model →Take the self-assessment

Generated from packages/frameworks at build time

Where every framework actually stands.

No hand-curated marketing inventory. The table below is derived directly from the open-source@regunav/frameworksregistry — 24 of 24 framework modules ship populated clause/control/question libraries, 20 participate in the cross-framework crosswalk graph (97 edges).

Framework	Version	Clauses	Controls	Status
Australia Privacy Act	1988 (Cth); amended 2022 (Enforcement & Other Measures)	16	12	PopulatedCrosswalked
Brazil LGPD	13.709/2018	18	12	PopulatedCrosswalked
CCPA / CPRA	2024	17	13	PopulatedCrosswalked
China PIPL	2021	18	12	PopulatedCrosswalked
DORA	(EU) 2022/2554	22	14	PopulatedCrosswalked
EU AI Act	(EU) 2024/1689	30	16	PopulatedCrosswalked
FedRAMP	Rev. 5 — 2024-05	28	18	PopulatedCrosswalked
GDPR	(EU) 2016/679	28	15	PopulatedCrosswalked
HIPAA Security & Privacy	2013 Omnibus	20	15	PopulatedCrosswalked
India DPDP Act	2023	16	11	PopulatedCrosswalked
ISO/IEC 27001:2022	2022	17	15	PopulatedCrosswalked
ISO/IEC 27701:2019	2019	15	12	PopulatedCrosswalked
ISO/IEC 42001:2023	2023	24	15	PopulatedCrosswalked
Japan APPI	2003 (Act No. 57); amended 2020 (effective 2022) + 2021	17	12	PopulatedCrosswalked
NIS2 Directive	2022/2555	17	14	PopulatedCrosswalked
NIST AI Risk Management Framework	1.0	20	14	PopulatedCrosswalked
NIST CSF 2.0	2.0	22	15	PopulatedCrosswalked
PCI DSS 4.0.1	4.0.1	12	14	PopulatedCrosswalked
SOC 2 Type II	2017 TSC	13	15	PopulatedCrosswalked
UK GDPR + DPA 2018	2018	16	10	PopulatedCrosswalked
EU Cyber Resilience Act	2024	18	13	Populated
HAARF — Healthcare AI Agents Regulatory Framework	1.0	12	21	Populated
HuggingFace Model Card	2024.04	9	0	Populated
SOC 1 Type II	SSAE 18 AT-C 320 (2017)	13	14	Populated

Populated — clauses, controls and self-assessment questions ship in the framework module.Crosswalked — framework appears in the CROSSWALKS edge set.

Worked example

One control. Many obligations.

A single reusable control satisfies multiple clauses across multiple frameworks, drives a concrete architecture capability, emits a single evidence stream, and lands inside every audit pack that needs it. Below is a real control object, mapped against real clause references from the populated framework modules.

Control object

CTRL-IAM-ACCESS-REVIEW-001

Periodic review of identity and access rights against business-need-to-know. Owner-approved, scheduled, evidenced.

Reusable across frameworks

Satisfies

↳ISO/IEC 27001Annex A.5Organisational controls — access control
↳SOC 2CC6Logical and physical access controls
↳PCI DSSReq. 7Restrict access on business need-to-know
↳NIST CSFPR.AAIdentity management, authentication and access control

Requires (architecture)

↳ RBAC / ABAC enforcement
↳ Identity event logs
↳ Scheduled review workflow

Emits (evidence)

↳ Quarterly access-review attestation
↳ Reviewer + approver identities
↳ Revocation log + delta

Appears in (audit packs)

↳ SOC 2 Type II
↳ ISO 27001 SoA
↳ PCI DSS ROC + AOC

Clause references above ship verbatim in @regunav/frameworks — ISO 27001 Annex A.5, SOC 2 CC6, PCI DSS Req. 7 and NIST CSF PR.AA are real clause records in the registry.

Before. After.

Left: what compliance looks like in side-systems. Right: what it looks like when the framework graph itself IS the system.

Before — side-systems

▸Regulation lives in PDFs
▸Controls live in spreadsheets
▸Evidence lives in folders
▸Architecture lives in engineers' heads
▸Audit packs assembled manually

After — the graph IS the system

▸Source clause mapped to obligation
▸Obligation mapped to reusable control
▸Control mapped to system capability
▸Policy enforced at runtime
▸Evidence captured continuously
▸Audit pack generated from the graph

Who is this for?

Compliance-to-architecture is not one job. The same control graph + evidence stream serves six different audiences — without forcing any of them to learn the others' tools.

Persona

Compliance teams

Translate obligations into controls and evidence.

Persona

Engineering teams

See what architecture capabilities each control requires.

Persona

Auditors

Trace each audit pack back to its source clause and underlying evidence.

Persona

AI governance teams

Map intended purpose, risk class, human oversight, and post-market monitoring.

Persona

CISOs

Connect controls to security architecture and policy-as-code.

Persona

Product teams

Know what must be built before launching in a given jurisdiction.

Who's evaluating the framework

Who is this for?

CtA is being evaluated and piloted across six categories of organisations. None of them are named here — named-customer attribution requires an explicit attestation letter (per the Compliance-by-Design principle). If you're piloting and want to be listed, open an attestation PR.

Regulated banks (pilot)

Crosswalking ISO 27001 + DORA + SOC 2 with one control set.

AI platforms (pilot)

Mapping EU AI Act Annex III high-risk obligations to runtime policies.

Healthcare SaaS (pilot)

HIPAA + GDPR + Saudi PDPL with a single evidence pipeline.

Payment processors (evaluation)

PCI DSS 4.0 + PSD2 SCA + DORA against the same control library.

Security teams (evaluation)

Policy-as-code unification — Cerbos + OPA bundles emitted from the graph.

Audit firms (research)

Verifying claims in audit packs against the open spec.

Submit an adopter attestation →

14 questions · the ones that actually get asked

Frequently asked questions.

An open framework that translates regulatory text (EU AI Act, GDPR, ISO 27001, SOC 2, PCI DSS, HIPAA, DORA, NIST CSF, and 16 more) into machine-readable controls, runtime policies, evidence schemas, and architecture patterns. It is published as a versioned specification + reference TypeScript implementation under Apache-2.0.

More questions? Open an issue on github.com/Compliance-to-Architecture/framework or join the spec discussion in the public RFC repo.

3-step adoption playbook

Bring this to your organisation.

A minimum-viable adoption fits in three steps and one afternoon. You do not need executive buy-in for step 1. You do not need a vendor for step 2. You do not need a project for step 3.

1
Read the spec, validate one control
Pick one existing control from your library — IAM access review, breach notification, encryption at rest — anything. Express it as a CtA manifest. Run it through the open validator. If the model fits, you have a 30-minute proof of concept.
Outcome
1 validated manifest
2
Fork the seed, add your private Rule Pack
Clone the open framework. Add a private Rule Pack on top — internal policies, bank-specific tightenings, sector overlays. Sign it with your org URN. The composition rules ensure your private Rule Pack cannot relax the open obligations — only tighten them.
Outcome
1 signed private Rule Pack
3
Wire the validator into your CI pipeline
Connect the validator to your CI/CD: every PR that touches a control / policy / evidence template runs the manifest schema check. Fail-closed on errors. This is the operating model at maturity tier L4 (Enforced).
Outcome
1 enforced CI gate

Self-serve

All three steps above can be completed entirely from the open repository. No vendor relationship required. No NDA. No call.

github.com/Compliance-to-Architecture/framework →

Enterprise rollout

For multi-tenant graph hosting, evidence storage, SLAs, and enterprise support, ReguNav operates a commercial implementation. The framework itself never requires the SaaS.

regunav.com →

Use it. Cite it. Extend it.

Apache-2.0. Open repository. Cite the framework version in your audit pack, your DPIA, your conformity dossier, your board pack.

View on GitHub →Read the specification spec.json (machine-readable)Conformance test

16 evidence-type JSON Schemas · 1 reference Cerbos bundle · 2 Terraform reference patterns (Cloudflare) · open-spec validator (zero deps).

ReguNav Compliance-to-Architecture Framework™, v0.1 (2026).
Regunav Inc. https://compliancetoarchitecture.com

Three steps to know if Compliance-to-Architecture™ fits.

Read the spec

See your maturity

Pick a partner

Turn regulations into software architecture.

What is Compliance-to-Architecture?

Event-driven by spec. No batch jobs. No post-facto.

Build your compliance stack.

Every team writes the same crosswalk. Compliance-to-Architecture™ writes it once.

Each compliance role uses the framework differently. The graph is the same.

Compliance is written for lawyers. Software is built by engineers. The gap is where risk lives.

Seven aspects of compliance — two ways.

Regulatory surface area, 2018 → 2026.

Compliance-to-Architecture changes the operating model.

Compliance-to-Architecture Framework™ vs OSCAL vs ATT&CK vs proprietary GRC.

Eight sectors, one framework graph.

How well do you know the framework?

What's at Layer 0 — the ROOT of the dependency chain?

Why are framework engines DETERMINISTIC (not LLM-backed)?

What's at L12 — the TOP of the chain?

What does a crosswalk in the framework represent?

Which policy-as-code engines does the framework compile to?

What is a 'manifest' in the framework?

The 8-Layer Spine.

Manifest

From legal obligation to runtime evidence.

The 13-layer Compliance-to-Architecture Graph™.

Risk / Harm

AI / System Governance

Runtime Monitoring

Language-agnostic by design.

Where does your organisation sit on the maturity model?

Where does your control library live?

How is evidence captured?

How do you crosswalk between frameworks (e.g. SOC 2 ↔ ISO 27001)?

Where do your controls actually run?

How are audit packs assembled?

Adding a new regulation to your scope today would require:

Validate a manifest.

Map a control once. Cover every framework that asks for it.

Periodic identity and access review

Authority coverage — what's open, what's mapped, what's on the roadmap.

Cross-walks across 20 regulations.

Browse the open ontology.

Know what applies, where, and why.

Geography

Convert controls into buildable system requirements.

Designed for the AI-regulation era.

Evidence pack lifecycle — 5 immutable states.

From ad-hoc to generative.

Ad-hoc

Documented

Mapped

Enforced

Generative

Where every framework actually stands.

One control. Many obligations.

Before. After.

Who is this for?

Compliance teams

Engineering teams

Auditors

AI governance teams

CISOs

Product teams

Who is this for?

Regulated banks (pilot)

AI platforms (pilot)

Healthcare SaaS (pilot)

Payment processors (evaluation)

Security teams (evaluation)

Audit firms (research)

Frequently asked questions.

Bring this to your organisation.

Read the spec, validate one control

Fork the seed, add your private Rule Pack

Wire the validator into your CI pipeline

Use it. Cite it. Extend it.