What an Unchanged Policy Export Does Not Prove

No separate configuration is required. Microsoft's own compliance table answers yes to whether the change modifies DLP policy enforcement.

Read that as an auditor would. Your DLP policy targets the Copilot workload, it has done since you wrote it, and the export you filed in September is the export you would file in November. The policy is the same and the set of things it governs is larger. If your attestation says "DLP blocks prompts containing card numbers in Copilot", it is now true of a second product that the statement never mentioned. That is probably a good outcome. It is still a change to what you are attesting, and nothing in the export records it.

The second goes the other way. Notice MC1481313, published on 28 September, says that legacy Teams retention policies which currently also apply to Microsoft 365 Copilot interactions will be treated as Teams-only. Copilot interactions will no longer be retained or deleted through them, and anyone who needs retention for Copilot has to configure a policy for that workload. Microsoft's compliance table answers yes to whether the change modifies retention policies, and it says the Teams behaviour is unchanged.

Here the policy object again stays as it is. Its name, its retention period and its Teams locations are all the same. What drops out is a workload that your retention schedule may have been quietly covering, and a retention period that was part of your answer to a records question will simply stop applying to it.

The third case is quieter. Notice MC1530948, published on 29 October, adds support for legacy Office formats, .doc, .xls and .ppt, to service-side auto-labelling in SharePoint and OneDrive. New policies pick the formats up automatically. Existing policies do not: Microsoft's instruction is to make a small edit, such as adding or removing a comment, save it, and run the policy again to restart the crawl. The preview begins in early November and general availability in late November, according to the notice.

Read between the lines of that instruction. An existing policy needs a restart to evaluate those formats because it did not evaluate them before. The notice does not say that in terms, and I have not seen a coverage report to check it against, so treat it as my reading and not as Microsoft's statement. But if it is right, then every auto-labelling policy you have is, today, a policy that has never looked at a legacy Office file. The policy is enabled. Its scope lists the right sites. Its simulation results were clean. An old .doc in a SharePoint library has been outside all of it, and the setting gave you no way to tell.

I do not know whether the Purview coverage reports distinguish a file that was evaluated and not labelled from a file that was never evaluated. That is the question to put to your own tenant, because the answer decides whether you can ever see this class of gap from the inside.

The fourth is dated, which makes it useful. Microsoft's documentation for the memberOf operator says that after 3 November 2026, dynamic membership groups, dynamic administrative units and entitlement management auto-assignment policies that use the operator "stop updating and remain in their last known state". The page lists what that can leave stale: Teams and SharePoint access, Conditional Access targeting, group-based licensing and access package assignments.

The group exists after 3 November. Its rule is unchanged and reads as valid. It just no longer moves, so a leaver stays in it and a joiner does not arrive. The page is also clear that the operator is a preview feature and "isn't intended for production use", which is fair, and which is not a reason to assume nobody built something on it. I have no way of knowing from outside a tenant, and the page says nothing about whether the audit log or the dynamic group processing status will tell you a group has frozen. Check before you assume it will.

A fifth case sits in Conditional Access, and the previous post left it for this one. Since 15 June 2026 Microsoft has been rolling out, progressively, evaluation of sign-ins that request only baseline scopes on policies that target All resources and carry a resource exclusion, where previously those scopes were excluded. A tenant that chose Disable enforcement or Customize behavior in the baseline scopes settings keeps the old behaviour for the policies it chose. Microsoft's enforcement page was updated on 8 October and now carries a Graph query that lists the affected policies, plus a per-policy way to keep the legacy behaviour using a placeholder application. The policy JSON you exported in May was correct then and describes a different enforcement now.

One more case belongs here as a warning about method, not as an instance. A Message Center notice about Teams file sharing in external chats, MC1479514, was first summarised as saying that the default would change from Disabled to Enabled "even if your organization previously configured the setting as Disabled". That is the strongest form of the claim in this post, a vendor overwriting a setting you chose. At its current version, which is the fifth, the notice no longer says it. It applies to tenants that left the setting at its default, it says an explicit Disabled is respected, and the rollout dates have been withdrawn. Its 15 October update did add one actionable line: "Please update your settings by the first week of November".

Microsoft shows only the current version of a notice. The community archive I read keeps the history, and its per-version links returned the current text when I tried them, so I could not recover the original wording myself. The consequence is the useful part. If you recorded the text on 25 September, you are holding a claim the vendor has since retracted, and if you did not, you cannot prove what it said. A record of what a notice said, with the date you read it, is evidence in a way that a link to the notice is not.

I run a nightly configuration snapshot of a developer tenant, the pattern described in Configuration as Code for Endpoint Management. In its first runs it returned five resource types and 35 resource instances.

I reverted two settings types by pull request, with the tenant read-back matching the baseline file after normalisation. That is a real answer to configuration drift: someone changes a setting, the snapshot diff shows it, and the change is reverted from the repository.

It is blind to every case above. A snapshot of an unchanged object is identical before and after a vendor-side change, which is the whole point. The DLP policy file is the same on the day Cowork is added. The retention policy file is the same on the day Copilot drops out. If the detection of drift in your estate is a diff of exported objects, you have detection for one of the two kinds of drift and none for the other, and the second kind is the one the auditor cannot see either.

1. List your dynamic groups that use memberOf. After 3 November 2026 they stop updating and stay in their last known state, so replace the rule, convert the group to assigned membership, or accept the freeze per group: a frozen Conditional Access exclusion group keeps its last members exempt, and a frozen target group stops covering joiners.
2. Beside each dated export, record in plain words what the control covers: the workloads, the file formats, the scopes, the group sources. Two sentences per control are enough. The point is to have something a notice can contradict.
3. Treat Message Center as a change feed for those records. Each notice that mentions a service you attest to gets read against the record, and an entry that no longer holds gets a dated correction. Keep the text you read, with the date, because Microsoft will not keep the earlier version for you.
4. For each classification, retention or access control, ask what it has evaluated and how you would know. For auto-labelling, that means finding out whether a coverage report separates unlabelled from unevaluated. For a dynamic group using memberOf, it means finding out what, if anything, tells you it has stopped.
5. Run the Graph query on Microsoft's baseline scopes page against your own tenant. It is the one case here where the vendor has published a way to find the affected policies, and it is a good habit to look for one each time.

I fetched the two Microsoft Learn pages cited above on 30 October 2026. The memberOf page was last updated on 5 August 2026 and says what is quoted. The enforcement page was last updated on 8 October 2026 and contains the Graph query and the placeholder application setting. Both are primary sources.

The four Message Center notices are mirror-verified, not verified at primary. I read them on 30 October through mc.merill.net, a community archive, because Message Center needs tenant authentication and I did not read them there. MC1477182 and MC1530948 show a publication date and no revision. MC1481313 shows a last-updated date of 28 October and two versions. MC1479514 shows a last-updated date of 15 October and five versions. I did not re-fetch the earlier Message Center notice for the baseline scopes change, and I did not read the notice behind the memberOf date, so its history is unchecked.

I have not read any of this from a live tenant. Whether the Purview interface or Get-RetentionCompliancePolicy shows the effective scope change, whether coverage reports separate "not labelled" from "not evaluated", and whether the Entra audit log surfaces a frozen group are open, and I have not tested any of them. Where I have read between the lines of a notice, I have said so.

Start with the two sentences per control from the second item: the post is only useful once you have something a notice can contradict.

Check the pages themselves before you act on this post. They are the part that moves.