22.1 Respond to Defender for Cloud Apps File Policy Alerts

Exam SC-401 lists Respond to Defender for Cloud Apps file policy alerts under Manage information security alerts and activities. Treat that as an operations skill, not a replay of creating the policy. Chapter 10 already covers Create file policies in Microsoft Defender for Cloud Apps by using a DLP policy. This section is what you do when a match fires: where the alert appears, how you prove it is a real overshare, which governance action you take, and how you close the row so the queue stays honest.

Microsoft Learn (file policies, commonly used information protection policies, governance actions, What’s new, and Migrate file policies to Microsoft Purview) still publishes that file policies retire on January 6, 2027. Partner Center’s July 2026 announcement uses the same date: after that date, 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, app governance, and threat detection. Until retirement, you still investigate file policy alerts. After it, the same overshare story is a Purview DLP or auto-labeling alert. The exam can ask either side.

Where the queue lives (and where it does not)

A file policy is an API-based, at-rest control. It scans connected cloud apps for files that already exist and for new content. When the policy is configured to Create an alert for each matching event with the policy's severity, Defender for Cloud Apps raises an alert. You can also send an alert as email, set a daily alert limit per policy, and send alerts to Power Automate. Microsoft is explicit on one exam trap: governance actions aren't impacted by the daily alert limit. If you cap email noise at a handful of alerts per day, quarantine, remove-external-users, and apply-label still run on later matches. Microsoft does not publish a default numeric daily cap in the file-policy article; the limit is a policy setting you configure, not a number to invent.

Those alerts surface in the Microsoft Defender portal (security.microsoft.com). The investigation path Microsoft documents for DLP-style file matches is Cloud Apps > Policies > Policy management > Information protection. Filter Type to File policy (use Malware detection policy when the risk type is malware). Open the Count column matches link, or use the row menu View all matches to open the File policy report. Matching now lists files that currently match. History lists matches going back up to six months.

The same Defender portal Incidents & alerts > Alerts queue also shows Microsoft Defender for Cloud Apps alerts next to endpoint, email, identity, and Purview DLP. Filter by the Cloud Apps / Defender for Cloud Apps source when you are hunting a file policy, not Data Loss Prevention and not Microsoft Purview Insider Risk Management. Chapter 21 is Purview DLP and IRM in that unified queue. This chapter is the file-policy story: a Box, Google Workspace, SharePoint, or OneDrive file that matched an MDCA file policy.

Do not start in the Microsoft Purview portal > Data loss prevention > Alerts dashboard for a classic MDCA file policy. That dashboard is for Purview DLP policies on Exchange, SharePoint, OneDrive, Teams, devices, Instances, and related locations. A Purview DLP policy scoped to Instances is automatically created as the same policy in Defender for Cloud Apps (chapter 10). After you migrate, matches move to Purview DLP alerts and Activity explorer. Until then, responding to file policy alerts means the Defender Cloud Apps policy-match experience.

As of August 28, 2022, Microsoft Entra Security Reader cannot manage Defender for Cloud Apps alerts. To continue managing them, the account needs a role such as Security Operator (Microsoft’s published replacement for that scenario). Cloud App Security Administrator, Security Administrator, and Security Operator are the roles Microsoft lists when malware governance actions must be visible.

Investigate a match before you close it

Microsoft’s investigation pattern for file policies is: open the match, understand who has the file, what sensitive content hit, and whether sharing is still live, then contain or authorize.

1. Open matches for the file policy. Confirm the app (SharePoint, OneDrive, Box, Google Workspace, Dropbox, Salesforce, and so on), owner, and access level (internal, external, public, public with a link).
2. Select the file to open the File drawer. Documented fields include URL (opens the file location), File identifiers (file ID and encryption keys when available), Owner, Matched policies, and Sensitivity labels. Collaborators show who still has access. Matches on the file can show the inspected evidence (for example Social Security numbers), with violations masked as X and 100 characters of context; numbers in context become # and are not stored. Unmask the last four characters is an optional policy setting, not a default you should assume is on.
3. Use the file’s activity trail. Microsoft documents that a file-policy alert can show activities performed on the matched file, and that the File Alert History tab holds a snapshot at alert time, including whether the file was later deleted or quarantined.
4. Decide true positive versus false positive. A public link on a file labeled Confidential, or a Box file with customer account numbers shared to a personal Gmail address, is the classic true positive. A training deck that uses fake 4111 credit-card examples, or a file your legal team already cleared, is a candidate to Authorize.

Authorizing a file is the documented false-positive exit for a specific file. After you investigate and determine the file is safe, select the check mark to Authorize on the matched-file row. Microsoft states that authorizing a file removes it from the malware detection report and suppresses future matches on this file. Authorizing one file is not the same as disabling the policy, and it is not the same as closing the alert without evidence.

If the event is allowed and you expect it to recur, update the policy filters (exclude a folder, raise the minimum SIT count, exclude an internal classification keyword) so the next scan does not reopen the same noise. Microsoft’s Cloud Apps investigation guidance: if the event is allowed and not likely to recur, you can dismiss/close the alert; if it will recur, tune the policy. When you close, send feedback (not interesting, too many similar alerts, severity should be lower, alert is not accurate). Microsoft calls that feedback a best practice because it improves detections.

Close the alert with a resolution type, then govern the file

The Cloud Apps Alerts page replaced separate Resolved and Dismissed statuses with Closed plus a resolution type. The Alerts API still documents the mapping you will see in automation and older screenshots:

Power Automate connectors follow the same model: Close as benign, Close as false positive, and Close as true positive replace deprecated Dismiss/Resolve actions. Closing as true positive without removing external sharing leaves the overshare in place. Closing as false positive without Authorize (when the file will match again) refills the queue.

Governance actions are how you contain a true positive. They run from the policy (automatic on match) or from the file (manual). Microsoft warns they can cause irreversible loss of access permissions. If a governance action fails because the file is locked, Defender for Cloud Apps automatically retries. Only the governance action of the first triggered policy is guaranteed. If policy 1 already applied a sensitivity label, policy 2 cannot apply a different label to the same file.

Actions are grouped as notifications, collaboration / sharing, security (quarantine, trash), and investigation. Availability varies by connected app. Memorize the documented examples, not a fake universal menu.

Exam scenarios map cleanly: Confidential label shared externally → Remove external users (Microsoft’s published best practice). Public Google Workspace file with GDPR identifiers → Remove external users and Remove public access. Malware or confirmed toxic file in SharePoint → admin quarantine or trash, not “email the owner and hope.” A file you need to inspect in Google Workspace before deciding → Grant read permissions to myself, then revoke.

Do not confuse this response path with Purview DLP’s Investigating status, shareable event links, or 30-day DLP dashboard retention (chapter 21). Do not confuse it with Insider Risk Management cases. Do not use eDiscovery search (next section) as the first response to an MDCA file-policy alert; search finds mailbox and site content for a case, it does not unshare a Box link.

Official resources

• File policies in Microsoft Defender for Cloud Apps — matches, History up to six months, Authorize, daily alert limit versus governance (updated 2026-07-03)
• Governing connected apps — per-app file governance actions (updated 2026-07-03)
• Commonly used information protection policies — alert-on-each-matching-file patterns
• What’s new in Defender for Cloud Apps — file policies retire January 6, 2027