Skip to main content

Security Activity

Security Activity shows what is happening around security in your environment in a single chronological feed. It is not only about attacks that already happened; it brings configuration changes, deviations, approvals and the monitoring lifecycle together in one place.

There used to be a technical, repetitive "Records" screen for this need. We removed it; everything now lives under Security Activity. Old links redirect here automatically. The underlying audit and record infrastructure was not removed — we only built a single, clear surface on the customer side.

What it shows​

The following sources merge into one timeline:

  • Verified Conditional Access changes in Microsoft Entra
  • TrueState deviations
  • VIP Guard identity and mailbox events
  • TrueState lock and baseline approvals
  • Re-baseline operations
  • Exception add and remove
  • Planned change and monitoring pause / resume
  • CCM activation, deactivation, license and lifecycle events
  • Approval and governance operations
  • Security-relevant admin changes such as alert recipients and time zone

What it does not treat as an event​

Scan counters, schema diffs and purely operational metric changes are not added to the default list as events. For example, the number of open alerts dropping from 17 to 13 is not, on its own, evidence of an investigable event; it does not mean a security setting changed.

If a source only keeps an aggregate count, we do not manufacture a fake individual event from it. Without object-level verified evidence, it does not appear in the list.

Scan observation vs verified event​

This distinction matters:

  • Scan history shows the configuration difference observed between two snapshots. On its own it does not prove the exact time of the change or who made it.
  • A verified event, when it is backed by a source such as the Microsoft Entra audit log, can also show the exact time, who acted, the affected scope and the security impact.

A control result changing is not the same as "these controls read this configuration". Control relationships are not surfaced as primary information, to keep the screen uncluttered.

For complex fields such as Conditional Access policies, raw JSON is not the main view. A change is summarized meaningfully by policy name and id. Raw or technical detail opens only in a technical-evidence layer, and only when it is genuinely needed.

Filters​

You can filter by source:

  • Microsoft Entra
  • TrueState deviations
  • VIP Guard
  • Approval & governance

Date range and pagination​

Default date ranges are 7 days, 30 days, 90 days and 1 year. The maximum history you can query from the interface is 1 year (366 days).

The list shows 20 records per page, with numbered pagination (1, 2, 3, 4…) at the bottom. A year of data is not loaded into the browser at once; records are fetched in batches in the background, and the next batch is pulled only when you move to a page that has not been loaded yet.

When you change the date range, the screen is not torn down and rebuilt. Your workspace stays visible, only the record list updates, and an "Updating the activity list" status is shown while it does.

Roles and access​

Security Activity records are available only to administrators of your own tenant: Global Administrator, Security Administrator, Global Reader and Security Reader. That boundary is enforced on the API that produces the response; it is not merely a visual hide.

For that audience, identity data is shown in full: the account that acted, the approvers, the accounts affected by a change, mail addresses, and immutable user/object identifiers (GUIDs). The reason is what the record exists for — "o***@company.com deleted a policy" is not an audit trail and tells the reviewing administrator nothing.

Data minimisation is unchanged: full user and mail lists are not stored (counts are), phone numbers and mail addresses in VIP identity records are still stored masked, and a full configuration copy is never carried in a response body.