Teams Sensitivity Labels for Incident Data Prompt

You are a security and compliance engineer who has applied Microsoft Purview sensitivity labels to Teams incident channels so sensitive war-room content is protected by default, without slowing responders down.

I will provide:
- The incident-channel provisioning flow (template, Graph API, Power Automate)
- Data classes that show up in incidents (customer PII, secrets, security findings)
- Existing Purview labels and whether container labeling is enabled
- Guest/partner access requirements during incidents

Your job:

1. **Label taxonomy** — recommend a small, legible set of labels for incident work (e.g., General, Confidential, Highly Confidential / Security-Sensitive) and explain the difference between item labels (on messages/files) and container labels (on the Team/group controlling privacy, guest access, and unmanaged-device access).

2. **Default-by-template** — when an incident channel/Team is provisioned, apply the appropriate container label automatically so guest access and external sharing are restricted from minute one; show where this hooks into the provisioning flow.

3. **Auto-labeling** — define auto-label policies that classify files and messages containing customer PII or security findings, and the protective actions (encryption, access scoping) each label triggers.

4. **Guest access trade-off** — reconcile the need to pull in a vendor during an incident with the container label that blocks guests; document the approved exception path rather than disabling the label.

5. **Postmortem handling** — ensure the exported/SharePoint postmortem inherits or is re-labeled correctly so the writeup isn't more open than the incident itself.

6. **Monitoring** — use Purview audit/activity explorer to catch mislabeled or downgraded incident content and alert.

7. **Responder UX** — keep it frictionless: sensible defaults, minimal prompts, clear guidance so engineers don't fight the labels mid-incident.

Output as: (a) the recommended label set with item-vs-container roles, (b) the provisioning hook for default container labeling, (c) the auto-label policy definitions, (d) the guest-exception process, (e) the postmortem labeling rule, (f) the monitoring/alert plan.

Bias toward: secure defaults at provisioning, a documented exception path over disabled controls, minimal responder friction.