What the Communication Compliance wizard does not tell you

Scoping looks like the easy part. You pick the groups you already use and move on.

The supported list is short: distribution groups and Microsoft 365 groups. Unsupported for scoped and excluded users: dynamic distribution groups, nested distribution groups, mail-enabled security groups, and Microsoft 365 groups with dynamic membership.

That rules out most of what a mature tenant runs on. Dynamic membership is exactly how you would want to scope this, because joiners and leavers handle themselves, and it is the one thing you cannot use. Nested groups are the other common casualty: if your department lists are built from sub-lists, the policy sees the wrapper and nothing inside it.

There is a soft ceiling too. A policy supports roughly 20 groups or distribution lists, and the real number drops as you add conditions.

This one is worth reading twice, because both options look interchangeable in the wizard.

Assign a distribution group and the policy detects all email from each user in it. Assign a Microsoft 365 group and the policy detects email sent to that group, not the mail each member sends or receives individually.

So one scopes people and the other scopes an address. If you wanted to monitor what a trading desk sends and you scoped their Microsoft 365 group, you are monitoring mail arriving at the group address and none of their outbound.

The policy will look healthy. It will just be watching the wrong direction.

Communication Compliance is sold on privacy by design, and usernames are pseudonymised by default. That is true, and it is narrower than it sounds.

With anonymisation on, someone in the Communication Compliance Analysts role sees a pseudonym like AnonIS8-988 instead of a name. Someone in the Communication Compliance Investigators role always sees real names, whatever that setting says.

So the privacy control is really a decision about which role group you put each reviewer in. Putting a reviewer in Investigators because it sounded like the right job title quietly opts them out of anonymisation.

Two more edges. The setting is all or nothing across every policy, current and historical, not per policy. And it does not apply while you are administering: names are shown in full when you add users to a policy.

Scoped users can be groups. Reviewers cannot. No group type is supported for reviewers at all, so they are named individually, one at a time, on every policy.

Each reviewer also has to clear three separate bars: a mailbox hosted on Exchange Online, membership of the Analysts or Investigators role group, and an explicit assignment on the policy itself. Missing the third is the common one, because the role group makes the menu appear and gives the impression the job is done.

Be ready for the side effect: adding someone as a reviewer sends them an automatic email telling them so. Worth knowing before you add your HR director at 6pm on a Friday to test something.

The people being monitored need the licence. It is not the reviewers. Scoped users need Purview Suite, an Office 365 E5 subscription, or Office 365 E3 with the compliance add-on.

Check your region. Communication Compliance only runs in tenants hosted where its Azure service dependencies exist. That is a hard stop, not a delay.

Allow 30 minutes after changing role groups before permissions actually apply. A reviewer who cannot see anything may simply be early.

Built-in classifiers cover 12 languages. Anything outside that needs a custom keyword dictionary or your own trainable classifier, which is real work rather than a checkbox.

Non-Microsoft channels need a connector first. WhatsApp and similar sources are only visible once the data is being imported into mailboxes in your tenant.

And get HR, Legal and Privacy in the room before the policy exists, not after the first alert. This is the one Purview solution where the output is a person rather than a file.