Retaining and Preserving Microsoft 365 and Purview Forensic Logs and Insider Risk Evidence

Retaining and Preserving Microsoft 365 and Purview Forensic Logs and Insider Risk Evidence

Managing a Microsoft 365 E5 tenant for forensic and legal requirements involves ensuring that all relevant logs and investigation data are retained in an immutable, tamper-proof format for long periods. This guide covers a Microsoft-native strategy to preserve logs from Microsoft Purview (including Insider Risk Management cases), Microsoft Entra ID, and Microsoft Sentinel, with steps for secure export, long-term retention (6 months interactive, 2+ years archived), and cost considerations.

1. Microsoft-Native Immutable Retention Strategy

Overview: Leverage built-in Microsoft 365 and Azure features to retain audit and security logs for 1–2 years (or more) in a non-erasable format. This includes configuring Purview (Compliance) audit log retention, exporting Insider Risk data, and using Azure Monitor/Sentinel for extended log storage.

1.1 Purview Audit Logs and Insider Risk Management Data

• Enable Advanced Audit: As an E5 tenant, you have Audit (Premium), which by default retains many audit logs for 1 year​ learn.microsoft.com. (This covers Exchange, SharePoint, OneDrive, and Entra ID audit events for E5-licensed users.) Verify that Audit (Premium) is active so that user activity logs in Microsoft 365 are kept for 365 days by default​ learn.microsoft.com. If needed, create custom audit retention policies to retain specific logs longer (up to 10 years with the appropriate add-on) ​learn.microsoft.com.
• Purview (Compliance) Portal: In the Purview compliance portal, review the Audit settings. The default E5 policy retains logs for 1 year ​learn.microsoft.com. If your legal requirement is 2 years, consider using the 10-year Audit Retention add-on for critical activities​ answers.microsoft.com or plan to export and archive the logs externally (covered in section 2).
• Insider Risk Management (IRM) Alerts & Cases: Understand the retention behavior:
  • IRM Alerts: Alerts that are not associated with an active case (e.g. still in “Needs review” status) are automatically deleted after 120 days ​learn.microsoft.com.
  • Active IRM Cases: If you create a case from the alerts, the case and its associated artifacts (alerts, insights, activity logs) have indefinite retention while the case remains active (no automatic expiration)​ learn.microsoft.com. This means you can keep a case open to retain its data.
  • Resolved/Closed Cases: Once you resolve a case, the case and all its associated data will be purged after 120 days ​learn.microsoft.com. Important: This is a critical window – you must preserve the case evidence before that time elapses (see section 3 for export steps).
• Forensic Evidence (Insider Risk): If you enabled the IRM forensic evidence feature (screen captures of user activity on endpoints via Intune), note that these recordings are stored for 120 days from ingestion ​learn.microsoft.com. After 120 days, they are removed from the cloud, regardless of case status. Microsoft explicitly recommends exporting forensic evidence if it needs to be retained longer ​learn.microsoft.com. Ensure you download any such evidence (videos, screenshots) well before this limit.
• Use Purview Retention Labels for Content (Optional): If the incident involves files or emails, you can apply retention labels or litigation hold on that content to preserve it. For example, if an insider exfiltrated files, applying a retention hold on those files (or the user’s mailbox, OneDrive, etc.) via Purview Data Lifecycle Management can preserve the content in an immutable state for legal review. (This is separate from logs, but part of end-to-end evidence retention.)

1.2 Entra ID Logs

• Azure AD Sign-In and Audit Logs: By default, Azure AD sign-in logs and audit logs are only interactive for 30 days in the Entra admin portal. To extend this natively, set up an Azure Monitor Diagnostic Setting:
  1. Export to Log Analytics: In the Entra ID (Azure AD) portal, navigate to Monitoring > Audit Logs and Sign-In Logs, and add a Diagnostic Setting to send these logs to an Azure Log Analytics workspace​ tminus365.com. (If you have Microsoft Sentinel, you can use its workspace; if not, create a dedicated Log Analytics workspace​ tminus365.com.) This allows retention up to 2 years in Log Analytics and the ability to run KQL queries across a longer period.
  2. Export to Azure Storage (Immutable): For long-term, tamper-proof storage, also send the logs to an Azure Storage account with immutability. In the same Diagnostic Setting, select an Azure Storage destination (and/or Event Hub). Configure the storage container with an immutability policy (either a time-based retention lock or a legal hold). For example, set a time-based retention of 2 years on the container so that any log blobs cannot be altered or deleted until that period passes ​manuals.supernaeyeglass.com. This meets WORM (Write-Once-Read-Many) requirements for legal admissibility. (Tip: Azure Storage immutability provides an audit log of any policy changes and guarantees data integrity​ learn.microsoft.com.)
  3. Retention in Log Analytics: In your Log Analytics workspace (Azure portal > Log Analytics > Usage and retention settings), increase the data retention for the Azure AD logs tables. You can set interactive retention (hot data) to 180 days (6 months) or more, and total retention to 2 years or beyond​ learn.microsoft.com​ learn.microsoft.com. For instance, you might keep 180 days of sign-in logs searchable, and have them archived in the workspace for up to 730 days total. After the interactive period, the data is still in the workspace in a low-cost archive and can be retrieved on demand​ learn.microsoft.com ​learn.microsoft.com.
• Linking Identities to Logs: Ensure that logs contain user identity context:
  1. Multi-Factor Authentication: Azure AD sign-in log entries show whether MFA was required and if it was satisfied. By enforcing MFA for user sign-ins (via Conditional Access), each log will indicate strong authentication.
  2. Device Identity and Compliance: Azure AD sign-in logs also include device information when available (device ID, Azure AD join type, compliance status, etc.). For example, if a user signs in from a compliant, Intune-managed device, the sign-in log will note the device ID and a flag that the device is compliant and Azure AD joined. These fields allow you to prove a specific managed device was used. You can use Kusto queries to filter or join logs by user, device, or IP address to trace activities ​tminus365.com.
  3. Intune Device Logs: Intune (Endpoint Manager) provides additional logs on device compliance, configuration changes, and actions (e.g., device wipe, app install). Configure Intune Diagnostics Settings to send these logs to Azure Monitor as well ​learn.microsoft.com. Intune can send Audit Logs (changes in Intune configurations), Operational Logs (enrollment successes/failures), Device Compliance logs, and Device Inventory logs to the same Log Analytics workspace or to an Azure Storage account​ learn.microsoft.com ​learn.microsoft.com. Archiving these ensures you have a record of device state and management actions. In a security incident, you can correlate Intune logs with Azure AD sign-in logs (via device IDs or timestamps) to show, for example, that a device was marked compliant at the time of a suspicious login.
• Azure AD Identity Protection & Others (Optional): If available, also consider retaining Azure AD Identity Protection logs (risky sign-ins, user risk events) by exporting them similarly. These can further validate user identities (e.g., confirming a sign-in had a low risk level after MFA).

1.3 Microsoft Sentinel and Log Analytics

• Ingesting Logs into Sentinel: Microsoft Sentinel (built on Azure Log Analytics) can serve as a central repository for security logs:
  • Connect Azure AD Logs: Use the built-in Azure AD connector in Sentinel or simply use the Log Analytics method above to ingest sign-in and audit logs. Sentinel will allow real-time alerting and convenient search across this data.
  • Connect Microsoft 365 Audit Logs: Use the Office 365 data connector in Sentinel to ingest Microsoft 365 audit logs (Exchange, SharePoint, Teams activities) into the workspace. Note: Office 365 audit logs are free to ingest in Sentinel ​learn.microsoft.com, meaning you can pull in all Purview audit data without increasing ingestion costs. This ensures that Purview logging (like file access, email send/receive, etc.) is also available in Sentinel and can be retained under the workspace’s retention settings.
  • Connect Insider Risk Alerts: There is also a Microsoft 365 Insider Risk Management connector for Sentinel​ learn.microsoft.com. This pulls IRM alerts into Sentinel (as security alerts in the SecurityAlert table)​ learn.microsoft.com. While it won’t import the full case details, it will log the alert metadata (user, severity, policy triggered) in Sentinel for correlation with other alerts. This is useful to have a unified incident view.
• Sentinel Data Retention Settings: Configure workspace retention to meet 6-month interactive and 2-year archival goals:
  • In the Log Analytics workspace settings (or via Azure Monitor CLI/PowerShell), set the retention period to 730 days (or 913 days if you want 2.5 years). Sentinel supports up to 2 years interactive retention on Analytics-tier data, and up to 12 years total with archive ​learn.microsoft.com ​learn.microsoft.com. For example, you could set 180 days interactive, 730 days total for most tables. This means data older than 180 days goes into the archive tier (still queryable via Search Jobs or by restoring for a limited time)​ learn.microsoft.com.
  • Long-term Archive: Data beyond the interactive retention remains in the workspace archive until the total retention period expires ​learn.microsoft.com. You can search archived logs using asynchronous search jobs when needed. This archive within Log Analytics is immutable to users (they cannot alter past log records), and coupled with Azure’s platform integrity, it’s suitable for long-term evidence storage.
  • Immutable Storage Backup: In addition to workspace retention, consider enabling Log Analytics continuous export to an Azure Storage account for an extra immutable copy. Azure Monitor can automatically export each log entry at ingestion time to a storage account or Event Hub​ learn.microsoft.com. By sending this to an immutable blob container (with a policy to retain data for 2 years), you create a write-once archive of all Sentinel-ingested logs outside the workspace. This provides a legally verifiable backup (even if someone had high privileges in Sentinel, they cannot retroactively alter the exported copy). The export is configured per table via Azure Monitor’s Diagnostics Settings or Data Export feature ​learn.microsoft.com.
• Linking Logs in Sentinel: With Azure AD, M365, and Intune data in Sentinel, you can create workbooks and queries to link user activity across sources. For example, a Sentinel workbook could show an Insider Risk alert alongside the user’s recent Azure AD logins (with IP and device info) and their recent file activity from audit logs. This comprehensive view helps prove “user X (verified via MFA on device Y at IP Z) accessed sensitive file Q and attempted to exfiltrate it,” all backed by logs stored for two years. Sentinel’s User Entity Behavior Analytics (UEBA) feature can also automatically map logs to user accounts, enriching incidents with a profile of the user’s activities.

2. Exporting and Preserving Logs in a Secure, Verifiable Way

In addition to in-place retention, export critical logs and case data to secure storage to meet legal hold requirements. This provides an extra layer of insurance (and portability) for your evidence. Key steps:

1. Export Purview Audit Logs to CSV: The Purview Compliance portal allows exporting audit log search results. Go to Audit > run a search for the relevant timeframe and activities > click Export to download the results as a CSV file​ learn.microsoft.com. (Up to 50,000 records per CSV export; use date filters to segment larger ranges)​ learn.microsoft.com. This CSV contains detailed JSON data for each event, including user, timestamp, activity, item accessed, IP, etc. Keep these raw exports as they represent the original log records ​learn.microsoft.com.
2. Export Sentinel Logs (if needed): If certain log data only lives in Sentinel (e.g. Azure AD sign-in logs beyond 30 days, or correlation results), you can export query results from Sentinel as CSV as well. Use the Log Analytics query interface to retrieve the data, then use the Export option or PowerShell/CLI to save results. (Alternatively, schedule a Logic App to periodically export specific tables to storage.)
3. Preserve Insider Risk Case Evidence: In the Purview Insider Risk Management module:
   • Export Alerts and User List: On the Alerts tab or Users tab of IRM, you can select entries and export them (up to 1000 items) to CSV ​learn.microsoft.com. This gives you a list of all alerts (with timestamps, severity, etc.) or users involved in a case.
   • Screenshots and Attachments: If your case includes any uploaded files, notes, or (via eDiscovery) collected content, download those items. For forensic evidence clips (screen recordings), use the Forensic Evidence section to download each clip within 120 days. The Purview portal provides a download link for each captured evidence clip – save the video file to your secure storage. (The IRM forensic log dashboard will show which events had evidence captured.)
   • Case Report: While there isn’t a one-click “export case” function for IRM, you can document the case by saving the Case timeline (perhaps screenshot or PDF print of the timeline showing all activities investigated). Also consider writing a summary report that references the key evidence (log IDs, file names, etc.) and store this report alongside the data. This will be useful in court to explain the evidence.
4. Use Immutable Storage for Exports: Simply exporting to CSV or downloading files is not enough – store them in an immutable, timestamped manner:
   • Azure Blob Storage (WORM): Create a dedicated Azure Storage container for “Forensic Archives.” Enable a time-based retention policy (e.g., 2 years) on this container ​learn.microsoft.com before uploading files. When you upload your CSV logs and case evidence files, they will be write-once; Azure will lock them against deletion or modification for the retention period. This ensures the files you exported cannot be tampered with.
   • Hash and Timestamp: For each exported file (CSV or evidence), compute a cryptographic hash (SHA-256 recommended). You can do this with PowerShell (Get-FileHash) or other tools. Record the hash value in a separate file or a log (even an email to yourself) along with the date and time. This provides an independent verification of integrity – if needed, you can later prove the file hasn’t changed by recomputing the hash and matching it.
   • Store Hashes Securely: Consider storing the hash values in an immutable format as well (for example, in the metadata of the blob, or in a small text file that is also stored in the immutable container). Azure Blob immutability can also lock the blob metadata, so you could tag each blob with its hash or a signature.
   • Multiple Copies: For extra safety, you might keep two immutable copies – e.g., one in Azure and one offline. You could burn the CSVs and evidence to write-once media (like a DVD or a hardware WORM drive) and store it securely offline. Or use a second storage account in a different region with its own immutability policy.
5. Time Stamping: The moment of upload to Azure Blob is logged by Azure (the blob’s properties will show a creation time). Since the container is immutable, even that timestamp can serve as evidence of when the data was finalized. For legal purposes, having an audit log of the preservation action is useful. Keep a record (in an investigator’s log or ticketing system) of the steps you took to collect and preserve the data, including dates and who performed it.

By following these steps, any extracted logs and case files are secured in a verifiable manner. Later, if an investigation goes to court, you can present the original CSV logs (with their hashes and timestamps) from immutable storage, which is much more defensible than screenshots or printouts alone. The combination of the cloud-retained logs (with audit trails of retention policies) and your exported, hashed copies provides strong evidence of authenticity.

3. Preserving Insider Risk Management Case Data

Insider Risk Management (IRM) cases contain aggregated information about user activities, risk insights, and any collected evidence. To ensure none of this is lost:

• Keep the Case Active (if possible): As noted, an Active case will not expire ​learn.microsoft.com. If your investigation and legal process are ongoing, you may choose to leave the IRM case in an active state for an extended period. (There is no auto-deletion for active cases.) Be mindful that there’s a limit of 100 active cases ​learn.microsoft.com, but with 15 users this likely isn’t an issue. You can use the active case as a living repository while working with legal teams.
• Export and Document Before Resolution: Eventually, you may need to resolve/close the case (for example, after an employee is terminated or the incident is concluded). Before marking the case as resolved, export all necessary information:
  • Export the list of associated alerts (so you have records of all alerts linked to the case)​ learn.microsoft.com.
  • Export the User activity timeline if possible (currently, there’s no direct export for the timeline, but you can use the Audit log and Activity explorer to get the underlying events).
  • Download any forensic evidence files as discussed in section 2.
  • If the case integrated with eDiscovery (Premium) for deeper investigation (IRM allows escalating a case to eDiscovery ​learn.microsoft.com), ensure any eDiscovery results (like emails or documents put on legal hold) are exported through the eDiscovery toolset (which provides its own export options with auditing).
• Default Retention Periods: Be aware of default retention:
  • Once a case is Resolved, the case and its alerts/activities will be deleted after 120 days​ learn.microsoft.com. Mark your calendar from the resolution date and ensure all data is archived by then.
  • User Activity Reports generated in IRM (if you use the “Analytics” or reports section) also expire after 120 days ​learn.microsoft.com. Export any PDF or CSV reports you generated in the IRM dashboard.
  • The Unified Audit Log events that IRM surfaces (like “File copied to USB” or “Sensitivity label removed”) will still exist in the audit log for 1 year by default, but after that they would vanish unless you’ve extended audit retention or archived them. So the IRM case might show an event happened, but if a year has passed, clicking “View activity in audit log” may no longer retrieve it. This is why exporting the audit log (or archiving via Sentinel) is crucial.
• Insider Risk Analyst Logs: All actions taken in the compliance center (like who resolved a case, who viewed an alert) are themselves audited. These records (in the Audit log) can show chain-of-custody of the case handling. With E5, those audit logs are kept for 1 year ​learn.microsoft.com. If needed for longer, export those as well.
• Escalation to Microsoft Purview eDiscovery: If the insider incident involves legal proceedings, you can escalate the IRM case to an eDiscovery (Premium) case ​learn.microsoft.com. This will allow you to put the user’s content on hold (ensuring emails, Teams chats, SharePoint files, etc., are preserved) and to collect relevant items. The eDiscovery case can serve as a container to hold all evidence from mailboxes, SharePoint, etc., under a legal hold indefinitely. It’s a Microsoft-native way to ensure content evidence remains immutable. Remember though, eDiscovery holds preserve content, not the activity logs – so use in combination with log retention.
• Document the Analysis: Alongside raw data, document your investigation steps. For instance, record that “On 2025-04-01, Security team exported the audit logs and forensic evidence related to case #IR-123 involving User X, and stored them in immutable storage reference ID…”. This kind of documentation, while not a technical configuration, is part of being legal-ready. It shows due diligence in handling evidence.

In summary, do not rely on the Purview portal alone to retain IRM case data long-term. Use the exports and holds available to you. The goal is that even if Microsoft’s internal retention purges the case after 120 days (post-closure) or 1 year (audit logs), you have your own secured copy for the full required period (1–2 years or more).

4. Ingesting Purview Logs into Sentinel for Long-Term Analysis

The user asked if logs from Purview can be re-ingested into Sentinel for longer retention and correlation. The answer is yes, with a few strategies:

• Office 365 Audit Integration: Many Purview-related activities (like Data Loss Prevention alerts, label changes, file access events, etc.) are recorded in the Unified Audit Log, which can be ingested into Sentinel via the Office 365 data connector. In Sentinel’s Data Connectors gallery, enable Office 365 (for SharePoint, Exchange, Teams). This will stream audit log events into the OfficeActivity table in Log Analytics. As noted, these audit logs are free to ingest​ learn.microsoft.com. Once in Sentinel, they’ll be subject to the 6-month/2-year retention you configured, rather than Purview’s 1-year limit. This effectively “re-hosts” the Purview logs in a platform where you control retention.
• Microsoft Purview Solution for Sentinel: Microsoft has a Sentinel solution for Purview (for example, for data classification and sensitivity label logs) ​learn.microsoft.com ​learn.microsoft.com. If your interest is in compliance scans (like which files are labeled sensitive), you can configure Purview’s diagnostic settings to send Data Classification or Data Discovery logs to Sentinel ​learn.microsoft.com. This might be slightly tangential to the IRM case, but it’s useful if you also want to monitor Purview scanning results in Sentinel.
• Custom Log Ingestion: If you have historical Purview exports (like the CSV files of audit events from February that you mentioned), and you want them inside Sentinel for querying, you can import them using Azure Log Analytics custom log ingestion. This involves converting the CSV to the required format (typically JSON) and using the Log Analytics Data Collector API or an Azure Logic App to send the data to a custom table. While feasible, this can be effort-intensive. An easier approach is often to keep those CSVs archived externally (immutable) and only ingest if you need to analyze them with KQL. Given the small tenant size, you might not need to re-ingest old logs if you can manually analyze the CSVs or import into Excel when needed. Going forward, rely on the continuous ingestion via connectors so you won’t have gaps.
• Insider Risk Management Alerts in Sentinel: As mentioned, the Insider Risk Management connector will send IRM alerts to Sentinel ​learn.microsoft.com. This is useful to correlate an insider incident with other security incidents. For example, if an insider risk alert fires for data exfiltration, Sentinel can correlate it with any unusual sign-in locations or Defender alerts on that endpoint. The connector does not send the full IRM case or user activity timeline to Sentinel – it’s primarily the alert meta-data. However, by having the audit logs ingested, you essentially have the raw events in Sentinel that correspond to the IRM case activities. You could reconstruct much of the case timeline by querying the OfficeActivity logs for that user/timeframe (file activities, etc.), along with Azure AD logs for that user’s logins, etc.
• Intune Logs in Sentinel: If you sent Intune logs to Log Analytics, you can analyze device compliance or enrollment issues in Sentinel as well. For instance, if an insider used an unmanaged device, an Intune Operational log would show a failed compliance check, and the Azure AD sign-in log would show “Device not compliant.” Bringing these together in Sentinel via queries or an incident playbook can strengthen your evidence.

Conclusion for re-ingestion: You should integrate Purview logs with Sentinel to avoid future loss. While past screenshots and CSVs can remain as offline evidence, configuring the connectors and diagnostic pipelines ensures going forward you won’t lose any Purview audit data (or at least it will live in Sentinel/Log Analytics beyond 30 days or 1 year). There’s no button to retroactively feed a CSV back into Purview or Sentinel’s regular logs, but having them stored immutably (and possibly in a custom log table if truly needed) is sufficient.

5. Automated Policies for Future Incidents and Long-Term Readiness

To avoid any manual scramble in the future, implement automation and policies now that will consistently preserve relevant logs and link data to users. Here’s a checklist of steps and best practices:

5.1 Enable and Configure Log Retention Pipelines

• Azure AD -> Log Analytics & Storage: As covered, set up diagnostic settings for Entra ID logs (Audit and Sign-In). This should be a one-time setup that continuously streams logs. All sign-in attempts, role changes, etc., will automatically flow to your Log Analytics workspace (searchable for 6+ months) and to your archive storage (held for 2+ years). Verify this by checking that new sign-in entries appear in the Log Analytics SigninLogs table and that blobs are created in the storage account container for each day’s logs.
• M365 Audit -> Sentinel: Connect Office 365 audit logs to Sentinel (or at least to Log Analytics). This is done by enabling the Office 365 connector (which uses the Office 365 Management API behind the scenes to pull events). Once enabled, it’s automatic. You can create an Analytics Rule in Sentinel to alert you if this connector ever fails or lags (in case of API issues), to ensure continuity.
• Intune -> Log Analytics/Storage: Configure Intune Diagnostics Settings as described in section 1.2. You might choose to send Intune logs to the same Log Analytics workspace (creating tables like IntuneAuditLogs etc.). Set their retention similar to other logs. Also send to the immutable storage if possible, for consistency. Intune audit logs by default are kept for 30 days in the portal (and some only 7 days for certain logs), so this capture is important for any device-related forensics.
• Sentinel Incident Playbooks: In Sentinel, you can set up a Playbook (Logic App) that triggers on incident creation. For example, when a high-severity incident or an Insider Risk alert arrives in Sentinel, a playbook could automatically gather context: it could fetch the user’s last login details via Microsoft Graph, pull the device info, and compile a little report or even dump related logs to a secure location. This is an advanced step and optional, but it demonstrates the automation possible. At minimum, you could have a playbook that flags certain incidents and reminds the admin to preserve data.
• User Identification Policies: Maintain Conditional Access policies that enforce MFA and compliant devices for sensitive apps and data. This not only enhances security but ensures the logs have the data you need (MFA, device ID). If a user somehow bypassed these (e.g., legacy protocols), those events might not have device info – so consider disabling or tightly controlling legacy auth. Also, ensure IP logging isn’t anonymized – in some compliance settings, SharePoint/OneDrive audit logs can anonymize user info for privacy. Given you need forensic detail, confirm that you are not using any privacy feature that would redact IP or user details in logs.

5.2 Ensure Cross-Linking of Logs to Identities

The goal is that for any security event, you can trace the “who, what, when, where, how” with high confidence:

• Who: The user’s identity (username, GUID) should be present in logs. By consolidating logs in Sentinel/Log Analytics, you can query by UserID across Azure AD and Office 365 logs easily. Use Azure AD’s ** user principal name** or object ID as a key.
• What: The action (file accessed, email sent, setting changed) is recorded in audit logs (with details in AuditData JSON as seen in the CSV export).
• When: Every log has a timestamp (usually UTC). Ensure time sources are consistent; Azure uses UTC by default. If needed, timestamp your exported files as well.
• Where (IP and Device): Azure AD sign-in logs give IP addresses and often the geolocation (approximate country/region) of the IP. They also include Device information for managed devices. Intune logs can give the device name, OS, compliance state. Having both means you can assert, for example, the IP was the employee’s home ISP and the device was their corporate laptop (by serial number from Intune inventory).
• How (Authentication): Logs show authentication method (MFA detail, token auth, etc.). Retain Azure AD MFA logs (Azure AD sign-in logs have a field for Authentication Details which shows if MFA was applied and which method, e.g., phone call, app code). If there are any failures or risky attempts, those are captured in Identity Protection logs (if enabled).

By proactively collecting all this, you won’t need to scramble when an incident occurs. It will be routine that all logs are being collected and retained according to policy.

5.3 Long-Term Archiving and Rotation

• Archive Policy: Decide how long you will keep data in archive and when to purge. The question mentions at least 2 years. You might choose to actually keep 3 or 5 years if storage allows, for extra cushion (some industries require up to 7). Azure Log Analytics can go up to 12 years, and Azure Blob can be set likewise. Just ensure you stay compliant with any data retention laws (don’t over-retain personal data without cause). Microsoft’s 10-year audit retention is available if you want to keep certain audit logs within Microsoft 365 for that long ​answers.microsoft.com – but since you have external archives, that may not be necessary.
• Verify Immutability Regularly: Have a process (maybe annual or per-incident) to test that your backups are indeed read-only. For example, try deleting a test blob in the immutable container to ensure the policy prevents it, and document that test.
• Logging of Exports: If you do regular exports (say monthly backups of certain logs), automate and script them. Use Azure Automation or a Logic App to perform the export, save to blob, and maybe email a summary to administrators. This creates a consistent trail.
• Monitor Log Pipeline Health: Set up Azure Monitor alerts for things like: if the diagnostic pipeline from Azure AD to Log Analytics fails (e.g., if the Log Analytics workspace is accidentally deleted or permission revoked), or if Sentinel connectors have an error. This way you can fix issues before data is lost. Also monitor Sentinel’s data volume to catch any unexpected drop that might indicate a source is not logging.

5.4 Incident Response Workflow

When a new incident arises (insider incident or otherwise), your policy should be:

1. Immediately preserve relevant data – with the above automation, most should already be preserved. But if there are ad-hoc sources (like a user’s local PST file or a third-party app log), grab those and put them in the secure storage.
2. Use Links between logs – e.g., take the suspicious file name from a Purview alert and search the Sentinel logs to see every time that file was accessed or sent via email by any user. Because you retained the logs, you can do this even for six-month-old events.
3. Track user identity – use the sign-in log to confirm it was the employee’s own account (and not someone using their credentials) by checking MFA and device. This ties the actions to the individual, which is crucial for non-repudiation in legal cases.

By enforcing these policies, future incidents will have a clear forensic data trail that is automatically preserved and easy to query. All logs being linked to users with MFA and device info provides a compelling story that the activity was indeed performed by that user on a known device.

6. Cost and Licensing Considerations for Extended Retention

Maintaining 6+ months of interactive logs and 2+ years of archives for a 15-user tenant is very achievable with minimal cost, especially using E5 capabilities and Azure’s pay-as-you-go model:

• Microsoft Purview/Compliance: Since you have Microsoft 365 E5, you already have Advanced Audit (1-year audit retention) at no extra cost. If you determined you need 10-year retention in M365 itself, that would require a 10-Year Audit Log Retention add-on license for each user or per organisation ​answers.microsoft.com – likely not necessary here given the small tenant and the alternative Azure storage solution.
• Azure Log Analytics and Sentinel Costs:
  • Data Ingestion: Azure Log Analytics (and Sentinel) charge per GB of data ingested. Rates are roughly on the order of $2.30 per GB for Log Analytics and an additional $2.30 per GB for Sentinel analytics (so about ~$4.6 per GB total in pay-as-you-go) – but remember many M365 sources are free. In a small 15-user environment, the volume of logs is low. For example, 500,000 sign-in log entries is about 1 GB of data​ tminus365.com, and your 15 users will generate far less than that in a year. Typical log generation for 15 users might be a few MB per day. Even with security solutions, assume (generously) 1 GB per month of various logs – that’s ~$5 of ingestion cost per month. In reality, “for small or midsize businesses, log volumes are often low enough that costs remain negligible—sometimes only a few cents to a few dollars per month” ​tminus365.com.
  • Retention: Azure includes the first 90 days of retention for free (with Sentinel) for Analytics logs​ azure.microsoft.com. Beyond 90 days, retaining data in Log Analytics costs about $0.10 per GB per month​ trstringer.com. This is a very low rate. For instance, if you retained 10 GB of data for an extra year, that’s $0.10 x 10 x 12 = $12 for the year. Our example of 1 GB per month ingest (~12 GB a year) would cost on the order of $1.2 per month to keep in archive after the free period.
    • Archive searches in Log Analytics (search jobs) incur a minor charge when scanning data, but for occasional use this is minimal.
  • Azure Storage: Storing log files in Blob storage is even cheaper: roughly $0.02 per GB per month (if using cool or archive tier, it can be <$0.01/GB). Even the more expensive immutable storage (hot tier with redundancy) might be $0.05/GB-month. For example, 50 GB of logs (a huge over-estimate for 2 years of 15 users’ audit logs) might cost $2.50 per month. Azure Storage also charges for operations (API calls, etc.), but for nightly appends it’s negligible. Thus, cost is no barrier to keeping these archives.
  • Sentinel Licensing: Sentinel itself doesn’t require a per-user license; it’s all consumption-based. You already benefit from free ingestion of Microsoft 365 audit logs ​learn.microsoft.com and various security alerts. Azure AD logs are not free, but as noted, those volumes are small (each sign-in record is a few kilobytes). Also, Defender alerts (if you use Microsoft Defender for Endpoint, etc.) are free to ingest as alerts ​learn.microsoft.com – only raw telemetry would cost, but you can decide if you need raw data beyond what audit logs capture.
• Forensic Evidence Add-on: One potential E5 cost area is the Insider Risk Management Forensic Evidence add-on (if you plan to use that feature extensively). You mentioned screenshots from Purview – it’s possible you used the 20 GB trial or a small purchase of that add-on. The forensic evidence feature is licensed by capacity (100 GB/month units) ​learn.microsoft.com. For 15 users, you likely do not need more than the trial or a single unit if you ever formally enable it. Remember to export any collected evidence because it’s purged after 120 days​ learn.microsoft.com regardless. If you don’t plan to capture screen recordings, you can avoid that add-on entirely (the IRM alerts themselves work without it).
• Cost Optimization: To optimize costs:
  • Set lower interactive retention for high-volume logs: For example, if you for some reason ingested very verbose logs (like detailed PowerShell logs or defender raw signals), you might keep 30 days hot and rest archived, to save on more expensive storage. But in this scenario, most data is user audit logs which aren’t huge anyway.
  • Use Archive tier for blob after a period: You could move older blobs to Azure Blob Archive tier after, say, 1 year. Or use Azure Storage Lifecycle Management rules to automatically delete blobs after 2 years (if you don’t need beyond 2). This would keep storage tidy and costs low.
  • Leverage free quotas: The first 5 GB of log ingestion to Log Analytics per month might be free (Azure often has a free allotment), and the first 31 days retention is free ​trstringer.com (Sentinel extended that to 90 days free ​azure.microsoft.com). With so few users, you might effectively stay under free limits for ingestion most of the time. Always check Azure’s updated pricing, but it’s safe to say the cost here is small relative to an E5 license cost you’re already paying.

Estimated Ballpark: For 15 users, 6 months online + 2 year archive of logs could be on the order of $10–$20 per month in Azure costs as a rough estimate, if that. It could even be less than $5, depending on usage. For example, one IT admin reported that most small tenants see only a few dollars a month in Log Analytics charges​ tminus365.com. The peace of mind of having the data far outweighs this minor cost. We strongly recommend not skimping on log retention given the low cost – losing data (as you experienced with 30-day Sentinel default) can be far more costly later.

7. Fallback Strategies and Low-Cost/Free Alternatives

If for some reason the above “all-in Microsoft” approach faces limitations (technical or budgetary), consider these fallback options to ensure no gaps in your forensic readiness:

• Azure Immutable Blob Only (No Sentinel): In scenarios where you cannot keep data in Sentinel due to cost or policy, you could choose to export logs directly to Azure Storage and not retain much in Log Analytics. For example, you might only keep 30 days in Sentinel for active threat detection (since that’s free) and rely on daily exports to blob for anything beyond 30 days. This was essentially the plan in the Microsoft Q&A you might have seen: keeping minimal data in LA and moving the rest to blob ​learn.microsoft.com. While you lose some query convenience for older data (since you’d have to download from blob to analyze), it’s a valid low-cost strategy. The data in blob is secure and cheap. You can always import specific blob files back into a temp Log Analytics table if you need to run KQL on them later.
• Periodic Offline Backups: In addition to cloud storage, you could implement a process to periodically download and offline-store logs. For instance, once a quarter, export all audit logs for that quarter (via the Office 365 Management API or PowerShell) and store them on an offline medium (external drive, tape, etc.) that is kept securely. This could be a no-cost storage solution (assuming you have hardware), though it is labor-intensive and riskier (media can fail, someone must remember to do it, etc.). It’s generally better to utilize cloud automation instead of manual offline copies, but it’s an extra insurance policy.
• Leverage Free Tools/APIs: Microsoft provides the Office 365 Management Activity API which can be used to pull logs (similar to how Sentinel does). If you did not want to pay for Sentinel at all, you could write a script or use a free community tool to continuously export these logs to a database or storage. Some organizations use PowerShell scripts to daily export Azure AD sign-ins (via MS Graph API) and unified audit logs, then store them in an on-premises SQL database or even in an Excel file. Given your tenant size, even a simple solution like exporting to CSV and checking into a version-controlled repository (like a private Git, which tracks changes) could serve as a pseudo-immutable store. However, these DIY solutions require maintenance and careful security (you wouldn’t want those logs to be accessible or modifiable by just anyone).
• SharePoint/OneDrive with Retention Labels: As a creative alternative, you could store log files in a SharePoint library and apply a retention label set to “Record” (do not delete) for 2 years. With a retention label in Records Management, even administrators cannot easily delete or alter the file until the period expires (the file is retained as a record) ​linkedin.com. This leverages Microsoft 365’s own compliance features to protect the file. While this is a valid approach, it’s not as foolproof as Azure Blob immutability (an admin with Site Collection access and Compliance admin rights could theoretically remove the label if they really tried, whereas Azure blob WORM is much harder to circumvent). Still, it’s a free approach since you already pay for M365 storage. If using this, maintain a separate site or library just for compliance data, locked down to only those who need access (e.g., SecOps and legal).
• Third-Party Archiving Solutions: There are third-party or open-source log archives (like Elastic Stack, etc.) that could ingest M365 logs for free or low cost. Given that you have E5 and Azure, it’s sensible to stick with Microsoft’s ecosystem, but if Azure was not an option, tools like AWS S3 (with Object Lock) could be used similarly for storage, or an on-prem WORM storage device. The key is to have the data in at least one system that is truly append-only.
• Testing the Fallback: Whichever fallback you use, test restoring or reading the data periodically. For instance, try pulling an older log from blob and verifying its hash against your records. Or try retrieving a log file from SharePoint and ensuring the retention lock prevented edits. Regular drills will give confidence that the process works and the data is accessible when needed.

Finally, make sure your organization’s incident response plan references these retention measures. People (not just systems) need to know that “if X incident happens, logs will be available, and here’s how to get them.” Train at least one backup person in maintaining these systems, so the knowledge isn’t siloed.

By implementing the above steps, you will achieve:

• Immutable retention of Microsoft Purview audit logs and Insider Risk case evidence for the required duration (and beyond if needed), using native features like Advanced Audit and Azure immutable storage.
• Secure, verifiable exports of critical logs (with hashing and multi-location storage) to serve as admissible evidence.
• Extended log availability in Microsoft Sentinel/Azure Monitor, so you can interactively query at least 6 months of data and retrieve up to 2 years (or more) on demand, preventing future data loss like the Sentinel 30-day issue you experienced.
• Correlation of identity signals (MFA, device compliance, AAD join status, IP geolocation) with activity logs, painting a full picture of “who did what, when, where, and how” for any incident.
• Automated enforcement of retention via policies and connectors, reducing reliance on remembering to manually collect evidence.
• Cost-effective compliance – leveraging licenses you already have (E5) and Azure services that cost only a few dollars a month – which is a small price for maintaining legal-grade evidence.

References

• Microsoft Purview Audit Log Retention and Advanced Audit ​learn.microsoft.com ​answers.microsoft.com
• Insider Risk Management data retention defaults​ learn.microsoft.com
• IRM Forensic Evidence retention and export guidance ​learn.microsoft.com
• Azure AD (Entra ID) log export to Log Analytics and retention setup ​tminus365.com ​tminus365.com
• Azure Log Analytics retention capabilities (interactive vs long-term) ​learn.microsoft.com
• Microsoft Sentinel free data types and retention costs​ learn.microsoft.com​ trstringer.com
• Small-tenant log volume and cost estimate ​tminus365.com