Reference · built on requestOperator by FibricSafety, security & compliance

Audit Trail

Compiles who changed what across access, identity and building systems. Proposes the period report and follow-ups on unexplained changes.

About

Every system keeps its own audit log, in its own shape, for its own retention period. A question like who gave that contractor access to the plant room, and who changed the chiller setpoint the same week, means separate logins and separate export formats. Audit Trail reads the audit logs as they are written: the Okta System Log and Microsoft Entra directory audits, the audit logs of your access platform, and the audits your building platform records against each object.

It matches each change to a change request or work order where one exists. At the end of the period it proposes a report by system, actor and object, and a follow-up ticket for each change that no request explains. The retained copy lands in your warehouse.

This is a reference listing. It documents what Fibric would read from Audit Trail and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Okta System Log events with actor, target, event type, outcome and published time, read by time bounds or polled
  • Microsoft Entra directory audits: activity, category, initiated-by, target resources and result
  • Access platform audit logs, such as Verkada Get Audit Logs with user, IP address, event and device, or Brivo Audit Events
  • Building platform audits with user identity, action type and pre and post values, from the Metasys audits and activities endpoints
  • Change requests and work orders in ServiceNow or Jira Service Management, to explain a change
  • Prior period reports and open follow-ups in your warehouse, such as BigQuery, to carry unanswered items forward

Proposed actions

  • Target capability: propose the period report, changes by system, actor and object with the request that explains each one, for the security lead to approve
  • Target capability: propose a follow-up ticket in ServiceNow or Jira Service Management for each change with no matching request
  • Target capability: propose an export of the period's matched log to BigQuery or Snowflake, so retention outlasts each source system's own
  • Target capability: propose a same-day Teams or Slack notice for changes to objects you mark sensitive, such as a plant room access level

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Explain every access level change this month

    Verkada audit log entries that add a user to an access group are matched to Jira Service Management requests. Those with no request become follow-up tickets for the security lead.

    With Verkada, Jira Service Management

  • Tie a setpoint change to a work order

    A Metasys audit shows a chiller setpoint written by a named user. The operator finds the ServiceNow change request for that night and lists the change as explained in the report.

    With Johnson Metasys, ServiceNow

  • Keep identity audits past their retention

    Okta System Log and Entra directory audits for the period are exported to BigQuery once the report is approved, so a question next year can still be answered.

    With Okta, Microsoft Entra ID, BigQuery

Requirements

  • An identity connector with audit access, such as Okta with the System Log API or Microsoft Entra ID with directory audit permissions
  • An access control connector that serves an audit log, such as Verkada or Brivo
  • A building platform connector that serves audits, such as Johnson Metasys, or Desigo CC where its log is exposed
  • A change or ticket connector for requests and follow-ups, such as ServiceNow or Jira Service Management
  • A warehouse connector for the retained copy, such as BigQuery, Snowflake, or PostgreSQL
Authentication
Audit Trail authenticates to no system itself. It reads each audit log through the connector you have connected for that system, and every report, ticket and export is a proposal until a person approves it.

Limits

  • Each source keeps its own retention. An Okta System Log query defaults to seven days before its upper bound; older history is read in slices.
  • A change is explained only by a request the operator can find. Changes agreed verbally show as unexplained until a person adds the reason.
  • Systems with no audit API, or with audits held only in a local database, are out of scope until a connector exposes them.
  • The operator reads audit logs. It never edits them, and it never reverses a change it finds.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Audit Trail ↗

Questions and answers

Who approves the period report?
The security lead or compliance owner you name. They see every change, the request that explains it or the note that none does, and the proposed follow-ups. They can add an explanation, drop a follow-up with a reason, or approve as is.
Can it undo a change it finds?
No. It reads audit logs and proposes reports, tickets and exports. Reversing a change is a separate action a person takes in that system, with its own audit entry.
What proves the report itself was not altered?
Each approved report is stored with the source log entries it was built from, the time bounds used, who approved it, and the export written to the warehouse. Regenerating the same period from the same sources produces the same report.
Ask about Audit Trail

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.