Does the Applicant employ Data Loss Prevention (DLP)?
Data loss prevention is licensed almost everywhere and enforcing in far fewer places. The question is about enforcement.
What the carrier is actually asking
The carrier is asking whether technology prevents sensitive data leaving through the channels people actually use: mail, collaboration platforms, cloud storage, and endpoints. It is asking about prevention, which distinguishes it from monitoring or classification.
Why it is underwritten
Exfiltration is now the standard second half of a ransomware event, and insider data loss is a steady and separate source of claims. Prevention at the egress points reduces the volume of data that leaves, which directly reduces the notification population the carrier funds.
Where the answer lives in Microsoft 365, Entra ID, and Azure
Microsoft 365 makes this measurable: which policies exist, which channels they cover, and whether they block or merely report.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Microsoft 365 | Data loss prevention policies and their locations | Policies covering mail, SharePoint, OneDrive, Teams, and endpoints rather than a single channel |
| Microsoft 365 | Policy mode: test, test with tips, or enforce | Enforcement for the sensitive information types that matter, since test mode prevents nothing |
| Microsoft 365 | Sensitive information types and their match accuracy | Types tuned to your data, because default types generate noise that leads teams to disable enforcement |
| Microsoft 365 | Policy alerts and who receives them | Alerts routed to a monitored destination, so violations are reviewed rather than counted |
| Microsoft 365 | Sensitivity labels and auto-labelling | Classification feeding prevention, which is what makes policies precise enough to enforce without breaking work |
Almost every deployment starts in test mode to tune the rules. A large proportion never leaves it, because enforcement generates support tickets. A policy in test mode is a reporting tool, and answering yes on the strength of it describes a control that has never blocked anything.
What a defensible yes requires
- Policies enforce rather than report for the highest-sensitivity information types.
- Coverage spans mail, collaboration, cloud storage, and endpoints.
- Information types are tuned to your data, so false positives do not force enforcement off.
- Alerts reach a monitored destination with an owner.
- A user override path exists with justification, so legitimate work is not blocked outright.
How this answer goes wrong
Policies exist for mail only, and the actual egress happens through personal cloud storage and collaboration sharing, which are unmonitored. Or every policy sits in test mode. Both look like deployment in a settings review and neither prevents anything.
Frequently asked
Does DLP stop ransomware exfiltration?
Partially. It raises the cost and catches the less sophisticated tooling, and a determined attacker with administrative access can work around it. It reduces volume rather than eliminating the risk.
Where should we start?
One information type that genuinely matters, enforced across the main channels, tuned until false positives are rare. That beats broad coverage in test mode.
Should users be able to override?
For most policies yes, with a recorded justification. It preserves legitimate work and produces a useful record; the highest-sensitivity types should not be overridable.
Does labelling need to come first?
It helps considerably. Labelled content lets policies be precise, which is what allows enforcement without disrupting people.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture