Microsoft 365 contains most enterprises' most sensitive data, and Microsoft's native DLP (Purview) is good but limited. Symantec CloudSOC extends Symantec DLP into M365 with deeper detection engines, broader coverage, and inline + API enforcement. The integration runs in two modes: inline (real-time block / allow during user activity) and API (scan data already at rest). Most enterprises deploy both for complete coverage.
Every enterprise's data center is now Microsoft 365. Email, files, calendars, Teams chats, OneDrive personal storage, SharePoint sites. If your DLP only sees what crosses the corporate firewall, you have no DLP for the place where most sensitive data actually lives. The standard solution: a CASB layer that extends DLP policy into SaaS. For Symantec-aligned organizations, that means Symantec CloudSOC.
This article covers how CloudSOC + Symantec DLP + M365 integrates, what's possible, what's limited, and how to deploy it. For the product overview, see our CloudSOC page; for broader DLP context, see the DLP deployment checklist.
What "M365 DLP" means in practice
Three categories of M365 data flows need DLP coverage:
- Data in motion (inline): A user is uploading a file to OneDrive, pasting text into a Teams chat, sending an email through Exchange Online. You want to evaluate the action in real time and block / allow / modify.
- Data at rest (API): A file already sits in SharePoint, a message already exists in a mailbox, a document already lives in a OneDrive folder. You want to scan it for sensitive content and remediate.
- Data on shared access (collaboration): A SharePoint site was shared externally, a OneDrive file was given a public link, a Teams channel includes guest users. You want to detect risky sharing and revoke or alert.
CloudSOC covers all three modes. Microsoft Purview covers the first two reasonably and the third partially. The decision tree usually comes down to: do you need detection depth (EDM, IDM, custom dictionaries that map to Symantec DLP policies)? If yes, CloudSOC. If you're entirely Microsoft-aligned and OK with Purview's detection model, Purview can suffice.
How CloudSOC connects to M365
Two integration modes, deployed together:
API connector mode uses M365's Graph API (and SharePoint REST API where needed) to scan data at rest. You authorize CloudSOC as an enterprise app in Entra ID, grant it the necessary application permissions (Mail.ReadWrite, Files.Read.All, Sites.Read.All, etc.), and CloudSOC starts scanning. It indexes existing content, monitors for new content via API events, and runs Symantec DLP detection rules against everything it finds.
Inline / proxy mode requires Cloud SWG. User traffic to M365 (browser-based traffic to outlook.office.com, onedrive.com, sharepoint.com) is proxied through Cloud SWG, where CloudSOC inspects the action and applies policy in real time. Web requests get evaluated by Symantec DLP rules before they reach M365.
Most enterprises deploy both. API mode for retroactive scanning and ongoing data-at-rest coverage; inline mode for real-time prevention.
Detection engines that come along
The architectural value of CloudSOC is that Symantec DLP detection engines run in M365 context. That means:
- DCM regex matches credit cards, SSNs, etc. in M365 files and emails.
- EDM matches your actual customer / employee / account database against M365 content. See our EDM/IDM deep-dive for how this works.
- IDM detects when your IP / patent / board document corpus appears in M365 shares.
- VML classifiers run against M365 file content for high-volume categories.
Microsoft Purview has detection rules but no equivalent to EDM or IDM fingerprinting. This is where CloudSOC wins for organizations with high-value structured or document IP.
What inline enforcement looks like for users
The user experience depends on what action they're taking. Examples:
- Upload to OneDrive containing PCI data: Cloud SWG inspects the upload, CloudSOC evaluates Symantec DLP policy, action is blocked at network layer before reaching OneDrive. User sees a block page explaining the policy.
- Paste customer SSNs into a Teams channel: Inline policy detects the SSN match, blocks the message before send. User sees a notification.
- Send email with attached patent draft: CloudSOC inline + DLP detects IDM match against patent corpus, blocks the send or routes to manager approval.
- Share SharePoint site externally: Depending on configuration, action is blocked, alerted, or escalated to data owner.
Each of these requires real-time inline evaluation - which is why the Cloud SWG dependency matters.
What API-mode coverage looks like
API mode is retroactive but powerful:
- Initial scan: CloudSOC connects to your M365 tenant and scans existing content. For a 5,000-user enterprise this typically finds 1,000-10,000 incidents in the first week - historical sensitive data that has been sitting in SharePoint, OneDrive, and mailboxes.
- Ongoing monitoring: New content gets scanned within minutes of being created. Modified content gets re-scanned.
- Remediation actions: Quarantine sensitive files, revoke external sharing, notify owners, alert security, redact specific content, encrypt with sensitivity labels.
- Compliance reporting: Where in M365 is regulated data sitting? Who has access? When was it last touched?
The retroactive scan is often the most valuable initial output. Customers regularly discover SSN lists in old shared SharePoint sites, customer rosters in personal OneDrives, executive comp data accidentally shared externally.
Deployment phases
Typical CyberKIS M365 + CloudSOC deployment:
- Weeks 1-2: Discovery. Map M365 architecture (tenant configuration, conditional access, existing Purview DLP if any, sensitivity labels, external sharing posture). Document gaps.
- Weeks 2-4: API connector deployment. Register CloudSOC as enterprise app in Entra ID, grant permissions, configure first connector (typically OneDrive + SharePoint), validate initial scan.
- Weeks 4-6: Symantec DLP policy unification. Map existing on-prem DLP rules to apply to M365. Author new M365-specific policies for cloud-only data flows.
- Weeks 6-8: Inline integration with Cloud SWG. Configure browser traffic forwarding to inline-inspect M365 actions. Test real-time enforcement on small user population.
- Weeks 8-10: Phased rollout. Expand inline enforcement to all users. Tune policies based on initial incident volume.
- Weeks 10-12: Migration of remaining SaaS apps to CloudSOC API. Common apps: Salesforce, Box, ServiceNow, Workday, Slack.
Common pitfalls we have walked into
Permission scope drift. CloudSOC needs specific Graph API permissions. If your Entra ID admin restricts these too aggressively, scanning misses content. Document the permission set explicitly during deployment.
Coexistence with Microsoft Purview. If you already have Purview DLP running, decide whether to keep it (layered defense) or retire it (single source of truth). Running both creates duplicate incidents.
Conditional access interaction. Conditional access policies in Entra can interfere with CloudSOC scanning if the service principal isn't excluded. Validate during deployment.
External sharing scope. M365 allows complex external sharing (anyone with link, specific people, organization-only). CloudSOC sees all of this and may surface surprising volume. Tune severity to focus on truly external sharing of sensitive content.
Mobile app coverage. Inline enforcement covers browser traffic. M365 native mobile apps (Outlook iOS, OneDrive Android) bypass Cloud SWG. API mode still catches the data at rest, but real-time inline enforcement is limited on mobile. Accept the gap or layer with Intune Mobile App Management.
What about Defender for Cloud Apps?
Microsoft's CASB (Defender for Cloud Apps) overlaps significantly with CloudSOC for M365. Tradeoffs:
- Defender wins for Microsoft-only environments - tighter integration with Purview, sensitivity labels, Conditional Access. Simpler licensing.
- CloudSOC wins for heterogeneous environments - broader third-party SaaS coverage, deeper integration with Symantec DLP, more mature inline + API parity. Better for enterprises with extensive on-prem DLP investment.
For Symantec-aligned shops, CloudSOC is almost always the right answer. The policy consistency across endpoint, network, email, and cloud DLP is worth the integration work.
What this looks like with CyberKIS
CyberKIS deploys M365 + CloudSOC as a standard CASB engagement. We bring the API connector deployment templates, the inline policy framework, the M365-specific incident workflow, and engineers who have integrated this stack across enterprise environments. Want to scope it? Talk to a CyberKIS engineer or read the CloudSOC services page. Related: DLP deployment checklist, EDM/IDM fingerprinting.