The GRC tool you already pay for.
Now with a Verifier in front of it.

This page is the canonical list of supported integrations. We update it as new connectors ship.

---

Live today

Eramba (open-source GRC).

We support Eramba, the open-source GRC platform. Eramba is the first connector because it has a well-documented REST API, an active community, and we use it ourselves.

Eramba version compatibility: 3.18.0 minimum, 3.21.0 maximum tested. We track new Eramba releases and update the connector as needed.

What the connector does:

Entity	Read	Draft write	Direct write	Webhook
Controls	✓	✓ (via review status)	Roadmap	Not supported by Eramba
Control Mappings	✓	✓	Roadmap	Not supported by Eramba
Evidence	✓	✓	Roadmap	Not supported by Eramba
Risks	✓	Read-only today	Roadmap	Not supported by Eramba
Policies	✓	Read-only today	Roadmap	Not supported by Eramba
Frameworks	✓	Read-only: frameworks are managed in Eramba	n/a	n/a
Requirements	✓	Read-only: sourced from Eramba	n/a	n/a

Approval model. Commits land as drafts in Eramba (status review); your reviewer approves in Eramba's UI. For changes Eramba doesn't support as drafts, the change waits behind a signed approval link sent to your CISO over email or Slack; clicking the link commits the change with a cryptographically signed approval token. Direct-write to Eramba is a Business-tier roadmap feature requiring explicit per-entity-type enable.

Connection. During onboarding, you provide your Eramba base URL and a bot-user API token. We provide the setup script to create the bot user with minimum-necessary permissions. We validate the connection by calling Eramba's /api/v1/user/me endpoint. If your Eramba instance is reachable only inside your network, a reverse-tunnel agent ships on the roadmap.

Provenance. Every entity Kanonik reads from or writes to Eramba carries a connector-provenance tag identifying the connector version (eramba/v1). An auditor reading your Eramba data can tell what came from Kanonik and when.

---

Roadmap

Four connectors next, in priority order.

Connector build order is driven by Founding Customer cohort signal. We do not commit to dates we have not started; we do commit to the order.

1. Vanta: next; build kicks off when the cohort signal commits.
2. Drata
3. Hyperproof
4. ServiceNow GRC

RSA Archer, OneTrust, and AuditBoard ship as customer demand justifies. Tell us your stack when you request a demo and you change the priority.

---

Source-to-destination pairs. Audit continuity across tools.

Connectors are useful on their own (Kanonik on top of your existing tool). Connector pairs make something more possible: read your compliance program out of one GRC tool, walk it through the canonical model, commit it into the next; the hash-chained evidence spans the transition uninterrupted. No audit-period gap. No "the chain restarted when we moved."

What is shipping when:

• Live today. Eramba as a single connector. Zero pairs (a pair requires two live connectors).
• Next pair shipping. Eramba <-> Vanta, with the Vanta connector build kicked off by Founding Customer signal. Either direction supported by the same canonical primitives.
• Following pairs. Each new connector that ships adds N-1 new directed pairs against the already-live set. By the time the four-connector roadmap completes (Vanta, Drata, Hyperproof, ServiceNow GRC), ten directed pairs are live.
• What we are NOT promising. A connector framework that automates one specific vendor-to-vendor migration as a single-click wizard. Migrations involve human judgement (control mappings, evidence re-classification, workflow re-design) that Kanonik supports through the canonical model and the Verifier but does not perform unattended.

The architectural primitive is the canonical model itself. In production code today. Each new connector is mechanical work; the schema decision that makes portability possible is already made. The chain follows the data; the data does not follow the tool.

---

How the connector model works

Connectors are products in their own right, not library code. Each connector ships with:

• A capability matrix declaring which entity types support read, draft-write, direct-write, and webhook subscription
• A canonical mapping that translates between the GRC tool's native entities and Kanonik's canonical model
• A sync state machine (IDLE -> FETCHING -> TRANSLATING -> RECONCILING -> COMPLETE) with explicit error handling and retry semantics
• Round-trip fidelity tests that verify a Kanonik-authored entity, written to the GRC tool and read back, produces an identical canonical entity
• Version compatibility window specifying which versions of the GRC tool the connector supports

Connector versions are independent of the canonical model. A connector at v1 may continue working as the canonical model moves to v2 and beyond, within published backward-compatibility windows.

---

Custom or in-house GRC tools

We hear this question often. Two options exist:

1. Wait for the connector we're building. If your in-house tool is similar to a commercial one we're roadmapped for, the eventual connector may cover your needs with configuration.
2. Sponsor a custom connector. Roadmap Enterprise customers can sponsor a connector to their in-house GRC tool. We deliver the connector as a versioned package under the same capability-matrix discipline that governs the public connectors. Talk to us about scope.

We do not build one-off integrations that ship outside the connector framework. The framework is what makes the audit-trail and Verifier story work consistently across every GRC tool we touch.

---

Talk to us

If your GRC tool is not on this list and you would like to discuss a connector, contact hello@kanonik.ai. Tell us what you use, how you use it, and what you would want Kanonik to do with it.