The Governance Controls page documents what the Governor Layer is. This is how it runs — the lifecycle a compliance or risk officer walks with the team: encode the policy, validate it read-only, grant scoped enforcement, export signed evidence, and feed the GRC program you already operate. Each step names the SOC 2 or ISO 27001 control it produces evidence for — and where a step has no defensible mapping, we say so instead of inventing one.
1
Encode the policy under maker–checker
Establish that policy is code-reviewed institutional intent — versioned and promoted deliberately, never edited in place.
- 1.1Express the rule you already enforce informally (margin floor, spend threshold, access gate) as a versioned policy, starting from a policy pack or the policy-encoding API.
- 1.2Route the new version through the maker–checker path: the author, the approval path it followed, and its effective window are preserved on the version itself.
- 1.3Scope who can author and who can approve via tenant-scoped RBAC, with sign-in through your IdP (OIDC / SAML).
Evidence after this step
A versioned policy snapshot with author, approval path, and effective window — attached to every future verdict, so you can always prove which policy version governed an action.
SOC 2 CC8.1Change-management evidence for policy and approval-path updates.
Versioned policy snapshot with author, approval path, and effective window; the governing policy version is attached to every signed dossier.
Auditor question: Can the team prove each material change followed the approved path?
2
Validate in read-only Shadow Mode
Prove the policy against real order and workflow history before it is granted any enforcement authority.
- 2.1Install read-only: Shadow Mode makes no checkout changes and enforces nothing.
- 2.2Let the policy evaluate live traffic and read the Drift Report built from your own data — the would-have-blocked verdicts and their value.
- 2.3Review the shadow verdicts with the policy owner; revise the policy version through the same maker–checker path if the floor is wrong.
Evidence after this step
A Drift Report computed from your own history, and shadow verdicts you can inspect — establishing the policy's impact before anyone authorizes enforcement.
We claim no SOC 2 or ISO control for this step. Its purpose is adoption risk control: the policy earns enforcement authority with evidence from your own data, not a vendor promise.
3
Grant enforcement authority — scoped and reversible
Show that turning enforcement on is a controlled, role-scoped act with a visible restraint surface, not a one-way door.
- 3.1Flip the validated rule from shadow to enforce — per rule, reversible without uninstalling.
- 3.2Keep the authority scoped: RBAC controls who can change enforcement, and AI reasoning stays separated from execution — no agent can mutate state without passing the deterministic gate.
- 3.3Retain the restraint surface: an org-wide halt and a per-decision kill switch stop high-stakes autonomous execution immediately.
Evidence after this step
Enforced verdicts recorded as signed dossiers, produced by a gate only authorized roles could enable and any authorized operator can halt.
SOC 2 CC6.1Logical access controls over who can grant, change, or halt enforcement authority.
Tenant-scoped RBAC with OIDC/SAML SSO across workspace, API keys, and connectors; per-rule reversible enforcement plus org-wide and per-decision kill switches.
Auditor question: Who could turn enforcement on, and could it be stopped immediately?
ISO 27001 A.5.15Access-control policy enforcement for operational automation.
Policy authorship, approval, and the enforcing runtime are distinct role-scoped surfaces, so no single actor both writes and silently executes a policy change.
Auditor question: Which access policy governed the automated action?
4
Export the evidence your auditor will accept
Hand the audit team tamper-evident artifacts they can verify themselves — not screenshots or mutable logs.
- 4.1Pull the Ed25519-signed Decision Dossier for any verdict: intent, policy version, reason codes, evidence, and integrity metadata in one artifact.
- 4.2Let the reviewer verify the signature on the public verification surface — no Decionis account required.
- 4.3Export validation packs (manifest and bundle hashes) and assemble the control-mapped evidence pack for the frameworks you report on (SOC 2, GDPR, EU AI Act).
- 4.4Where an exception occurred, export the Override Dossier: the original verdict stays intact and the override is its own signed artifact with reviewer identity and rationale.
Evidence after this step
Signed, hash-linked dossiers and validation packs a reviewer can verify independently, plus a control-mapped evidence pack — audit preparation becomes an export, not a reconstruction.
ISO 27001 A.8.34Audit-log protection against tampering, deletion, and ambiguous ownership.
Ed25519-signed dossiers linked into Decision Chains and an Execution Ledger, with a public verify path — attributable, non-repudiable evidence inspectable without an account.
Auditor question: Is audit evidence protected and attributable after the decision is made?
5
Feed your GRC program
Slot Decionis into the governance stack you already run — as an evidence source, not another platform to govern.
- 5.1Push signed dossiers, validation-pack manifests, and policy snapshots into RSA Archer, OneTrust, or ServiceNow GRC as control evidence, via API and webhooks.
- 5.2Give auditors the read-only view instead of screenshots, so evidence review does not require operator access.
- 5.3Watch recurring overrides surface as Policy Drift signals, and evolve the policy through the same maker–checker path — closing the loop your GRC program reviews.
Evidence after this step
Your existing GRC platform holds Decionis-signed evidence against its own risk and control records — integration-ready via API and webhooks, not a certified turnkey connector.
This step consumes the evidence produced above rather than generating a new control claim. Decionis is not a full GRC suite, by design — Archer, OneTrust, and ServiceNow GRC stay the systems of record.
Honest scope: the control mappings above show where Decionis evidence fits your controls. They are not a certification claim; the Trust Center lists current audit status. Decionis is not a full GRC suite, by design: it is the gate that produces the signed evidence your GRC program consumes.
How do I get my security team to approve Decionis?
Point them at the published review path: the Trust Center starts with what they can check directly (Ed25519-signed Decision Dossiers and single-use execution grants) and lists audit status; Governance Controls documents the Governor Layer design — maker–checker policy approval, separation of duties, RBAC, OIDC/SAML SSO, a signed tamper-evident audit trail, controlled overrides, and kill switches; the Governor Playbook walks the lifecycle step by step with its SOC 2 / ISO control mapping; and the sandbox produces a real signed Decision Dossier they can verify without an account. Public API docs, quickstart, and deployment posture are reviewable before a diligence cycle starts.
What can a security reviewer verify without an audit report?
Two things, directly: Ed25519-signed Decision Dossiers and single-use execution grants. Any dossier verifies offline against the published JWKS with the open @decionis/verify CLI, and a grant is claimed once, immediately before the action runs; a second claim is refused. The compliance standards matrix shows which SOC 2 and ISO 27001 controls that evidence supports. It is alignment evidence, not a certification claim, and the Trust Center lists current audit status.
What authority does Decionis need to start?
None over your execution. Shadow Mode installs read-only: it makes no checkout changes, enforces nothing, and builds a Drift Report from your own order history. Enforcement is a later, explicit, role-scoped act — enabled per rule, reversible without uninstalling, and covered by an org-wide halt and per-decision kill switches.
How do Decision Dossiers map to SOC 2 controls?
Three examples from the published matrix: versioned maker–checker policy changes produce change-management evidence (SOC 2 CC8.1); role-scoped enforcement with kill switches produces logical-access evidence (SOC 2 CC6.1); and Ed25519-signed, hash-linked dossiers with a public verify path produce audit-log-protection evidence (ISO 27001 A.8.34). The full control-by-control mapping — each with the evidence artifact and the auditor question it answers — is on the compliance standards matrix, as alignment evidence rather than a certification claim.
Does Decionis replace our GRC platform?
No — by design. Decionis is the deterministic gate in the execution path that produces signed evidence; your GRC program consumes it. Signed dossiers, validation packs, and policy snapshots feed RSA Archer, OneTrust, or ServiceNow GRC as control evidence via API and webhooks — integration-ready framing, not a certified turnkey connector.
Can our auditor verify the evidence independently?
Yes. Every certified verdict is an Ed25519-signed Decision Dossier a reviewer can verify on the public verification surface without a Decionis account. Dossiers hash-link into Decision Chains and an Execution Ledger, validation packs carry manifest and bundle hashes, and a read-only auditor view avoids granting operator access for evidence review.
