How the audit is produced

Data is collected from your tenants through Microsoft Graph, using a per-client Entra app registration that exists for no other purpose. The registration authenticates with a certificate, not a client secret, and holds only the read permissions the collection needs; it is granted nothing that can write.

The consent grant, with the exact permission list, is documented and provided to you for your own records, so your own auditors can see precisely what was granted and when.

GCC High tenants are collected through the sovereign cloud endpoint under a separate registration. Commercial and sovereign data are kept distinct through collection and joined only at reconciliation.

Raw collection output is hashed and timestamped before any processing touches it. That snapshot is the evidence. Every figure in the report is derived from it and nothing else.

Snapshots are retained for the life of the engagement, so a number in a report from eight months ago can be traced to the exact bytes it came from.

Snapshot data is normalized into an identity graph: users, groups, roles, devices, applications, service principals, and the relationships between them, across every tenant in scope. Every record in the graph carries source lineage back to the snapshot and API call that produced it.

The current graph is diffed against the previous cycle's graph. That diff is what "what changed since last month" means: not a narrative, but a list of objects and relationships that appeared, disappeared, or changed, each attributable to a specific collection.

Findings are generated by evaluating versioned, declarative rules against the graph. The rules live in version control. Each rule has:

• A stable identifier that does not change between releases
• A severity
• A mapping to the compliance frameworks it supports
• Remediation guidance

A finding exists because a rule matched. Not because of judgment applied on the day, and not because a language model produced it.

Every report cites the collection hash and the rule set version it was generated under. Re-running a past cycle against its stored snapshot with its cited rule set produces identical numbers.

When a rule set changes, the change is versioned and the report says so. A finding count that moves between cycles is either a change in your tenant or a change in the rules, and the report makes clear which.

Collection completeness is asserted programmatically: expected object counts, paging boundaries, and per-endpoint success are checked before anything downstream runs.

A failed assertion blocks report generation. You do not receive a partial report presented as a whole one. You receive a notice that collection was incomplete, what was missing, and a re-run.

When remediation is performed in your tenant under the retainer's included hours, every action is recorded: what changed, who requested it, who approved it, who executed it, when, and the rollback plan.

That record is part of the evidence package. The next cycle's diff will show the same change from the collection side, so the two can be reconciled against each other.