Orkena

TRUST CENTRE

The plumbing, stated honestly.

For procurement, legal and security reviewers. If a commitment below changes, this page changes and the change is dated. Nothing here claims a certification not held.

Legal entity

Orkena · Registered jurisdiction: entity registration pending · Business registration number: [to be confirmed before launch]. The registered entity name appears on the footer, on contracts and on the DPA, and is the contracting counterparty on every agreement. This line is updated the day the registration number exists, not before.

Procurement note: this page is the single source for the vendor-review inputs — entity, register, commitments — and every change is dated, so a review performed once can be refreshed against diffs rather than redone from scratch. Contract forms are published as they exist, not anticipated here.

Contact

Three domain mailboxes today; response SLA one business day. Dedicated security, privacy and legal addresses are the plan as the team grows — this page updates the day they exist.

Sub-processors

The register lists only processors Orkena actually uses. The strongest row in it is the first one: zero by default. A VPC or air-gapped deployment — the two modes shipping today — runs every component (Postgres, Redis, object store, API, workers, sandbox) inside your infrastructure, with telemetry disabled. In that shape the sub-processor list is empty, and the architecture is the evidence that it is allowed to be.

Two sets of processors exist outside that shape:

Section A — build and release pipeline. Processors of Orkena's source code and artifacts; no customer data passes through these in a self-hosted deployment:

ProcessorRoleData processed
GitHub, Inc.Repository hosting, CI/CD, vulnerability reportingSource code, CI configuration, scan results, release artifacts
Python Software Foundation (PyPI)Package registryPublished Python package artifacts, publish-time only
npm, Inc.Package registryPublished SDK artifacts, publish-time only
Container registries (GHCR / Docker Hub)Image distribution; base images at buildSigned container images

Section B — operator-declared. Per-deployment integrations that you configure: the LLM provider your graph calls (bring-your-own-key — prompts and tool calls route to the endpoint you declare), your OTel backend if you enable telemetry export, your object store if it is a vendor S3 endpoint rather than self-hosted MinIO, and your KMS vendor if you use a cloud driver rather than the local driver. Each deployment registers these itself — the platform cannot know which endpoints you point at, and does not pretend to. Air-gapped deployments declare none.

A hosting provider for the managed tier joins Section A when that tier ships (roadmap, 2027) — region-pinned per tenant, and the register updates before, not after. Sub-processor changes are notified 30 days in advance with a right to object, and the register is reviewed quarterly, aligned to the same cadence as the backup and DR drills.

Data residency

  • Managed tier (roadmap, 2027), region-pinned: data at rest never leaves the region you select; residency labels are carried per tenant and per run
  • Customer VPC: your cloud, your region, your KMS, your network
  • Air-gapped: no outbound connectivity, ever; local models for embeddings and classifiers

Residency is not asserted — it is carried. Region labels travel with the tenant configuration and into evidence exports, so a residency question answers from the artifact rather than from a policy statement.

Retention model

Default retention is customer-configurable per workspace, with legal hold available. Evidence bundles — the ledger slices, anchors, public keys and reports — are yours permanently; exports are available at any time and verify without any Orkena service in the loop. Hard-delete is available on request with written confirmation, and key material is destroyed under your KMS control, after which nothing Orkena holds is recoverable by anyone.

Incident commitment

Classification follows DORA-style criteria — affected customers, duration, geographical spread, data-loss severity, criticality of services, economic impact — with the evidence for each criterion drawn from the platform's own record: SLO snapshots, ledger volumes per org, chain-verification results. From the point an incident is classified:

ReportDeadline
Initial notification≤ 24 hours
Intermediate status≤ 72 hours
Final report — root cause, impact, remediation, lessons≤ 1 month

Communication runs through your designated security contact. Post-mortems are written and shared; findings feed the SDLC. In VPC and air-gap modes, your team runs the incident process — Orkena has no access to your environment by design — and the ledger gives you the immutable record of everything the runtime did.

Business continuity

Managed tier (roadmap, 2027): three-region high availability, validated in a controlled test environment; RPO/RTO commitments will be documented in the DPA rather than asserted here. VPC and air-gap modes inherit your infrastructure's posture; the software resumes runs from checkpoint after failure. The drills are documented runbooks either way — backup/restore with ledger re-verification, regional failover, game-day rehearsal, kill switch — so continuity is practiced, not promised.

Certifications and attestations

The honest register, dated 2026-08-16: no external audit has yet been completed against SOC 2, ISO 27001, or any other framework.

  • SOC 2: readiness — audit engagement planned (Type I planning now; Type II observation window targeted within 12 months)
  • ISO/IEC 42001: control mapping shipped
  • NIST AI RMF: control mapping shipped
  • HIPAA: designed to support administrative and technical safeguards
  • ASVS L2: self-assessment maintained against the application-security surface
  • Penetration testing: pen-test-style suites run in CI; an external commercial engagement against the staged deployment is planned before GA

When an attestation lands, it will be added here, dated, one framework at a time — never batched, never anticipated.

DPA

The standard Data Processing Agreement is available on request from info@orkena.com. It covers processing roles (Orkena as Processor, you as Controller), instructed-processing scope, data residency, sub-processor commitments (30-day notice, right to object, quarterly review), incident notification per the table above, deletion at end of contract with written confirmation, and audit rights — your auditors may verify, and the evidence bundles give them something concrete to verify against. The current sub-processor register travels with the DPA.

On audit: Orkena supports customer audit rights with documentation and, where the deployment allows it, evidence-bundle verification rather than conference-room testimony — the artifacts your auditor checks are the same ones the runtime produced, not exports prepared for the occasion. The DPA's audit clause and the evidence-bundle mechanism are designed to line up.

One rule governs this whole page: if a commitment changes, the page changes, and the change is dated. The trust centre is not marketing; it is a record.