AuraBoot
Start free
English简体中文

Compliance & Risk

Why this is a runtime problem, not a CRUD problem

A compliance program is not a list of policies in a wiki. It is a continuous evidentiary chain: a risk is identified, mapped to a control, the control is exercised by a real business operation, the operation produces an artifact, an auditor inspects the artifact, a finding is opened, a remediation is dispatched, and somewhere a regulator asks "show me, for the period 2026-01-01 to 2026-03-31, every write to the customer-PII table and who approved it." A data-app builder can model the registers — but the moment the auditor asks for the artifact, the trail dies at a screenshot in an email. A packaged GRC suite has the registers and the workflows, but its audit trail is its own — disconnected from the systems where the controlled work actually happens.

AuraBoot inverts this. Every Command pipeline run emits one structured audit record, signed with the user, role activation, ABAC attributes evaluated, before/after field deltas, and trace span. The compliance plugin does not synthesize evidence; it indexes what the pipeline already produces. The risk register, the control library, and the audit case board are configuration on top of that substrate.

Data model summary

The Compliance & Risk solution ships as a single plugin (auraboot.compliance) with four core models, plus a thin SoD policy model that crosses module boundaries.

  • cmpl_risk — Inherent risk identified against a process, system, or vendor. Fields: title, category (data-breach, system-failure, insider-threat, vendor, regulatory, operational), inherent likelihood × impact (5×5), residual score after controls, owner, status (identified → assessed → mitigated/accepted → closed).
  • cmpl_control — Control measure mitigating one or more risks. Fields: framework (SOC 2 / ISO 27001 / GDPR / HIPAA / PCI DSS / CCPA / internal), category, priority, owner, status (not_started → in_progress → implemented → verified, plus non_compliant), test cadence.
  • cmpl_audit_case — A discrete audit or attestation cycle (internal, external, spot-check). Fields: framework, auditor, scope window, finding counts, status (scheduled → in_progress → completed → follow_up). Linked to evidence drawn from the Command pipeline audit log.
  • cmpl_sod_policy — Separation-of-duties rule expressed as "no single principal may execute both Command A and Command B within window W on the same business object". Evaluated by the Command pipeline at admission time, not by a nightly scanner.

Each control links to zero or more risks (mitigation), to zero or more SoD policies (enforcement), and — through evidence queries — to the Command audit log entries that prove it was exercised. Frameworks are themselves a small reference model so a control can be cited against multiple frameworks (one MFA control covers SOC 2 CC6.1, ISO 27001 A.9.4.2, and PCI DSS 8.3 simultaneously).

Key commands

The full plugin defines roughly forty commands. Five representative ones cover the three command shapes:

CommandShapeRiskIdempotentWhy it matters
cmpl.risk.assessStateTransitionwritetrueMoves a risk from identified to assessed; requires likelihood, impact, owner
cmpl.control.verifyStateTransitionwritetrueMarks a control verified; gated on at least one attached evidence artifact within the test cadence window
cmpl.audit.openStateTransitionwritetrueOpens an audit case; freezes the in-scope evidence index at the scope start timestamp
cmpl.sod_policy.evaluateActionreadtrueDry-runs an SoD policy against historical audit log to find latent violations before activating enforcement
cmpl.audit_case.closeStateTransitionirreversiblefalseCloses an audit case after all findings resolved; signs the evidence bundle

A button labeled "Open audit" is wired to cmpl.audit.open — not to a raw PUT /api/cmpl_audit_case. The same command is reachable from automation rules ("auto-open Q2 SOC 2 review on April 1"), from BPM steps, and — because it declares riskLevel: write, idempotent: true, agentHint: "Use when a scheduled audit window opens; do not use for ad-hoc investigations" — from an AI agent acting on behalf of a compliance officer.

Permission example

A realistic compliance role: "External Auditor — Read-Only" granted to a Big Four engagement team for the duration of an audit window.

  • RBAC: granted cmpl.risk.read, cmpl.control.read, cmpl.audit_case.read, cmpl.evidence.read; not granted any .manage, .verify, or .close command.
  • Org scope: the default data-scope for external auditors is "self only" — but for this role we apply a deliberate override of org-tree-all, so the auditor sees records from every business unit across the org tree (audit scope is the legal entity, not the auditor's home unit).
  • ReBAC: can read evidence attached to controls in the active audit case's scope; cannot read evidence attached to controls outside that scope (relationship: evidence → control → audit_case.scope).
  • ABAC: case-escalation rule — if a finding is marked severity = critical, the auditor's read view of the underlying records is broadened to include masked PII columns; below critical, those columns remain redacted. Attribute evaluated at every read.
  • Field-level: every field the auditor can see is rendered read-only — not by hiding the edit button, but by the field-level permission layer rejecting any Command that mutates those fields, even if a UI bug or API client tried.

All five layers are evaluated in order. The result is exactly what a regulator wants: the external auditor sees everything in scope, can edit nothing, and every byte they read is logged.

Process orchestration

The audit case lifecycle is a BPMN diagram. Each task is bound to a command.

                       ┌────────────────────────┐
                       │ Scheduled / Triggered  │
                       └───────────┬────────────┘
                                   │
                       ┌───────────▼────────────┐
                       │ Open audit case        │  ←  cmpl.audit.open
                       │ (freeze evidence index)│
                       └───────────┬────────────┘
                                   │
                       ┌───────────▼────────────┐
                       │ Fieldwork: walk        │  ←  cmpl.evidence.attach (loop)
                       │ controls, attach proof │      cmpl.control.test
                       └───────────┬────────────┘
                                   │
                     ┌─────────────▼─────────────┐
                     │ Findings? (gateway)       │
                     └──┬─────────────────────┬──┘
                        │ yes                 │ no
              ┌─────────▼──────────┐ ┌────────▼─────────┐
              │ Open findings      │ │ Draft report     │
              │ + remediation plan │ │                  │
              └─────────┬──────────┘ └────────┬─────────┘
                        │                     │
              ┌─────────▼──────────┐          │
              │ Remediate + re-test│          │
              └─────────┬──────────┘          │
                        │                     │
                        └──────────┬──────────┘
                                   │
                       ┌───────────▼────────────┐
                       │ Sign + close case      │  ←  cmpl.audit_case.close
                       │ (evidence bundle hash) │
                       └────────────────────────┘

Mid-audit changes do not break the trail: the evidence index was frozen at cmpl.audit.open, and any post-freeze mutation to an in-scope record appears in the audit case's "scope drift" view rather than silently rewriting history.

Agent integration

Three command classes are intentionally exposed to AI agents in this solution:

  1. Read-and-summarize commands (cmpl.risk.list_overdue, cmpl.audit_case.weekly_status) — read-only, idempotent, low risk. Agents call freely; results feed into compliance officer briefings.
  2. Drafting commands (cmpl.finding.draft_from_evidence) — write, idempotent, reversible. The agent reads recent failed control tests and drafts a finding; a human reviews and runs cmpl.finding.open.
  3. Diagnostic commands (cmpl.sod_policy.evaluate) — read-only over historical audit logs. The agent surfaces "this SoD policy, if activated today, would have blocked 14 historical operations" before a human decides to enforce.

What is not exposed: cmpl.audit_case.close (irreversible + signs an evidence bundle), cmpl.control.verify (verification is a human attestation), and any cmpl.evidence.delete shape (immutable by policy). These have agentHint: "Human-only"; the agent surface excludes them.

How to get it

  • Community: build it yourself. The Command pipeline audit log, the five-layer permission model, and the SoD enforcement hook are all open-core. The compliance plugin's risk/control/audit-case schemas are documented; reproduce them.
  • Standard: white-label the base platform; ship your own compliance pack on top.
  • Professional: get the Compliance & Risk plugin package — risk register, control library pre-seeded with SOC 2 / ISO 27001 / GDPR / HIPAA mappings, audit case board, and the standard SoD policy set.
  • Enterprise: same package plus dedicated compliance review, regulatory mapping for your jurisdictions, and SLA-backed support.

See Pricing for the full edition comparison.

Enterprise note — Signed audit-log replay (cryptographic re-derivation of any historical state from the pipeline's audit stream), advanced ABAC (declarative attribute graphs with multi-hop relationship traversal), and signed policy export (offline-verifiable bundles of risk / control / SoD definitions for regulator handoff) are commercial-only capabilities. The open-core audit log, permission engine, and SoD admission hook described above are the same in every edition.

Next steps