DC Security Log Retention Review: Verify Readable History

What Is a DC Security Log Retention Review?

A dc security log retention review establishes which Security events an investigator can still read from each domain controller, its archives, and the central logging destination. The useful result is a dated evidence record tied to an approved organizational policy. A configured maximum file size, an old event, or a healthy forwarding connection is only part of that record.

Three questions need separate answers: were the required events generated, are they still readable locally, and did the intended central system receive and retain them? Start with the effective audit policy checks for event generation. That guide uses auditpol to examine audit settings; this review addresses readable history, channel behavior, archives, and proof of a central copy.

This procedure covers Active Directory domain controllers and their Windows Security channels. It does not assess Microsoft Entra audit-log retention. The commands below are documentation-based examples for authorized Windows operators; they were not executed against a customer domain for this article. Documentation and collector behavior were reviewed on October 4, 2026.

How Channel Capacity and Retention Mode Work

Microsoft documents three relevant behaviors through wevtutil: with retention disabled, new records overwrite the oldest records when capacity is reached; with retention enabled and auto-backup disabled, existing records remain and incoming records are discarded when full. Auto-backup requires retention enabled and backs up the log when it reaches maximum size. The /ms setting controls a byte limit, not a guaranteed number of days. See the wevtutil command reference.

Treat each domain controller separately. One quiet server's history cannot represent a busier controller, and a configuration export cannot stand in for a successful event read. Keep the effective settings alongside the observations rather than using settings alone to close the review.

Define the policy before assigning a verdict. Ask the accountable owner to name the event populations, required period, local and central responsibilities, access requirements, and acceptable recovery behavior. Record the policy version and approval. The compliance mapping guide connects named controls to production evidence; apply that approach to the actual retention policy rather than inventing a universal regulatory duration.

Detection: Capture a Dated Record for Every DC

Step 1: Read the Effective Security Channel Configuration

Run these commands locally on each identified DC with authorized access. Their syntax is documented by Learn; Security is the channel selected for this procedure.

wevtutil gl Security
Get-WinEvent -ListLog Security
Get-WinEvent -ListLog Security | Format-List -Property *

The Get-WinEvent reference documents -ListLog, configuration properties, event ordering, -MaxEvents, -Oldest, and saved-log reads through -Path. Capture LogMode, MaximumSizeInBytes, FileSize, RecordCount, IsLogFull, and LogFilePath where returned. Keep the raw output, host identity, collection time with time zone, operator, and command outcome.

Do not silently exclude a DC because a read fails. Preserve the error and classify its evidence as unavailable pending investigation. A permission error, empty result, and successfully read log are different outcomes. The review register should make all three visible to its owner.

Step 2: Read Both Ends of the Available Event Sequence

Get-WinEvent -LogName Security -MaxEvents 1 -Oldest |
    Select-Object MachineName, LogName, TimeCreated, RecordId, Id, ProviderName
Get-WinEvent -LogName Security -MaxEvents 1 |
    Select-Object MachineName, LogName, TimeCreated, RecordId, Id, ProviderName

The default order is newest first; -Oldest reverses it. Keep the returned timestamps and identities without assuming they prove uninterrupted coverage. Reconcile time-zone presentation before comparing sources. These bounded reads identify the ends of the available sequence, rather than calculating the minimum and maximum timestamps across every record.

For review purposes, write down the observed span and its limitations. If the first readable record falls after the policy's required starting point, investigate whether an archive or approved central copy supplies the missing history. If it falls before that point, continue checking the required event populations and known interruptions. An early timestamp alone cannot establish completeness.

Step 3: Record the Evidence and Its Decision

Use one row per DC, then linked rows for archives and central destinations. Avoid a single domain-wide pass/fail cell that conceals an inaccessible server. The following is a proposed evidence register, not measured output:

Have the reviewer distinguish a demonstrated shortfall from an unanswered question. An unreadable archive is an evidence gap even if the file exists. A central query that omits a DC is an incomplete test even if the destination returns many records from other servers. Preserve these distinctions in the remediation ticket.

Verify Archives and the Central Copy

An archive inventory should lead to actual reads. Adapt this documented -Path syntax to each approved Security archive location; the path below is an example, not a discovered file.

Get-WinEvent -Path 'C:\ApprovedArchives\Security.evtx' -MaxEvents 1 -Oldest
Get-WinEvent -Path 'C:\ApprovedArchives\Security.evtx' -MaxEvents 1

Record failures alongside successful reads. Then search the archives for the event populations and periods required by the policy. A readable boundary sample establishes only that those records can be opened; the review still needs an explicit search covering the relevant investigation questions.

For WEC or another logging destination, select known source events and locate their corresponding central records. Retain source computer, channel, provider, event identifier, timestamp, and relevant event data for comparison. Document any transformation in the ingestion pipeline rather than assuming a destination-assigned record number is the source record number.

Separate receipt from searchability. The evidence package should show the central ingestion destination and the query used by an investigator, including filters, time range, and result. A record visible in a landing log but unavailable through the approved search path leaves a practical investigation gap. Conversely, a successful central sample does not certify every record or every DC.

Remediation: Meet the Approved Policy and Test Recovery

Step 1: Resolve the Specific Gap

Choose the change from the evidence: local capacity, full-log handling, archive access, subscription scope, central storage, or the search pipeline. Assign an owner and a verification step. Size and mode decisions need the expected event volume and interruption scenario for that environment; this article prescribes no universal byte limit or retention period.

Before changing a channel, preserve the current configuration and required evidence. Apply the approved configuration through the team's managed process, then repeat the configuration and event reads. Record both the intended setting and the observed result. Do not clear a Security log to make an old retention concern disappear, or treat a larger capacity setting as proof that previously lost history has returned.

Step 2: Review Documented WEF Delivery Settings

Microsoft's WEF intrusion-detection guidance explains that WEF reads existing channel events; it does not enable generation or resize the source log. The local log buffers events during disconnection. Overwrite can lose events without a gap notification to WEC. The guide also documents bookmarks, heartbeats, the option to read existing events, and custom delivery settings.

These are Microsoft's example parameters, to review from an elevated shell for an approved test subscription on WEC, not production sizing recommendations:

Wecutil ss "testSubscription" /cf:Events
Wecutil ss "SubscriptionNameGoesHere" /cm:Custom
Wecutil ss "SubscriptionNameGoesHere" /dmi:1
Wecutil ss "SubscriptionNameGoesHere" /dmlt:10

/cf:Events selects event format; /cm:Custom selects custom delivery; /dmi sets the maximum number of events per delivery, while /dmlt sets the maximum delivery latency in milliseconds. Replace the example names only after reviewing the intended subscription. Reading existing events can collect available history; it cannot recreate overwritten or never-generated events.

Step 3: Validate an Approved Interruption

Plan a controlled test with the monitoring owner, a defined scope, a stop condition, and a recovery procedure. Choose benign activity already covered by the required audit settings and subscription. Record the corresponding source events before, during, and after the interruption. Specify in advance which records should be searchable centrally and when the team will assess them.

Restore collection, then verify those records through the approved central search path. Keep the source evidence, interruption timeline, subscription settings, central results, and errors. Investigate discrepancies even if connectivity has recovered. Report any missing interval explicitly and identify whether surviving archives or another approved copy can supply it.

Step 4: Close the Evidence Review

Closure should identify exactly what was assessed: the DC population, required events, policy period, available local history, archives, central destination, and search path. Attach unresolved exceptions with owner and review date. If the test only covered one controller or selected events, state that scope and schedule the remaining checks.

Keep the evidence dated. Repeat the review after changes that affect the DC population, logging configuration, archives, or central collection. The useful maintenance task is to refresh the underlying proof and investigate discrepancies, rather than copying the previous verdict into a new report.

How EtcSec Detects This

In etc-collector at commit 9f698083354a1cb7f625df5cb490a515823c3257, AUDIT_LOG_RETENTION_SHORT emits one Info finding with a constant Count=1. Its Detect() reads no DetectorData fields and returns the reminder even without DC data. It measures neither log capacity nor readable retention, and cannot distinguish a compliant environment from a deficient one or automatically turn green after remediation.

The inspected AD collection path retrieves directory objects and GPO data through LDAP; this detector invokes no event-log provider and reads no local Security channel. Use the reminder to request the per-DC evidence described above, not as proof of a retention deficit.

Record the manual review and approved decision alongside the reminder. Keep the proof of readable history and central search results available to the owner who accepts closure.