Introduction
If you still make screenshots of Microsoft 365 security settings or export the settings manually, Microsoft Graph now offers a much better way. The Tenant Configuration Management (TCM) APIs let you define the settings that matter, take repeatable snapshots of their current state, and detect configuration drift over time across Microsoft 365 workloads.
For NIS2 and ISO-style audits, that is exactly what an evidence collector is expected to do: produce time-stamped, consistent, machine-readable proof of how your tenant was configured at a given moment, and show what changed between review points.
Why this matters for auditors
Auditors rarely want just a point-in-time screenshot. They want evidence that is:
- repeatable
- traceable
- time-bound
- broad enough to cover key controls
- reliable between audit windows
That is where TCM fits well. Instead of opening five admin centers and manually collecting settings, you can use one API family to capture configuration evidence across workloads such as:
- Microsoft Entra for identity and access controls like Conditional Access and authentication policies
- Exchange Online for mail flow and protection settings like transport rules, Safe Links, and Safe Attachments
- Intune for device compliance, endpoint security, and configuration policies
- Microsoft Purview / Security & Compliance for DLP, retention, and labeling-related controls
- Microsoft Teams for collaboration and policy settings, including guest and encryption-related controls
In other words, TCM is not just an API for administrators. It is a strong foundation for an automated compliance evidence pipeline.
The core idea: snapshot plus drift monitoring
The TCM model is easiest to understand in four building blocks which are baseline, snapshot, monitor, and drift.
Baseline
A baseline is your declared scope. It describes the resources and properties you care about. For an evidence collector, think of it as the definition of a control pack: the Microsoft 365 settings you want to prove for NIS2 or ISO reviews.
Snapshot
A snapshot captures the current configuration state for that scope. This is your evidence artifact for a point in time.
Monitor
A monitor runs in the background on a fixed cadence and checks whether the live tenant has drifted from the baseline.
Monitoring results and drifts
Monitoring results tell you whether a run succeeded and how many deviations were found. Drift records tell you what changed, where, and since when.
That distinction is important:
- Snapshots answer: “What was configured on this date?”
- Monitors answer: “What changed since the approved baseline?”
For auditors, you usually want both.
What an evidence collector should do
A practical NIS2/ISO evidence collector built on these APIs should follow a simple pattern.
Define the evidence scope as baselines
Group settings by control theme, not by API convenience. For example: Identity Protection, Email Security, Endpoint Security, Data Protection, and Collaboration Governance.
Take scheduled snapshots
Run snapshots on a schedule that matches your audit needs: monthly, before internal reviews, before external audits, and after major change windows.
Archive the snapshot output immediately
Snapshot jobs complete asynchronously and expose a downloadable output. That output should be copied into your own durable evidence store right away.
Run monitors between snapshots
Use monitors to watch for drift during the period between formal evidence captures. This gives you continuous oversight instead of “audit day only” visibility.
Preserve drift history alongside snapshot evidence
When a configuration changes, drift data shows which resource and properties moved away from the baseline and when the drift was first reported.
This creates a much stronger audit story than a bunch of screenshots. You can show both the approved state and whether it stayed stable.
A good operating model for NIS2 and ISO
The best use of these APIs is not “collect everything.” It is collect the settings that prove your controls are operating.
A good structure looks like this:
- Identity and access: Conditional Access, authentication methods, security defaults, named locations
- Email protection: Safe Links, Safe Attachments, transport rules
- Endpoint and device security: device compliance, endpoint protection, attack surface reduction, onboarding and security policies in Intune
- Data protection and retention: DLP, retention, labeling and related compliance settings
- Collaboration governance: Teams guest and messaging-related policies, relevant encryption or client policies
This aligns much better to audit frameworks than organizing evidence by admin portal.
What makes this especially useful for auditors
Three details from the Microsoft docs make TCM especially practical for audit evidence.
Snapshots are declarative and cross-workload
You are not limited to one service at a time. You can define a structured baseline and use it to retrieve current settings across multiple Microsoft 365 areas.
Drift is a first-class concept
The API does not just expose raw configuration. It explicitly models drift, including status and the time it was first detected. That is valuable for proving change detection and control monitoring.
Monitoring results are operational evidence too
A monitor run records whether it succeeded, partially succeeded, or failed, and how many drifts it found. That helps prove your evidence collection process itself is running reliably.
Design limits
There are a few constraints worth building around:
- Monitors run on a fixed six-hour cadence. You cannot turn them into near-real-time alerts.
- There is a limit of 30 monitors per tenant and a daily monitoring quota across resources, so scope matters.
- Snapshot extraction has a monthly resource quota, so avoid dumping unnecessary settings.
- Snapshot jobs are short-lived. The docs state snapshots are retained for only seven days, so an evidence collector should ingest and store them immediately.
- Only 12 snapshot jobs are visible at once, so clean-up and archival are part of the design.
- Changing a monitor baseline deletes prior monitoring results and drifts for that monitor. For audit scenarios, that means you should treat baselines as versioned evidence definitions, not something you casually overwrite.
That last point is easy to miss, and it matters. If historical evidence is important, manage baseline changes carefully and keep your own archive outside the service.
The real value: from screenshots to evidence engineering
The biggest shift here is not technical. It is operational.
With TCM, you can move from manual evidence gathering to evidence engineering:
- baselines become your control definitions
- snapshots become your audit artifacts
- monitors become your continuous assurance layer
- drifts become your exception log
That is a much better fit for modern compliance programs, especially where NIS2, ISO 27001, or internal governance require repeatable proof rather than one-off attestations.
Conclusion
If you are building an NIS2/ISO Evidence Collector for Microsoft 365, use Microsoft Graph TCM as the backbone. Take scheduled snapshots for formal evidence, use monitors for drift between evidence points, and store everything outside the service in a durable audit repository.
The result is simple to explain to auditors: this was our approved configuration, this is what the tenant looked like on each evidence date, and this is every meaningful drift detected in between.
