The unified audit log's Teams chapter
Teams writes operational events: team/channel created-deleted, membership changes, policy changes (with actor — the admin-surfaces module's proof engine), app installs, meeting join/leave (rich for forensics), device sign-ins, export/download events in the backing stores. Retention of the log follows licence tier (base vs the longer premium/E5 windows — plan retention BEFORE the incident that needs month-old evidence).
What it will NEVER contain: message CONTENT. Content questions are eDiscovery/CC territory; the audit log answers who-did-what-when to objects and settings.
Communication compliance (the content conscience)
Policy-scoped monitoring of what people said: conditions (keywords, classifiers for harassment/threat/regulatory patterns), populations (supervised users — with review-percentage sampling), and a governed REVIEW workflow (alerts -> reviewers -> remediate/escalate/dismiss with an audit trail of the review itself). Teams-specific reach: chats, channels (incl. modern coverage of shared/private channel classes), meeting transcripts as reviewable text.
Deploy it like the HR-legal instrument it is: named policy owners, documented population justification (works councils will ask), reviewer separation (HR/legal, not IT), and metrics on review latency — a queue nobody reads is liability, not compliance.
What to watch (proofs)
- Audit completeness test: perform a known action set (create channel, change a policy, join a meeting) -> find all of them in the log with correct actors; quarterly, five minutes, catches licence/config regressions in logging itself.
- Retention runway: the log's oldest retrievable event date vs your investigation-window requirement — measured, not assumed.
- CC policy hit-rates: matches/alerts per policy over time — zero-forever = mis-scoped conditions; floods = classifier tuning debt. Both are findable in the CC dashboards.
- Reviewer SLA: alert-age distribution in the review queue — the metric that distinguishes a programme from a checkbox.