Nembl
Admin Guide
Audit Trail

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, or system
  • 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
  • Sourcenembl (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.

PresetCovers
SOC 2 Access ReviewAuthentication, role assignments, permission changes, session events
SOC 2 Change ManagementWorkflow publish/version bumps, role and policy changes, system configuration
ISO 9001 Document ControlWorkflow template releases, form updates, service catalog changes
ISO 9001 Corrective ActionsRequest rejections with revision feedback, workflow cancellations and resumptions, escalations
ISO 9001 Process ChangesWorkflow 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.compliance feature flag is off. Upgrade to Business or Enterprise, or ask support to toggle it for your account.
  • Missing expected events — confirm the audit.request_logging flag is on for request-level events; admin and workflow events require audit.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:reveal event 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.