Audit Log
The Audit Log is a comprehensive, tamper-proof record of all actions taken in your Plexicus account. Each entry is cryptographically signed using SHA-256 hash chaining, providing chain-of-custody evidence for compliance audits and security investigations.
Audit Log access requires Admin or SuperAdmin role. Regular users cannot view audit logs.
Accessing the Audit Log
- Navigate to Settings → Audit Log (or
app.plexicus.ai/settings#audit-log) - You will see a paginated list of events, newest first
Understanding Audit Events
The audit log records the following categories of actions:
| Category | Examples |
|---|---|
| User Events | User login, password change, 2FA setup, passkey registration, role assignment |
| Client Events | Organization name change, subscription tier update, feature flag toggles (Fix Verification, Autonomous Scan, etc.) |
| Repository Events | Repository added/removed, branch scanned, scan configuration changed, webhook triggered |
| Finding Events | Finding created, severity updated, marked as false positive, assigned to team member, remediation requested |
Each event record includes:
- Timestamp — ISO-8601 UTC timestamp when the action occurred
- Actor — User ID and email of who performed the action
- Action — The specific operation (e.g., "USER_LOGIN", "FINDING_CREATED")
- Resource Type — The entity affected (e.g., "finding", "repository", "user")
- Resource ID — The specific ID of the affected entity
- Previous Hash — Cryptographic link to the prior entry (enables tamper detection)
- Entry Hash — SHA-256 signature of this record (used to verify integrity)
Filtering and Searching
Use the filter controls to narrow results:
By Time Range
- Select From Date and To Date to view events in a specific period
- Useful for incident response ("What changed between 3pm and 5pm?")
By Actor
- Actor ID: Exact match on user ID
- Actor Email: Case-insensitive partial match on email address
- Example: Filter by "alice@company.com" to see all changes made by that user
By Action
- Action Type: Case-insensitive partial match on action string
- Examples: "PASSWORD", "REMEDIATION", "LOGIN" to find related events
- Useful for compliance ("Show all password changes in Q2")
By Resource
- Resource Type: Exact match (e.g., "finding", "repository", "user")
- Resource ID: Exact match on the entity's ID
- Example: Filter by resource_type="finding" and resource_id="CVE-2024-1234" to track an specific vulnerability
Pagination
- Results are cursor-based (not offset-based) to ensure consistency
- Default limit: 50 records per page (max 200)
- Navigate using Next and Previous buttons
Integrity Verification
Plexicus uses SHA-256 hash chaining to prevent audit log tampering. Each entry contains:
previous_hash: The entry hash of the immediately preceding recordentry_hash: SHA-256(previous_hash + canonical JSON of this record)
If an auditor later modifies or deletes an entry, all subsequent hashes will no longer match.
Verifying the Hash Chain
To verify your audit log has not been tampered with:
-
In the Audit Log page, click Verify Integrity (if available in your UI)
- The system recomputes every hash from oldest to newest
- Reports
valid: trueif all hashes and linkages are intact - Reports
valid: falsewith afirst_breakpointer to the tampered entry
-
Programmatically (for automated compliance workflows):
curl -X GET "https://api.plexicus.ai/audit-logs/integrity-verification" \
-H "Authorization: Bearer $TOKEN"Response example:
{
"valid": true,
"total_records": 5432,
"pre_chain_records": 0,
"first_break": null,
"computed_at": "2026-07-02T20:15:00Z"
}If
valid: false, thefirst_breakfield will indicate the record ID and hash mismatch.
The hash chain only protects records written after hash chaining was introduced in your Plexicus deployment. Older records appear in pre_chain_records and are excluded from the integrity verdict.
Compliance Use Cases
SOC 2 Type II
Demonstrate user access controls and change tracking by exporting audit logs filtered by date range and action type. The hash chain proves the records have not been modified.
GDPR Data Subject Access Requests (DSAR)
Filter by actor email to show all actions taken by a specific user. Useful for privacy audits.
Incident Response
Filter by time range and action type to reconstruct the timeline of a security incident.
- Example: "Show all FINDING_CREATED and REMEDIATION_REQUESTED events between 2026-07-01 12:00:00Z and 2026-07-01 14:00:00Z"
Compliance Audits (ISO 27001, FedRAMP, etc.)
The SHA-256 hash chain provides chain-of-custody evidence that audit logs are authentic and unmodified.
Retention and Limits
- Data retention: Audit logs are retained per your plan's retention policy (typically 1–7 years)
- Query limits: Maximum 200 records per request; use pagination for larger datasets
- Export: Contact support to export audit logs for external audit trail systems
Related Pages
- Two-Factor Authentication — MFA events appear in audit log
- Roles and RBAC — Role changes appear in audit log
- Domain Verification — Domain verification events appear in audit log