Microsoft 365 (M365) provides comprehensive logging capabilities to track user activities, administrative actions, security events, and more across its cloud services[2][1]. These logs are crucial for security monitoring, compliance audits, and troubleshooting. Below, we outline the key types of logs in M365 and provide a step-by-step guide to ensure all logging is fully enabled and configured for maximum benefit.

Logging Capabilities in Microsoft 365

M365 generates a variety of logs, each serving different purposes. Key logging categories include audit logs, activity logs, security logs, compliance logs, and diagnostic logs – though there is significant overlap among these terms in practice. The table below summarizes the main logging capabilities:

Step-by-Step: Ensuring All Logging is Fully Enabled

To get full visibility into your M365 environment, it’s important to verify and enable all relevant logging features. Follow these steps to ensure no audit or logging capability is overlooked:

1. Verify Unified Audit Logging is Turned On: Audit log search is on by default for all Microsoft 365 organizations, but you should confirm this setting, especially for new tenants[4][3]. In the Microsoft Purview Compliance Portal (formerly Security & Compliance Center), go to Audit. If you see a banner saying “Start recording user and admin activity,” auditing is not yet active[4]. Click that banner to enable the Unified Audit Log. Once enabled, M365 will begin recording user and admin activities across workloads. (It may take up to an hour for logging to begin after activation[4].) You can also verify or enable this via PowerShell: run Get-AdminAuditLogConfig | FL UnifiedAuditLogIngestionEnabled – a value of True means auditing is on[4]. If False, enable it with Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true (requires the Audit Logs role). This step is critical, as the unified audit log is the central repository for most M365 activity logs.

2. Ensure Mailbox Auditing is Enabled for All Mailboxes: Exchange Online’s mailbox auditing (logging of mailbox access/actions) is enabled by default for all user, shared, and group mailboxes[6]. However, it’s good practice to verify this setting. Run Get-OrganizationConfig | FL AuditDisabled in Exchange Online PowerShell – it should return False (meaning auditing is not disabled, i.e. it’s active)[6]. By default, dozens of mailbox actions (emails read, sent, deleted, etc.) by owners, delegates, and admins are automatically logged without any manual configuration[6]. If for some reason auditing was turned off at the mailbox or org level, re-enable it with Set-Mailbox -Identity <mailbox> -AuditEnabled $true (per mailbox) or Set-OrganizationConfig -AuditDisabled $false for the organization. Also consider enabling auditing on resource mailboxes (room/equipment mailboxes) if needed, as those might not be covered by the default in some cases. Verifying mailbox audit logs are on ensures you capture all email activity events in the audit logs for security and compliance needs.

3. Enable and Check Entra ID Logs: You don’t “turn on” Entra ID sign-in or audit logs – they are always recording by default – but you should ensure you can access them and are licensed for adequate retention. In the Entra ID portal, navigate to Monitoring > Sign-in logs and Audit logs to confirm data is flowing. No specific enablement is required, but note the default retention (generally 30 days for sign-in and audit events with premium licenses, or 7 days on free tier)[5]. To retain Entra ID logs longer or integrate them with other logs, set up Diagnostic Settings in Entra ID to export logs to an Azure Monitor Log Analytics workspace or a SIEM. This involves configuring an Azure Storage/Log Analytics target (requires Entra ID P1/P2 and an Azure subscription)[5]. In summary: verify you have the necessary Entra ID Premium license to capture all identity logs (most M365 enterprise plans include at least P1), and configure log forwarding if you need retention beyond the default.

4. Check Logging for Other Services: Most other M365 services feed into the unified audit log automatically once auditing is on. Verify that activities from key workloads are appearing in the audit log. For example, perform a test action (like accessing a SharePoint file or sending a Teams message) and then search the audit log for that activity to ensure it’s recorded. There is generally no separate “enable” switch for SharePoint, OneDrive, Teams, etc., beyond the unified audit setting – those services automatically log events to the unified log when auditing is enabled[1]. Additionally, M365 Compliance/Protection features (like DLP or label policies) will also log their events to the audit log when triggered. However, if your organization uses Power Platform (Power Apps, Power Automate) or other connected services, ensure auditing for those is enabled in their respective admin settings if applicable (most now also rely on unified audit). Essentially, once the Unified Audit Log is on, all supported M365 services start logging events by default, but it’s good to double-check for any particular application logs you expect.

5. Configure Advanced Audit (if available): If your organization has Microsoft 365 E5 or an add-on like Microsoft Purview Audit (Premium), make sure to take advantage of advanced auditing features. Advanced Audit automatically expands the range of log data captured – for example, it logs mailbox item read access events, SharePoint file access details, and other events that standard audit might not capture[3]. It also extends retention: Audit Premium retains logs for at least 1 year by default and allows creating audit log retention policies for up to 10 years for specific activities[3]. There’s no separate “on switch” if you have the license; you just need to assign the appropriate licenses to users (audit events are tied to user licenses) and the additional events are recorded automatically[1]. Verify that your premium audit events are showing up by searching for a few sample activities (for example, the MailItemsAccess event which records email reads by non-owners – this event is available only with advanced auditing). If they’re not present and you have E5, ensure users’ licenses are correctly applied and that the unified audit log hasn’t been inadvertently turned off. Note: In 2023, Microsoft began rolling out some advanced log types (like detailed email access logs) to standard customers at no additional cost[1], so you may see more detailed events even without E5, thanks to these updates.

6. Set Log Retention Policies (Optional): With Audit (Premium), admins can create custom audit log retention policies to preserve certain logs up to 10 years[3]. If you have this capability and a compliance requirement to keep logs longer than the default, configure a retention policy in the Compliance Center (under Audit -> Audit retention). For example, you might retain all Exchange mailbox audit records for 5 years. Without Audit Premium, you cannot change the 180-day default within the service – in that case, plan to regularly export logs if longer retention is needed (see step 9). For Entra ID logs, use Azure Monitor export as mentioned to keep data beyond 30 days[5]. Ensuring proper retention configurations will help fully “enable” your logging from a data lifecycle perspective, so you don’t lose valuable log data over time.

7. Assign Proper Permissions for Log Access: Having logs enabled is only part of the solution – you need the right roles to access and utilize them. In M365 Compliance Center, only users in specific roles can search the audit log. By default, Global Admins and members of the Organization Management or Compliance Management role groups have this access (these include the Audit Logs role)[3]. You can also assign the dedicated View-Only Audit Logs or Audit Logs role (via Exchange Online’s role management) to any staff who need to review logs[3]. Follow the principle of least privilege: assign view-only roles to auditors or investigators who just need to read logs, and restrict the ability to delete or turn off logging to only a few top admins. For Entra ID logs, roles like Security Reader or Report Reader can view sign-in and audit logs without full admin rights. Make sure these permissions are in place so that the security/compliance team can access logs independently. Logging isn’t fully operational unless the right people can reach the data.

8. Monitor Logs and Set Up Alerts: Once logging is enabled everywhere, configure alerting to get notified of important events rather than having to manually hunt through logs continuously. In the Microsoft Purview compliance portal, go to Alerts (Alert policies) and set up policies for activities of interest. For example, you might create an alert for “Mass download of files from SharePoint” or “Mailbox admin delegation added” – when such an audit event occurs, the system will send an email alert to chosen recipients. Microsoft provides many built-in alert templates for suspicious or anomalous activities. Similarly, in Entra ID you can enable Entra ID Identity Protection alerts for things like impossible travel logins or multiple failed sign-ins. If you have Microsoft Defender for Cloud Apps (MCAS), it can also watch user activity logs (including O365 audit events) and trigger alerts for things like data exfiltration patterns. Setting up these alerts ensures that your logging works proactively for you, raising flags when something in the logs looks wrong. It’s a key step to operationalize your logs for security monitoring.

9. Integrate Logs with Analysis Tools or SIEM: To fully leverage M365 logs, you may want to aggregate and analyze them using advanced tools. Microsoft provides APIs to facilitate this. Enable the Office 365 Management Activity API (now part of the Graph Security API/Purview Audit) if you want to pull audit logs into a Security Information and Event Management (SIEM) system or a custom dashboard[3]. Many organizations integrate M365 audit logs into tools like Splunk, IBM QRadar, or Azure Sentinel (Microsoft Sentinel). For instance, in Azure Sentinel you can use the built-in Office 365 connector to stream audit logs (Exchange, SharePoint, Teams events) and Entra ID sign-in logs continuously. If using a third-party SIEM, set up the polling of the Management Activity API or use the newer M365 Defender Streaming API for real-time event streaming (this requires some Azure setup and is often used to send Defender alerts to an event hub). Additionally, you can export audit search results from the portal in CSV format for offline analysis (the portal allows exporting up to 50,000 events per CSV). Regularly exporting or streaming logs ensures you have a backup of log data outside Microsoft’s 180-day window and allows you to run complex queries or correlations on log data (for example, joining sign-in logs with mailbox logs to investigate a potential breach). Integration with external tools is vital for advanced threat hunting and for keeping logs long-term.

10. Verify and Test Logging Configuration: Finally, conduct periodic tests and reviews. For example, perform known activities (like a test user deleting multiple files, or an admin changing a setting) and then verify those actions appear in the audit log. Check that mailbox audit events (like a delegate reading someone’s mailbox) are being captured by searching the audit log for MailboxAudit entries. Attempt some sign-in events (successful and failed logins) and ensure they show up in Entra ID logs. If you have alert rules configured, trigger a test alert (Microsoft provides a way to simulate some alerts) to see if notifications fire. Review role assignments to confirm only intended personnel have access to log searches. Also, periodically review Microsoft 365 Message Center announcements or Tech Community blogs for any changes to logging behavior or new log types being added. By testing and reviewing, you ensure that logging remains fully operational and reliable as your M365 environment evolves.

Accessing and Managing M365 Logs

Once all logging is enabled, it’s important to know how to access these logs and manage them on an ongoing basis:

• Microsoft Purview Compliance Portal (Audit Search): This is the primary GUI to search unified audit logs. Go to Compliance Portal > Audit and use the search interface to query activities by date range, user, file, folder, etc. You can filter by activity type (the portal provides categories) and export results. Keep in mind the interface returns a maximum of 5,000 results per search (most recent first)[3], so use filters to narrow down data if needed. The audit search covers Exchange, SharePoint, OneDrive, Teams, Power BI, Dynamics 365, and many other services in one place.
• Exchange Admin Center & Security Portal: Some logs can be accessed in specialized interfaces. For instance, Mailbox audit logs can also be viewed via certain Exchange PowerShell cmdlets (Search-MailboxAuditLog for older approach, though unified audit log supersedes this). The modern Security & Compliance (now split into Purview Compliance and 365 Security) portals also allow audit searching. Additionally, the Exchange Admin Center has the Message Trace tool for email flow logs – you can query by sender, recipient, date, etc., to see what happened to an email (this is separate from the user/admin audit log).
• Entra ID Portal (Entra Admin Center): For identity-related logs, use the Entra admin center (Entra ID). Under Monitoring, check Sign-in logs for interactive login events and Audit logs for directory changes. You can filter by status, user, application, and download the logs as CSV or JSON. Entra ID logs provide details like IP addresses, device info, and error codes for sign-ins, which are invaluable for security analysis.
• Microsoft 365 Defender Portal: If your organization uses Microsoft 365 Defender services (like Defender for Endpoint, Defender for Office 365, Cloud App Security, etc.), the unified Defender portal (security.microsoft.com) provides an Advanced Hunting feature. This is a query-based search over security logs (using Kusto Query Language). It allows you to query things like email events, device logs, cloud app events, etc., across a 30-day window. While this is more of an analysis tool than raw log search, it effectively lets you tap into detailed log data for threat hunting. The Defender portal also shows Alerts and incidents, which are derived from underlying logs.
• PowerShell and CLI: Microsoft provides PowerShell cmdlets for retrieving logs. For audit logs, you can use Search-UnifiedAuditLog in Exchange Online PowerShell to retrieve audit data programmatically (with parameters for date range, users, activities, etc.). For mailbox audit specifically, Search-MailboxAuditLog can be used (though unified log is preferred). Azure AD logs can be fetched via the Azure CLI or PowerShell (Get-AzureADAuditDirectoryLogs and Get-AzureADSignInLogs in the Azure AD module). Using scripts, you can automate log retrieval or integrate with internal tools.
• Office 365 Management Activity API: As noted, this REST API allows subscription to various activity log feeds (e.g., Exchange, SharePoint, Azure AD, DLP, etc.). Third-party SIEM solutions often use this to pull data continuously. It requires setting up an app in Azure AD, granting it proper permissions, and then pulling down content via REST calls[3]. Microsoft also has a newer Graph API for audit logs that E5 customers can use for certain advanced events.
• Log Analytics / Sentinel: If you route logs to an Azure Log Analytics workspace (via Azure Monitor), you can use Log Analytics queries to search through data, and use Azure Sentinel for correlation rules and alerting. For example, Azure AD sign-in and audit logs forwarded to Log Analytics can be queried with KQL and retained for much longer. Office 365 unified audit logs can also be ingested into Sentinel using the O365 connector, which then allows blending those logs with others (like Azure AD or firewall logs) for a holistic view.
• Reports and Insights: M365 provides various activity reports in the Microsoft 365 admin center (under Reports > Usage or Security & Compliance > Reports). These are more high-level (e.g., how many files accessed or emails sent by users), not detailed logs, but they are derived from the logging data. They can be useful for a quick overview or for non-technical audiences. For instance, the Office 365 Secure Score and Compliance Score dashboards show your status and actions, some of which relate to logging/configuration.

Managing logs also involves ensuring their integrity and reviewing them regularly. Remember that log data is only useful if someone looks at it – so implement processes for regular audit log reviews, especially for admin activities or anomalous user activities. Many organizations designate a security analyst or compliance officer to routinely review critical logs (for example, weekly checks of admin activities, or daily review of Azure AD risky sign-in reports).

Best Practices and Security Considerations for M365 Logging

Implementing logging is not just a technical switch – it should be part of your security and compliance strategy. Here are some best practices and considerations:

• Auditing Policy and Scope: Understand what activities are being logged and ensure they align with your needs. Microsoft 365’s unified audit covers thousands of events across dozens of services[1]. Review the list of audit log activities available for M365 to know what is captured. If there are critical actions not logged by default, see if advanced audit or another solution is needed. For example, by default you get events like file accessed, modified, shared, login events, mailbox operations, etc. With Advanced Audit, you get extra events like mail item read access and deeper SharePoint query events[3]. Tailor your use of logs to the risks and compliance requirements of your organization.
• Retention vs. Volume: Balance log retention with volume. Longer retention is valuable for investigating incidents that happened months ago, but it also means a lot of data. Microsoft now provides 180 days standard retention[4], which is a generous default. If regulatory compliance demands longer (e.g. financial or healthcare sectors might require a year or more of audit logs), use either the Audit Premium with 10-year retention policies, or export the logs periodically to an external archive. Keep in mind Azure AD sign-in logs default to 30 days – if those are crucial, set up forwarding to keep them longer[5]. It’s best practice to have security logs retained for at least 6-12 months, either in the cloud or in your SIEM, to cover the window when breaches might be discovered.
• Security of Logs: Treat log data as sensitive. Audit logs can contain information like filenames, email subjects, or user details that might be confidential. Ensure that only authorized personnel can access the logs (via the role-based permissions discussed). All access to auditing data itself is logged – you can see who searched the audit log and what they searched for, which is important for chain-of-custody in investigations. Microsoft also protects the integrity of audit logs internally (they cannot be changed or deleted by users once recorded). Avoid exporting logs to insecure locations or emailing raw logs without protection; if you must share log data for analysis, use secured methods and sanitize if needed.
• Monitoring and Anomaly Detection: Logs by themselves are reactive unless you actively monitor them. Leverage tools (or services) that analyze log patterns and flag anomalies. Microsoft 365 has built-in analytics (like Insider Risk Management, which can use audit signals to detect risky user behavior, or Cloud App Security policies that detect impossible travel logins). Even with those, you might use a SIEM or XDR solution to correlate M365 logs with other data (firewall logs, endpoint logs) for a fuller picture. For example, if you see a log of a user downloading 10GB of data from OneDrive at 3 AM, and around the same time your firewall log shows large data egress from that user’s IP – together that indicates a potential incident. Define what constitutes “normal” vs “suspicious” in your environment and set up alerts accordingly.
• Combining Multiple Log Sources: Remember that not everything is in one place. For a given incident, you may need to consult multiple logs. Example: To investigate a potential email breach, you’d check Azure AD sign-in logs (for login patterns on that mailbox account), mailbox audit logs (for any unusual mailbox access or email forwarding rules set), unified audit log (for any data exports from SharePoint by that user, etc.), and possibly Defender logs (for malware or phishing alerts involving that mailbox). Get familiar with all the log sources so you know where to look when something happens.
• Regular Audit of Logging Configuration: Periodically audit your logging setup itself. Ensure auditing hasn’t been turned off (it’s rare, but an attacker with high privileges could attempt to turn off logging – note that requires Global Admin and is itself a logged event if they tried). Check that new services or features in M365 are included in your audit coverage – Microsoft often adds new audit event types (for example, if you deploy a new M365 app like Viva or Yammer, verify that their activities are being logged). Stay updated via Microsoft’s documentation or announcements on any changes to logging behavior.
• Compliance and Privacy: Be aware of data privacy laws – some regulations require informing users that their activities may be monitored and logged. M365 audit logs are typically considered for legitimate security/compliance use, but your organization should have clear policies about log use and retention that align with GDPR, etc., if applicable. Also, if you have data residency requirements, note that audit data is stored in a region (for multi-geo tenants, consult Microsoft docs on where audit logs reside).
• Backup and Disaster Recovery of Logs: In cloud services, Microsoft ensures high availability of logging infrastructure, but as a best practice, treat critical logs as you would important data – have a backup. Exporting logs daily or weekly to an immutable storage (like write-once storage) can protect you in case logs are inadvertently cleared or if an account that had access to search logs gets compromised. This is not usually needed for Microsoft’s cloud (since you can trust the service’s durability), but for utmost caution in high-security environments, some do pull logs regularly and keep a separate copy.
• Use of Diagnostic Logs: For more in-depth troubleshooting (outside security), know how to enable and collect diagnostic logs. If an issue arises, say with an Office app or an email that went missing, Microsoft Support might ask for client-side logs or run traces. Tools like the Microsoft Support and Recovery Assistant can collect diagnostic logs for Office apps. In Exchange Online, there’s a feature called ** mailbox audit log search ** (as covered) and also message trace for mail flow. In SharePoint/OneDrive, site admins can view some audit logs at the site level if needed. So, beyond security, use logging as a general troubleshooting aid – e.g., to find why a document was inaccessible, or who changed a configuration that broke something.

Integration with Third-Party Tools and Advanced Monitoring

Microsoft 365 logs are powerful on their own, but integrating them with other systems can provide a unified view of your organization’s IT environment:

• SIEM Integration: Whether it’s Splunk, Azure Sentinel, IBM QRadar, or any other SIEM, integrating M365 logs allows you to correlate cloud activities with on-premises events. For instance, a SIEM rule might combine a physical badge access log (from a building entry system) with an O365 login log to detect if a user’s account was used from another country while they badged into the office locally – a likely security incident. Most SIEM solutions have connectors or scripts to ingest M365 logs. Use the Office 365 Management API or Azure Event Hub streaming (for Defender alerts) as needed[3]. Azure Sentinel (Microsoft Sentinel) has native connectors for Office 365 (audit logs) and Azure AD, which can be enabled in a few clicks and continuously pull data. Ensure whatever third-party tool you use is properly authenticated and scoped to get the logs it needs (principle of least privilege for API access too).
• Third-Party Monitoring and CASBs: Cloud Access Security Brokers (CASBs) and other monitoring tools can also use M365 logs. Microsoft’s own CASB (Defender for Cloud Apps) can ingest audit logs from M365 and provide dashboards of risky behavior (like unusual download patterns, or use of a newly discovered OAuth app by many users). Third-party CASBs (Netskope, McAfee, etc.) similarly can pull these logs via API for their analysis. If using one, follow their integration guides for O365 – typically you create an app in Azure AD and give it the Audit.Read.All permission to the Graph or similar.
• Audit Log Customization and Analytics: With logs in a central database or SIEM, you can run custom analytics. Write queries to answer questions like “Who accessed confidential Project X files in the last 6 months?” or “List all admin actions in Exchange in the past week” or “How many failed login attempts did we have each day this month”. Many organizations build reports from log data for compliance reporting (e.g., a monthly access report to demonstrate to auditors that only authorized changes were made). M365’s management API and PowerShell allow you to extract data and feed it into such reports.
• Automated Response: Going a step further, you can tie logging to automated responses. For example, using Azure Sentinel or Azure Logic Apps, you could trigger a workflow when a certain log event occurs – like if an account is added to a high-privilege role (logged in Azure AD audit logs), you could automatically remove it or send an approval request to IT. Or if multiple failed logins for a user from different locations appear (from sign-in logs), automatically force a password reset or disable the account pending investigation. Microsoft 365’s ecosystem allows these kind of orchestrations (often referred to as SOAR – Security Orchestration, Automation, and Response). Ensure any automation is tested to avoid false positives causing disruptions.

Recent Updates and New Features in M365 Logging

Microsoft is continually improving M365 logging capabilities. Here are a few notable recent updates:

• Expanded Audit Log Coverage (2023): In response to evolving threats, Microsoft announced an expansion of cloud logging for all customers. More log types that were previously exclusive to premium (E5) are being made available to standard (E3) customers. Notably, detailed email access logs and over 30 additional event types are now included in Audit Standard[1]. This change, rolling out from late 2023 into 2024, means even without an E5 license, organizations get deeper visibility (for example, tracking when emails are accessed, not just sent). This was accompanied by an increase of the default audit retention from 90 to 180 days[4][1], significantly boosting the “memory” of the audit log for all customers.
• Microsoft Purview Rebranding and Integration: The logging and compliance tools were unified under the Microsoft Purview brand. The Audit log search, Compliance center, and related features might look slightly different as Microsoft integrates them. For instance, Audit search moved from the old Security & Compliance Center to the new Purview Compliance Portal. Microsoft 365 Defender portal now also can be used to search the unified audit log in some cases[3], creating a more seamless experience between security and compliance centers.
• Advanced Audit Features: Microsoft Purview Audit (Premium) introduced Intelligent Insights – advanced analysis to help determine the scope of a compromise by processing audit logs in the backend (for example, highlighting unusual download activities automatically). Additionally, the ability to create custom log retention policies up to 10 years for specific activities was introduced for organizations with long-term retention needs[3]. These features are continuously being improved, and Microsoft often adds new auditable events (e.g., new Microsoft Teams or Microsoft 365 Copilot activities are being logged as those services evolve).
• Integration and API Enhancements: Microsoft Graph API is gradually becoming a one-stop shop for all sorts of audit log access. New endpoints in Microsoft Graph (beta) can retrieve audit logs across services with a unified schema. This is part of Microsoft’s effort to streamline how developers and tools access the data. Moreover, Azure AD logs can now be streamed in near real-time to Azure Event Hubs using the diagnostic settings – allowing better integration with SIEMs without waiting for the typical 15-minute aggregation. The M365 Defender Streaming API now enables real-time alert forwarding to external systems, which complements the periodic pulling of the Management API for audit data.
• CISA and Security Community Guidance: Microsoft worked with the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to release guidance (the Expanded Cloud Logs playbook) for leveraging M365 logs. This highlights how to enable and use these logs for advanced threat detection, reflecting lessons from recent supply-chain attacks. Microsoft’s collaboration with industry partners means best practices for logging are being shared more broadly – it’s wise to stay informed through Microsoft’s security blogs and documentation for such guidance.
• Future Developments: Logging in cloud services is an area of rapid development. Expect to see even more granular logs (for instance, deeper visibility into SharePoint file read activities or Teams chat message edits), longer retention included by default for some customers, and more machine learning applied to logs (to detect anomalies). Microsoft 365 Copilot itself will generate audit logs of its operations, and administrators will likely get new tools to review Copilot’s actions via those logs. Keeping an eye on the M365 roadmap and tech community will help you stay ahead of changes in logging capabilities.

In conclusion, Microsoft 365 offers a robust set of logging tools that, when fully enabled, give organizations deep insight into activities and security events in their cloud environment. By turning on and configuring Unified Audit Logging, ensuring all services (Exchange, SharePoint, Azure AD, etc.) are covered, and following best practices for retention, monitoring, and integration, administrators can greatly enhance their security posture and compliance readiness. Remember that logs are your friend in both investigating incidents and demonstrating proper governance – so enable them, protect them, and use them proactively. With the steps and considerations outlined above, you can be confident that all logging capabilities in M365 are enabled and functioning to their fullest extent.[2][1]

References

[1] Expanding cloud logging to give customers deeper security visibility

[2] M365 Logging: A Guide for Incident Responders

[3] Discovering Microsoft 365 Logs within your Organization [ Part 1]

[4] Turn auditing on or off | Microsoft Learn

[5] Microsoft Entra data retention – Microsoft Entra ID

[6] Manage mailbox auditing | Microsoft Learn