Skip to main content

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.

note

Audit Log access requires Admin or SuperAdmin role. Regular users cannot view audit logs.

Accessing the Audit Log

  1. Navigate to SettingsAudit Log (or app.plexicus.ai/settings#audit-log)
  2. You will see a paginated list of events, newest first

Understanding Audit Events

The audit log records the following categories of actions:

CategoryExamples
User EventsUser login, password change, 2FA setup, passkey registration, role assignment
Client EventsOrganization name change, subscription tier update, feature flag toggles (Fix Verification, Autonomous Scan, etc.)
Repository EventsRepository added/removed, branch scanned, scan configuration changed, webhook triggered
Finding EventsFinding 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 record
  • entry_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:

  1. In the Audit Log page, click Verify Integrity (if available in your UI)

    • The system recomputes every hash from oldest to newest
    • Reports valid: true if all hashes and linkages are intact
    • Reports valid: false with a first_break pointer to the tampered entry
  2. 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, the first_break field will indicate the record ID and hash mismatch.

warning

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