Microsoft 365 Security Design

Why M365 Security Is an Architecture Problem

Most organisations treat M365 security as an admin task — enable MFA, turn on some alerts, move on. But SC-100 tests whether you can design a security architecture that governs how data flows, who collaborates with whom, and what happens when AI has the same permissions as your users.

Three forces collide in M365 security design:

1. Productivity pressure — users want frictionless collaboration, external sharing, and fast access to information
2. Data governance — sensitive data lives in SharePoint sites, Teams channels, OneDrive folders, and email — often with permissions inherited from years of organic growth
3. AI amplification — M365 Copilot uses the Microsoft Graph to access everything the user can access, turning a manageable permissions problem into an urgent data exposure risk

The security architect designs the balance between these forces.

---

M365 Security Posture and Secure Score

Microsoft Secure Score assigns a numeric score to your tenant’s security configuration. It measures how many recommended security controls you’ve implemented across Identity, Data, Device, Apps, and Infrastructure categories.

What Secure Score Measures for M365

• Exchange Online: Anti-phishing policies, DKIM signing, DMARC enforcement, mailbox auditing, transport rules
• SharePoint/OneDrive: Sharing defaults, anonymous link expiry, DLP policies
• Teams: Meeting policies, external access, guest permissions, app governance
• Identity (Entra): MFA enforcement, Conditional Access, PIM usage, risky sign-in policies

Architect’s Perspective on Secure Score

Secure Score is a starting point, not a finish line. A perfect score doesn’t mean perfect security — it means you’ve implemented Microsoft’s recommended controls. The architect must evaluate each recommendation against the organisation’s risk profile:

• Some recommendations increase user friction (e.g., disabling anonymous sharing links) — is the trade-off justified?
• Some recommendations have prerequisites (e.g., auto-labelling requires sensitivity labels to be defined first)
• Some recommendations conflict with business requirements (e.g., blocking all external sharing when the organisation depends on external collaboration)

🎯 Exam Tip: Secure Score Design Questions

SC-100 won’t ask you what Secure Score is. It will present a scenario where an organisation has a specific score and ask what architectural change would improve it most. Focus on which recommendations yield the highest point improvement relative to implementation effort. Know that Secure Score improvements are prioritised by impact category, not alphabetically.

---

Copilot Security and Governance

M365 Copilot is the most consequential security design challenge in modern M365 architecture. It doesn’t create new permissions — it exploits existing ones at machine speed.

The Oversharing Problem

When a user asks Copilot “What are our plans for the Q3 product launch?”, Copilot searches across every SharePoint site, OneDrive, email, Teams message, and meeting recording that user has access to. In most organisations, users have access to far more than they realise:

• SharePoint sites with “Everyone except external users” permissions
• Teams channels they were added to years ago and forgot about
• OneDrive files shared broadly during a project that was never cleaned up
• Email threads with distribution lists that include hundreds of people

Without Copilot, this oversharing was a theoretical risk — users rarely searched across all these sources simultaneously. With Copilot, it becomes a practical risk. Copilot surfaces the answer instantly, regardless of whether the user knew they had access.

Copilot Readiness Assessment

Before deploying Copilot, the security architect designs a readiness programme:

1. Permission audit — Use SharePoint Advanced Management to identify sites with overly broad access. Look for “Everyone except external users” and “All company” permissions on sensitive sites.
2. Sensitivity label coverage — Ensure sensitive content is labelled. Copilot respects sensitivity labels — if a document is labelled “Confidential,” Copilot includes that label context in its responses.
3. Site access governance — Implement site access reviews. Owners review who has access quarterly.
4. Restricted Content Discovery — For high-risk deployments, restrict Copilot’s content discovery to specific SharePoint sites during the initial rollout.
5. Purview DLP for M365 Copilot — Configure DLP policies to prevent Copilot from processing content with specific sensitivity labels.
6. Copilot admin controls — Configure which users have Copilot licences, manage plugin permissions, and set audit log retention for Copilot interactions.

Copilot Admin Controls

Copilot Security Controls

Control	What It Does	When to Use
Restricted Content Discovery	Limits which SharePoint sites Copilot can discover for all users (formerly Restricted SharePoint Search)	Initial rollout phase — limit exposure while permissions are cleaned up
Sensitivity label context in Copilot	Copilot displays the highest-priority sensitivity label from source documents in chat and citations	Always — provides classification visibility to users
Sensitivity label inheritance	Newly created content inherits the highest sensitivity label from source documents (supported in Word, PowerPoint, Outlook)	Always — ensures generated documents carry classification. Note: Teams meeting/chat labels are not currently recognised by Copilot
Copilot licence assignment	Controls which users can use Copilot	Phased rollout — start with groups that have clean data governance
Audit logging	Records every Copilot interaction in the unified audit log	Always — required for compliance and incident investigation
Data access governance (SAM)	SharePoint Advanced Management provides oversharing reports and automated access reviews	Pre-deployment and ongoing — identifies permission sprawl
Purview DLP for M365 Copilot	DLP policies exclude files and emails with specific sensitivity labels from Copilot processing	Sensitive content categories that must never surface in Copilot answers — more granular than Restricted Content Discovery
Restricted Content Discovery (site-level)	Excludes specific SharePoint sites from Copilot's content discovery	Individual sensitive repositories that should not appear in Copilot results

🌐 Scenario: Elena’s Copilot Readiness Programme

Elena has been asked by Marcus Chen to deploy Copilot to Meridian’s leadership team within 90 days. She runs a SharePoint Advanced Management oversharing report and discovers:

• 47 SharePoint sites have “Everyone except external users” as a member or visitor
• 12 of those sites contain HR data, M&A plans, or executive compensation information
• Teams channels from a 2022 reorganisation project still include 300 employees who no longer need access
• OneDrive sharing links from a board preparation project give 15 executives access to each other’s personal folders

Elena designs a phased approach:

Phase 1 (Weeks 1-4): Permission cleanup

• Remove “Everyone except external users” from all 47 sites
• Implement site access reviews for the 12 sensitive sites
• Expire stale Teams channel memberships
• Revoke OneDrive sharing links older than 90 days

Phase 2 (Weeks 5-8): Classification foundation

• Deploy sensitivity labels (Confidential, Highly Confidential, Internal, Public)
• Auto-label documents in the 12 sensitive sites based on content inspection
• Enable Restricted Content Discovery to limit Copilot to approved sites during initial rollout

Phase 3 (Weeks 9-12): Controlled deployment

• Deploy Copilot to 20 executives with the cleanest permission profiles
• Monitor audit logs for unexpected data access patterns
• Expand gradually as permission hygiene improves

Elena tells Marcus: “Copilot doesn’t create new risks — it reveals existing ones at speed. The 90-day timeline works, but only because we’re spending the first 60 days fixing the permissions we should have fixed years ago.”

---

Collaboration Security Design

External Sharing Architecture

SharePoint and OneDrive sharing is controlled at four levels, each more restrictive than the last:

1. Organisation level — Sets the maximum sharing capability for the entire tenant
2. Site level — Can be equal to or more restrictive than the organisation level
3. File/folder level — Individual sharing links within the site’s allowed range
4. Conditional Access — Session controls that restrict download, print, or sync for unmanaged devices

The architect designs the default settings, then identifies exceptions. The principle: start restrictive, grant exceptions with justification.

Guest Access Design

Guest access lets external users participate in Teams, SharePoint, and other M365 services using their own identity (personal email or their organisation’s Entra ID). The architect decides:

• Who can invite guests? (Everyone, specific roles, or admins only)
• What can guests access? (Specific Teams/channels, SharePoint sites, or broader access)
• How long does guest access last? (Access reviews to expire stale guest accounts)
• What conditions apply? (Conditional Access policies for guest users — require MFA, block unmanaged devices)

Information Barriers

Information barriers prevent specific groups from communicating with each other. They’re essential in financial services (Chinese Wall requirements), legal firms (conflict of interest), and regulated industries.

💰 Scenario: Ingrid’s Chinese Wall Design

Ingrid at Nordic Capital Partners must design information barriers for regulatory compliance. Nordic Capital has three divisions:

• Investment Banking — advises on M&A transactions
• Trading — executes trades based on market analysis
• Research — publishes analyst reports

Regulators require a Chinese Wall between Investment Banking and Trading. If a banker learns about an upcoming acquisition, a trader with that information could engage in insider trading.

Ingrid designs the barrier architecture:

Information Barrier policies:

• Investment Banking ↔ Trading: Blocked (cannot communicate via Teams, cannot access each other’s SharePoint sites, cannot find each other in People Search)
• Investment Banking ↔ Research: Blocked (research must remain independent)
• Trading ↔ Research: Allowed (research publishes public analysis that traders use)

Complications Ingrid addresses:

• Shared services (HR, IT, Legal) need to communicate with all three divisions — they’re placed in a neutral segment not blocked by any barrier
• Deal teams occasionally need cross-barrier communication — Ingrid designs a controlled exception process: Legal approves temporary barrier exemptions, logged and time-limited
• Teams channels that predate the barriers must be audited — users from blocked segments in the same channel would violate compliance

Harald Eriksen in compliance validates that the barrier design meets FMA (Financial Markets Authority) requirements. Ingrid adds quarterly access reviews and annual barrier policy audits to the governance plan.

---

Teams Meeting Security

Teams meetings present unique security challenges because they combine real-time communication, screen sharing, and recording:

• Meeting policies control who can present, whether attendees can unmute, and whether recording is automatic
• Sensitivity labels for meetings (with Teams Premium) control encryption, watermarking, who can bypass the lobby, and whether recording is allowed
• End-to-end encryption for one-to-one calls prevents Microsoft from accessing the call content — but disables features like recording, live captions, and transcription
• Meeting recording storage determines where recordings land (OneDrive/SharePoint) and inherits the site’s sharing and retention policies

🎯 Exam Tip: Teams Security Architecture

SC-100 questions about Teams security focus on architectural decisions, not configuration steps. You might see: “An organisation needs to prevent meeting recordings from being shared externally. What should the architect recommend?” The answer involves designing the right combination of meeting policies, sensitivity labels, SharePoint sharing restrictions on the recording storage location, and DLP policies — not a single toggle.

---

M365 Threat Protection Architecture

M365 security isn’t just governance — it includes active threat protection:

• Microsoft Defender for Office 365 — Safe Attachments (sandbox detonation), Safe Links (URL rewriting and time-of-click verification), anti-phishing (impersonation protection, mailbox intelligence)
• Microsoft Defender for Cloud Apps — CASB functionality for M365 and third-party SaaS — session controls, anomaly detection, OAuth app governance
• Microsoft Purview Insider Risk Management — Detects risky user behaviour (mass downloads, unusual sharing patterns, data exfiltration attempts)

The architect designs how these services work together. Defender for Office 365 catches inbound threats. Defender for Cloud Apps monitors user activity. Insider Risk Management correlates signals across M365 to identify internal threats. Together they form a defence-in-depth layer for M365 data.

Knowledge Check

Meridian Global is deploying M365 Copilot. Elena discovers that 47 SharePoint sites use 'Everyone except external users' permissions. Several contain HR and M&A data. What should Elena's FIRST architectural priority be before enabling Copilot?

AA. Enable Restricted Content Discovery to limit Copilot's scopeBB. Remediate overly broad SharePoint site permissionsCC. Deploy sensitivity labels on all documents across the tenantDD. Configure Copilot audit logging in the compliance portal

Check Answer

Knowledge Check

Nordic Capital Partners requires information barriers between Investment Banking and Trading divisions per regulatory requirements. The IT department is in a shared services role and must communicate with both divisions. How should the architect design this?

AA. Create an information barrier policy blocking Investment Banking and Trading, then add IT as an exception to the blocking policyBB. Place IT in a neutral segment that is not included in any blocking information barrier policyCC. Create separate Teams tenants for each division to ensure complete separationDD. Use sensitivity labels to prevent document sharing between the two divisions instead of information barriers

Check Answer

Knowledge Check

An organisation wants to prevent sensitive meeting recordings from being shared externally. What combination of controls should the security architect recommend?

AA. Enable end-to-end encryption for all Teams meetingsBB. Apply sensitivity labels to meetings and configure DLP policies on the SharePoint site where recordings are storedCC. Disable meeting recording globally and require users to take notes insteadDD. Configure Teams meeting policies to restrict recording to organisers only

Check Answer

---

Knowledge Check

Question

Why is M365 Copilot considered a data governance challenge rather than a security tool challenge?

Click or press Enter to reveal answer

Answer

Copilot inherits the user's existing permissions via the Microsoft Graph. It doesn't create new access — it surfaces data the user already has access to, but at machine speed. The security challenge is that most organisations have years of permission sprawl (oversharing) that was low-risk when humans searched manually but becomes high-risk when AI can instantly find and synthesise data across all M365 sources.

Click to flip back

Question

What is Restricted Content Discovery and when should an architect use it?

Click or press Enter to reveal answer

Answer

Restricted Content Discovery (formerly Restricted SharePoint Search) limits which SharePoint sites M365 Copilot can discover for all users. The architect should use it as an interim control during Copilot rollout — it reduces the blast radius while permission cleanup is underway. It's not a permanent solution because it applies tenant-wide rather than addressing specific oversharing problems. For more granular control, use Purview DLP for M365 Copilot to exclude content by sensitivity label.

Click to flip back

Question

How do information barriers differ from sensitivity labels in M365?

Click or press Enter to reveal answer

Answer

Information barriers prevent communication between defined user segments (blocking Teams chat, calls, SharePoint access, People Search). They enforce separation of duties (Chinese Walls). Sensitivity labels classify and protect documents and meetings based on data sensitivity. Barriers control who talks to whom; labels control what happens to content. They solve different problems and are often used together.

Click to flip back

Question

What does Microsoft Secure Score measure and what is its limitation?

Click or press Enter to reveal answer

Answer

Secure Score measures how many of Microsoft's recommended security controls have been implemented across Identity, Data, Device, Apps, and Infrastructure. Its limitation: a high score means you've followed Microsoft's recommendations, not that your organisation is secure. Recommendations may conflict with business requirements, and the score doesn't account for organisation-specific risks, custom applications, or compensating controls.

Click to flip back

---

🎬 Video coming soon

---

Summary

M365 security design is fundamentally about governing data access and collaboration. Copilot amplifies existing permissions, making data governance a prerequisite rather than an afterthought. The security architect designs the permission model, sharing policies, information barriers, and Copilot controls that balance productivity with data protection. Secure Score provides a baseline, but architectural decisions about what to enable, restrict, or block require understanding the organisation’s risk tolerance and regulatory requirements.

Next module: We shift from M365 workloads to application security architecture — how to design identity, access, and protection for custom applications, APIs, and containers.