Tag: Security Data Retention

Implement data retention in Microsoft Sentinel data stores (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Manage and monitor security posture (20–25%)
   --> Implement activity and event collection in Microsoft Sentinel
      --> Implement data retention in Microsoft Sentinel data stores


Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Introduction

Microsoft Sentinel collects large volumes of security data from cloud services, applications, operating systems, network devices, identity systems, and security products. Not all of that data needs to remain immediately available for real-time investigation.

For example:

  • Authentication logs may be needed for active threat hunting.
  • Firewall logs may need to be retained for compliance and historical investigations.
  • Detailed diagnostic logs may have limited day-to-day value but significant forensic value.
  • Regulatory requirements may require security records to be retained for several years.

Data retention in Microsoft Sentinel provides a way to balance these requirements against storage and query costs.

For the SC-500 exam, it is important to understand the difference between:

  • Analytics retention
  • Total retention
  • Analytics tier
  • Data Lake tier
  • Basic Logs
  • Auxiliary tables
  • Querying older data
  • Table-level retention configuration
  • The relationship between retention, cost, and Microsoft Sentinel functionality

Microsoft’s current architecture allows security data to remain in the Analytics tier for active security operations and then be retained longer in the Data Lake tier for lower-cost historical storage.


1. Why Data Retention Matters

Security organizations frequently face a fundamental trade-off:

How long should security data be retained, and how quickly does that data need to be accessible?

Keeping every log in the highest-performance storage tier indefinitely can be expensive.

Conversely, deleting historical data too quickly can create problems for:

  • Incident investigations
  • Threat hunting
  • Forensic analysis
  • Regulatory compliance
  • Internal audits
  • Legal investigations
  • Historical security analysis
  • Detection of long-running attacks

A good retention strategy therefore classifies data according to its value.

For example:

Data typeTypical requirementAppropriate strategy
Sign-in/security eventsActive threat huntingAnalytics tier
High-value security alertsReal-time detectionAnalytics tier
Verbose firewall logsHistorical analysisData Lake/long-term retention
Compliance recordsMulti-year retentionData Lake
Low-value diagnostic dataOccasional investigationLower-cost retention tier
Frequently queried security dataFast investigationAnalytics tier

The goal is not simply to maximize retention.

The goal is to retain the right data for the right amount of time at the appropriate cost and accessibility level.


2. Understanding the Analytics Tier

The Analytics tier is the high-performance tier used for active security operations.

Data in the Analytics tier supports capabilities such as:

  • Real-time analytics
  • Analytics rules
  • Alerting
  • Threat hunting
  • Workbooks
  • Microsoft Sentinel investigations
  • High-performance KQL queries
  • Other Microsoft Sentinel features

Microsoft currently describes Analytics retention as the period during which data is maintained in the high-performance state for real-time analytics.

For Microsoft Sentinel, the standard retention period has historically been associated with 90 days, although current table-level settings and integrations can have different defaults and retention behavior. The important exam concept is that Analytics retention is configurable independently of longer-term retention.

Analytics retention can be extended to as much as two years for supported Analytics tables.

Example

Suppose an organization retains:

  • 90 days of Analytics data
  • 2 years of total retention

The most recent 90 days are optimized for active security operations.

Older data remains available as long-term retained data rather than consuming the same high-performance Analytics capacity.


3. Understanding Total Retention

One of the most important concepts for the SC-500 exam is the distinction between Analytics retention and total retention.

Analytics retention

Determines how long data remains in the high-performance Analytics state.

Total retention

Determines how long the data remains retained overall.

For example:

Analytics retention = 90 days
Total retention = 2 years

The data is actively available in the Analytics tier for 90 days. After that, it can remain retained in the lower-cost long-term/Data Lake state for the remainder of the two-year retention period.

Microsoft currently supports total retention of up to 12 years for applicable table configurations.

This distinction is extremely important.

Think of it this way

Analytics retention answers:

“How long do I want this data optimized for active security operations?”

Total retention answers:

“How long do I want to keep this data before it is ultimately removed?”


4. Analytics Tier vs. Data Lake Tier

Microsoft Sentinel’s current retention architecture provides two primary tiers:

  1. Analytics tier
  2. Data Lake tier
CharacteristicAnalytics tierData Lake tier
Primary purposeActive security operationsLong-term retention
PerformanceHighLower/cost optimized
Real-time analyticsYesLimited
Threat huntingFully supportedMore limited
Analytics rulesSupportedNot fully supported
WorkbooksSupportedLimited
Long-term compliance storagePossibleExcellent use case
CostHigherLower
Maximum retentionUp to 2 years for Analytics retentionUp to 12 years total retention
Best useFrequently accessed dataHistorical/low-touch data

The Data Lake tier is intended for lower-cost long-term storage and is particularly useful for:

  • Compliance
  • Historical investigations
  • Forensics
  • Long-term trend analysis
  • Data that is rarely accessed

5. What Happens When Analytics Retention Expires?

Consider the following configuration:

Analytics retention: 90 days
Total retention: 2 years

The data does not disappear after 90 days.

Instead, data can move out of the high-performance Analytics retention period while remaining available for the remainder of its total retention period.

Conceptually:

Day 0
|
|---- Analytics tier --------------------|
| 90 days |
|
|---- Data Lake / long-term retention ------------------------|
| Remaining retention |
|
|-------------------------------------------------------------|
2 years

This architecture allows organizations to avoid keeping infrequently accessed historical data in the most expensive/high-performance state.

Microsoft documents this as the distinction between Analytics retention and total retention.


6. Example: One-Year Security Retention Strategy

Imagine a company has the following requirement:

Security logs must be retained for one year, but analysts primarily investigate incidents from the most recent 90 days.

The organization could configure:

  • Analytics retention = 90 days
  • Total retention = 365 days

The result is:

0–90 days
High-performance Analytics data
91–365 days
Long-term retained data
After 365 days
Data expires

This can be considerably more economical than maintaining a full year of data in the highest-performance tier.


7. Table-Level Retention

Retention is increasingly managed at the table level.

Different tables can have different retention requirements.

For example:

TableSecurity valueExample retention strategy
SigninLogsHighLonger Analytics retention
SecurityEventHighAnalytics + long-term retention
Firewall logsMediumShorter Analytics + longer Data Lake
Verbose diagnosticsLow/mediumData Lake
Compliance logsHistoricalLong-term retention

This allows security teams to avoid applying a single retention policy indiscriminately to every data source.

The Microsoft Defender portal provides centralized table-level configuration for supported Microsoft Sentinel and Microsoft Defender XDR tables.


8. Changing Retention Settings

When retention settings are changed, administrators need to understand the consequences.

Increasing total retention

When total retention is increased, data that has not yet expired can benefit from the new retention period.

Decreasing total retention

Microsoft provides a safety period when total retention is shortened. Current documentation states that Microsoft waits 30 days before removing the affected data, allowing administrators an opportunity to reverse an accidental configuration change.

Changing Analytics retention

Changes to Analytics retention affect how long existing data remains in the Analytics state.

For example:

Original:
Analytics = 180 days
Total = 180 days
New:
Analytics = 90 days
Total = 180 days

The result is effectively:

0–90 days Analytics
91–180 days Data Lake/long-term retention

The data has not necessarily been deleted; it has simply moved beyond the high-performance Analytics period.


9. Data Lake Retention

The Microsoft Sentinel Data Lake provides a lower-cost location for retaining large volumes of security information for extended periods.

Data can be retained in the Data Lake for as long as 12 years, depending on the table and configuration.

Typical use cases include:

  • Regulatory compliance
  • Long-term forensic investigations
  • Historical threat analysis
  • Security trend analysis
  • Low-touch security telemetry
  • Large volumes of security data that do not need constant real-time access

The Data Lake is therefore particularly useful when an organization has a requirement such as:

“Retain security logs for seven years, but we don’t need all seven years available for real-time detection.”


10. Data Lake Does Not Provide Identical Functionality to Analytics

This is an important exam distinction.

Moving data from Analytics to the Data Lake is not simply a storage optimization with no functional consequences.

Some Microsoft Sentinel functionality depends on data being available in the Analytics tier.

For example, the Data Lake has limitations around features such as:

  • Certain analytics rules
  • Some hunting capabilities
  • Watchlists
  • Workbooks
  • Playbooks
  • Other real-time security operations

Therefore:

Do not automatically move every table to the Data Lake just because it costs less.

Determine whether the table is required for active detections and investigations.


11. Promoting Historical Data Back to Analytics

Historical data does not necessarily become useless simply because it is no longer in the Analytics tier.

Microsoft Sentinel can promote appropriate data back into an Analytics context when deeper interactive investigation is required.

For example:

A security team discovers that a compromised account may have been active nine months ago.

The relevant historical data might be retained in the Data Lake.

Instead of maintaining nine months of all data in Analytics solely for this possibility, the organization can retain the historical data more economically and retrieve/promote relevant information when needed.

This is one of the important architectural advantages of separating active analytics from long-term storage.


12. Basic Logs and Auxiliary Tables

SC-500 candidates should also understand that not all tables use exactly the same retention model.

Azure Monitor Logs supports different table plans, including:

  • Analytics
  • Basic
  • Auxiliary

Analytics tables

Designed for active querying and broad Azure Monitor/Microsoft Sentinel functionality.

Interactive retention can be configured for supported Analytics tables, with longer-term retention available separately.

Basic tables

Designed for lower-cost logging scenarios such as troubleshooting and incident response.

Basic tables have a fixed 30-day interactive query period under the current model.

Auxiliary tables

Designed for low-touch data such as verbose logs and auditing/compliance data.

Auxiliary tables are intended for lower-cost retention where data does not require the same interactive capabilities as Analytics data.

Exam Tip

Do not assume:

“Every table in Microsoft Sentinel behaves exactly like an Analytics table.”

Table plan matters.


13. Choosing the Appropriate Retention Strategy

A useful decision process is:

Step 1 — Determine the business requirement

Ask:

  • How long must the data be retained?
  • Is there a regulatory requirement?
  • How frequently will analysts query it?
  • Does it support active detections?

Step 2 — Determine operational requirements

Ask:

  • Is the table used by an analytics rule?
  • Is it used for threat hunting?
  • Is it needed for real-time investigations?
  • Is it used by workbooks or other Sentinel capabilities?

Step 3 — Determine the appropriate tier

Use:

Analytics

when data needs frequent, high-performance access.

Use:

Data Lake/long-term retention

when data primarily needs to be preserved for historical, forensic, or compliance purposes.

Step 4 — Determine retention duration

Configure:

  • Analytics retention
  • Total retention

based on the actual business and security requirements.

Step 5 — Monitor cost and usage

High-volume tables can produce significant storage and ingestion costs.

Table insights can help administrators examine factors such as:

  • Average daily ingestion
  • Estimated daily ingestion cost
  • Table tier
  • Retention
  • Ingestion fluctuations

14. Example: Designing Retention for Firewall Logs

Suppose an organization receives:

500 GB/day of firewall telemetry.

Security analysts typically need only the most recent 30 days for active investigations.

However, corporate policy requires seven years of retention.

Keeping seven years of firewall logs in the highest-performance Analytics tier would be unnecessarily expensive.

A better architecture could be:

Firewall logs
|
v
+-----------------------+
| Analytics Tier |
| 30 days |
| Active investigations |
+-----------------------+
|
v
+-----------------------+
| Data Lake |
| Long-term retention |
| Up to 7 years |
| Compliance/forensics |
+-----------------------+

This architecture satisfies the retention requirement while limiting the amount of data that must remain optimized for active querying.


15. Retention and Cost

Retention has a direct relationship with cost.

The cost model depends on factors such as:

  • Data ingestion volume
  • Table plan
  • Analytics retention
  • Long-term retention
  • Data Lake usage
  • Queries against lower-cost tiers

Microsoft notes that retention beyond included periods can incur additional charges and that Data Lake retention provides a lower-cost option for long-term security data.

Therefore, retention policies should be designed around security value, rather than simply maximizing the amount of data retained.


16. Retention vs. Backup

A common exam trap is confusing retention with backup.

Retention

Answers:

“How long should security log data remain available?”

Backup

Answers:

“How can I recover protected data after deletion, corruption, or another failure?”

Microsoft Sentinel retention is primarily concerned with preserving security telemetry for investigation, detection, compliance, and historical analysis.

It is not a replacement for a backup strategy.


17. Retention vs. Archiving

Older Microsoft Sentinel and Log Analytics terminology frequently referred to archive or archived logs.

The current architecture emphasizes the Data Lake tier and long-term retention.

For exam preparation, understand the underlying concept:

Data can move from high-performance, actively queried storage into lower-cost long-term storage while remaining retained.

If you encounter older documentation or training material using “archive,” understand that it refers to the long-term storage concept rather than assuming it represents the exact current Microsoft Sentinel terminology.


18. Important Data Lake Compliance Consideration

Data retention policies should also consider privacy and data deletion requirements.

One important current consideration is that data stored in the Microsoft Sentinel Data Lake has different deletion behavior from Analytics data.

Microsoft documents that the purge capability used for GDPR-related deletion in the Analytics tier does not affect data in the Sentinel Data Lake, and individual records cannot currently be purged from the Data Lake.

This means organizations should carefully consider:

  • Data residency
  • Privacy requirements
  • Regulatory requirements
  • Retention requirements
  • Data deletion requirements

before designing a long-term Data Lake retention strategy.


19. Managing Retention in the Microsoft Defender Portal

Microsoft’s current management experience provides table-level retention and tier configuration through the Microsoft Defender portal for supported tables.

Administrators can review and configure:

  • Table tier
  • Analytics retention
  • Total retention
  • Data Lake settings

The exact controls available depend on the table type. Some tables have restrictions because Microsoft security services require them to remain available for security operations.

Basic Logs tables, for example, can be viewed from the Defender portal but currently have some management capabilities that remain in the Log Analytics workspace experience.


20. Common Mistakes

Mistake 1: Treating Analytics retention as total retention

A 90-day Analytics period does not necessarily mean the data is deleted after 90 days.

Remember:

Analytics retention ≠ total retention.


Mistake 2: Assuming Data Lake is identical to Analytics

Data Lake is designed for cost-effective, long-term storage and does not provide the complete real-time security feature set of Analytics.


Mistake 3: Moving detection data out of Analytics without checking dependencies

If an analytics rule depends on a table, moving that data exclusively into a lower-cost tier can interfere with the security capabilities that depend on Analytics data.


Mistake 4: Retaining everything for the maximum period

Maximum retention is not automatically the best security strategy.

Consider:

  • Cost
  • Regulatory requirements
  • Security value
  • Query frequency
  • Detection dependencies

Mistake 5: Assuming all tables have identical retention capabilities

Table plans and table types matter.

Analytics, Basic, Auxiliary, Sentinel, custom, and XDR tables can have different retention and management characteristics.


Mistake 6: Confusing retention with backup

Keeping security logs for seven years does not mean the organization has a seven-year backup strategy.


21. Best Practices

1. Classify data by security value

Not every log deserves the same retention period or storage tier.

2. Keep active detection data in Analytics

If a table is important for real-time detections and hunting, make sure it remains available in the appropriate Analytics tier.

3. Use Data Lake for long-term, low-touch data

Use the Data Lake for compliance, historical analysis, and forensic data that does not require continuous real-time access.

4. Use table-level configuration

Avoid applying the same retention policy to every table.

5. Review retention periodically

Security requirements, regulations, data volumes, and costs change.

6. Monitor ingestion and costs

High-volume tables should be reviewed regularly for their actual security value.

7. Validate dependencies before changing tiers

Before moving or shortening retention for a table, determine whether:

  • Analytics rules
  • Hunting queries
  • Workbooks
  • Playbooks
  • Investigations
  • Other Sentinel capabilities

depend on that data.

8. Consider privacy requirements

Long-term retention should be evaluated against privacy and data deletion requirements, particularly when using the Data Lake.


22. SC-500 Exam Tips

For the exam, remember these distinctions:

ConceptRemember
Analytics tierHigh-performance security operations
Data Lake tierLower-cost long-term retention
Analytics retentionHow long data remains in the Analytics state
Total retentionHow long data remains retained overall
Basic LogsLower-cost table plan with 30-day interactive query period
AuxiliaryLow-touch/verbose/audit-oriented data
Up to 2 yearsMaximum Analytics retention for supported tables
Up to 12 yearsMaximum total/long-term retention for applicable configurations
RetentionDetermines how long data is kept
BackupProvides recoverability; different concept
Data LakeExcellent for compliance and historical investigations
AnalyticsRequired for many real-time Sentinel capabilities

A particularly important exam pattern

If the question says:

“The organization must retain logs for seven years but only needs them for active investigations for the first 90 days.”

Think:

Short Analytics retention + longer total/Data Lake retention.

If the question says:

“Security analysts need high-performance querying and real-time detection against the data.”

Think:

Analytics tier.

If the question says:

“The data is primarily retained for compliance and occasional historical investigations.”

Think:

Data Lake/long-term retention.


23. Key Takeaways

The most important concepts to remember are:

  1. Analytics retention controls how long data remains in the high-performance Analytics state.
  2. Total retention controls how long data remains retained overall.
  3. Microsoft Sentinel supports Analytics and Data Lake tiers for different security and cost requirements.
  4. Analytics is optimized for real-time detection, hunting, investigation, and other Sentinel features.
  5. Data Lake is optimized for long-term, lower-cost security data retention.
  6. Applicable Analytics tables can have Analytics retention of up to two years.
  7. Applicable data can have total retention of up to 12 years.
  8. Basic and Auxiliary tables have different retention/query characteristics from Analytics tables.
  9. Retention should be configured based on security value, regulatory requirements, query frequency, and cost.
  10. Do not confuse retention with backup.
  11. Before changing a table’s tier or retention, determine whether Sentinel detections and other security capabilities depend on that data.
  12. Long-term Data Lake retention should also be evaluated against privacy and data deletion requirements.

Practice Exam Questions

Question 1

A security team wants to retain Azure firewall logs for seven years because of a regulatory requirement. Analysts only need the most recent 60 days for routine threat hunting.

Which approach best satisfies the requirements while minimizing the amount of data kept in the high-performance tier?

A. Keep all seven years of data in the Analytics tier.

B. Configure a short Analytics retention period and a seven-year total retention period using long-term/Data Lake retention.

C. Delete the firewall data after 60 days and rely on Azure Activity Logs.

D. Store all firewall data in Basic Logs for seven years and use analytics rules against it.

Answer: B

Explanation: Analytics retention and total retention can be configured to serve different purposes. Keeping the most frequently accessed data in Analytics while retaining older data in the Data Lake provides a better balance between operational access, compliance, and cost.


Question 2

An administrator configures an Analytics table with:

  • Analytics retention: 90 days
  • Total retention: 365 days

What should the administrator expect?

A. All data is permanently deleted after 90 days.

B. Data remains in the Analytics tier for 365 days.

C. Data is copied to a backup service after 90 days.

D. Data can remain retained for 365 days, with the older portion outside the high-performance Analytics retention period.

Answer: D

Explanation: Analytics retention determines the high-performance period, while total retention determines how long the data remains retained overall. The 275 days after the 90-day Analytics period can therefore be retained as long-term data.


Question 3

A SOC requires real-time analytics rules and high-performance threat hunting against a particular table.

Which tier is most appropriate for the actively queried data?

A. Analytics tier

B. Data Lake tier only

C. Auxiliary tier

D. External archival storage

Answer: A

Explanation: The Analytics tier is designed for high-performance querying, analytics rules, threat hunting, alerting, and other active Microsoft Sentinel security operations.


Question 4

An organization wants to retain large volumes of historical security telemetry primarily for compliance and occasional forensic investigations. The data does not need to support continuous real-time analytics.

Which option is most appropriate?

A. Keep all data in the Analytics tier indefinitely.

B. Delete the data after 30 days.

C. Convert all security data to Azure Activity Logs.

D. Use the Data Lake/long-term retention capability.

Answer: D

Explanation: The Data Lake is designed for cost-effective long-term security data retention, including compliance, historical analysis, and forensic investigations.


Question 5

A security administrator reduces a table’s total retention from five years to one year. The administrator immediately realizes that the change was accidental.

What is an important behavior to know about reducing total retention?

A. All data older than one year is immediately destroyed.

B. Microsoft provides a 30-day period before data affected by the shortened retention is removed.

C. The table automatically changes to Basic Logs.

D. The data is automatically exported to Azure Storage.

Answer: B

Explanation: Microsoft currently provides a 30-day safety period when total retention is shortened, allowing an administrator to reverse an accidental configuration change before affected data is removed.


Question 6

A security team is evaluating whether to move a table from Analytics to the Data Lake tier.

Which consideration is most important before making the change?

A. Whether the table name contains _CL

B. Whether the table was created before Microsoft Sentinel was enabled

C. Whether security capabilities such as analytics rules or other real-time functionality depend on the table remaining in Analytics

D. Whether the table contains more than 1 GB of data

Answer: C

Explanation: Moving data out of the Analytics tier can affect functionality that depends on Analytics data. Administrators should identify detection, hunting, workbook, and other security dependencies before changing tiers.


Question 7

An organization wants to keep security data for 10 years but does not need all 10 years available for continuous high-performance queries.

Which statement best describes the appropriate strategy?

A. Keep all 10 years in the Analytics tier.

B. Keep the data for only two years because Analytics retention cannot exceed two years.

C. Use Basic Logs exclusively because Basic Logs automatically provide 10-year retention.

D. Use an appropriate Analytics retention period and longer total/Data Lake retention where supported.

Answer: D

Explanation: Analytics retention and total retention serve different purposes. Applicable data can have total retention of up to 12 years, while Analytics retention can be configured separately, up to two years for supported Analytics tables.


Question 8

Which statement correctly describes the relationship between Analytics retention and total retention?

A. Analytics retention determines how long data remains in the high-performance Analytics state, while total retention determines how long the data is retained overall.

B. Analytics retention is always longer than total retention.

C. Total retention applies only to Azure Activity Logs.

D. Analytics retention and total retention are two names for exactly the same setting.

Answer: A

Explanation: This is one of the most important concepts for the SC-500 exam. Analytics retention describes the active/high-performance retention period, whereas total retention describes the overall retention period.


Question 9

A company stores verbose auditing data that is rarely queried but must be retained for compliance.

Which characteristic best describes the type of storage strategy that should be considered?

A. Keep all data in Analytics because compliance data always requires real-time analytics.

B. Delete the data immediately after an audit.

C. Use a lower-cost long-term retention approach such as the Data Lake or an appropriate low-touch table plan.

D. Convert the audit records into Microsoft Entra authentication events.

Answer: C

Explanation: Verbose, low-touch auditing data is a strong candidate for lower-cost retention. Depending on the table and requirements, Data Lake or an appropriate lower-cost table plan can provide long-term retention without keeping all data in the highest-performance tier.


Question 10

A security engineer needs to retain historical data for privacy-sensitive investigations and is considering using the Microsoft Sentinel Data Lake.

Which consideration is particularly important?

A. Data Lake automatically purges individual records whenever they are purged from the Analytics tier.

B. Data Lake retention is limited to 30 days.

C. Data Lake data cannot be used for any historical investigation.

D. Data Lake has different data deletion behavior, and individual records cannot currently be purged from the Sentinel Data Lake.

Answer: D

Explanation: Microsoft documents that the purge capability for the Analytics tier does not affect data in the Sentinel Data Lake, and individual records cannot currently be purged from the Data Lake. This makes privacy, regulatory, and data-deletion requirements an important consideration when designing long-term retention.


Final Exam Reminder

When you see a retention scenario on the SC-500 exam, first identify how the data will be used, and then distinguish between how long it needs to be highly accessible and how long it must be retained.

A useful mental model is:

                  SECURITY DATA
                       |
          +------------+------------+
          |                         |
   Active / frequently        Historical /
       queried                compliance
          |                         |
          v                         v
   ANALYTICS TIER              DATA LAKE
          |                         |
   Fast queries,              Long-term,
   detections,                lower-cost
   hunting,                   retention
   investigations
          |
          +----------+
                     |
             TOTAL RETENTION
          determines how long
          the data is retained

The key distinction is:

Analytics retention = how long the data is optimized for active security operations.

Total retention = how long the data remains retained overall.

That distinction is central to understanding how Microsoft Sentinel balances security operations, compliance, historical investigation, and cost.


Go to the SC-500 Exam Prep Hub main page