Microsoft 365 SOC 2 Compliance Playbook

Practical Guide with Policies, Configurations & Evidence Collection

Version: 1.0
Author: Mehul Kava | Sorath Technologies
Last Updated: September 2025

Purpose

This document establishes the baseline Microsoft 365 security and compliance configuration aligned with SOC 2 Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy).
It serves as a template and guideline for organizations to implement strong security controls, meet audit requirements, and protect business-critical data.

Scope

Applies to:

Microsoft 365 tenants (Exchange Online, SharePoint, OneDrive, Teams, Azure AD/Entra ID).
All users, devices, and administrators accessing organizational resources.
Supporting compliance with SOC 2, NIST, and ISO 27001 best practices.

Introduction

This playbook provides a practical guide to configuring Microsoft 365 for SOC 2 compliance, with references to ISO 27001 and CIS Critical Security Controls (v8).

It is designed for:

Organizations preparing for SOC 2 Type I / II audits
Consultants implementing secure Microsoft 365 environments
IT leaders who need evidence packages for auditors

Each section includes:

Policy Statement — aligned with SOC 2 Trust Services Criteria (TSC), ISO 27001 Annex A, and CIS Controls.
Microsoft 365 Configuration — step-by-step guidance (Entra/Azure portal and PowerShell).
Expected Evidence — artifacts auditors typically require (screenshots, reports, exports).

1. Identity

1.1 Enforce MFA

Policy Statement

All user accounts must be protected by multi-factor authentication (MFA) to reduce the risk of unauthorized access, in accordance with SOC 2 CC6.1, ISO 27001 A.5.15, and CIS Control 6.

MS365 Configuration

Azure/Entra UI
- Go to Microsoft Entra Admin Center → Protection → Conditional Access.
- Create a policy: Require MFA for All Users (exclude break-glass accounts).
- Assign: All users (exclude service accounts).
- Cloud apps: All.
- Grant → Require multi-factor authentication.
PowerShell (MSOnline module):

				
					Get-MsolUser -All | Where-Object {$_.StrongAuthenticationRequirements -eq $null}

(Lists users without MFA enabled).

Expected Evidence

Screenshot of Conditional Access policy enforcing MFA.
PowerShell report showing 100% users with MFA enforced.
Policy document referencing SOC 2 / ISO / CIS alignment.

1.2 Restrict Geo-based Access

Policy Statement
Access to Microsoft 365 resources must be restricted to approved geographic regions to mitigate risks of unauthorized or suspicious sign-ins.

MS365 Configuration

Azure/Entra UI
- Go to Conditional Access → Named Locations.
- Define “Approved Countries” (e.g., India, US).
- Create a policy: Block access from non-approved countries.
PowerShell:
Azure AD PowerShell doesn’t directly enforce geo-blocking, but you can export risky sign-in reports:

				
					Get-AzureADAuditSignInLogs | Select-Object UserPrincipalName,IPAddress,Location

Expected Evidence

Screenshot of Conditional Access policy with country-based restriction.
Audit logs showing blocked sign-in attempts from outside allowed regions.

1.3 Disable Legacy Authentication

Policy Statement
Legacy authentication protocols (POP3, IMAP, SMTP basic auth) must be disabled to prevent bypass of modern security controls like MFA.

MS365 Configuration

Azure/Entra UI
- Go to Azure AD → Conditional Access → Policies.
- Block legacy authentication protocols.
Exchange Online PowerShell:

				
					Get-AuthenticationPolicy
New-AuthenticationPolicy -Name "Block Legacy Auth"
Set-AuthenticationPolicy -Identity "Block Legacy Auth" -AllowBasicAuthPop:$false -AllowBasicAuthImap:$false -AllowBasicAuthSmtp:$false
Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Legacy Auth"

Expected Evidence

Screenshot of Authentication Policy in Exchange Admin Center.
PowerShell output showing AllowBasicAuth* = False.
Sign-in logs proving legacy protocols are blocked.

2. Endpoint Protection

2.1 SOC 2 Compliant Endpoint Controls

Policy Statement
All endpoints accessing Microsoft 365 must be enrolled in device compliance policies and monitored for security posture. Non-compliant devices must be blocked.

MS365 Configuration

Entra/Intune UI
1. Go to Intune → Devices → Compliance Policies.
2. Create baseline compliance:
  - Require BitLocker encryption.
  - Require password complexity.
  - Require device to be free from malware.
  - Require up-to-date OS patches.
3. Assign compliance policy to All Users.
4. Create a Conditional Access Policy: Require compliant device.
PowerShell (Intune Graph API):

				
					Connect-MSGraph
Get-DeviceManagement_DeviceCompliancePolicy
Get-DeviceManagement_ManagedDevice | Select displayName, complianceState

Expected Evidence

Screenshot of Intune compliance policy.
Report showing compliance status of devices.
Conditional Access policy screenshot enforcing “Require compliant device.”

2.2 Device Compliance

Policy Statement
All corporate endpoints must be enrolled in Intune and comply with defined security baselines. Non-compliant devices are automatically blocked from accessing Microsoft 365 resources.
Microsoft 365 Configuration
1. In Intune → Devices → Enrollment restrictions, enforce enrollment of Windows/macOS/iOS/Android devices.
2. Define Compliance Policies: require PIN/biometric, encryption, OS version, no jailbreaking/rooting.
3. Configure Conditional Access (CA): block access to Microsoft 365 for non-compliant devices.
PowerShell Example:

				
					Get-MgDeviceManagementCompliancePolicy
Get-MgConditionalAccessPolicy

Expected Evidence

Screenshot of compliance policies in Intune.
CA policy export showing “Require compliant device”.
Compliance reports listing compliant vs non-compliant devices.

2.3 Encryption & Hardening

Policy Statement
All corporate endpoints must use full-disk encryption (BitLocker for Windows, FileVault for macOS). Mobile devices must use device encryption with strong PIN or biometric authentication.

Microsoft 365 Configuration

1. In Intune → Endpoint security → Disk encryption, deploy BitLocker/FileVault profiles.
2. Enforce encryption as part of compliance policies.
3. Require secure startup and TPM for Windows devices.
4. Enforce iOS/Android encryption via Intune device compliance.

PowerShell Example:

				
					Get-BitLockerVolume
Get-MgDeviceManagementCompliancePolicy | Select-Object DisplayName, Rules

Expected Evidence

Intune Disk Encryption profile details.
Device compliance reports showing encryption status.
Sample BitLocker/FileVault recovery keys stored in Azure AD.

2.4 Antivirus & EDR

Policy Statement
All endpoints must run Microsoft Defender for Endpoint (MDE) with real-time protection and automated remediation enabled. Devices must be continuously monitored for malware, ransomware, and exploits.
Microsoft 365 Configuration
1. Onboard devices to Defender for Endpoint via Intune security baselines.
2. In Microsoft 365 Security & Compliance Center → Threat policies, configure automated investigation & response (AIR).
3. Enable attack surface reduction rules and exploit protection.
4. Integrate Defender alerts with Microsoft Sentinel for SOC visibility.
PowerShell Example:

				
					Get-MpComputerStatus
Get-MgDeviceManagementManagedDevice | Select DeviceName, DeviceHealthStatus

Expected Evidence

Defender Security Center dashboard showing onboarded devices.
Malware detection/response reports.
SIEM (Sentinel) export of alert logs.

2.5 Patch Management

Policy Statement
All endpoints must have automatic updates enabled. Critical patches must be applied within 7 days of release and verified via compliance reporting.
Microsoft 365 Configuration
1. Use Intune Update Rings for Windows 10/11 to enforce automatic updates.
2. For macOS/iOS/Android, configure update policies in Intune.
3. Define servicing channels (Semi-Annual Enterprise for stability, or Current Channel for faster patching).
4. Enable reporting of patch compliance.
PowerShell Example:

				
					Get-MgDeviceManagementSoftwareUpdateStatusSummary
Get-WindowsUpdateLog

Expected Evidence

Intune Update Ring configuration.
Patch compliance report from Intune/Defender.
Logs showing installation date vs patch release date.

3. Data Security & Protection

Overall, Policy Statement:

All organizational data must be classified, protected, encrypted, retained, and securely destroyed in accordance with SOC 2 and NIST SP 800-53 / 800-88 standards. Microsoft 365 Purview and other integrated security tools must be utilized to safeguard data throughout its lifecycle.

3.1 Sensitivity Labels (Microsoft Purview Information Protection)

Policy Statement:

All organizational information must be labeled with appropriate sensitivity levels (e.g., Public, Internal, Confidential, Restricted) to ensure protection according to data classification and handling requirements.

Microsoft 365 Configuration:

Enable Microsoft Purview Information Protection.
Create and publish Sensitivity Labels and Label Policies.
Configure Encryption, Watermarking, and Header/Footer markings for confidential data.
Enable Mandatory labeling in Office apps and Outlook.
Configure Auto-labeling for specific content or sensitive info types.

PowerShell Verification:

				
					Get-Label
Get-LabelPolicy
Get-LabelPolicy | fl Name,Enabled,Settings

Expected Evidence:

Screenshot of Sensitivity Labels and Policies in Purview.
Export of label configuration.
Screenshot of a labeled document or email.
Audit logs showing label application (Search-UnifiedAuditLog -Operations ApplyLabel).

3.2 Data Classification Framework

Policy Statement:

Data must be classified and inventoried using Microsoft Purview Data Classification Framework to ensure proper identification, handling, and monitoring of sensitive information.

Microsoft 365 Configuration:

Configure Microsoft Purview Data Classification portal.
Review and map Sensitive Information Types (SITs) to organizational data categories.
Create Custom SITs or Trainable Classifiers for organization-specific data.
Review classification reports regularly for compliance assurance.

PowerShell Verification:

				
					Get-DlpSensitiveInformationType
Get-DlpSensitiveInformationType | where {$_.Publisher -eq "Microsoft Corporation"}

Expected Evidence:

Screenshot of Data Classification dashboard.
Export list of Sensitive Information Types and Classifiers.
Data classification matrix mapping business data to sensitivity levels.

3.3 Data Loss Prevention (DLP) Policies

Policy Statement:

Controls must be implemented to prevent unauthorized sharing or transmission of sensitive or classified data across email, Teams, SharePoint, and OneDrive environments.

Microsoft 365 Configuration:

Configure DLP Policies in Microsoft Purview for Exchange Online, SharePoint, OneDrive, and Teams.
Set rules to detect and restrict sharing of sensitive data.
Enable User Notifications and Policy Tips.
Enable Incident Reporting for policy violations.

PowerShell Verification:

				
					Get-DlpCompliancePolicy
Get-DlpComplianceRule
Get-DlpCompliancePolicy | fl Name,Mode,ExchangeLocation,SharePointLocation,TeamsLocation

Expected Evidence:

Screenshot of active DLP policies.
Sample alert or incident report.
PowerShell export of DLP policy configuration.
Audit log of a DLP event (DlpRuleMatch).

3.4 Retention Policies & Litigation Hold

Policy Statement:

Information assets must be retained and disposed of in accordance with legal, regulatory, and business requirements. Data under investigation or litigation must be preserved using hold mechanisms.

Microsoft 365 Configuration:

Configure Retention Policies in Microsoft Purview for Exchange, SharePoint, and OneDrive.
Define Retention Labels with retention and deletion durations.
Apply Litigation Hold or eDiscovery Hold to relevant mailboxes.
Enable audit and review of retention activities.

PowerShell Verification:

				
					Get-RetentionCompliancePolicy
Get-RetentionComplianceRule
Get-Mailbox -ResultSize Unlimited | where {$_.LitigationHoldEnabled -eq $true} | ft DisplayName, LitigationHoldDuration

Expected Evidence:

Screenshot of Retention Policy and Label configuration.
PowerShell export of policy settings.
Screenshot of mailbox under litigation hold.
Audit record of retention/deletion prevention.

3.5 Secure Data Destruction (NIST SP 800-88)

Policy Statement:

All data must be securely destroyed at the end of its lifecycle following NIST SP 800-88 standards to prevent recovery or unauthorized access after disposal.

Microsoft 365 Configuration:

Implement Retention and Deletion policies to automate secure data lifecycle management.
Use Inactive Mailboxes for leavers until deletion date.
For physical or exported data, ensure destruction per NIST SP 800-88 (shredding, degaussing, etc.).
Document all destruction activities.

PowerShell Verification:

				
					Search-Mailbox -Identity "User" -DeleteContent
Remove-Mailbox -PermanentlyDelete
Get-Mailbox -InactiveMailboxOnly

Expected Evidence:

Deletion or purge report.
Screenshot of inactive mailbox.
Written SOP outlining NIST 800-88 compliance process.
Logs confirming data deletion events.

3.6 Rights Management (Encryption at Rest & In Transit)

Policy Statement:

All sensitive information must be encrypted both at rest and in transit using Microsoft 365 encryption mechanisms, ensuring confidentiality and data integrity across all services.

Microsoft 365 Configuration:

Enable Azure Information Protection (AIP) and IRM.
Verify Exchange Online Protection (EOP) and TLS encryption for email in transit.
Confirm BitLocker encryption for OneDrive and SharePoint (data at rest).
Enable Microsoft 365 Message Encryption (OME) for external communication.

PowerShell Verification:

				
					Get-IRMConfiguration
Get-IRMConfiguration | fl InternalLicensingEnabled,ExternalLicensingEnabled
Get-TransportRule | where {$_.ApplyOME -eq $true}

Expected Evidence:

Screenshot of IRM/AIP configuration.
Example of an encrypted message (OME).
Export of transport rule for encryption.
Microsoft compliance documentation showing encryption at rest.

4. Email Security

4.1 Anti-Malware Protection

Policy Statement
All inbound and outbound email must be scanned for malware.

MS365 Configuration

Exchange Admin Center → Protection → Anti-malware policy.
Configure:
- Enable zero-hour auto purge.
- Enable notification to admins.
PowerShell:

				
					Get-MalwareFilterPolicy

Expected Evidence

Screenshot of malware policy.
PowerShell output showing policy enabled.
Logs of quarantined malware emails.

4.2 Anti-Phishing

Policy Statement
All inbound mail must be evaluated against impersonation and phishing attacks.

MS365 Configuration

Defender for Office 365 → Anti-phishing policies.
Enable: impersonation protection, mailbox intelligence, spoof intelligence.
PowerShell:

				
					Get-AntiPhishPolicy

Expected Evidence

Screenshot of anti-phishing policy.
Report of blocked phishing attempts.

4.3 Safe Links & 4.4 Safe Attachments

Policy Statement
All links and attachments must be scanned in real-time before delivery.

MS365 Configuration

Safe Links: Enable URL rewriting.
Safe Attachments: Enable dynamic delivery (delivers message while attachment scans).
PowerShell:

				
					Get-SafeLinksPolicy
Get-SafeAttachmentPolicy

Expected Evidence

Policy screenshots.
Logs showing blocked malicious links/attachments.

4.5 Disable Auto-forwarding

Policy Statement
Automatic external email forwarding must be disabled to prevent data exfiltration.

MS365 Configuration

Exchange Online → Remote Domain settings → Disable auto-forwarding.
PowerShell:

				
					Set-RemoteDomain Default -AutoForwardEnabled $false

Expected Evidence

Screenshot of setting in EAC.
PowerShell output confirming AutoForwardEnabled: False.

4.6 Email Encryption

Policy Statement
All sensitive emails must be encrypted using Microsoft Purview Message Encryption.

MS365 Configuration

Enable Office Message Encryption (OME).
Create mail flow rule: If sensitivity = Confidential, encrypt message.
PowerShell:

				
					Get-IRMConfiguration

Expected Evidence

Screenshot of mail flow rule.
Test email encrypted + decrypted successfully.

4.7 SPF, DKIM, DMARC Records

Policy Statement:
All domains used for sending email must implement SPF, DKIM, and DMARC to authenticate legitimate senders and prevent spoofing.

Microsoft 365 Configuration:

Configure SPF: Add TXT record in DNS, e.g.,

				
					v=spf1 include:spf.protection.outlook.com -all

Enable DKIM for each domain in Microsoft 365 Defender portal.
PowerShell:

				
					Get-DkimSigningConfig

Configure DMARC in DNS:

				
					v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-fail@yourdomain.com; pct=100

Expected Evidence:

DNS record screenshots for SPF, DKIM, and DMARC.
PowerShell output showing DKIM status as Enabled.
Email header showing SPF=pass, DKIM=pass, DMARC=pass.
DMARC report or summary dashboard showing alignment rates.

5. Monitoring, Logging & Alerting

Overall Policy Statement:
“All security-relevant activities must be logged, monitored, and reviewed to ensure timely detection, investigation, and response to potential threats and anomalies within the Microsoft 365 environment.”

5.1 Unified Audit Log (Microsoft 365 Compliance Center)

Policy Statement:
“All user and admin activities across Microsoft 365 services must be captured and retained in the Unified Audit Log for accountability, forensic analysis, and compliance reporting.”

Microsoft 365 Configuration:

Enable Unified Audit Log in Microsoft Purview → Audit → Audit Search.
Ensure Audit (Standard or Premium) is turned on for the organization.
Configure Audit Log Retention Policies (default 90 days for standard, up to 1 year+ for E5).
Grant compliance and security teams appropriate roles (e.g., Audit Logs, View-Only Audit Logs).
Enable Advanced Auditing for high-value events (e.g., mail forwarding, permission changes).

Expected Evidence:

Screenshot of “Audit (Standard/Premium)” enabled in Compliance Center.
Exported sample of audit log search results showing recent events.
Screenshot of Audit Retention Policy configuration.
Role assignment report for audit permissions.

5.2 Sign-in Risk & User Risk Policies (Microsoft Entra ID Protection)

Policy Statement:
“Risk-based sign-in and user risk policies must be configured to detect anomalous authentication activity and enforce automated responses such as MFA or account blocking.”

Microsoft 365 Configuration:

Navigate to Entra ID → Protection → Risk Policies.
Enable Sign-in Risk Policy → action: require MFA or block access.
Enable User Risk Policy → action: require password change or block sign-in.
Define thresholds (e.g., Medium and above).
Monitor Risky Users and Risky Sign-ins dashboards regularly.

Expected Evidence:

Screenshot of active Sign-in Risk and User Risk Policies.
Exported Risky Users or Sign-in Risk report.
Policy configuration screenshots showing conditions and actions.
Sign-in logs demonstrating enforcement.

5.3 Defender Security Alerts & Automated Response

Policy Statement:
“Microsoft 365 Defender must be configured to detect, alert, and automatically respond to security incidents to minimize the impact of threats.”

Microsoft 365 Configuration:

Enable Microsoft 365 Defender portal (https://security.microsoft.com).
Ensure Defender for Office 365, Defender for Endpoint, and Defender for Identity are integrated.
Configure Alert policies for suspicious or anomalous activities (e.g., malware detected, mass downloads).
Set Automated Investigation and Response (AIR) to “Auto-remediate threats” for supported scenarios.
Enable Email notifications to security admins for high severity alerts.

Expected Evidence:

Screenshot of Alert Policy list in Security Portal.
Example of a triggered alert with details.
Screenshot of Automated Investigation and Response settings.
Evidence of email notification or alert triage report.

5.4 SIEM Integration (Microsoft Sentinel / 3rd Party)

Policy Statement:
“All Microsoft 365 audit and security logs must be integrated with a central SIEM solution for unified monitoring, correlation, and threat detection.”

Microsoft 365 Configuration:

Connect Microsoft 365 Defender and Entra ID logs to Microsoft Sentinel via data connectors.
Configure Data Connectors (Office 365, Azure AD, Defender for Endpoint, Defender for Cloud Apps).
Set up Analytics Rules and Workbooks for monitoring incidents and trends.
Integrate with 3rd-party SIEM via API or log forwarding if applicable.

Expected Evidence:

Screenshot of Sentinel Data Connectors with status “Connected.”
Sample Analytics Rule or Workbook dashboard.
Example of a correlated alert or incident generated from M365 data.
Exported Log Analytics Workspace event sample.

5.5 Incident Response Workflow

Policy Statement:
“All identified security incidents must follow a documented incident response workflow—covering detection, containment, investigation, remediation, and post-incident review.”

Microsoft 365 Configuration:

Define workflow within Microsoft Defender → Incidents & Alerts.
Use Automated Playbooks (Logic Apps) in Sentinel or Defender for triage and escalation.
Assign incident owner, severity, and status tracking.
Document steps in the Incident Response Plan (IRP) aligned with NIST 800-61.
Configure email or Teams alerts for new incidents to security personnel.

Expected Evidence:

Screenshot of Incident Queue in Microsoft 365 Defender or Sentinel.
Example of incident lifecycle (detected → investigated → resolved).
Copy of Incident Response Policy/Playbook document.
Evidence of post-incident review report or ticket closure summary.

6. Change Management

Overall Policy Statement:
All configuration and system changes within the Microsoft 365 environment must follow a formal change management process to ensure security, traceability, and business continuity. Changes must be documented, reviewed, approved, and implemented by authorized personnel only. The organization uses role-based access controls, audit logging, and an integrated ticketing or approval workflow to manage and record configuration changes in alignment with SOC 2 and ISO 27001 standards.

6.1 Documenting Microsoft 365 Configuration Changes

Policy Statement:
All Microsoft 365 configuration changes (including security, compliance, and administrative settings) must be documented and tracked to maintain an accurate configuration baseline and provide traceability for audits or incident reviews.

Microsoft 365 Configuration:

Enable Unified Audit Log in Microsoft Purview Compliance Portal to record configuration and administrative activities.
Regularly export configuration baselines from Exchange Online, SharePoint, Teams, Intune, and Entra ID using PowerShell scripts or Microsoft Graph.
Maintain a Change Register (e.g., SharePoint list or secure Excel workbook) referencing ticket numbers, date, description, and responsible admin.
Use Change Notifications (via Microsoft 365 Message Center or Service Health) for awareness of system-level updates.

Expected Evidence:

Unified Audit Log entries showing configuration or administrative changes.
Change Register or documented change records (ticket ID, date, summary, owner).
Exported configuration baselines or change comparison reports.
Screenshots or audit trail showing change documentation procedures.

6.2 Role-Based Access Control (RBAC) for Admins

Policy Statement:
Administrative privileges must be restricted to authorized personnel based on the principle of least privilege. Each admin role must be assigned according to job responsibilities, reviewed periodically, and documented.

Microsoft 365 Configuration:

Manage roles in Entra ID → Roles and Administrators.
Assign granular roles (e.g., Exchange Administrator, Security Administrator, Intune Administrator) instead of Global Admin wherever possible.
Enable Privileged Identity Management (PIM) to enforce just-in-time (JIT) access and approval workflows for privileged roles.
Conduct quarterly reviews of admin role assignments.
Maintain approval records for any new or modified admin role assignments.

Expected Evidence:

Screenshot or export of Active Directory Role Assignments and PIM configuration.
Role assignment review reports or access review logs.
Documentation of approval for any RBAC changes (e.g., from ServiceNow/Jira).
Records of periodic RBAC reviews.

6.3 Change Approvals & Ticketing System Integration (ServiceNow/Jira)

Policy Statement:
All configuration or system changes must be initiated, reviewed, and approved through an authorized change ticketing system to ensure accountability and proper impact assessment before implementation.

Microsoft 365 Configuration:

Integrate change management system (e.g., ServiceNow, Jira, or SharePoint form) with M365 change documentation workflow.
Require ticket IDs and approval notes before implementing any configuration change.
Assign change categories (standard, normal, emergency) and require approval from designated change approvers for each.
Maintain linkage between Microsoft 365 change logs and the corresponding ticket record.

Expected Evidence:

Approved change request tickets showing description, approval status, and implemented changes.
Evidence of workflow approvals within ServiceNow/Jira.
Change management reports summarizing approved and implemented changes.
Audit log correlation between ticket ID and change activity timestamp.

6.4 Evidence: Change Logs, RBAC Role Assignments

Policy Statement:
Evidence of configuration changes, access modifications, and administrative activities must be collected, reviewed, and retained for a minimum of one year (or per company retention policy) to support audits, investigations, and compliance verification.

Microsoft 365 Configuration:

Enable Unified Audit Logging in Microsoft Purview to capture all administrative and configuration activities.
Configure Defender for Cloud Apps (MCAS) or Microsoft Sentinel for centralized log collection and correlation.
Schedule periodic export or backup of change logs.
Maintain records of RBAC role assignments and PIM activations in compliance dashboards.

Expected Evidence:

Unified Audit Log exports filtered for admin and configuration activities.
Microsoft Sentinel or MCAS activity reports.
RBAC/PIM activity reports and access review documentation.
Archived change logs stored securely in SharePoint, OneDrive, or Azure Storage.

7. Risk Management

Overall Policy Statement

The organization shall identify, assess, and mitigate security and compliance risks associated with Microsoft 365 environments, third-party integrations, and cloud operations. Continuous monitoring through Microsoft 365 Compliance Manager and Secure Score shall guide proactive risk reduction and alignment with regulatory and business objectives.

7.1 Risk Assessments in Microsoft 365 Compliance Manager

Policy Statement:
All Microsoft 365 security, privacy, and compliance risks must be periodically assessed using Microsoft 365 Compliance Manager. Assessments shall include evaluating controls, improvement actions, and residual risks to maintain compliance with SOC 2, ISO 27001, and organizational policies.

Microsoft 365 Configuration:

Access Compliance Manager → Assessments in the Microsoft 365 Compliance portal.
Assign applicable templates (e.g., SOC 2, GDPR, ISO 27001) to your tenant.
Define assessment frequency (quarterly or semi-annually).
Assign ownership for each control action and track completion status.
Configure email notifications for overdue improvement actions.

Expected Evidence:

Compliance Manager Assessment reports (export PDF/CSV).
Improvement actions dashboard screenshots.
Audit trail of completed and pending actions.
Record of responsible users and periodic review dates.

7.2 Secure Score Tracking (Baseline + Improvement Plan)

Policy Statement:
Microsoft Secure Score shall be actively monitored to measure security posture. A baseline score must be established, and an improvement plan maintained to ensure continuous enhancement of Microsoft 365 security configurations.

Microsoft 365 Configuration:

Navigate to Microsoft 365 Defender → Secure Score.
Record the baseline Secure Score and compare monthly progress.
Review top recommendations and assign improvement actions.
Integrate Secure Score metrics with Compliance Manager or internal dashboards.
Enable alerting or Power Automate workflows for critical score drops.

Expected Evidence:

Secure Score trend export (Excel/PDF).
Baseline and target score documentation.
Monthly or quarterly Secure Score review reports.
Evidence of closed improvement actions.

7.3 Vendor & Third-Party App Risk Evaluation

Policy Statement:
All third-party or vendor-provided apps connected to Microsoft 365 (via OAuth or API) must undergo security and compliance risk evaluation prior to approval and periodically thereafter.

Microsoft 365 Configuration:

Review connected apps under Entra ID → Enterprise Applications and App Registrations.
Disable “Users can consent to apps accessing company data” unless explicitly approved.
Maintain an internal Vendor Risk Register documenting app purpose, permissions, and owner.
Require vendor compliance documentation (e.g., SOC 2, ISO 27001) before integration.
Use Microsoft Defender for Cloud Apps (MCAS) to monitor app behavior and permissions.

Expected Evidence:

Export of Enterprise Applications list and risk classification.
Vendor Risk Assessment records or review forms.
Approval workflow logs or tickets for each integrated app.
Reports from Defender for Cloud Apps identifying risky apps.

7.4 Evidence: Compliance Manager Reports, Secure Score Exports

Policy Statement:
Evidence supporting ongoing risk management must be maintained, reviewed, and stored securely to demonstrate due diligence and audit readiness.

Microsoft 365 Configuration:

Export Compliance Manager assessment reports and Secure Score reports on a quarterly basis.
Store exported reports in SharePoint (Compliance Documentation Library) with restricted access.
Implement version control for all exported evidence files.
Tag all evidence with metadata: “Assessment Type,” “Period,” and “Reviewer.”

Expected Evidence:

Compliance Manager reports (PDF/CSV).
Secure Score export files and trend charts.
Evidence storage folder structure in SharePoint with access controls.
Audit trail of periodic review and approvals by security team.

8. Business Continuity & Resilience

Overall Policy Statement

The organization shall maintain a comprehensive Business Continuity and Resilience strategy to ensure uninterrupted access to critical Microsoft 365 services, data integrity, and recovery capabilities in the event of system failures, disasters, or security incidents. Backup, recovery, and resilience measures must align with the organization’s Business Continuity Plan (BCP) and Disaster Recovery (DR) framework to meet SOC 2 and ISO 22301 requirements.

8.1 Backup & Recovery Strategy (SharePoint, OneDrive, Exchange)

Policy Statement:
All business-critical Microsoft 365 data—including SharePoint Online sites, OneDrive for Business content, and Exchange Online mailboxes—must be protected through native retention features and/or third-party backup solutions. Recovery mechanisms must enable restoration of deleted or corrupted data within defined Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).

Microsoft 365 Configuration:

Enable Retention Policies and Litigation Hold for key mailboxes and sites via Microsoft Purview.
Implement Version History for SharePoint and OneDrive to allow file-level restores.
Configure Recycle Bin retention (1st and 2nd stage) to retain deleted items for at least 93 days.
Integrate a third-party backup solution (e.g., Veeam, AvePoint, or Synology M365 Backup) for point-in-time restore capabilities.
Define RTO/RPO targets in the IT continuity plan.

Expected Evidence:

Screenshot or export of retention and litigation hold policies.
Backup configuration report from third-party tool (if applicable).
Documentation of recovery procedures and test logs.
Audit logs showing restore tests or recent recovery operations.

8.2 Microsoft 365 Service Availability SLA

Policy Statement:
The organization relies on Microsoft’s global infrastructure and SLA guarantees to ensure business continuity. Microsoft 365 services must maintain a minimum 99.9% uptime, and service health must be continuously monitored to identify potential disruptions impacting operations.

Microsoft 365 Configuration:

Monitor real-time service health via Microsoft 365 Service Health Dashboard and Message Center.
Subscribe IT administrators to Service Health notifications and Advisory alerts.
Periodically review Microsoft’s SLA and ensure vendor commitments are documented in the organization’s risk register.
Enable Microsoft 365 Admin Mobile App for on-the-go service health tracking.

Expected Evidence:

Export or screenshot of Service Health Dashboard showing uptime metrics.
Documentation of SLA review and acceptance in vendor management records.
Record of recent advisories and administrative response logs.
IT continuity log of any service degradation and mitigation action taken.

8.3 DR/BCP Testing & Evidence

Policy Statement:
Disaster Recovery (DR) and Business Continuity Plan (BCP) testing must be conducted at least annually to validate recovery processes for Microsoft 365 and supporting systems. Test results must demonstrate the organization’s ability to restore access, recover data, and sustain operations under simulated outage conditions.

Microsoft 365 Configuration:

Document DR/BCP procedures specific to Microsoft 365 workloads.
Conduct mock recovery tests for Exchange, SharePoint, and OneDrive environments.
Store recovery documentation securely in SharePoint Online (restricted access).
Maintain version-controlled test results with approval from IT leadership.

Expected Evidence:

Copy of the latest DR/BCP test report with sign-off.
Meeting minutes or screenshots of test execution steps.
Record of corrective actions and improvements implemented post-test.
BCP schedule/calendar showing periodic testing dates.

8.4 Ransomware Recovery Policies

Policy Statement:
Ransomware resilience must be ensured through a combination of preventive security controls, immutable backup configurations, and verified recovery procedures. Microsoft 365 data must be protected against unauthorized encryption, deletion, or corruption through continuous monitoring and version control.

Microsoft 365 Configuration:

Enable Microsoft Defender for Office 365 for threat protection and Safe Links.
Configure OneDrive and SharePoint ransomware detection alerts.
Maintain file versioning and Recycle Bin configurations to recover pre-encrypted versions.
Apply Conditional Access and Multi-Factor Authentication (MFA) to limit unauthorized access.
Document a Ransomware Response Playbook outlining recovery steps.

Expected Evidence:

Screenshot of Defender for Office 365 ransomware alert settings.
Incident response documentation from mock ransomware recovery.
Audit logs showing file restore operations post-simulation.
Copy of the approved ransomware recovery playbook.

9. Vendor & Third-Party Management

Overall Policy Statement

The organization must identify, evaluate, and manage all third-party applications, integrations, and external users accessing Microsoft 365 resources to ensure data protection, least-privilege access, and compliance with SOC 2 and NIST standards. All vendor-related access must undergo due diligence, approval, and ongoing monitoring to mitigate security and privacy risks.

9.1 App Governance & Permissions (OAuth Apps, Entra Enterprise Apps)

Policy Statement:
All third-party or OAuth-based applications integrated with Microsoft 365 must be explicitly reviewed and approved by IT Security. Only applications with verified publishers, minimal required permissions (least privilege), and legitimate business justification shall be granted tenant-level or user-level consent.

Microsoft 365 Configuration:

Enforce admin consent workflow for all enterprise applications.
Enable App Governance Add-on in Microsoft Defender for Cloud Apps (MDCA) or Purview App Governance.
Restrict user consent to verified publishers or specific security groups.
Regularly review Enterprise Applications and OAuth app permissions in Entra ID → Enterprise Applications → Permissions.
Use Defender for Cloud Apps to monitor risky or high-permission OAuth apps.

Expected Evidence:

Screenshots or export of “Enterprise Applications” list with granted permissions.
Admin Consent workflow configuration documentation.
App Governance dashboard report showing risky apps and alerts.
Review log of app approval requests and corresponding security evaluations.

9.2 Access Reviews for External Users

Policy Statement:
All external or guest user accounts must be subject to periodic access reviews to confirm ongoing business justification. Any inactive, expired, or unverified external accounts must be promptly removed or blocked.

Microsoft 365 Configuration:

Configure Access Reviews for guest users in Entra ID → Identity Governance.
Automate periodic reviews (e.g., quarterly) for Teams, SharePoint, and OneDrive shared resources.
Implement lifecycle policies to automatically expire guest access after a defined duration (e.g., 90 days).
Require multi-factor authentication (MFA) for all external users.

Expected Evidence:

Access Review reports from Entra ID Identity Governance (export or screenshot).
Guest lifecycle policy configuration details.
Audit logs showing guest account removals or review completions.
Conditional Access policies enforcing MFA for guest users.

9.3 Guest Access Policy (Teams, SharePoint, OneDrive)

Policy Statement:
Guest access in Microsoft Teams, SharePoint, and OneDrive must be controlled, monitored, and aligned with business needs. Only authorized personnel may invite guests, and all guest sharing must comply with data classification and sensitivity labeling requirements.

Microsoft 365 Configuration:

Disable tenant-wide anonymous sharing; allow only authenticated guest access.
Configure External Sharing settings in SharePoint Admin Center and OneDrive Admin Center (organization-level + site-level).
Restrict guest invitations to specific security groups.
Apply Sensitivity Labels that restrict sharing for confidential content.
Enable Teams Guest Access with limited permissions (chat, meeting participation only if needed).

Expected Evidence:

Screenshots or export of SharePoint/OneDrive sharing settings.
Teams guest access configuration report.
List of current guest users from Entra ID.
Evidence of sensitivity label policy applied to shared content.
Documentation of periodic guest access reviews and removal process.

10. Training & Awareness

Overall Policy Statement

All employees, contractors, and third-party users must receive regular security and compliance training to ensure awareness of organizational policies, security responsibilities, and evolving cyber threats. Training and awareness initiatives shall be designed to reduce human error, promote a culture of security, and align with SOC 2, ISO 27001, and NIST standards.

10.1 Security Awareness Program (Phishing Simulations, Training Campaigns)

Policy Statement:
The organization must conduct periodic security awareness programs, including simulated phishing exercises and mandatory online training sessions, to educate users about cyber threats and reinforce secure behavior.

Microsoft 365 Configuration:

Use Microsoft Defender for Office 365 Attack Simulation Training for phishing simulations.
Track completion and reporting metrics within Microsoft 365 Defender → Attack Simulation Training → Reports.
Integrate with Microsoft Viva Learning or Microsoft Learning Pathways for ongoing security education.
Encourage all users to review Microsoft 365 Secure Score recommendations related to user behavior.

Expected Evidence:

Records of training sessions and attendance logs.
Attack Simulation reports showing campaign details, results, and improvement rates.
Quarterly awareness summary reports or dashboards.
Screenshots or exports from Defender Attack Simulation portal.

10.2 Acceptable Use Policy (AUP)

Policy Statement:
All users must acknowledge and comply with the organization’s Acceptable Use Policy before accessing corporate resources. The AUP defines acceptable behavior for using Microsoft 365, devices, and cloud resources to ensure data protection and prevent misuse.

Microsoft 365 Configuration:

Publish the AUP within Microsoft SharePoint, Teams, or Intune Company Portal.
Require users to accept AUP acknowledgement via Microsoft Entra ID Terms of Use (Azure AD Conditional Access).
Monitor compliance through Entra ID Sign-In Logs and Audit Logs for terms acceptance events.

Expected Evidence:

Copy of the current Acceptable Use Policy document.
Terms of Use configuration screenshots from Entra ID.
User acceptance logs or reports.
Audit log evidence showing AUP enforcement and review dates.

10.3 Continuous Education

Policy Statement:
The organization must provide continuous cybersecurity education opportunities through newsletters, knowledge-sharing sessions, or updated e-learning materials to maintain staff awareness of new threats, compliance changes, and Microsoft 365 best practices.

Microsoft 365 Configuration:

Deliver educational content through Microsoft Viva Engage (Yammer), SharePoint, or Teams channels.
Schedule quarterly awareness updates via Microsoft Planner or Outlook distribution lists.
Maintain a centralized repository of cybersecurity resources in SharePoint Online.
Optionally integrate Microsoft Viva Learning for ongoing curated training content.

Expected Evidence:

Records of training materials, newsletters, or learning paths.
Attendance or engagement metrics from Teams or Viva.
Evidence of quarterly awareness updates or communications.
Documentation of continuous improvement in awareness initiatives.

11. Evidence Collection & Audit Preparation

Overall Policy Statement

The organization must maintain accurate, consistent, and verifiable evidence of Microsoft 365 configurations, controls, and security measures to support SOC 2 compliance. All evidence collection activities must follow a documented and repeatable process, ensuring traceability, integrity, and confidentiality of audit materials.

11.1 Screenshots & Config Export Guidelines

Policy Statement:
Screenshots and configuration exports must be captured directly from Microsoft 365 admin portals (Entra ID, Intune, Purview, Defender, Exchange Admin Center, etc.) and stored securely with timestamps. Evidence should be limited to configuration views, excluding sensitive personal or customer data.

Microsoft 365 Configuration:

Use built-in export features such as:
- Security & Compliance Center → Export Audit Logs
- Defender Portal → Export Policies
- Intune → Device Compliance/Configuration Profile Export
Establish a standard evidence folder structure (e.g., /SOC2 Evidence/YYYY-MM/Control_#).
Apply file naming conventions like ControlID_ControlName_Date_AdminInitials.

Expected Evidence:

Screenshots with visible timestamps and admin context.
Configuration export files (CSV, JSON, XML).
Documented folder structure within SharePoint or Teams (restricted access).

11.2 PowerShell Scripts for Evidence

Policy Statement:
PowerShell scripts must be used to automate the collection of system configuration evidence from Microsoft 365, ensuring consistency, accuracy, and repeatability during SOC 2 audits.

Microsoft 365 Configuration:

Use Exchange Online PowerShell, MSGraph API, and Intune PowerShell SDK for exporting configurations.
Example scripts:
- Export all Conditional Access Policies.
- Export M365 Secure Score data.
- Export mailbox forwarding and auditing settings.
Store PowerShell scripts in a secured Git repository with version control.

Conditional Access Policies
Purpose: Evidence for Access Control / Device Compliance

				
					Connect-AzureAD
Get-AzureADMSConditionalAccessPolicy | 
Select DisplayName, State, Conditions, GrantControls | 
Export-Csv "C:\Evidence\ConditionalAccessPolicies.csv" -NoTypeInformation

📄 Output: ConditionalAccessPolicies.csv
📦 Evidence: Save to SharePoint → /SOC2 Evidence/2.1_DeviceCompliance/

Admin Role Assignments
Purpose: Evidence for Change Management (RBAC)

				
					Connect-ExchangeOnline
Get-RoleGroup | Select Name, Members | 
Export-Csv "C:\Evidence\AdminRoleAssignments.csv" -NoTypeInformation

📄 Output: AdminRoleAssignments.csv
📦 Evidence: /SOC2 Evidence/6.2_RBAC/

Mailbox Forwarding Rules
Purpose: Evidence for Email Security → Auto-forwarding restriction

				
					Get-Mailbox -ResultSize Unlimited | 
Get-InboxRule | 
Where-Object {$_.ForwardTo -ne $null -or $_.ForwardAsAttachmentTo -ne $null} | 
Select MailboxOwnerId, Name, ForwardTo, ForwardAsAttachmentTo | 
Export-Csv "C:\Evidence\MailboxForwarding.csv" -NoTypeInformation

📄 Output: MailboxForwarding.csv
📦 Evidence: /SOC2 Evidence/5.5_DisableAutoForwarding/

MFA & Sign-in Risk Policies
Purpose: Evidence for Access Control & Identity Protection

				
					Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy -All | 
Select Id, DisplayName, State, Conditions, GrantControls | 
Export-Csv "C:\Evidence\MFA_Policies.csv" -NoTypeInformation

📄 Output: MFA_Policies.csv
📦 Evidence: /SOC2 Evidence/2.4_ConditionalAccess/

Secure Score Export
Purpose: Evidence for Risk Management / Secure Score Tracking

				
					Connect-MgGraph -Scopes "SecurityEvents.Read.All"
Get-MgSecuritySecureScore | 
Select ActiveUserCount, CurrentScore, MaxScore, EnabledServices, VendorInformation | 
Export-Csv "C:\Evidence\SecureScore.csv" -NoTypeInformation

📄 Output: SecureScore.csv
📦 Evidence: /SOC2 Evidence/8.2_SecureScore/

Intune Device Compliance
Purpose: Evidence for Device Compliance & Encryption Controls

				
					Connect-MSGraph
Get-IntuneDeviceCompliancePolicy | 
Select DisplayName, Description, LastModifiedDateTime | 
Export-Csv "C:\Evidence\IntuneCompliancePolicies.csv" -NoTypeInformation

📄 Output: IntuneCompliancePolicies.csv
📦 Evidence: /SOC2 Evidence/2.1_DeviceCompliance/

Audit Log Configuration
Purpose: Evidence for Monitoring, Logging & Alerting

				
					Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) -ResultSize 100 | 
Select CreationDate, UserIds, Operations | 
Export-Csv "C:\Evidence\UnifiedAuditLog.csv" -NoTypeInformation

📄 Output: UnifiedAuditLog.csv
📦 Evidence: /SOC2 Evidence/5.1_AuditLogs/

SPF, DKIM, and DMARC Validation
Purpose: Evidence for Email Security Authentication

				
					Get-DkimSigningConfig | 
Select Domain, Enabled, Selector1Cname, Selector2Cname | 
Export-Csv "C:\Evidence\DKIM_Configuration.csv" -NoTypeInformation

📄 Output: DKIM_Configuration.csv
📦 Evidence: /SOC2 Evidence/5.7_SPF_DKIM_DMARC/

Microsoft Defender Alerts Summary
Purpose: Evidence for Monitoring & Threat Detection

				
					Connect-MgGraph -Scopes "SecurityEvents.Read.All"
Get-MgSecurityAlert -All | 
Select Id, Title, Category, Severity, Status, CreatedDateTime | 
Export-Csv "C:\Evidence\DefenderAlerts.csv" -NoTypeInformation

📄 Output: DefenderAlerts.csv
📦 Evidence: /SOC2 Evidence/5.3_DefenderAlerts/

List of Licensed Users
Purpose: Evidence for License management & user access

				
					Connect-MsolService
Get-MsolUser | 
Select DisplayName, UserPrincipalName, isLicensed | 
Export-Csv "C:\Evidence\LicensedUsers.csv" -NoTypeInformation

📄 Output: LicensedUsers.csv
📦 Evidence: /SOC2 Evidence/2.3_UserAccess/

✅ Recommended Practice

Save all script outputs in SharePoint → “SOC2 Evidence Repository”
Use subfolders for each control (e.g., /2.1_DeviceCompliance/, /5.1_EmailSecurity/)
Keep a PowerShell Evidence Log.xlsx recording:
- Script name
- Execution date
- Admin initials
- Output path
- Control reference

11.3 Audit Checklists (SOC 2 M365)

Policy Statement:
The organization must maintain an up-to-date SOC 2 control checklist mapping each Microsoft 365 configuration and policy to its corresponding SOC 2 criteria for readiness verification.

Microsoft 365 Configuration:

Maintain a master Excel or SharePoint-based checklist with:
- Control IDs (e.g., 2.1 Device Compliance)
- Policy statements
- Evidence paths (SharePoint links)
- Responsible owner
- Review frequency
Update checklist quarterly or upon significant configuration changes.

Expected Evidence:

Completed SOC 2 → M365 control mapping spreadsheet.
Change logs or update history (Excel version control).
Approval records from compliance owner or IT manager.

11.4 Gap Assessment Template

Policy Statement:
Periodic gap assessments must be conducted to identify deviations between current Microsoft 365 configurations and SOC 2 compliance requirements, with remediation plans documented and tracked.

Microsoft 365 Configuration:

Use Microsoft Secure Score, Compliance Manager, and Defender Recommendations to identify configuration gaps.
Maintain a Gap Assessment Report template (Excel/Word) that includes:
- Control Reference
- Current State
- Gap Identified
- Recommended Action
- Owner and Target Date

Expected Evidence:

Completed Gap Assessment Report.
Secure Score or Compliance Manager screenshots.
Status tracker showing open vs. closed remediation tasks.

11.5 Auditor Walkthrough Guide

Policy Statement:
An Auditor Walkthrough Guide must be maintained to assist auditors in reviewing Microsoft 365 configurations, evidence, and control ownership efficiently and consistently.

Microsoft 365 Configuration:

The guide should include:
- Overview of Microsoft 365 environment and tenants.
- List of relevant portals and admin roles.
- Steps to navigate to evidence sources (e.g., Audit Logs, Intune Policies).
- Links to stored evidence folders and control mapping spreadsheet.

Expected Evidence:

Finalized “Auditor Walkthrough Guide” document (PDF/Word).
Updated screenshots and links embedded for each control area.
Review/approval record from compliance lead.

Conclusion & References

Conclusion:
Continuous monitoring and governance are vital to maintaining compliance and ensuring ongoing security maturity. Microsoft 365 provides integrated tools such as Compliance Manager, Secure Score, Purview, and Defender that help organizations align with SOC 2, ISO 27001, and CIS benchmark requirements.

By leveraging these native capabilities, organizations can not only meet audit obligations but also strengthen their overall security posture, improve operational resilience, and reduce risk exposure. Consistent documentation, evidence collection, and review cycles ensure that compliance becomes an ongoing operational discipline rather than a one-time activity.

🌍 Global Standards That Can Be Generalized

You asked if there are global standards you can reference instead of just SOC 2. Yes — most organizations align with at least one of these:

SOC 2 (AICPA – US focused, widely adopted globally)
- Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy).
- Best if your clients are US-based SaaS, finance, or healthcare companies.
ISO/IEC 27001:2022 (International standard)
- Annex A controls cover identity, access, cryptography, operations security, etc.
- Broad global recognition, especially in EU/Asia.
NIST Cybersecurity Framework (CSF)
- Categories: Identify, Protect, Detect, Respond, Recover.
- Often used in the US, but respected worldwide.
NIST SP 800-53 / 800-171 (Very detailed, US government/DoD context).
CIS Critical Security Controls (CIS v8)
- Practical, technical baseline — easier to explain to SMBs.
- Example: CIS Control 4 → Secure Configuration for Hardware/Software.

📚 Sources (official references)

SOC 2 TSC (AICPA):
SOC 2 Trust Services Criteria (AICPA)
ISO/IEC 27001:2022 Standard Overview:
ISO 27001 – International Organization for Standardization
NIST Cybersecurity Framework (CSF 2.0):
NIST CSF 2.0
CIS Critical Security Controls (v8):
CIS Controls

Purpose

Scope

Table of Contents

Introduction

1. Identity

1.1 Enforce MFA

Policy Statement

1.2 Restrict Geo-based Access

1.3 Disable Legacy Authentication

2. Endpoint Protection

2.1 SOC 2 Compliant Endpoint Controls

2.2 Device Compliance

2.3 Encryption & Hardening

2.4 Antivirus & EDR

2.5 Patch Management

3. Data Security & Protection

3.1 Sensitivity Labels (Microsoft Purview Information Protection)

3.2 Data Classification Framework

3.3 Data Loss Prevention (DLP) Policies

3.4 Retention Policies & Litigation Hold

3.5 Secure Data Destruction (NIST SP 800-88)

3.6 Rights Management (Encryption at Rest & In Transit)

4. Email Security

4.1 Anti-Malware Protection

4.2 Anti-Phishing

4.3 Safe Links & 4.4 Safe Attachments

4.5 Disable Auto-forwarding

4.6 Email Encryption

4.7 SPF, DKIM, DMARC Records

5. Monitoring, Logging & Alerting

5.1 Unified Audit Log (Microsoft 365 Compliance Center)

5.2 Sign-in Risk & User Risk Policies (Microsoft Entra ID Protection)

5.3 Defender Security Alerts & Automated Response

5.4 SIEM Integration (Microsoft Sentinel / 3rd Party)

5.5 Incident Response Workflow

6. Change Management

6.1 Documenting Microsoft 365 Configuration Changes

6.2 Role-Based Access Control (RBAC) for Admins

6.3 Change Approvals & Ticketing System Integration (ServiceNow/Jira)

6.4 Evidence: Change Logs, RBAC Role Assignments

7. Risk Management

7.1 Risk Assessments in Microsoft 365 Compliance Manager

7.2 Secure Score Tracking (Baseline + Improvement Plan)

7.3 Vendor & Third-Party App Risk Evaluation

7.4 Evidence: Compliance Manager Reports, Secure Score Exports

8. Business Continuity & Resilience

8.1 Backup & Recovery Strategy (SharePoint, OneDrive, Exchange)

8.2 Microsoft 365 Service Availability SLA

8.3 DR/BCP Testing & Evidence

8.4 Ransomware Recovery Policies

9. Vendor & Third-Party Management

9.1 App Governance & Permissions (OAuth Apps, Entra Enterprise Apps)

9.2 Access Reviews for External Users

9.3 Guest Access Policy (Teams, SharePoint, OneDrive)

10. Training & Awareness

10.1 Security Awareness Program (Phishing Simulations, Training Campaigns)

10.2 Acceptable Use Policy (AUP)

10.3 Continuous Education

11. Evidence Collection & Audit Preparation

11.1 Screenshots & Config Export Guidelines

11.2 PowerShell Scripts for Evidence

✅ Recommended Practice

11.3 Audit Checklists (SOC 2 M365)

11.4 Gap Assessment Template

11.5 Auditor Walkthrough Guide

Conclusion & References

🌍 Global Standards That Can Be Generalized

📚 Sources (official references)

Leave a Comment Cancel reply