Monitoring and Observability in Lumos

Last updated: September 8, 2026

This document covers two related topics. The first is what Lumos produces at the end of a user access review campaign and how that evidence holds up for an auditor. The second is a recommended set of observability standards, including a health-check dashboard you can build in Lumos, so your team can monitor the platform continuously rather than only when something breaks.

Part 1: Audit Logs and Reporting at Campaign End

What "campaign end" means in Lumos

A campaign cannot be completed until every application in scope has reached a completed state. Each in-scope application moves through preparation, reviewer assignment, in progress, and then completed or waiting for manual action. Lumos blocks the "Complete Review" action while any line item in any in-scope application still has no decision recorded against it, so a completed campaign is by definition a campaign with 100 percent decision coverage.

When the campaign is completed, Lumos stamps a completion timestamp on the campaign, records a "Completed Review" event with the actor who completed it, and finalizes the auditor report. If your campaign is configured to recur, the next campaign in the series is prepared at that moment from the recurrence settings.

The auditor report package

Completing a campaign produces two report artifacts, and both are generated from a point-in-time snapshot of the review data rather than from live data. This matters for audit defensibility: the report reflects what the reviewer saw and decided at the time of the review, not what the entitlement looks like today.

The PDF auditor report is the narrative evidence package. It opens with a cover page carrying the campaign name, your company name, the date the campaign was created, who created it, the date the report was generated, and who generated it. It then lists every reviewed application. For each application it presents a summary page showing whether the review was conducted on accounts or on permissions, the total number reviewed, and the counts rejected, modified, and accepted, along with the timestamp of the data sync the review was built from and the complete list of reviewers. If the application was scoped rather than reviewed in full, the scope filters that were applied are printed alongside the summary, so an auditor can see exactly what population was in and out of scope. Following the summary, the report includes a per-application results breakdown table, an evidence section containing any attachments and notes reviewers uploaded, a permissions section, and a separation of duties section listing any rule violations surfaced during the review.

The CSV report is the line-level export, and it is the artifact most audit teams work from because it is filterable. Every reviewed line item becomes a row. The columns include the application, the review type, the account holder's name and email, the account source, title, employee status, provisioned date, last login, last activity, final account status, the entitlements or roles held (with descriptions for account reviews and a dedicated permission description and permission tags column for permission reviews), any separation of duties rule violation, the reviewer who made the decision, the date the decision was made, the decision itself, the originally assigned reviewer, the notes and removal method, any linked service ticket, the decision reason, modification instructions, and the account's external identifier in the source system. Where AI assistance was enabled, the AI suggestion, category, and insight are carried as their own columns so an auditor can see both the recommendation and the human decision side by side.

Both reports are downloadable from the campaign in Lumos. Report downloads are themselves recorded, so there is a record of who pulled the evidence and when.

Two practical notes. First, reports can be generated before a campaign is finished, and Lumos marks those as incomplete rather than complete, which prevents a mid-campaign export from being mistaken for final evidence. Second, on very large campaigns the PDF can exceed a practical page count, in which case the CSV remains the complete artifact and the PDF is skipped. If you expect campaigns at that scale, plan on the CSV as the primary evidence file and let us know so we can confirm your threshold ahead of your first audit cycle.

The activity log as the underlying audit trail

The reports summarize decisions. The activity log is the immutable event trail behind them, and it is where an auditor goes when they want to reconstruct a sequence of events rather than read a summary.

Lumos records a discrete, timestamped, actor-attributed event for effectively every meaningful action in the review lifecycle. That includes campaign creation, scope changes, applications added or removed, reviewer assignment and notification, reminders and escalations sent, delegation and reassignment of a reviewer, each individual approve, reject, and modify decision, decisions that were subsequently removed or changed, notes added, evidence uploaded, service tickets created for remediation, access actually removed, manual removals recorded by an administrator, removal failures, per-application completion, and campaign completion. Permission-level reviews carry their own parallel set of events, so entitlement decisions are distinguishable from account decisions in the trail.

Each event carries the event type, a human-readable label, the outcome, the actor (including whether the actor was a person or the platform acting automatically), the target or targets, and the time the event began, plus event-specific metadata. The distinction between a human actor and a system actor is explicit in the record, which is the field auditors typically ask for when a review includes automated decisioning.

Administrators reach the log at the Activity Log page in Lumos, where it can be filtered by actor, application, event name, status, target user, review name, and time range, and exported to CSV directly from the filtered view. That filtered export is usually the fastest way to answer a narrow auditor request, for example every rejection and every subsequent removal for one application in one quarter.

Programmatic access

If you want to pull this evidence into your own GRC tooling rather than download it manually, both objects are available through the Lumos API (see the REFERENCES Section below for documentation pages).

GET /activity_logs  (see documentation) returns activity events with since and until date filters and standard pagination, returning the event type, friendly label, outcome, targets, actor, start time, and event metadata for each record.

GET /access_reviews  (see documentation) returns your campaigns with their status, the path they were created through, owner and creator, deadline, start time, completion time, and the list of applications attached to each. Individual campaigns, campaign creation, updates, and application scoping are all addressable through the same API surface, which is how you would drive campaign creation from your own scheduling if you prefer that to Lumos recurrence.

Streaming events to your security stack

For continuous monitoring rather than periodic pulls, activity events flagged for security export can be streamed out of Lumos as they happen. There are three delivery options: through a SIEM platform integration configured as an application in Lumos, through an outbound webhook to an endpoint you control, or by having Lumos write events into an S3 bucket that you own, using a role you grant with an external ID. The S3 path is generally the cleanest fit for a team that already lands identity telemetry in its own data platform and wants to avoid a per-event webhook dependency.

Review events, including campaign completion, are included in the exported set, so campaign lifecycle milestones can be alerted on in your own tooling without polling Lumos.

Remediation evidence, which is usually the harder half of the audit

Most audit findings on access reviews are not about the decision, they are about proving the decision was carried out. Lumos treats remediation as part of the same record rather than as a separate process.

When a reviewer rejects access, Lumos can revoke it automatically where the integration supports write operations. The revocation attempt, its success, and its failure are all separate logged events, so a failed revocation is visible rather than silent. Where an application cannot be written to, the line item moves into a state that waits for manual action, an assigned remover is notified, reminders are sent on the deadline approach, and the administrator records the manual removal in Lumos, which produces a "manually removed" event attributed to them. Where you have a service management integration in place, a ticket can be raised for the removal and the ticket reference is carried on the line item and into the CSV export, which gives you a clean join between the review decision and the ticket that fulfilled it.

The result is that the CSV report's final account status and notes and removal method columns, read alongside the activity log's removal events, answer the two questions auditors actually ask: was the access removed, and can you show me when and by whom.

One point worth planning around

Because a completed campaign is a point-in-time snapshot, the report will not reflect access changes made after completion. That is the correct behavior for evidence, but it means that if a rejected line item is remediated after the campaign is closed, the remediation lives in the activity log rather than in the report. For SOX-style testing we generally recommend closing the campaign only after remediation is complete, or pairing the report with an activity log export covering the remediation window. We can help you decide which pattern fits your control language.

Part 2: Observability Standards and a Health-Check Dashboard

The goal here is that a data problem in a connected system never reaches a reviewer as a bad review population, and never reaches an auditor as an unexplained gap. Lumos gives you five layers to work with. Used together they cover connection health, sync correctness, data freshness, and campaign progress.

Layer 1: Connection health per integration

Every connected application in Lumos carries a connection health indicator, shown as a connected badge on the application's Integrations tab. This reflects whether Lumos can currently authenticate and reach the source system. It is deliberately separate from sync outcome, so it is possible for a connection to be healthy while the most recent sync failed for a data reason. Read the two together rather than treating the badge alone as an all-clear.

When a credential or scope problem breaks a connection, Lumos notifies domain administrators by email and by Slack, naming the application, quoting the error, and linking to the Integrations tab. If you run on-premises agents, agent disconnection is a separate administrator notification. We recommend confirming which of your team members hold the administrator role that receives these, since that is the alert path that matters most in practice.

Layer 2: Sync visibility per run

Sync Visibility gives you a run-by-run view of each integration's syncs, reachable from the application's Integrations tab. For each run it shows the stages the sync moved through, how long each stage took, and how many records each stage produced, across data acquisition, data transformation, data installation, and coalescing. You can view results grouped by entity type (accounts, identities, entitlements, associations) or by pipeline stage. Runs in flight show a live indicator with elapsed time.

This is the right tool for two specific questions: did this sync actually finish, and where did the record count change unexpectedly. Two limits to know: the view covers the last seven days, and per-run sync detail is not currently exposed through the API, so this layer is a console workflow rather than something you can pull into your own dashboards today.

Layer 3: Circuit breakers, which prevent bad data from landing

Circuit breakers are the safeguard that stops an anomalous sync before Lumos installs the data, which is the mechanism that protects you from a truncated or malformed source response cascading into unintended deprovisioning or a wrong review population. Four rules evaluate every full sync by default: mass account deactivation, which trips when half or more of active accounts are reported deactivated; mass account absence, which trips when half or more of active accounts are missing from the response; empty account response, which trips when zero accounts are returned; and mass identity deactivation, which trips when half or more of active identities move to terminated after coalescing. The ratio rules require a minimum sample size before they evaluate, so small applications do not trip them spuriously.

When a rule trips, the sync halts before installation and nothing in Lumos changes. The blocked run appears on the application's Integrations tab showing the expected value, the actual value, and the threshold that was crossed. Every change to a rule or threshold is recorded in the activity log with actor, timestamp, reason, and before and after values, which means your circuit breaker configuration is itself auditable. Resolution is either to wait for the source to be corrected and resync, or, if the change was legitimate, to raise the threshold or disable that rule for the application and rerun.

Layer 4: A health-check dashboard you own

Lumos includes customizable dashboards, and this is where you can build the single pane your team checks each morning. The application-level fields most relevant to platform health are the last finished sync timestamp, the last sync state, a derived data freshness indicator, and last known activity age for accounts. A useful starting layout is four tiles:

Integration health. A table of all applications showing last sync state and last finished sync timestamp, filtered to failures, sorted oldest first. This is your daily triage list.

Data freshness. A table of applications where the freshness indicator is false, which surfaces the applications whose data is too old to be trusted as a review population.

Review readiness. Counts of terminated user accounts, partially offboarded users, dormant privileged accounts, and unmatched accounts, each filtered to applications whose data is fresh. Filtering on freshness is the important detail: an unfiltered count mixes real findings with stale-data artifacts, which is how teams end up chasing false positives.

Campaign progress. Complete and incomplete counts for in-flight campaigns against their deadlines, plus reviewed and rejected volumes over time and rejections broken out by application.

Two field-level cautions. The last finished sync timestamp is the completion time of the last successful full sync, not the last attempt, so an application that has been failing for weeks will show a stale but valid timestamp rather than an error. Always pair it with last sync state. And a last attempted sync timestamp is not currently exposed in the dashboard field list, so "when did it last try" is answered in Sync Visibility rather than on the dashboard.

Layer 5: Continuous monitoring outside Lumos

For alerting rather than dashboarding, use the activity log stream described in Part 1. The events worth building alerts on are integration errors, removal failures, campaign auto-launch blocked events (Lumos will refuse to auto-launch a recurring campaign on stale or incomplete source data, and that refusal is both a notification and an event), and campaign completion. Streaming these into your SIEM gives you paging on identity governance failures on the same footing as the rest of your infrastructure.

Daily. Check the integration health and data freshness tiles. Anything failing more than 24 hours gets an owner.

Weekly. Review any blocked or circuit-broken runs in Sync Visibility for applications in your next campaign's scope. Confirm administrator notification recipients are still correct.

Monthly. Review dormant privileged accounts, partially offboarded users, and unmatched accounts, filtered to fresh data. Confirm circuit breaker thresholds still match expected business volatility.

Before each campaign launch. Confirm every in-scope application has a successful recent full sync and a true freshness indicator. This single check is the highest-leverage thing your team can do, because it prevents the most expensive failure mode, which is a reviewer certifying a population that was already wrong.

At each campaign close. Download both report artifacts, export the activity log for the campaign window, and confirm every rejection has a corresponding removal event or a recorded manual removal.

Where to read more