Legal
Data Processing Addendum.
Our GDPR Article 28 obligations, the security measures we apply, and the sub-processors we use.
1. The parties & subject matter
This Data Processing Addendum (the "DPA") forms part of, and is governed by, the Terms of Service or Order Form between the Customer (the "Controller") and Kanonik LLC (the "Processor") for use of Kanonik (the "Service").
The Processor will Process Personal Data on behalf of the Controller in connection with the Service, in accordance with this DPA. Capitalised terms not defined here have the meaning given in the Terms of Service or in Regulation (EU) 2016/679 (the "GDPR") and its UK equivalent (the "UK GDPR").
2. Duration & termination
This DPA applies for the duration of the Customer's Subscription. On termination, the Processor will return or delete Personal Data in accordance with Section 12.
3. Nature & purpose of processing
The Processor will Process Personal Data only as necessary to provide the Service and to comply with the Controller's documented instructions, including (a) running the MCP server and tools, (b) executing the server-side Verifier, (c) producing and storing audit-log events, (d) generating Auditor Export bundles, and (e) reading and writing to the Controller's GRC tool on the Controller's authority.
The Controller's acceptance of the Terms of Service, the configurations the Controller makes in the Service, and any subsequent written instructions from the Controller constitute its documented instructions to the Processor.
4. Categories of personal data & data subjects
Categories of personal data: as described in Annex I. In summary: (a) account data of the Controller's authorised users (name, work email, role, OIDC subject identifier); (b) the canonical representation of the Controller's GRC entities (controls, evidence, mappings) which may incidentally contain the names of the Controller's personnel; (c) audit-log content describing operations on (a) and (b); (d) approval-token references and approver identities.
Categories of data subjects: the Controller's employees, contractors, and authorised users; the Controller's customers, suppliers, and third parties to the extent they appear in Customer Data.
The Service is not designed to process special categories of personal data within the meaning of GDPR Article 9. The Controller agrees not to submit special-category data unless strictly necessary; if it does, additional measures may apply by separate agreement.
5. Processor obligations
The Processor will:
- Process Personal Data only on documented instructions of the Controller, including with regard to international transfers, unless required by applicable law (in which case the Processor will inform the Controller of that legal requirement, unless prohibited);
- Ensure that personnel authorised to Process Personal Data are bound by confidentiality obligations or are under appropriate statutory obligations of confidentiality;
- Take all measures required pursuant to GDPR Article 32 (security of processing), as detailed in Annex II;
- Engage sub-processors only in accordance with Section 6 and impose on them obligations no less protective than those in this DPA;
- Assist the Controller, taking into account the nature of processing, in fulfilling its obligations to respond to requests from data subjects (Section 9);
- Assist the Controller in complying with its obligations under GDPR Articles 32-36 (security, breach notification, DPIAs, prior consultation), taking into account the nature of processing and the information available to the Processor;
- At the choice of the Controller, delete or return all Personal Data after the end of the provision of services (Section 12);
- Make available to the Controller all information necessary to demonstrate compliance with this DPA and allow for and contribute to audits, in accordance with Section 11.
6. Sub-processors
The Controller provides general written authorisation for the Processor to engage the sub-processors listed in Annex III.
The Processor will inform the Controller of any intended addition or replacement of sub-processors at least thirty (30) days before the change takes effect, by updating Annex III at this URL and notifying registered Customers by email.
The Controller may object to a new sub-processor on reasonable grounds within fifteen (15) days of notification by emailing [email protected]. If the Controller objects, the parties will work together in good faith to resolve the objection. If no resolution is reached, the Controller may terminate the affected Subscription with a pro-rata refund of pre-paid fees.
The Processor remains fully liable to the Controller for the performance of its sub-processors' obligations.
7. International transfers (SCCs)
Where the Processor transfers Personal Data of EU / EEA / UK / Swiss data subjects outside the EEA / UK / Switzerland to a country not covered by an adequacy decision, the parties agree that the European Commission's Standard Contractual Clauses (Decision 2021/914), Module 2 (Controller to Processor) or Module 3 (Processor to Sub-Processor) as applicable, are incorporated into this DPA by reference. The UK International Data Transfer Addendum (or its replacement) is incorporated for transfers from the UK.
Where the SCCs require party choices, the parties agree:
- Clause 7 (docking): the option is enabled;
- Clause 9(a) (sub-processors): option 2 (general written authorisation), with thirty (30) days' notice as set out in Section 6 above;
- Clause 11 (independent dispute resolution): the optional element is not selected;
- Clause 17 (governing law): the law of Ireland;
- Clause 18 (forum): the courts of Ireland;
- Annex I, II, and III of the SCCs are populated by Annexes I, II, and III of this DPA respectively.
The Processor has assessed transfer impact and applies supplementary technical measures (encryption in transit and at rest, key isolation, pseudonymisation where feasible) consistent with European Data Protection Board recommendations.
8. Security measures
The Processor implements and maintains the technical and organisational measures set out in Annex II, designed to ensure a level of security appropriate to the risk of processing.
The Processor's architecture is designed to be compatible with FedRAMP Moderate baseline expectations from day one (FIPS 140-validated cryptography, mTLS internal services, append-only audit log, signed events, infrastructure-as-code with GitOps, signed container images and SBOM per build, supply-chain vulnerability scanning in CI). Authorisation pursuit is on the Processor's longer-term roadmap and not represented as obtained.
9. Data subject rights
The Processor will, taking into account the nature of processing, assist the Controller by appropriate technical and organisational measures, insofar as possible, in fulfilling the Controller's obligation to respond to requests for exercising the data subject's rights under Chapter III GDPR (rights of access, rectification, erasure, restriction, portability, objection, and rights related to automated decision-making).
Where data subjects contact the Processor directly, the Processor will, without undue delay, refer them to the Controller and inform the Controller of the request.
The Processor offers the following self-service mechanisms accessible to the Controller:
- Auditor Export - one-click signed bundle (PDF + JSON) of all events, mappings, evidence, and reasoning for a tenant, supporting access and portability requests;
- Tenant deletion - multi-step delete with 30-day grace period followed by cryptographic erasure (Section 12), supporting erasure requests;
- REST API access (Team and Business tiers) for granular data export.
10. Personal data breach notification
The Processor will notify the Controller without undue delay, and in any event within seventy-two (72) hours, after becoming aware of a Personal Data Breach affecting the Controller's Personal Data. The notification will include, to the extent then known:
- The nature of the breach, including the categories and approximate number of data subjects and records affected;
- The likely consequences of the breach;
- The measures taken or proposed to address the breach, including measures to mitigate possible adverse effects;
- The Processor's contact point for further information.
The Processor will continue to update the Controller as additional information becomes available and will cooperate with any necessary investigation, regulatory reporting, or notification to data subjects.
11. Audit & inspection rights
The Processor will make available to the Controller, on request, the most recent third-party audit reports (e.g., SOC 2 Type II reports when obtained) and a written summary of its security and privacy practices.
The Controller may, no more than once per twelve-month period (or more frequently where required by a competent supervisory authority or following a Personal Data Breach), conduct an audit of the Processor's compliance with this DPA. Audits will be conducted at the Controller's expense, on at least thirty (30) days' written notice, during normal business hours, in a manner that does not unreasonably disrupt the Processor's business or compromise the confidentiality of other customers' data, and subject to a written confidentiality agreement.
The Processor may satisfy audit requirements by providing the Controller with the audit reports referenced above.
12. Return or deletion of personal data
On termination of the Subscription, the Processor will, at the Controller's choice and within the timelines below:
- Within 30 days of termination - make Personal Data available for export by the Controller via the Auditor Export and (where applicable) the REST API;
- After the 30-day grace period - destroy the Controller's tenant-level encryption keys (the "crypto-erase" described in the Privacy Policy), rendering Personal Data mathematically inaccessible;
- Append-only audit log entries - retained in the Processor's event store for the regulatory retention period stated in the Privacy Policy (currently 7 years), with the underlying Personal Data already inaccessible due to crypto-erase.
The Processor will provide written confirmation of crypto-erase on request.
13. Liability & precedence
The liability of each party under this DPA is subject to the limitations set out in the Terms of Service. In the event of any conflict between this DPA and the Terms of Service in respect of Personal Data processing, this DPA prevails.
Where the SCCs are incorporated under Section 7 and conflict with any other term of this DPA or the Terms of Service, the SCCs prevail.
Annex I
Description of processing
A. List of parties
Data exporter (Controller): the Customer entity that has accepted these terms.
Data importer (Processor): Kanonik LLC, organised under the laws of the State of Wyoming, United States of America. Contact: [email protected].
B. Description of transfer
- Categories of data subjects: the Controller's authorised users (employees, contractors, vCISOs); other individuals named in Customer Data (e.g., policy owners in the Controller's GRC tool).
- Categories of personal data: identification (name, work email, role, country); authentication (OIDC subject identifier, MFA enrolment status); usage (MCP tool calls, Verifier verdicts, approval references, sync operations); communications (support tickets, onboarding and customer correspondence).
- Special categories of personal data: none anticipated. The Service is not designed for special-category data.
- Frequency of transfer: continuous, for the duration of the Subscription.
- Nature of the processing: hosting, storage, transmission, computation (rule-based and LLM-based verification), encryption, signing, audit logging.
- Purpose of processing: to provide the Kanonik Service to the Controller as set out in the Terms of Service.
- Retention: as described in the Privacy Policy Section 8 and DPA Section 12.
C. Competent supervisory authority
For Customers established in the EU or with EU data subjects, the supervisory authority is determined under GDPR Article 56. As the Processor is established in the United States, EU/UK data subjects may lodge complaints with their local supervisory authority.
Annex II
Technical and organisational security measures
The Processor implements and maintains the following measures, derived from its product Architecture Decision Records and updated as the architecture evolves:
1. Cryptography
- FIPS 140-validated cryptographic modules for all key operations;
- TLS 1.3 for all external traffic, with FIPS-validated cipher suites;
- Mutual TLS (mTLS) between internal services, with FIPS-validated cipher suites;
- AES-256-GCM for symmetric encryption at rest and for in-flight payload envelopes;
- ECDSA P-384 for chain-root signing (highest-value key); ECDSA P-256 for short-lived approval tokens and mTLS;
- SHA-256 for content hashing; SHA-384 for chain-root signing payloads.
2. Audit & accountability
- Append-only event store, hash-chained from creation;
- Every event signed at creation with a FIPS-validated key (Ed25519 or ECDSA P-384);
- Hash-chain verification included in every Auditor Export;
- Operational logs retained per tier (30 days / 90 days / 1 year for Solo / Team / Business);
- Audit-log events retained for a minimum of seven (7) years.
3. Authentication & authorisation
- OIDC-based identity for the Service dashboard;
- Multi-factor authentication enforced for privileged operations;
- RBAC plus capability-based per-MCP-session scoping;
- Multi-tenant isolation through (a) type-system separation (branded UUIDs make cross-tenant references impossible), (b) signed tenant-context propagation, (c) Postgres row-level security with FORCE ROW LEVEL SECURITY, (d) per-tenant data encryption envelopes.
4. System & communications protection
- Per-tenant data encryption envelope: a per-tenant Data Encryption Key (DEK) wrapped by a per-tenant Key Encryption Key (KEK) held in the Processor's secrets vault;
- Cloud-portability: no vendor-specific dependencies in application code (isolated to infrastructure-as-code modules);
- Network segmentation between authentication, application, and data tiers.
5. System & information integrity
- Container images signed (cosign) and verified at deploy time;
- Software Bill of Materials (CycloneDX) generated per build and attached to releases;
- Server-side Verifier non-bypassable: rule-based deterministic checks plus an independent LLM cross-check, both required to pass before any commit;
- Confidence-gated commit: proposals below a configurable confidence threshold are routed to a manual review queue and never auto-applied;
- Hash-chained events make tampering detectable.
6. Supply-chain protection
- Permissive open-source license policy: only MIT, Apache 2.0, BSD, ISC, MPL 2.0, PostgreSQL License, and similar licenses in runtime dependencies;
- GPL / LGPL / AGPL prohibited in runtime dependencies (limited exceptions only when isolated by process and network boundaries, documented and reviewed);
- CI enforces license policy on every build (build fails on prohibited licenses);
- Dependency lock files committed and reproducible;
- govulncheck, gosec, trivy fs, and trivy image run in CI; HIGH/CRITICAL findings block merge;
- SBOM linked to vulnerability databases on each release.
7. Configuration management
- Infrastructure-as-code (OpenTofu) - no manual production changes;
- GitOps continuous deployment (Argo CD) - every production change is a reviewed pull request;
- All services versioned; rollback path documented.
8. Risk assessment & incident response
- Living threat model maintained at each major architectural milestone;
- Documented break-glass procedure for emergency access; all break-glass actions logged;
- Forensics supported by the audit log;
- Personal Data Breach notification per DPA Section 10.
9. Contingency planning
- Encrypted snapshots of the Service event store every fifteen (15) minutes;
- Backups retained for thirty (30) days for disaster recovery;
- Materialised views derived from events are rebuildable from the event store.
10. Personnel security
- Personnel with access to Personal Data sign confidentiality agreements;
- Need-to-know access controls;
- All admin access logged and surfaced to the Customer where appropriate.
Annex III
List of sub-processors
This list is current as of the "Last updated" date at the top of this page. The Processor will update this list and notify registered Customers in accordance with Section 6 of the DPA.
| Sub-processor | Purpose | Data categories | Location of processing |
|---|---|---|---|
| Oracle Cloud Infrastructure (OCI) | Compute, storage, networking, object storage for the Service. Infrastructure is cloud-agnostic by design (portable infrastructure-as-code); currently hosted on OCI. | All Service data, encrypted at rest and in transit | United States |
| Cloudflare, Inc. | CDN, edge delivery, TLS termination, DDoS and WAF protection, and security-header enforcement for the Service | HTTP request metadata (IP address, request headers); no GRC content stored at the edge | Global edge network (United States primary) |
| Anthropic, PBC | Server-side Verifier LLM calls (rule-based plus LLM cross-check before commit) | Canonical entity excerpts and retrieved candidates; PII redacted at ingress | United States (Anthropic data-handling terms apply) |
| Stripe, Inc. | Merchant of Record (Stripe Managed Payments): subscription billing, payment processing, global tax calculation and remittance, and chargeback handling. As Merchant of Record, Stripe determines the means and purposes of certain billing and tax-remittance processing and acts as an independent controller for those functions under its own terms. | Billing contact, company name, billing address, payment method (card data is processed by Stripe under PCI DSS; the Processor does not store full card numbers) | United States |
| Postmark (Wildbit, LLC) | Transactional and approval-link email delivery | Recipient email and approval-token references; no GRC content | United States |
| Slack Technologies, LLC (optional, per-tenant opt-in) | Approval-channel notifications | Approval-token references; no GRC content | United States |
| Self-hosted SigNoz on OCI | Operational logs, traces, metrics | Service performance data; PII redacted at ingestion | United States |
| The Customer's own GRC tool (e.g., Eramba) | Read and draft-write to the Customer's GRC tool, on the Customer's authority and using credentials the Customer provides | Whatever the Customer has stored in that tool, accessed via Customer-provided credentials | Wherever the Customer hosts that tool |
Sub-processors planned for future Service phases (introduction will trigger Section 6 notification): a cloud HSM (provider-appropriate to the deployment, consistent with the cloud-agnostic posture above) for hardware-rooted key isolation in the Enterprise tier; an isolated, government-cloud-bound model-access path for Customers who require it.