Every meaningful action in Venvera leaves a trace. Who logged in, who created a provider, who changed a risk score, who deleted a policy - all of it is written to a tamper-evident audit log the moment it happens. Entries are recorded automatically by the system as people work; they cannot be created, edited, or deleted by hand from anywhere in the product. That is what makes the trail tamper-evident - what you read is what happened. This gives you the accountability trail that regulations such as DORA, NIS2 and ISO 27001 expect, and the forensic timeline you need when something looks wrong.
Two places to look
There are two audit views, aimed at two different audiences.
| View | Where | What it shows |
|---|---|---|
| Audit Trail | Reports › Audit Trail | What users did inside your organisation - the data changes made to records you own. |
| Platform Audit Log | /admin/audit | A unified, cross-tenant log for Venvera platform administrators that combines tenant data changes, platform-admin actions and authentication events in one stream. |
The tenant Audit Trail
The Audit Trail under Reports › Audit Trail is your own organisation's activity log. It records every create, update and delete made to records across the platform - providers and contracts in the Register of Information, incidents, policies, risk assessments, gap responses, remediation plans, tasks, users and more.
What each entry records
| Field | Description |
|---|---|
| Timestamp | When the action happened, in your chosen date and time format. |
| User | The person who performed the action (name and email). System-generated changes are attributed to System. |
| Action | Create, Update or Delete, shown as a colour-coded badge. |
| Module | The type of record affected (for example Incidents, Policies, ICT Providers). |
| Record ID | The identifier of the specific record. |
| Changes | How many fields changed. Click any row to expand a full before-and-after view. |
Expanding a row shows exactly what changed. For an update you see each field with its old value struck through beside the new one; a create shows the full new record; a delete shows the record that was removed. This is the difference between "someone edited this contract" and "someone changed the renewal date from 2026 to 2028 at 14:32".
Who sees what
Visibility follows your role. A regular team member sees only their own actions. An organisation admin sees the actions of everyone in the organisation. In every case the trail is scoped to your own tenant - you never see another organisation's activity. The three summary cards at the top count total entries, entries today, and entries this week.
The platform Audit Log
The Platform Audit Log at /admin/audit is the platform administrator's single pane of glass. Instead of one organisation's data changes, it merges three sources into one time-ordered stream:
| Source | What it covers |
|---|---|
| Tenant | Data mutations across all organisations - the same create / update / delete events surfaced in each tenant's own Audit Trail. |
| Platform | Actions taken by platform administrators in the /admin panel. |
| Auth | Authentication events - login successes, login failures and single sign-on failures - each with the originating IP. |
Each row carries a colour-coded source badge (Tenant, Platform, Auth) and records the full picture: who (user name and email), what (the action), the target (record type and ID), the timestamp, the organisation the event belongs to, and the IP address it came from. Click a row to expand the complete event detail, including the raw changes or metadata as recorded.
Filters
| Filter | Options / behaviour |
|---|---|
| Source | All sources, Tenant events, Platform admin, or Auth events. |
| Action | Create, Update, Delete, Login, Export, Auth Success, Auth Failure, SSO Failure - or all actions. |
| IP address | Show only events from a given IP (partial matches work, so you can filter by a subnet prefix). |
| User | Match by email or name. |
| Date range | A From and To date; the To date is inclusive of the whole day. |
| Search | Free-text search inside the event details and recorded changes. |
| Demo sessions | All sessions, Demo sessions only, or Exclude demo sessions - so you can separate real user activity from actions taken by read-only demo users. |
Filters combine, and a Clear all link resets them. Opening a specific user's record elsewhere in the admin panel and choosing View user logs deep-links straight here with the user filter already applied.
Every action records an IP
Every audited action now captures the originating IP address - tenant data changes, platform-admin actions and authentication events alike. Where an IP could not be determined the field simply shows a dash. Because the IP is stored on the event itself, you can pivot an entire investigation around a single address.
Exporting to CSV
From the Platform Audit Log you can export the current view to a spreadsheet for offline analysis, ticketing, or handing to an auditor.
Narrow the log to exactly what you need - a source, an action, a date range, an IP, a user, or any combination. The export respects whatever is on screen.
Use the Export CSV button at the top right. Venvera gathers every matching event (not just the current page) and downloads a file named audit-log-YYYY-MM-DD.csv.
Each row carries the timestamp, source, user email and name, action, target type and ID, organisation, IP address, and the full details column, ready for Excel, a SIEM import, or an evidence pack.
Scenario: chasing down a suspicious login
Priya is the security lead at a mid-size bank. Overnight her SIEM flags a login to Venvera from an IP she does not recognise. She wants two answers: what did that address do, and does anything else that week look off.
Priya opens /admin/audit, sets Source to Auth events, and pastes the suspicious address into the IP address filter. The log now shows only sign-in attempts from that IP - she can see immediately whether they were an Auth Success or a string of Auth Failure attempts, which account was targeted, and the exact timestamps.
She clears the source filter, switches the User filter to the affected account, and reviews everything that account did across tenant and platform events after the login - any records created, changed or deleted. That tells her whether the session did anything or was caught first.
To rule out anything else, Priya sets a From and To range covering the week and sets Demo sessions to Exclude demo sessions. Now she is looking only at genuine user activity, with demo sessions filtered out, so nothing is buried in noise.
She clicks Export CSV to capture the filtered timeline exactly as she found it, and attaches it to the incident ticket. The trail is her contemporaneous, tamper-evident record of the investigation.