10.3 Create File Policies in Defender for Cloud Apps Using DLP

The July 28, 2026 SC-401 outline still includes Create file policies in Microsoft Defender for Cloud Apps by using a DLP policy. Teach the skill. Also teach the current product news: Microsoft’s Defender for Cloud Apps Learn pages (file policies, commonly used information protection policies, DLP content inspection, What’s new, and Migrate file policies to Microsoft Purview, the last updated 2026-08-07) state that file policies retire on January 6, 2027. Partner Center’s July 2026 announcement uses the same date: after January 6, 2027, file policies configured in Defender for Cloud Apps will no longer be supported or enforced. File-based data protection is moving to Microsoft Purview DLP and auto-labeling. Defender for Cloud Apps keeps SaaS discovery, posture management, app governance, and threat detection. Session policies are a different control; they are not the file-policy retirement.

Until that date, you still create and operate file policies. After it, you need the Purview equivalents. SC-401 can ask either side.

Two supported ways to “use a DLP policy”

Path A — Purview DLP creates the MDCA policy. Connect the non-Microsoft app in Defender for Cloud Apps first (documented connectors include Box, Dropbox, Google Workspace, Salesforce, and Cisco Webex). In the Microsoft Purview portal, create a DLP policy (Custom is the usual template for Instances). On Locations, turn Instances on. Edit the location, choose Specific instances, and Include instances for the connected apps — or include none, which scopes the policy to all connected apps in the MDCA tenant. Build the rule (SITs, sharing, and so on). Under actions, use Restrict Third Party Apps and pick listed apps. Microsoft’s non-Microsoft cloud apps DLP article states: when you create a DLP policy scoped to Instances, the same policy is automatically created in Microsoft Defender for Cloud Apps. That sentence is the exam wording almost verbatim. Role groups that can create that DLP policy include Compliance administrator, Compliance data administrator, Information Protection, Information Protection Admin, and Security administrator. Instances do not support administrative units. Data state is at rest.

Path B — File policy in the Defender portal with DLP inspection. In the Microsoft Defender portal, go to Cloud Apps > Policies > Policy management, open the Information Protection tab, Create policy, and choose File policy. Default Category is DLP. Give it a name, severity, and filters. Set Inspection method to Data Classification Service (DCS) (Microsoft recommends DCS). DCS is the same classification engine Purview DLP uses for sensitive information types: pick the SIT (or GDPR-style EU identifier types), set a minimum number of content violations (for example 10 credit card numbers), and optionally exclude a regex for an internal classification keyword. You can inspect content, metadata, and/or file name; the default is content and metadata. Matches are masked with “X” and shown with 100 characters of context; numbers in context become “#” and are not stored. Unmask the last four characters of a match is optional. You can also inspect protected files. Third-party DLP or anti-malware engines can extend inspection; that is optional, not the exam default.

The first file policy in a tenant requires Microsoft Entra Service Principal permissions; those permissions are granted automatically only when no file policy exists yet. Later policies do not need that grant again. You are limited to 50 file policies per tenant. Purview’s published ceilings after migration are 10,000 information protection and governance policies and 600 DLP rules per tenant — do not invent other numbers. If file monitoring is enabled but no file policy exists or all are disabled for seven consecutive days, file monitoring is autodisabled; create or re-enable at least one file policy to keep monitoring on.

File policy anatomy versus Purview locations

A file policy is API-based. It continuously scans connected cloud apps for files that already exist and for new content. It is not Exchange/Teams in-motion DLP and not Endpoint DLP. Microsoft documents content inspection across 100+ common file types (Office, Open Office, compressed files, rich text, XML, HTML, and more) and more than 20 metadata filters.

Only the governance action of the first triggered policy is guaranteed. If file policy 1 applies a sensitivity label, file policy 2 cannot apply a different label to the same file. Narrow filters; use Edit and preview results. The Contains filter matches complete words separated by punctuation; spaces/hyphens behave like OR unless you quote strings.

Access-level and ownership traps: OneDrive treats files an external user dropped into your tenant as internally owned, so MDCA does scan them. Google Drive, Box, and Dropbox treat externally owned files as outside your legal ownership; MDCA does not have access. In trash does not apply to SharePoint and OneDrive. Sensitivity-label filters on file policies apply to Microsoft Office files only. Apply sensitivity label as a governance action is currently supported for Box, Google Workspace, SharePoint Online, and OneDrive for Business, and the label must already be published in Purview. Supported Office/PDF types for applying labels are listed in the Purview integration article; PDF needs unified labels.

Where Purview DLP already covers the app

Microsoft’s migration table maps MDCA Access level External or Public to Purview Content is shared from Microsoft 365 with people outside my organization, DCS inspection to Content contains SITs, custom regex to custom SITs, minimum violation count to SIT instance count, and file name/extension to document name / file extension conditions. Parent folder becomes site-level scoping only — Purview has no folder-level equivalent. File ID has no Purview equivalent. Sharing remediation in Purview blocks future access; it does not always strip existing sharing the way MDCA Remove external users does — Microsoft points at Restrict access plus Power Automate when you need to unwind sharing. Trash or delete file, expire shared link, and transfer file ownership have no direct Purview DLP equivalent.

Important: Policies in Defender for Cloud Apps and Purview cannot coexist. Running equivalent policies in both products at the same time creates enforcement conflicts. Validate Purview in simulation mode, turn Purview on, then set the MDCA file policy to Disabled (do not delete yet), confirm protection, then delete the file policy.

Build the classic DLP file policy, then plan the 2027 move

Common exam/lab pattern from Microsoft’s information-protection policy article:

1. Connect at least one app with an app connector.
2. Create a File policy.
3. Set Access Level equals Public / Public (Internet) / External if the story is oversharing.
4. Set Inspection method to DCS and pick the SIT (or set Sensitivity label equals Confidential if the story is labeled data).
5. Set governance: for Google Workspace, Remove external users and Remove public access are the documented examples; for labeling at rest, Apply sensitivity label on supported apps.
6. Create the policy and review matches (Matching now versus History up to six months).

Split migration work by purpose: DLP detection and response file policies become Purview DLP; apply label file policies become Purview auto-labeling (auto-labeling does not backfill unchanged files — use on-demand classification for at-rest catch-up). Recreate each MDCA file policy as one or more Purview DLP rules because Purview policies contain multiple rules and MDCA file policies do not. Purview gains simulation mode, which file policies never had.

After migration, DLP matches live in Purview > Data loss prevention > Alerts and Activity explorer; auto-labeling matches live under Information protection; incidents can still appear in the Defender portal. File-policy alerts remain a later SC-401 bullet; this section is create, not respond.

Do not invent unpublished file-policy limits beyond the 50-policy cap, the seven-day monitoring autodisable, the query-size warning on huge collaborator filters, and the first-policy Service Principal requirement. When you can create the Instances DLP policy that auto-stamps MDCA, build a DCS file policy in the Defender portal, contrast those API file policies with Purview SharePoint/OneDrive locations, and cite January 6, 2027 without dropping the exam skill, you have this blueprint bullet.