DLP Policies and Sensitive Info Types

Quick Answer: Microsoft Purview DLP policies detect sensitive information types (SITs) — patterns such as credit card numbers or national IDs — and can block Copilot from processing or surfacing matching content. Device restrictions use Conditional Access, not DLP.

Exam Context

DLP is one of the most testable Purview capabilities on AB-900 because it directly intersects with Microsoft 365 Copilot. Examiners want you to know where DLP applies, what it detects, and what it cannot do. The wrong answers often assign DLP jobs that belong to sensitivity labels (watermarking), Conditional Access (device blocking), or Communication Compliance (harassment detection).

What DLP Does

Data Loss Prevention (DLP) policies identify, monitor, and automatically protect sensitive information across Microsoft 365 workloads. When content matches a rule, DLP can:

• Block sharing or processing outright.
• Warn users with a policy tip explaining the violation.
• Encrypt in some configurations (often paired with sensitivity labels).
• Generate alerts for compliance administrators.

For Copilot specifically, DLP extends to AI interactions: if a user prompt or retrieved document contains configured sensitive information types, DLP can prevent Copilot from processing, summarizing, or surfacing that content.

Sensitive Information Types (SITs)

An sensitive information type is a pattern Purview uses to detect regulated or confidential data. Categories AB-900 emphasizes:

Microsoft ships 100+ built-in SITs. Organizations can also create:

• Custom SITs — regular-expression or keyword patterns for proprietary data formats.
• Exact data match (EDM) — detect values from an uploaded database of sensitive tokens.
• Trainable classifiers — machine learning models trained on sample documents (for example, merger agreements).

On the Exam: Trainable classifiers detect document types; SITs detect data patterns. Both can trigger auto-labeling or DLP, but the detection mechanism differs.

DLP Policy Locations Relevant to Copilot

When authoring a DLP policy, administrators choose locations where rules apply:

Including the Microsoft 365 Copilot location is essential for AI-era governance. A policy that only covers Exchange will not protect Copilot Chat prompts.

Policy Actions and Policy Tips

A typical DLP rule contains:

1. Conditions — which SITs, how many instances (for example, 10+ credit cards), confidence level.
2. Actions — block, notify, generate incident report.
3. User overrides — whether users can justify and bypass (often disabled for highly regulated data).

Policy tips appear inline in Office apps: "This message contains credit card numbers and cannot be sent." In Copilot, an equivalent block might prevent summarizing a spreadsheet column of SSNs even though the user can open the file manually — DLP adds a compliance gate at AI processing time.

DLP vs Other Controls (High-Yield Comparison)

This table resolves many AB-900 distractors. If the stem mentions devices, think Conditional Access — not DLP.

Adaptive Protection and Copilot Signals

Adaptive Protection connects Insider Risk Management user risk levels to DLP enforcement. When a user's risk score rises — potentially driven by unusual Copilot data retrieval volumes — DLP can automatically apply stricter actions for that user without rewriting the base policy.

Adaptive Protection does not permanently block Copilot or auto-author new policies from AI recommendations. It dynamically tightens existing DLP enforcement for elevated-risk users. Permanent access removal remains a manual admin decision.

Purview Activity Explorer and Data Explorer

Two Purview investigation surfaces appear on AB-900 skills lists and are easy to confuse with DLP policy configuration itself.

Activity explorer is the go-to when a stem asks you to identify user activities related to sensitivity labels, DLP policy matches, or how people interacted with protected content. Filter by activity, location, user, or label to investigate oversharing before or after Copilot rollout.

Data Explorer / sensitive-info discovery views help admins find where sensitive information exists so they can prioritize labeling and DLP. On the exam, if the goal is discovery of sensitive content locations, choose Data Explorer-style discovery; if the goal is auditing what users did with that content, choose Activity explorer.

On the Exam: "Identify user activities reported by activity explorer" maps to Activity explorer. "Identify sensitive information" in a discovery sense maps to Data Explorer / content exploration, not to creating a new retention label.

Worked Scenario: Copilot + PHI Block

A pharmaceutical company enables Copilot for research staff. Compliance requires that Copilot never summarize clinical trial patient identifiers. The administrator should:

1. Confirm HIPAA-related SITs are in use (built-in health patterns).
2. Create a DLP policy scoped to SharePoint, OneDrive, Teams, and Microsoft 365 Copilot.
3. Set action to block when SITs match in Copilot processing.
4. Enable Simulation mode first to measure false positives.
5. Pair with sensitivity labels on trial document libraries for defense in depth.

Choosing to disable Copilot tenant-wide is disproportionate; targeted DLP with Copilot location scoped is the exam-aligned answer.

Implementation Tips for Administrators

• Start with Simulation mode — logs matches without blocking.
• Tune instance counts to reduce false positives (one SSN in a test doc vs bulk export).
• Document override justification settings — regulators often prohibit bypass for PCI data.
• Review DLP incidents alongside Purview AI Hub for centralized AI compliance visibility.

Study Checklist

• Define sensitive information types and name three built-in categories.
• Explain how DLP integrates with Microsoft 365 Copilot.
• List at least four DLP policy locations.
• Distinguish DLP from sensitivity labels and Conditional Access.
• Describe Adaptive Protection's relationship to Insider Risk Management.