โœ… Compliance

Audit-ready, always. Not just at quarter-end.

Continuous certifications fire on a rolling clock per target-kind. Smart certs fire on movers and new grants. SOL vs IST reconciliation surfaces drift the moment it happens. Every decision is recorded in an immutable, HMAC-signable audit chain.

What's inside

Two cert flows. One reconciliation engine. One audit chain.

Periodic reviews catch slow drift on a calendar. Event-triggered smart certs catch fast change as it happens. Reconciliation surfaces unauthorised grants the moment they appear on a target. The audit chain ties everything together with cryptographic integrity.

Periodic certifications
Certifications dashboard

Campaign-based access reviews with KPIs

See what's waiting on reviewers right now, what's overdue, and campaign-by-campaign progress. Spawn ad-hoc campaigns from any cert-rule or let the continuous sweep handle it automatically.

Certifications
Cert rules

Per-target-kind rules โ€” grant / role / policy / identity

Different review cadences for different subjects: grants every 180 days, privileged grants every 90 days, business roles yearly, NHI ownership every 6 months. Each rule has its own reviewer chain (multi-step + quorum) and auto-action on deadline (revoke, disable, flag-for-review).

Cert rules
Event-triggered smart certs
Smart certs

"Something changed โ€” review now"

When an identity transfers between departments, a smart cert fires for the new manager to confirm existing access. When a new grant lands, an optional 30-day grant-review fires. Distinct from periodic certs โ€” different task type, different routing, both auditable.

Smart certs
SOL vs IST reconciliation
Reconciliation

What should be granted vs what is granted

SOL (should-be access) is the calculated baseline from policies + roles. IST (actual access) is what the recon engine reads off the target. Drift falls into three buckets: unapproved grants (someone has more than they should), missing grants (they should have it but don't), and attribute drift (HR-leading attributes diverge on target).

Reconciliation
Identity warnings

Per-identity drift surfaced as work items

Each identity gets a "warnings" view โ€” derived from SOL-vs-IST plus other compliance signals. Operators can take action directly: re-grant the missing entitlement, request revoke for the unapproved one, or approve as a justified exception with audit trail.

Identity warnings
Cross-system SoD
SoD rules

Declare toxic combinations, not just within one app

Cross-system SoD rules let you declare conflicting capabilities across different connected applications: "vendor maintenance in Workday" vs "payment approval in SAP". The advisor flags every identity holding both sides โ€” and the risk-score weight scales by severity (critical, warning).

SoD rules
Toxic combinations

Continuous SoD detection across the population

Beyond preflight at grant-time, the toxic-combo scanner sweeps the existing population for SoD pairs that emerged via aggregation: someone got "payment requester" from role A and "payment approver" from role B. Surface, route to compensating control, or revoke.

Toxic combinations
Audit packs
Compliance evidence packs

SOX, ISO 27001, HIPAA, GDPR โ€” one click each

Framework-mapped evidence packs: pick a date range, hit "Generate + download" and you get a ZIP with HTML index, per-section data files, and a manifest. Pre-built templates for SOX ยง Access Management, ISO 27001 Annex A.9, HIPAA ยง 164.312, and GDPR Art. 32 โ€” each mapped to the specific controls your auditor will ask about.

Audit packs

Built for auditors

Evidence โ€” cryptographically signable, instantly exportable.

๐Ÿ”— Immutable audit chain

Every audit row carries SHA256(prev_hash + canonical_row). A PostgreSQL BEFORE-UPDATE/DELETE trigger physically blocks tampering โ€” not an app policy that could be bypassed. Verify the entire chain with one API call.

๐Ÿ“ค HMAC-signed NDJSON export

Export audit events as NDJSON with HMAC-SHA256 signature. Auditors re-verify outside the platform without trusting our infrastructure. Filterable by date range, event type, actor, or subject.

๐Ÿ“ฆ Framework-mapped evidence packs

Pre-built ZIP-format evidence packs for SOX ยง Access Management, ISO 27001 Annex A.9, HIPAA ยง 164.312, and GDPR Art. 32 โ€” each mapped to the framework's control identifiers your auditor expects. One-click generate with a date range. No manual data assembly.

โš–๏ธ GDPR Art. 17 retention

Erase service pseudonymises Identity PII and removes TenantUser rows, but never touches audit_event โ€” that's retained under Art. 17(3)(b) for compliance obligation. Trigger physically enforces this; can't be bypassed by ORM code.

๐Ÿ” Audit replay

Forensic read-only replay of any tenant's audit log over any date range. Summarised by event type, severity, and actor; chronological timeline for incident reconstruction. Always safe โ€” read-only by immutability invariant.

Take your next audit from 6 weeks to 6 hours.

Bring an audit scope. We'll show you the audit chain verifying clean, NDJSON export with HMAC signature, and the reconciliation panel surfacing live drift.

Book a POC demo โ†’
EU-hosted ยท No installation footprint ยท Walks away cleanly if you don't convert