Audit Trail
Nembl records every material action — who logged in, which workflows were published, which policies changed, which requests were approved — in an immutable audit trail. The trail supports compliance reporting (SOC 2, ISO 9001), incident investigation, and general accountability.
Admin → Audit Trail (/admin/audit)
Access
The audit page is gated by the audit.compliance feature flag, which is enabled on Business and Enterprise plans. Companies on lower tiers can still see recent request events on individual request detail pages, but the full searchable audit trail with compliance presets is a paid feature.
If the flag is off, the page displays an upgrade prompt rather than the audit table.
What Gets Recorded
Every auditable action writes one row containing:
- Timestamp (UTC)
- Actor — the user or system identity that performed the action
- Action — e.g.
role.create,workflow.publish,request.accept,policy.delete - Category — coarse grouping (auth, iam, workflow, request, responsibility, etc.)
- Target — the entity acted upon (
workflow:abc123,user:xyz789) - Source — where the action originated:
nembl,plan-admin, orsystem - Details — a JSON blob with action-specific context (before/after values, reason codes, etc.) — expandable inline
Click the chevron on any row to reveal the full Details JSON.
Filters
Above the table:
- Search — full-text match against actor, action name, target type, and target ID
- Category — dropdown of action categories
- Source —
nembl(this app),plan-admin(DevOpspolis ops tooling),system(automated) - Compliance preset — shortcut filters for common review scenarios (see below)
- Sort — newest-first (default) or oldest-first
Compliance Presets
Preset filters pre-configure the view for auditors and internal reviewers. They match actions by wildcard pattern so all related events surface together.
| Preset | Covers |
|---|---|
| SOC 2 Access Review | Authentication, role assignments, permission changes, session events |
| SOC 2 Change Management | Workflow publish/version bumps, role and policy changes, system configuration |
| ISO 9001 Document Control | Workflow template releases, form updates, service catalog changes |
| ISO 9001 Corrective Actions | Request rejections with revision feedback, workflow cancellations and resumptions, escalations |
| ISO 9001 Process Changes | Workflow phase edits, responsibility-matrix application/clearing, intake-mode changes |
Select a preset and the table immediately filters. Combine with a date range and CSV export for a ready-to-hand-off audit artifact.
CSV Export
Click Export CSV to download the currently-filtered table as a dated CSV file. The export endpoint is GET /api/audit/export?from=…&to=… and respects the active filters. Date range is required to prevent accidentally exporting the entire history at once.
Typical uses:
- Quarterly SOC 2 evidence
- ISO 9001 surveillance audits
- Customer security questionnaires
- Incident forensics (filter by actor or target, date-scoped)
Tiered Recording
The audit system has two feature-flag tiers:
audit.request_logging— records request-level events (submit, accept, reject, forward, revise, complete). Enabled on all plans that include a request catalog.audit.compliance— unlocks the full audit page with search, filters, presets, and CSV export, plus records higher-frequency administrative events (role/policy/workflow/secret changes, login/logout).
This tiering keeps storage costs proportional to plan value and gives you control over how much auditing to retain.
Retention
Audit log rows are kept in hot storage for real-time querying and also archived for long-term retention. Hot storage is pruned on a configurable schedule (defaults to 90 days); the archive is retained indefinitely.
Staff Actions on Your Behalf
When a DevOpspolis staff member takes an action that affects your company — extending your trial, adjusting a subscription limit, resetting a user's password at your request — the action is recorded in your audit trail with Source = staff. You always have a record of operational actions taken on your behalf, even when you didn't perform them yourself.
What staff cannot do:
- Read your vault values. Vault creation and rotation are audited, but the underlying values are encrypted and not accessible to staff.
- Access workflow instance variables, request content, or form submissions. Operational data within your tenant stays in your tenant.
- Log in as a user. There is no impersonation feature. Password resets produce a temporary credential the user must change on first login.
If an action shows up in your audit trail that you didn't request, contact your account manager.
Troubleshooting
- Can't see the audit menu — your role may lack
audit:view. Admins can grant this on Admin → IAM → Roles. - Upgrade prompt shown — the
audit.compliancefeature flag is off. Upgrade to Business or Enterprise, or ask support to toggle it for your account. - Missing expected events — confirm the
audit.request_loggingflag is on for request-level events; admin and workflow events requireaudit.compliance. - CSV is empty — check that a date range is set and that your filters aren't too narrow.
Related
- Admin → IAM → Responsibilities — matrix and assignment changes surface in the audit trail under the
responsibility_matrix.*actions. - Admin → Vaults — vault creation, rotation, and deletion are audited (but never the values). The
secret:revealevent is logged whenever a user views a stored value. - Admin → Feature Flags — flag changes are audited so you can trace when a feature was enabled for a specific company.