---
title: 11.01 The Audit Trail
description: Every meaningful action in SimpleRisk (risk submission, mitigation update, document approval, user login, configuration change) writes a row to the…
---
[Skip to content](https://support.simplerisk.com/kb/11-01-the-audit-trail#main-content)
English
Show submenu for translations
[Customer portal](https://support.simplerisk.com/tickets?hsLang=en)
[](https://www.simplerisk.com/)
Open main navigation
Close main navigation
- English
Show submenu for translations
- [Customer portal](https://support.simplerisk.com/tickets)
- [Contact us](https://www.simplerisk.com/about-us/contact-us)
[Contact us](https://www.simplerisk.com/about-us/contact-us)
How can we help you?
- There are no suggestions because the search field is empty.
1. [SimpleRisk Knowledge Base](https://support.simplerisk.com/kb?hsLang=en)
2. [Administrator Guide](https://support.simplerisk.com/kb/administrator-guide?hsLang=en)
3. [11 Reporting and Auditing](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#11-reporting-and-auditing)
# 11.01 The Audit Trail
## Every meaningful action in SimpleRisk (risk submission, mitigation update, document approval, user login, configuration change) writes a row to the audit\_log table. The audit trail is a per-record history accessible from each entity's detail view, exportable for compliance evidence, and queryable from the database for custom analysis.
## Why this is a reference article
This article documents the audit trail's data model, scope, and access patterns. For specific tasks (exporting evidence for an audit, troubleshooting a record's history, querying for compliance), use this as the reference of what's available and where it lives.
## What the audit trail captures
Every entity in SimpleRisk that has a lifecycle (risks, mitigations, controls, audits, documents, users, exceptions, frameworks, configuration) has audit-trail entries. Each entry records:
- **`risk_id`** (or the equivalent entity identifier — the column is named `risk_id` historically but holds the ID for whichever entity the entry concerns).
- **`message`** — the human-readable description of what happened, with HTML markup for highlighting (e.g., changed values are wrapped in ``**).**
- **`timestamp`** — when the action occurred.
- **`user_id`** — the user who performed the action (or `0` for system-initiated actions).
**The trail is append-only at the application level — the application doesn't expose UI for editing or deleting audit entries. Database-level access can modify them, but doing so is detectable (timestamps don't update in expected ways) and contradicts the audit trail's purpose.**
## What gets logged
**Substantive list, not exhaustive:**
- Risks: submission, every field update, status change, scoring methodology change, review action, comment, mitigation creation, close, deletion.
- Mitigations: creation, every field update, deletion.
- Controls: creation, every field update, deletion, mapping changes.
- Tests: creation, execution (test run, results, evidence attached), update, deletion.
- Audits: cycle initiation, status change, completion, comment.
- Documents: upload, update, approval, expiration, deletion.
- Frameworks: creation, update, control additions/removals.
- Users: creation, role change, team-membership change, permission grant/revoke, password change, MFA enroll/disable, deactivation.
- Configuration: settings updates, Extra activations/deactivations, framework installations.
- Authentication: login (success and failure depending on log-level configuration), logout, session-related events.
**Not logged (typically):**
- Read operations — viewing a risk doesn't generate an audit entry. The audit trail captures changes, not access.
- API list endpoints — `GET /api/v2/risks` doesn't audit each call.
- Routine system operations — cron job runs, scheduled tasks (these go to the [debug log](https://support.simplerisk.com/kb/11-02-the-debug-log?hsLang=en), not the audit trail).
**For programs that need read-access auditing (who looked at this risk?), the audit trail isn't the source — web server access logs are, plus any application-level access logging you configure separately.**
## How to access the trail
### Per-entity view
**Every entity's detail view in the SimpleRisk UI shows its audit trail history. For risks: open the risk → the audit-trail panel (typically labeled History or Audit Trail) shows the chronological list of changes for that specific risk.**
**Operators reviewing a specific record use this view; it answers "what happened to this risk?"**
### System-wide view (admin)
**Settings cog → Settings Hub → Audit Trail tile shows every logged event on the instance, newest first. It's the page to open when the question is "what happened on Tuesday?" rather than "what happened to this risk?"**
**The page opens on the Past Hour, so it shows what's happening now rather than a wall of history. The date range list runs from there through Past Day (the last 24 hours) out to All Time; the ranges of a week or more count whole days back from midnight. Beside it, the Type filter narrows the log to one or more kinds of event (risks, controls, users, assets, and so on), and the User filter narrows it to what particular people did. Each list only offers what actually appears in the chosen range, with a count beside each. The search box finds entries containing the text you type.**
**Entries load as you scroll: the first hundred appear immediately and the next hundred arrive as you near the bottom, so even All Time on a long-lived instance stays responsive. The count beside the title says how many entries match the current filters, and the line under the table says how many are loaded so far. Click Date & time to flip between newest first and oldest first. Long entries, such as the full permission list of a role, show three lines with a Show More... link.**
**One limit. When database encryption is on, entries are stored encrypted and can't be searched by text, so the search box is disabled with a note saying why; the date range, type, and user filters still work.**
**Export needs the Import/Export Extra (it shows as locked without it) and downloads exactly what you're looking at: the chosen range, types, users, search, and sort order. The spreadsheet has Date and time, Type, Username, and Message columns. Exporting All Time on a long-lived instance can take a while, since it writes every matching entry.**
### Per-user view
**There's no separate per-user page. To see what one person did, choose their name in the User filter on the system-wide view.**
### API
**An admin API key can read the same data. `GET /api/v2/admin/audit-trail` returns one page of entries (newest first by default) with the log types and users present in the range. It takes `days` (or `hours`), `types`, `users`, `search`, `start`, `length` (up to 100), and `dir`, and it's documented in the API reference alongside the other administrator operations. Integrations that need the whole log for external analysis (a SIEM, say) page through it with `start` and `length`.**
### Direct database query
**For ad-hoc analysis or compliance reporting, direct SQL queries against `audit_log`:**
```
-- All audit entries for a specific risk, chronological
SELECT timestamp, message FROM audit_log WHERE risk_id = 1234 ORDER BY timestamp ASC;
**-- All entries by a specific user in the last 30 days
SELECT timestamp, risk_id, message FROM audit_log
WHERE user_id = 42
AND timestamp >= DATE_SUB(NOW(), INTERVAL 30 DAY)
ORDER BY timestamp DESC;**
-- Configuration changes (entries where risk_id = 0 typically indicate system-level events)
SELECT timestamp, user_id, message FROM audit_log
WHERE risk_id = 0
ORDER BY timestamp DESC LIMIT 100;
```
## Retention and growth
**The audit trail grows continuously. A program with active risk activity produces hundreds to thousands of entries per day. Without intervention, the table grows without bound.**
**Most installs leave the trail in place indefinitely — disk is cheap relative to the value of historical context for audits and investigations. For installs with strict storage constraints or regulatory requirements that mandate a specific retention period:**
- Truncate old entries: `DELETE FROM audit_log WHERE timestamp < DATE_SUB(NOW(), INTERVAL 7 YEAR);` (or whatever your retention window). Coordinate with operations; deletion is irreversible.
- Archive before deletion: `mysqldump --where "timestamp < ..." simplerisk audit_log > audit_log_archive.sql` to a separate archive file, then delete from the live table.
- Partition the table: MySQL supports table partitioning by date, allowing efficient drop of entire partitions at retention boundaries.
**The decision is operational: balance the storage cost against the lookup value of historical entries. Most programs find the storage cost is low enough that retention beyond regulatory requirements is fine.**
## Encryption considerations
**If the [Encryption Extra](https://support.simplerisk.com/kb/09-01-the-encryption-extra-overview?hsLang=en) is active, the `audit_log.message` column is encrypted at rest. Database-level queries return ciphertext for the message field; application-level queries (via API or admin views) decrypt and display.**
**This means:**
- Direct SQL queries against the audit log won't return readable messages without decryption tooling.
- Backups contain encrypted audit messages — restoration requires the master key.
- Analytics pipelines that bypass the application need to handle the encryption (typically by restoring to a non-encrypted environment, or by including decryption logic).
**For most programs, accessing the audit trail through the application's UI or API is the simpler path; direct SQL is for one-off investigations.**
## HTML in audit messages
**Audit messages carry a little HTML markup for highlighting and emphasis. SimpleRisk sanitizes and renders that safely on screen. A custom integration reading the messages directly should treat them as HTML and either render them or strip the markup — don't assume plain text.**
## Compliance evidence
**For compliance audits, the audit trail is often the source of evidence for "we did the things we said we'd do":**
- User access reviews: query for user-management entries in the period.
- Risk reviews: query for risk-review entries showing reviewers and review dates.
- Control changes: query for control-update entries showing when controls were modified.
- Configuration changes: query for system-level entries showing when settings or frameworks changed.
**See [Compliance Evidence Export](https://support.simplerisk.com/kb/11-03-compliance-evidence-export?hsLang=en) for the export workflow.**
## Common patterns
### Investigating a record's history
**A risk shows unexpected state — the audit trail tells you what happened.**
1. Open the risk.
2. Open the audit trail panel.
3. Read chronologically; look for the field change that explains the unexpected state.
### Investigating a user's activity
**A user reports doing X but can't see X — verify whether they actually did X.**
1. Open User Management → the user.
2. View their audit trail entries.
3. Confirm or refute the action.
### Investigating a configuration change
**Something changed in the install — find out who and when.**
1. Direct SQL query against `audit_log` for the relevant time window with `risk_id = 0` (or the relevant entity ID).
2. Identify the change; trace responsibility.
### Sanitizing for sharing
**Sometimes audit trail entries need to be shared (with auditors, with vendors). Strip sensitive content before sharing:**
- Replace user names with anonymized identifiers.
- Redact specific risk descriptions if they contain confidential information.
- Use the API to pull just the metadata (who did what when) without the message body.
## Common pitfalls
**A handful of patterns recur with the audit trail.**
- Modifying audit entries directly in the database. Don't. The trail's value is its append-only nature. Modification undermines its usefulness as evidence.
- Deleting audit entries to "clean up." A user asking to remove their entries is asking for the audit trail to be tampered with. Audit policies should explicitly prohibit deletion outside formal retention purges.
- Treating the audit trail as a complete activity log. It captures changes; not reads. For "who looked at this," see web server logs.
- Querying without an index hint. The `audit_log` table can be large; queries without filters scan the full table. Always filter on `risk_id`, `user_id`, or `timestamp`.
- Letting the table grow indefinitely without monitoring. A 100-million-row audit log slows queries and bloats backups. Define a retention policy and apply it.
- Forgetting that audit messages contain HTML. Custom integrations that treat the field as plain text get HTML tags in the output.
- Not configuring the encryption layer for direct SQL access. With encryption active, direct SQL returns ciphertext for `message`. Use the application or API for human-readable access.
- Treating the audit trail as the only source for compliance evidence. Combine with the debug log, web server access logs, and authentication logs for full visibility.
- Truncating audit entries during normal operations. Bulk-deletion is irreversible; truncate only as part of a deliberate, documented retention purge with prior backup.
- Not periodically reviewing the audit trail for anomalies. Unauthorized configuration changes, mass user deletions, suspicious activity — the audit trail records them, but only review surfaces them. Build periodic review into operations.
## Related
- [The Debug Log](https://support.simplerisk.com/kb/11-02-the-debug-log?hsLang=en)
- [Compliance Evidence Export](https://support.simplerisk.com/kb/11-03-compliance-evidence-export?hsLang=en)
- [Scheduled Reports](https://support.simplerisk.com/kb/11-04-scheduled-reports?hsLang=en)
- [The Permission Model](https://support.simplerisk.com/kb/03-02-the-permission-model?hsLang=en)
- [The Encryption Extra Overview](https://support.simplerisk.com/kb/09-01-the-encryption-extra-overview?hsLang=en)
- [Database Backup and Restore](https://support.simplerisk.com/kb/02-05-database-backup-and-restore?hsLang=en)
- [FAQs](https://support.simplerisk.com/kb/faqs?hsLang=en)
- [SimpleRisk Extras](https://support.simplerisk.com/kb/simplerisk-extras?hsLang=en#main-content)
- [Vulnerability Management Extra](https://support.simplerisk.com/kb/simplerisk-extras?hsLang=en#vulnerability-management-extra)
- [Team Separation Extra](https://support.simplerisk.com/kb/simplerisk-extras?hsLang=en#team-separation-extra)
- [Import-Export Extra](https://support.simplerisk.com/kb/simplerisk-extras?hsLang=en#import-export-extra)
- [Administrator Guide](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#main-content)
- [00 About This Guide](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#00-about-this-guide)
- [01 Installation and Deployment](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#01-installation-and-deployment)
- [02 Upgrades and Maintenance](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#02-upgrades-and-maintenance)
- [03 Users and Permissions](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#03-users-and-permissions)
- [04 Authentication](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#04-authentication)
- [05 Customization](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#05-customization)
- [06 Configuring Risk and Compliance](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#06-configuring-risk-and-compliance)
- [07 Integrations](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#07-integrations)
- [08 The API](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#08-the-api)
- [09 Encryption and Data Security](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#09-encryption-and-data-security)
- [10 Workflows and Automation](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#10-workflows-and-automation)
- [11 Reporting and Auditing](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#11-reporting-and-auditing)
- [12 Operations](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#12-operations)
- [13 Reference](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#13-reference)
- [User Guide](https://support.simplerisk.com/kb/user-guide?hsLang=en#main-content)
- [00 Foundations of GRC](https://support.simplerisk.com/kb/user-guide?hsLang=en#00-foundations-of-grc)
- [01 Risk Management](https://support.simplerisk.com/kb/user-guide?hsLang=en#01-risk-management)
- [02 Compliance Management](https://support.simplerisk.com/kb/user-guide?hsLang=en#02-compliance-management)
- [03 Governance](https://support.simplerisk.com/kb/user-guide?hsLang=en#03-governance)
- [04 Asset and Data Inventory](https://support.simplerisk.com/kb/user-guide?hsLang=en#04-asset-and-data-inventory)
- [05 Threat and Vulnerability Management](https://support.simplerisk.com/kb/user-guide?hsLang=en#05-threat-and-vulnerability-management)
- [06 Assessments](https://support.simplerisk.com/kb/user-guide?hsLang=en#06-assessments)
- [07 Incident Management](https://support.simplerisk.com/kb/user-guide?hsLang=en#07-incident-management)
- [08 Audit and Reporting](https://support.simplerisk.com/kb/user-guide?hsLang=en#08-audit-and-reporting)
- [09 Day-to-Day SimpleRisk](https://support.simplerisk.com/kb/user-guide?hsLang=en#09-day-to-day-simplerisk)
- [10 Continuous Improvement](https://support.simplerisk.com/kb/user-guide?hsLang=en#10-continuous-improvement)
- [SimpleRisk User Guides](https://support.simplerisk.com/kb/simplerisk-user-guides?hsLang=en)
- [Troubleshooting](https://support.simplerisk.com/kb/troubleshooting?hsLang=en)
- [SimpleRisk Hosted](https://support.simplerisk.com/kb/simplerisk-hosted?hsLang=en)
- [How To videos](https://support.simplerisk.com/kb/how-to-videos?hsLang=en)
[](https://www.simplerisk.com)
Copyright © 2026, SimpleRisk, Inc.