When Decionis sits in the execution path, your compliance and risk approvers need to know the same thing they ask of any control that touches checkout, ERP, or automation: who can change the policy, who approves it, how it is enforced, and how a change is proven after the fact. Here is the control design — each item labeled with its honest status.
Policy is versioned and promoted deliberately. A material policy change is an explicit new version with its author, the approval path it followed, and its effective window preserved — so a change can be proven to have followed the approved path (SOC 2 CC8.1), not edited in place.
AI reasoning is separated from execution: agents cannot mutate state without passing a deterministic policy gate. Policy authorship, approval, and the runtime that enforces it are distinct surfaces, so no single actor both writes and silently executes a policy change.
Access is tenant-scoped and role-based across the workspace, API keys, connectors, and callback destinations, so operators, reviewers, and administrators see and act only within their role.
Enterprise sign-in paths support OIDC and SAML so identity stays in your IdP rather than a separate Decionis credential store.
Every certified verdict is recorded as an Ed25519-signed Decision Dossier that links into a Decision Chain and Execution Ledger — attributable, non-repudiable evidence a reviewer can verify without an account, rather than mutable logs and screenshots.
Exceptions are not silent bypasses. The original dossier stays intact, the override is linked as its own signed artifact with reviewer identity and rationale, and recurring overrides surface as Policy Drift signals for governed policy evolution.
Teams retain a visible restraint surface: an org-wide halt and per-decision kill switch to stop high-stakes autonomous execution immediately.
How these controls run in practice — the lifecycle from first policy to auditor sign-off.
The mapped controls behind these guarantees, standard by standard.
How the Decionis Score maps to Articles 12, 14, and beyond.
Feed signed evidence into Archer, OneTrust, or ServiceNow GRC.
Certification status, data residency, and sub-processor posture.
Define the authority once and enforce it at each point of execution. The alternative — reimplementing the same limit in the storefront, the ERP, the ITSM queue and the agent framework — gives you four implementations with four drift rates and no single answer to what the rule actually is.
A purchase order, vendor onboarding, or supplier change is submitted for release.
9 executable policies
A vendor payment, payout batch, or cross-border transfer is released.
7 executable policies
An access request grants elevated or root scope to a person, contractor, or service.
6 executable policies
A workflow posts customer or business data to a webhook, an external API, or a vendor integration.
6 executable policies
Someone edits a policy, raises a threshold, or disables a rule.
6 executable policies
A payroll run commits, or an HR business process (termination, compensation change, hire) executes.
3 executable policies
