The account, not the domain
This is where most policies go wrong.
chatgpt.com is not sanctioned or unsanctioned; the session is. Your enterprise tenant and an employee’s personal free account are the same hostname, the same interface, and entirely different legal positions.
A control that classifies by domain will mark both as approved. One that classifies by tenant or account context can tell them apart — and that difference is usually the difference between a governed disclosure and an ungoverned one.
Why severity should differ
The same finding is a different event.
A card number reaching your contracted tenant under a no-training DPA is a policy matter to correct. The same card number reaching a personal free-tier account is an uncontrolled third-party disclosure.
Scoring them identically produces a queue your analysts stop reading — mostly full of alerts about the tool you told everyone to use.
| Sanctioned tenant | Personal / unsanctioned | |
|---|---|---|
| Contract and DPA | ✓ | — |
| Training exclusion | ✓ | Depends on tier |
| Retention terms | Defined, often negotiable | Provider default |
| Deletion on request | Contractual | Best effort |
| BAA available, for PHI | Sometimes | — |
| Your audit rights | Defined | — |
In Itzal this is a per-framework parameter. PCI DSS might exempt nothing; an internal codename policy might warn only on unsanctioned destinations.
Sanctioning is not permanent
Two failure modes worth a calendar reminder.
Terms change. A provider updates its data handling and your sanctioned tool is now governed by something you have not read. Re-verify at renewal, at minimum.
Features appear. An approved SaaS product ships an AI feature after your assessment. The vendor is still approved; a new data flow to a model provider is not. This is the third form of shadow AI, and it arrives without anyone deciding anything.