COMPLIANCE
Mapped to the regimes you are examined against.
How to read this page: these are Orkena's runtime controls mapped to your obligations. Orkena is not certified against these frameworks on your behalf — it produces the runtime controls and the evidence your own certification and supervisory processes require.
| REGIME | STATUS | WHAT ORKENA PROVIDES |
|---|---|---|
| DORA | In force since Jan 2025 | ICT risk evidence, resilience testing artefacts, third-party register inputs |
| EU AI Act — Annex III high-risk | Applies 2 Dec 2027 | Article 12 logging, Article 14 human oversight, Article 15 accuracy and robustness controls |
| ISO/IEC 42001 | Control mapping shipped | AI management-system evidence per clause |
| NIST AI RMF | Control mapping shipped | Govern / Map / Measure / Manage coverage |
| SOC 2 | Readiness — audit engagement planned | Controls implemented; report to design partners on completion |
| HIPAA | Designed to support administrative safeguards | Access controls, audit controls, integrity controls, transmission security |
How the mapping works
Every mapping on this page follows one structure: an obligation in the regulation, the Orkena control that answers it, and the evidence artifact that proves the control ran. The controls come from a catalog — policy engine, human-in-the-loop gates, the hash-chained ledger, purpose-tagged data access, the run inspector and evidence bundles, eval-gated promotion, taint containment, right-to-be-forgotten cascade, RBAC, model governance, the sandbox, guardrails, kill switch, retention, and residency pinning — and each control carries at least one machine-checkable evidence artifact: a ledger event category, a config object, an exported bundle, or a runbook. A control without evidence does not enter the catalog, and a gap is stated in the catalog rather than hidden.
Two rules govern everything below. First, Orkena is a runtime, not a certifier: these mappings support your conformity assessment, your audit, your supervisory notification — they do not replace them. Second, where a mapping is a proposal rather than a confirmed interpretation, it says so on the page.
The catalog, in its current form:
| Control | What it does | Evidence artifact |
|---|---|---|
| Policy engine | Authorizes every action in Cedar, in-process, before execution | ledger:policy.decision, config:policies |
| Human-in-the-loop gates | Quorum, SLA, escalation on high-impact actions | ledger:gate.opened / resolved / escalated |
| Audit ledger | Per-tenant hash chain of every authorization, execution, approval, admin event | ledger:*, bundle:ledger_chain |
| Purpose-tagged access | Every memory read and retrieval records its purpose | ledger:memory.read, ledger:knowledge.retrieved |
| Run inspector & bundles | Readable narrative, control table, run timeline per run | bundle:narrative, ledger:stream.chunk |
| Eval-gated promotion | No version reaches production without passing its regression suite | ledger:promotion.completed, config:evals |
| Taint containment | Provenance tracking; irreversible actions from untrusted content denied by default | ledger:policy.decision, ledger:guardrail.triggered |
| Right-to-be-forgotten cascade | Purge events propagate across memory, runs and exports | ledger:memory.purged |
| RBAC | Role-based access; every tenant route requires an explicit permission | ledger:auth.login, config:roles |
| Model governance | Model allowlist; the model used is recorded per run | config:models, ledger:run.started |
| Guardrails | Budgets, hard-pause, structural loop bounds | ledger:guardrail.triggered |
| Kill switch | Pause or cancel runs at org / workspace / graph / agent level | ledger:run.paused, ledger:run.cancelled |
| Retention & legal hold | Configurable retention policies per workspace | ledger:retention.policy.upsert, config:retention_policies |
| Residency pinning | Region labels carried per tenant and per run | config:regions, bundle:residency |
| Backup / restore | Dump → restore → migrate → ledger re-verification drill | Backup-restore runbook, chain re-verify |
| Annex IV documentation | EU AI Act technical documentation inputs, seven blocks | bundle:control_table, config:graph_dsl |
A control that loses its evidence does not stay in the catalog — the pairing is test-enforced, not editorial. Where a framework obligation is covered by a planned control rather than a shipped one, the gap is listed under the regime below instead.
DORA
DORA (the EU Digital Operational Resilience Act) has been in force since January 2025 and the examinations have begun. It requires financial entities to demonstrate documented governance and control over their ICT risk, including third-party ICT providers. Orkena answers the operational-resilience articles with runtime controls whose evidence is the platform's own immutable record.
| DORA article | Orkena control mapping | Evidence artifact |
|---|---|---|
| Articles 5–8 — ICT risk management | Policy-as-code evaluated on every action; guardrails (budgets, hard-pause) on every run; kill switch at four levels | ledger:policy.decision, ledger:guardrail.triggered, kill-switch runbook |
| Article 9 — protection and prevention | Per-tenant RLS isolation, envelope encryption under your KMS, egress control on code execution, taint containment on untrusted content | RLS test suite, sandbox egress matrix, ledger:policy.decision |
| Article 10 — detection | SLO snapshots, drift alerts, distributed traces | SLO-breach runbook, alert history |
| Article 11 — response and recovery | Four-tier kill switch (org / workspace / graph / agent); durable executor resumes runs from checkpoint after failure; regional HA/DR runbook with drill (standby region, ledger quorum) | Kill-switch and HA/DR runbooks, ledger:run.paused, ledger:run.cancelled |
| Article 12 — backup and restoration | Backup/restore drill: dump → restore → migrate → ledger re-verification, proving the evidence chain survived | Backup-restore runbook + drill script |
| Article 18 — register of information | Sub-processor register with functions and regions; zero sub-processors by default in air-gap mode | Register on the trust centre |
| Article 19 — major incident reporting | DORA-style initial / intermediate / final report templates (24 h / 72 h / 1 month), each field mapped to platform evidence | Incident-reporting template |
| Articles 24–25 — testing | Chaos suites in CI (Postgres failover, Redis flush — invariants: no duplicate effects, no lost audit), game-day rehearsal runbook | Chaos test suite, game-day runbook |
| Articles 28–29 — third-party contractual arrangements | DPA on request; sub-processor changes notified 30 days in advance with right to object | Trust centre, DPA |
Known gaps, stated honestly: the Art. 19 report template and the Art. 18 register exist as documents and platform evidence, but the in-product workflow that walks an operator from classification to submitted notification is not yet productized; detection signals ship, classification workflow is roadmap. And DORA also requires entity-level incident reporting processes, business continuity testing programmes and board-level attestations that are the institution's own obligations. Orkena produces the runtime evidence that supports those processes; it does not perform them on your behalf.
The DORA drill, end to end: run the chaos suite — induced Postgres failover and Redis flush — and confirm the invariants (no duplicate effects, no lost audit). Engage the kill switch mid-run and read the pause events off the ledger. Execute the backup/restore drill and re-verify the chain after the restore. Then file an Art. 19 initial report from the incident-reporting template, with each field pointing at a ledger row or an SLO snapshot. Every claim in the report resolves to a row in the record — that is the property DORA is really asking for.
EU AI Act — Annex III high-risk
The Annex III high-risk provisions apply from 2 December 2027 — the buying trigger for the finance, health and public-sector use cases Orkena is built for. (General-purpose-AI obligations have been enforced since August 2025; prohibited practices from December 2026.) One honest framing note first: the article-to- control pairing below requires legal confirmation against the official text before customer use — this mapping is engineering provenance, not a legal opinion.
| Article | Orkena control mapping | Evidence artifact |
|---|---|---|
| Article 9 — risk management system | Policy engine (Cedar) on side-effectful steps; guardrails with budgets and hard-pause | ledger:policy.decision, ledger:guardrail.triggered |
| Article 10 — data and data governance | Right-to-be-forgotten cascade; configurable retention with legal hold | ledger:memory.purged, ledger:retention.policy.upsert |
| Article 11 — technical documentation | Annex IV documentation inputs in seven blocks: system description, system details, monitoring, risk management, changes, conformity, management | Control table exports, graph DSL config, security documentation |
| Article 12 — record-keeping | Per-tenant hash-chained ledger with Ed25519 signed anchors; every action, authorization, approval and administrative event; the model used recorded per run | ledger:run.started, ledger:step.completed, ledger-chain bundle, offline-verifiable |
| Article 13 — transparency | Run inspector, evidence bundles with readable narrative, token streaming for user-facing transparency | bundle:narrative, ledger:stream.chunk |
| Article 14 — human oversight | HITL gates with quorum, SLA and escalation; four-eyes approvals; conflict-of-interest blocking (self-approval, same-team) | ledger:gate.opened, ledger:gate.resolved, ledger:gate.escalated |
| Article 15 — accuracy, robustness, cybersecurity | Evaluation-gated promotion — no version reaches production without passing the regression suite; taint-based injection containment; sandbox isolation for code execution | ledger:promotion.completed, SSRF matrix, sandbox egress matrix |
| Article 26 — deployer obligations | RBAC, kill switch, break-glass with dual control and full audit | ledger:auth.login, kill-switch runbook |
Known gaps, stated honestly: there is no built-in prohibited-use classification workflow for Art. 5 screening (policy packs can express the restriction, but the checklist is not a product flow), and per-regime template selection for conformity assessments is not yet a shipped UX. Both are tracked roadmap items. What you (the deployer) bear under Articles 16–29 — conformity assessment, registration, post-market monitoring — Orkena supports with the technical-documentation inputs and the audit trail above, and cannot perform for you.
How the Annex IV blocks fill in practice: the system description
is the versioned graph definitions; the monitoring block is the
eval-gated promotion record plus drift alerts; the risk-management
block is the policy packs and their change history; the changes
block is the ledger's admin and gate
categories. The control table export assembles these per
obligation — the exporter organizes what the runtime already
records; it does not write anything new for the occasion.
ISO/IEC 42001
ISO/IEC 42001 is the AI management-system standard: an organization-wide system for governing AI, assessed by an external certifier. Orkena's control mapping ships per clause, aligned to an AI-MS evidence pack:
- Clause 6.1 — risks and opportunities: the ledger is the record of AI system operation; taint propagation and eval gates make risk measurable per run rather than estimated per quarter.
- Clause 8.1 — operational planning and control: policy packs are the governance framework encoded — versioned, immutable, and changeable only through simulation and review; eval-gated promotion is the change-management control.
- Clause 10.x — improvement: post-incident deterministic replay, drift detection with alert routing, and consolidation of memory with human veto give the management system its feedback loops.
The evidence bundles are the audit artifacts: export a control table, run timeline and ledger chain per clause, verifiable offline. Clause-by-clause mapping is available to design partners on request. As with every framework here: the mapping supports your certification; it is not one.
One structural note for the management-system reader: an AI-MS is audited on operation, not on aspiration. The auditor asks what the system did, how changes were controlled, and how failures were absorbed. Those three questions are exactly the three surfaces Orkena records — the ledger for what happened, the eval-gated promotion path for what changed, and the replay plus post-incident record for what went wrong and what was learned. The mapping above is clause-to-control; the deeper fit is question-to-surface.
NIST AI RMF
The NIST AI Risk Management Framework's four functions — Govern, Map, Measure, Manage — map directly:
- Govern: policy-as-code with versioned, immutable policy packs; approval gates with quorum and escalation
- Map: graph definitions are versioned and diffable; every run's context is captured; taint and data labels track provenance end to end
- Measure: evaluation suites as first-class objects; regression eval on every promotion; drift detection with alert routing
- Manage: kill switch at four levels; incident response with notification commitment; right-to-be-forgotten cascade
The mapping extends to the NIST AI 600-1 generative-AI profile's risk categories, with one category — environmental impact — marked uncovered by design rather than hand-waved. Honest coverage, not total coverage.
Concretely, each function maps to an artifact rather than an intention: Govern to the versioned, immutable policy packs and the approval-gate ledger events; Map to the diffable graph definitions and the per-run context capture; Measure to the evaluation suites that gate every promotion and the drift alerts that route to owners; Manage to the four-level kill switch and the incident-reporting commitment. A risk practitioner reading the RMF can point at each function and name the artifact.
SOC 2
Readiness — audit engagement planned. No SOC 2 report exists yet, and this page will not claim one until it does. What exists today:
- A Type I readiness assessment mapping controls to the Trust Service Criteria, scoped to Security + Availability + Confidentiality — Processing Integrity and Privacy are declared out of scope for the Type I engagement and can be added when customers ask.
- Evidence-backed, not asserted: every criterion row cites a test, script or migration — the RLS tenancy suites, the dependency and image scan gates, the backup/restore drill, the chaos suites.
- A Type II observation window planned to open within 12 months (~6 months of observation), with an auditor selection brief for a licensed CPA firm experienced in multi-tenant SaaS.
Design partners receive control-mapping details ahead of the report. General availability of the managed tier follows the audit.
The readiness verdict, stated plainly: ready to plan the Type I engagement — control design substantially in place across Security, Availability and Confidentiality, with test-backed evidence per criterion. The remaining pre-engagement work is organizational policy documentation, not platform controls.
HIPAA
Orkena is designed to support HIPAA administrative and technical safeguards — it is not a covered entity, and this page does not claim HIPAA compliance on anyone's behalf.
| Safeguard | Orkena control mapping |
|---|---|
| §164.308 administrative | Scoped agent credentials via KMS; role-based access with RLS; SSO; audit trail of every access decision |
| §164.312 technical | Hash-chained ledger of every PHI-adjacent action; Ed25519 anchors detecting post-facto modification; TLS 1.3; envelope encryption under your KMS; data labels (PHI) propagated through runs |
| §164.312(c)(1) integrity | Ledger chain verification detects any modification of the record itself; deterministic replay reconstructs any run byte-for-byte |
| HITECH breach notification | Deterministic replay + evidence bundle export scoped to any incident window; auditor verifies offline |
Orkena acts as a business associate and signs a BAA where it processes PHI on your behalf (the managed, region-pinned tier, on the roadmap). In customer VPC and air-gapped deployments Orkena has no access to your data, and a BAA does not apply.
Two controls answer the minimum-necessary and access questions that dominate HIPAA reviews: data labels (PHI) propagate through every run, so a policy can deny any action that would move PHI somewhere it should not go — and the denial is recorded; and every memory read and retrieval is purpose-tagged, so the question "which agent saw this record, and why?" answers from the ledger rather than from an access-review spreadsheet.
GDPR
Orkena is a Processor to your Controller. Data residency options are the managed region-pinned tier (roadmap), customer VPC, or air-gapped — in VPC and air-gap modes, data never leaves your infrastructure. The standard DPA is available on request. Sub-processor commitments and the register live on the trust centre.
Article 28 obligations, mapped:
- Processing only on instruction: policy packs encode the processing scope; actions outside the packed policy are denied before execution.
- Assisting the controller with data-subject requests: purpose-tagged data access and a right-to-be-forgotten cascade — purge events propagate across memory, runs and exports, and are themselves ledger-recorded.
- Security of processing (Art. 32): the controls on the security page, unchanged.
- Sub-processor management: register with functions and regions, 30-day change notification, right to object.
GDPR compliance is the customer's; Orkena supports their obligations. The same purpose-and-provenance controls underpin the UK DUAA accountability mapping (DUAA-1…4, SME-validated references) for public-sector deployments.
On transfers: the deployment mode is the transfer story. In customer VPC and air-gap modes there is no transfer — data never leaves your infrastructure, so no transfer mechanism is needed. In the managed tier (roadmap), data stays in the region-pinned cell you select. Nothing in the architecture depends on moving data across borders to function.
For your Article 30 records of processing: the purpose-tagged access ledger and the sub-processor register are the inputs — the processing inventory writes itself from the record rather than from a spreadsheet that is out of date the week after it is signed.
Sector-specific regimes
- SR 11-7 (US model risk): version-controlled agent workflows, regression eval suites, drift detection with alert routing
- MiFID II algorithmic-trading review: deterministic replay + time-travel fork; every non-deterministic input captured
- NY DFS 500 / state insurance: cybersecurity programme support, incident response, third-party risk documentation
- UK DUAA accountability: purpose and provenance tagging on every data access (see GDPR above)
These are support mappings to controls, not certifications — the same register applies here as everywhere else on this page.
How to verify the mapping
Every mapping on this page is verifiable in a demo session rather than asserted in a document. The repeatable sequence: run a governed workflow — a payment-adjacent flow with an approval gate and a model allowlist — then inspect the run inspector and the token stream. Export the evidence bundle and run the dependency- free verifier on your own machine; bit-flip or truncate the bundle and watch the verification fail. Pull the compliance profile for the graph: every active control, with its evidence links, per obligation. The same drill answers DORA's operational articles — engage the kill switch mid-run and read the pause events off the ledger, or run the chaos suite and confirm the invariants: no duplicate effects, no lost audit.
That is the difference between a mapping document and a mapping that runs. The document is this page; the runtime is the product.
The honesty note
Orkena is not certified against these frameworks on your behalf. It produces the runtime controls and the evidence your own certification and supervisory processes require. Certification is between you and your certifier. We will not ship a certification claim until the attestation exists — and when one lands, it will land one framework at a time, on this page, dated. This page and /security undergo legal review before publication, and the article-to-control pairings above are revised against the official texts before customer use.
Treat this page as a live register rather than a brochure: it changes when the controls change, and when it changes, the change is visible. A reviewer who returns in a quarter should be able to diff the page, not re-audit it — the honesty note stays because the discipline is permanent, not because the gaps are.