SC-200Chapter 67 of 101Objective 3.2

Security Policy Initiatives

This chapter covers security policy initiatives in Microsoft 365 Defender, focusing on how to define, deploy, and manage policies that enforce security controls across identities, endpoints, and cloud apps. For the SC-200 exam, this topic is critical because approximately 15-20% of questions assess your ability to configure and interpret security policies—especially in Microsoft Defender for Cloud Apps (MDCA) and Microsoft 365 Defender. You will learn the policy types, their components, and how they interact to protect an organization's digital assets.

25 min read
Intermediate
Updated May 31, 2026

Security Policy as a Building Access System

Imagine a large corporate building with multiple floors, each housing different departments. The building has a main entrance with a security guard who checks every visitor against a list of approved personnel and their access rights. This list is the security policy. It specifies who can enter which floors, at what times, and under what conditions. For example, employees in Finance can access the 3rd floor (financial systems) Monday to Friday, 9 AM to 6 PM, but cannot enter the 5th floor (R&D lab) without a special badge. The guard also logs every entry attempt—successful or denied—and sends alerts if someone tries to access a restricted area. This is exactly how Microsoft Defender for Cloud Apps (MDCA) works: it sits as a reverse proxy (the guard) between users and cloud apps, enforcing access policies based on user identity, device state, location, and app sensitivity. It logs all activities (unified audit log) and can trigger automated responses like blocking access or requiring multi-factor authentication. Just as the building's access system can be updated dynamically (e.g., revoking access for a terminated employee), MDCA policies can be modified in real time to respond to threats.

How It Actually Works

Overview of Security Policy Initiatives

Security policy initiatives in Microsoft 365 Defender are the set of rules and conditions that define how an organization protects its assets. These policies are not static; they are part of a continuous improvement cycle that includes defining, deploying, monitoring, and refining. The SC-200 exam tests your ability to understand policy types (access, session, app discovery, anomaly detection), policy components (filters, actions, notifications), and how to configure them using Microsoft Defender for Cloud Apps (MDCA) and Microsoft 365 Defender.

Microsoft Defender for Cloud Apps (MDCA) Policies

MDCA offers several policy categories: - Access policies: Enforce controls when users access cloud apps (e.g., require MFA, block access). - Session policies: Monitor and control user activities within a session (e.g., block download of sensitive files). - App discovery policies: Identify shadow IT by analyzing traffic logs. - Anomaly detection policies: Detect unusual behavior like impossible travel or mass download. - File policies: Scan files in cloud apps for sensitive content (using DLP). - Cloud Discovery anomaly detection: Detect anomalies in discovered apps.

Policy Components

Every policy has three main components: 1. Scope: Which users, groups, apps, or IP ranges are affected. For example, an access policy might apply to all external users. 2. Conditions: The triggers that activate the policy. Conditions can include:

- User identity (e.g., group membership) - Device state (managed/unmanaged) - Location (IP range, country) - App sensitivity (e.g., Microsoft 365, Box) - Activity type (e.g., download, share) - Risk level (from Microsoft Entra ID Protection) 3. Actions: What happens when conditions are met. Actions include: - Block: Deny access outright. - Allow with monitoring: Permit but log all activities. - Allow with restriction: Permit but enforce controls like read-only or no download. - Require MFA: Force multi-factor authentication via Microsoft Entra ID. - Custom block message: Display a message to the user.

How Policies Are Enforced

MDCA operates as a reverse proxy (when using Conditional Access App Control) or via API integration. For access and session policies, MDCA integrates with Microsoft Entra ID Conditional Access. When a user tries to access a cloud app, the following flow occurs: 1. User authenticates to Microsoft Entra ID. 2. Conditional Access policies are evaluated; if they require session control, the user is redirected to MDCA. 3. MDCA evaluates its own policies (access or session). 4. If conditions are met, the configured action is enforced.

For file policies, MDCA uses APIs to scan files in cloud apps (e.g., SharePoint Online, OneDrive, Box). It checks for sensitive content using built-in DLP classifiers or custom expressions.

Anomaly Detection Policies

These policies use machine learning to detect unusual behavior. Examples: - Impossible travel: Two logins from distant locations within a short time (default threshold: 1 hour for impossible travel, but configurable). - Activity from anonymous IP addresses: Uses known proxy/VPN IP lists. - Mass download by a single user: Detects when a user downloads many files (default: 50 files in 10 minutes). - Ransomware activity: Detects high-rate file deletions/uploads.

Configuration Example: Access Policy

To create an access policy in MDCA: 1. In the Microsoft 365 Defender portal, go to Cloud Apps > Policies > Policy management. 2. Click Create policy > Access policy. 3. Provide a name and description. 4. Set Policy severity (Low, Medium, High). 5. Define Activities matching all of the following: - App: Select the target app (e.g., Microsoft 365). - Users: Select specific users/groups. - IP address: Optionally restrict to certain IP ranges. - Device: Optionally require device management. 6. Define Actions: - Block: Check to block access. - Allow with monitoring: Select to log. - Allow with restriction: Choose from dropdown (e.g., read-only). 7. Set Notifications: Optionally send email to users or admins. 8. Click Create.

Session Policies

Session policies are similar but operate at the session level. They can control what users can do within an app. For example: - Block download: Prevent downloading files in a browser session. - Protect download: Apply classification labels or encryption on download. - Block paste: Prevent pasting content into restricted fields.

App Discovery Policies

App discovery policies analyze traffic logs from network proxies or Microsoft Defender for Endpoint to identify shadow IT. You can create policies that: - Block discovered apps: Automatically block high-risk apps. - Tag apps: Categorize apps as sanctioned, unsanctioned, or monitored. - Generate alerts: When a new app is discovered.

Microsoft 365 Defender Policies

Beyond MDCA, Microsoft 365 Defender includes policies for: - Microsoft Defender for Endpoint (MDE): Attack surface reduction rules, antivirus policies, firewall policies. - Microsoft Defender for Office 365: Anti-phishing, anti-spam, safe attachments, safe links. - Microsoft Defender for Identity: Sensitive group monitoring, honeytoken accounts.

Integration with Microsoft Entra ID

MDCA policies rely on Conditional Access for enforcement. You must have Microsoft Entra ID P1 or P2 licenses. The Conditional Access policy must be configured to route traffic to MDCA. For example:

Create a Conditional Access policy that targets all cloud apps.

Assign to users.

Under Session, select Use Conditional Access App Control and choose Monitor only or Block downloads.

Default Policies

Microsoft provides several default policies in MDCA: - Impossible travel: Enabled by default. - Activity from anonymous IP addresses: Enabled. - Activity from unexpected locations: Disabled by default. - Mass download: Disabled.

Policy Evaluation Order

When multiple policies apply, the most restrictive action is enforced. For access policies, the order is: Block > Allow with restriction > Allow with monitoring > Allow. For session policies, multiple restrictions can be combined.

Monitoring and Reporting

Policies generate alerts in the Microsoft 365 Defender portal. You can view policy matches under Cloud Apps > Alerts. You can also use Microsoft 365 Defender advanced hunting to query policy actions.

Best Practices

Start with monitoring policies before blocking to avoid disruption.

Use groups to target policies to specific user populations (e.g., test group).

Regularly review policy matches and tune conditions.

Combine with Microsoft Entra ID Identity Protection risk policies for adaptive access.

Use app discovery to understand the app landscape first.

Exam Relevance

SC-200 expects you to:

Identify which policy type to use for a given scenario.

Configure access and session policies.

Interpret policy logs and alerts.

Understand the difference between API-based and proxy-based enforcement.

Know default thresholds (e.g., impossible travel time, mass download count).

Walk-Through

1

Identify Security Objectives

Begin by determining what you want to protect and from whom. For example, you may want to prevent external users from accessing sensitive data in SharePoint, or block downloads from unmanaged devices. This step involves consulting with stakeholders to define acceptable use, compliance requirements, and risk tolerance. The output is a list of policy goals (e.g., 'Block all downloads from unmanaged devices for the Finance group').

2

Configure Conditional Access in Entra ID

Navigate to Microsoft Entra ID > Security > Conditional Access. Create a new policy. Assign users/groups and cloud apps (e.g., Office 365). Under Conditions, you can set device state, location, and risk. Under Session, select 'Use Conditional Access App Control' and choose a mode: Monitor only, Block downloads, or Custom policy. This step is essential because MDCA policies are only evaluated if the traffic is routed through the proxy via this session control.

3

Create MDCA Access Policy

In Microsoft 365 Defender, go to Cloud Apps > Policies > Policy management > Create policy > Access policy. Define the policy name, severity, and conditions. For example, select 'App: Office 365', 'Users: Finance group', 'IP address: All'. Under Actions, choose 'Block' if you want to deny access, or 'Allow with restriction' to enforce read-only. Set notifications. This policy will apply when the Conditional Access session control redirects the user to MDCA.

4

Create MDCA Session Policy

Session policies control in-session activities. Create a new session policy. Under Activities matching all, select the app and users. Under Actions, choose 'Block' for specific activities like download or paste. You can also choose 'Protect' to apply sensitivity labels. For example, block download of files labeled 'Confidential' from unmanaged devices. Session policies are evaluated after access is granted, during the session.

5

Test and Monitor Policy

After creating policies, test them with a small group of users. Use the 'What If' tool in Conditional Access to preview policy effects. In MDCA, go to Policy management and view matches. Check alerts under Cloud Apps > Alerts. Use advanced hunting to query for policy actions: `CloudAppEvents | where ActionType == 'BlockAccess' | ...`. Monitor for false positives and adjust conditions accordingly. Tuning is critical to avoid user frustration.

What This Looks Like on the Job

Enterprise Scenario 1: Protecting Sensitive Data in Microsoft 365

A large financial services company uses Microsoft 365 for collaboration. They have strict compliance requirements (PCI-DSS) that mandate that credit card numbers must not be downloaded to unmanaged devices. They deploy MDCA with a session policy that blocks download of files containing credit card numbers (using a DLP policy) from any unmanaged device. They also create an access policy that blocks access to the Finance SharePoint site from IP addresses outside the corporate network. The policies are tested on a pilot group of 50 users before broad rollout. Performance is negligible because MDCA uses a reverse proxy with minimal latency. Common misconfiguration: forgetting to exclude service accounts from policies, causing automated processes to fail. They monitor alerts daily and tune the DLP rule to reduce false positives.

Enterprise Scenario 2: Shadow IT Discovery and Control

A mid-sized tech company wants to discover unauthorized cloud apps used by employees. They deploy the Cloud Discovery feature by integrating with their network proxy (Zscaler) and enabling Windows Defender for Endpoint to provide traffic logs. After two weeks, they discover 300 apps, 20 of which are high-risk (e.g., file sharing sites with weak encryption). They create an app discovery policy that automatically blocks high-risk apps via the proxy and alerts the security team. They also tag sanctioned apps like Box and Dropbox for business. The challenge is false positives: some apps are needed for business but appear risky. They create exceptions using the 'App tags' feature. The policy is updated weekly based on new app discoveries.

Enterprise Scenario 3: Anomaly Detection for Insider Threats

A healthcare organization uses MDCA anomaly detection policies to detect potential insider threats. They enable impossible travel detection (default 1-hour window) and mass download detection (50 files in 10 minutes). One day, an alert fires for a user who downloaded 200 files from a medical records app in 5 minutes. The policy automatically suspends the user's account via integration with Microsoft Entra ID. Investigation reveals the user was a terminated employee who still had access. The organization learns to regularly review and update policies to reduce false positives, especially for legitimate bulk operations like data migration.

How SC-200 Actually Tests This

What SC-200 Tests on Security Policy Initiatives

The exam objective 3.2 focuses on configuring and managing security policies in Microsoft 365 Defender, specifically within Microsoft Defender for Cloud Apps (MDCA) and Microsoft Defender for Endpoint (MDE). Key topics: - Policy types: Access, session, file, app discovery, anomaly detection. - Policy components: Scope, conditions, actions, notifications. - Integration with Conditional Access: How MDCA policies are invoked via session controls. - Default thresholds: Impossible travel time window (1 hour), mass download (50 files in 10 minutes). - Action precedence: Block > Allow with restriction > Allow with monitoring > Allow. - Enforcement methods: Proxy-based (for access/session) vs API-based (for file policies).

Common Wrong Answers and Why Candidates Choose Them

1.

Selecting 'File policy' instead of 'Session policy' for blocking downloads: Candidates confuse file policies (which scan static files) with session policies (which control user actions in real time). The exam presents a scenario where a user is currently uploading a file; a session policy can block that, while a file policy would only detect after upload.

2.

Choosing 'Block' action when 'Allow with restriction' is more appropriate: The scenario might require read-only access, not full block. Candidates see 'block' as the strongest action and choose it, but the requirement is to allow access with restrictions.

3.

Forgetting to create the Conditional Access policy: Many questions describe an MDCA policy that doesn't work. The missing piece is the Conditional Access session control that routes traffic to MDCA. Candidates often look for issues in the MDCA policy itself.

4.

Misunderstanding default anomaly detection thresholds: The question asks for the default mass download threshold. Candidates might guess 100 files or 5 minutes. The correct answer is 50 files in 10 minutes.

Specific Numbers and Terms to Memorize

Impossible travel default time window: 1 hour.

Mass download default: 50 files in 10 minutes.

Activity from anonymous IP: uses known proxy lists.

MDCA policy evaluation order: block > restriction > monitoring > allow.

Conditional Access session control options: Monitor only, Block downloads, Use custom policy.

API-based policies: file policies, app discovery.

Proxy-based policies: access, session.

License requirement: Microsoft Entra ID P1 or P2 for Conditional Access.

Edge Cases and Exceptions

Policy not applying to mobile apps: Some mobile apps don't support session controls; only browser-based access is controlled.

Multiple policies: When multiple access policies apply, the most restrictive action is taken. For session policies, restrictions are additive.

Service accounts: Always exclude service accounts from policies to avoid breaking automation.

Guest users: By default, guest users are subject to policies; you can exclude them.

How to Eliminate Wrong Answers

If the scenario mentions controlling user actions within a session (like blocking download), it's a session policy, not an access policy.

If the scenario mentions scanning files for sensitive content, it's a file policy.

If the scenario mentions detecting new apps, it's an app discovery policy.

If the scenario mentions unusual behavior patterns, it's an anomaly detection policy.

For enforcement method: if the scenario involves real-time control of user actions, it's proxy-based; if it's about scanning existing files, it's API-based.

Key Takeaways

MDCA access/session policies require Conditional Access session control to be enforced.

File policies are API-based and scan files after upload; they cannot block uploads in real time.

Default impossible travel threshold is 1 hour; mass download threshold is 50 files in 10 minutes.

Policy actions follow precedence: Block > Allow with restriction > Allow with monitoring > Allow.

Session policies can block specific activities like download, paste, and print within a session.

App discovery policies identify shadow IT by analyzing traffic logs from proxies or endpoints.

Always exclude service accounts from policies to prevent disruption of automated processes.

Easy to Mix Up

These come up on the exam all the time. Here's how to tell them apart.

Access Policy

Controls initial access to an app (allow/block/require MFA).

Evaluated before the user enters the app.

Actions include Block, Allow with monitoring, Allow with restriction (e.g., read-only).

Cannot control specific activities like download or paste within the app.

Example: Block access from unmanaged devices.

Session Policy

Controls activities within an already-allowed session.

Evaluated during the session, after access is granted.

Actions include Block download, Block paste, Protect download (apply label).

Can target specific file types or sensitivity labels.

Example: Block download of files labeled 'Confidential'.

Watch Out for These

Mistake

MDCA policies work independently without Conditional Access.

Correct

MDCA access and session policies are only enforced when traffic is routed through the MDCA proxy via a Conditional Access session control. Without the Conditional Access policy, MDCA policies are not triggered.

Mistake

File policies can block uploads of sensitive files in real time.

Correct

File policies are API-based and scan files after they are uploaded. They can alert or quarantine, but cannot block the upload in real time. To block uploads, use a session policy.

Mistake

The default Impossible Travel policy blocks access after detection.

Correct

By default, the Impossible Travel policy only generates alerts. It does not block access. You must configure an action (e.g., block) if desired.

Mistake

Session policies and access policies are the same thing.

Correct

Access policies control initial access (allow/block/require MFA). Session policies control activities within an already-allowed session (e.g., block download, block paste). They are different policy types.

Mistake

MDCA can control all cloud apps equally.

Correct

MDCA has varying levels of control. For apps that support Conditional Access App Control, it can proxy traffic. For others, it uses API integration with limited capabilities. Not all apps are fully controllable.

Do You Actually Know This?

Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.

Frequently Asked Questions

What is the difference between an access policy and a session policy in MDCA?

An access policy controls whether a user can enter an app at all. It can block, allow with monitoring, or allow with restrictions (like read-only). A session policy controls what the user can do inside the app after access is granted, such as blocking downloads or pasting. Access policies are evaluated first; session policies apply during the session. For example, you might use an access policy to block access from unmanaged devices, and a session policy to block download of sensitive files from managed devices.

Do I need Microsoft Entra ID P1 or P2 for MDCA policies?

Yes, to use MDCA access and session policies, you need Microsoft Entra ID P1 or P2 licenses because these policies are enforced via Conditional Access, which requires those licenses. Microsoft Defender for Cloud Apps itself also requires a license (e.g., Microsoft 365 E5 or standalone MDCA). Without Conditional Access, MDCA policies cannot be applied to user sessions.

Can MDCA block uploads of sensitive files in real time?

No, MDCA cannot block uploads in real time using file policies because they are API-based and scan files after they are stored. To block uploads, you need a session policy, which can block the upload action in the browser session. For example, you can create a session policy that blocks upload of files with a specific sensitivity label.

What are the default thresholds for anomaly detection policies?

The default thresholds are: Impossible travel time window is 1 hour (the time difference between two logins from distant locations). Mass download threshold is 50 files in 10 minutes. Activity from anonymous IP addresses uses known proxy/VPN lists. These thresholds can be customized in the policy settings.

How do I exclude service accounts from MDCA policies?

When creating an access or session policy, under the 'Users' condition, you can add service accounts (or a group containing them) to the exclusion list. Alternatively, in the Conditional Access policy, you can exclude service accounts. This prevents the policy from blocking automated processes like backup or synchronization.

Can MDCA control mobile apps?

MDCA session controls work only in browser-based sessions for most apps. Some mobile apps may not support the reverse proxy. For mobile apps, you can use Microsoft Intune app protection policies to control data access and actions. MDCA can still monitor activities via API for some mobile apps, but real-time control is limited.

What is the difference between proxy-based and API-based enforcement?

Proxy-based enforcement (used for access and session policies) routes user traffic through MDCA, allowing real-time control of access and actions. API-based enforcement (used for file policies and app discovery) uses the app's APIs to scan data and activities, which is asynchronous and does not provide real-time blocking of user actions. API-based is good for detecting and remediating after the fact.

Terms Worth Knowing

Ready to put this to the test?

You've just covered Security Policy Initiatives — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.

Done with this chapter?