How I Built a Log Validation SOP for SIEM Using ACSC Standards (With a Reusable Template)

If you’ve worked in a SOC for any length of time, you already know the frustration. You get a new log source onboarded. The team celebrates. Then three months later, someone raises a detection gap. You realize half the required fields were never there to begin with. The timestamps were wrong. The user identity was only populated during authentication. The event IDs you needed for a critical detection rule? Never ingested.

This is not a tooling problem. It’s a process problem. And it’s fixable.

For the past few months, I’ve been developing a Log Validation Runbook. This is aligned with the ACSC (Australian Cyber Security Centre) logging guidance. It specifically follows the guidance under Priority logs for SIEM ingestion. The goal was simple. We wanted to give the team a structured and repeatable way to validate a log source. This ensures it actually meets the standard before it’s signed off as production-ready in the SIEM.

This post walks through how I structured it. It shows what validation looks like in practice. At the end, I’ve included a reusable template. You can take and adapt this template for your own environment.

Why Most Log Onboarding Fails?

The typical log onboarding process looks something like this: a ticket gets raised. Then, someone configures the agent or syslog forwarder. Next, a few sample logs arrive in SIEM. Finally, the task gets closed. Done.

But “logs are arriving” and “logs are compliant” are two very different things. You can have thousands of events per second flowing into your SIEM and still be blind to critical activity because:

The timestamp is normalised to local time instead of UTC, breaking correlation across sources
The user_identity field is only populated for interactive sessions, not service accounts
Key Windows Event IDs that ACSC flags as high priority like 4768, 4771, 4776 are present but 4772 is missing entirely
The log format is inconsistent, making parsing fragile

The runbook I built directly addresses these gaps. It provides analysts with a structured checklist. They use this checklist to run through every log source.

The Scope: What We’re Validating

The validation covers three key areas drawn from the ACSC Logging Guidance:

Log Format: Is the log in a structured format (CEF or JSON)? Can it be reliably parsed?
Required Fields: Are all mandatory fields present and populated correctly?
Technology-Specific Requirements: Are the right event types and IDs present for this particular log source category?
Clock Synchronization & Time Handling: Are timestamps in millisecond precision, UTC, and ISO 8601 format?

Step 1: Validate Log Format

The first check is straightforward, confirm whether logs are arriving in Common Event Format (CEF) or structured JSON or other. For each log type, you pull a sample entry and inspect it.

For example, an Active Directory log source ingested via Winlogbeats should arrive as JSON. You confirm the format, document a sample log entry in the validation record, and move on.

This matters more than it sounds. Unstructured syslog-style logs can technically be parsed, but field extraction becomes brittle and maintenance-heavy. Enforcing structured formats up front saves significant pain down the line.

Step 2: Validate Required Fields

This is where the real work happens. Every log record should contain at minimum the following nine fields:

Field Category	Expected Field Names	Notes
Log received date/time (UTC)	`@timestamp`, `eventtime`	Must be normalised to UTC
Log creation date/time (UTC)	`event.created`
System type	`device_type`, `product`	e.g., firewall, endpoint, vendor/product name
Source address	`src_ip`, `src_host`
User identity	`user`, `usrName`	Partial only when authenticated
Severity / Priority	`level`, `severity`
Action / Message	`event.action`, `msg`
Impacted object	`object`, `file`, `account`	Only for certain events
Result of activity	`status`, `outcome`	success / failure

For each field, you mark Y (present), N (missing), or Partial (conditionally populated). Then, add a notes column explaining the mapping. Make sure to include any caveats. This table becomes the living record for that log source.

Step 3: Validate Technology-Specific Requirements

This step is where you get specific about what each log source type should be generating. The ACSC guidance breaks this down by technology category and so does the runbook. I have added only a partial list of events for most of the technology in this post. The goal is more about the validation process.

Note: For complete set of logging guidance refer the doc here

a. Microsoft Domain Controllers & Windows Events

For Active Directory and Windows hosts, we validate against the full list of event IDs from the ACSC Domain Controller logging guide. In Kibana/Elasticsearch, you can run this directly using ES|QL like the sample query below.

FROM active-directory* | WHERE event.code.keyword IN (
  "4618", "4649", "4964", "4662", "4670", "4897", "4673", "4694",
  "4724", "4739", "4728", "4729", "4737", "4732", "4733", "4735",
  "4713", "4768", "4769", "4771", "4821", "4824", "4780", "4794",
  "5141", "4725", "4726", "4738", "4776", "3970", "4071", "4172"
)
| STATS cnt = count(*) BY event.code.keyword
| SORT cnt DESC
| LIMIT 10000

Export the results and compare against the ACSC guide. Any event ID with a count of zero over the last 30 days is flagged as missing or never generated. It should be documented in the Gaps & Recommendations about checking logging policy.

Sample validation output for Account Logon events looks like this:

Category	Subcategory	Event ID	Present	Outcome
Account Logon	Audit Credential Validation	4776	Y	success, failure
Account Logon	Audit Kerberos Authentication Service	4768	Y	failure, success
Account Logon	Audit Kerberos Authentication Service	4771	Partial	failure
Account Logon	Audit Kerberos Authentication Service	4772	N	—

Event 4772 being absent is a real finding, it means failed Kerberos pre-authentication with smart card errors won’t surface in detections. That goes straight into the recommendations.

b. Linux Endpoint Auditing

For Linux endpoints, the validation checks that the following log files are being collected and forwarded to the SIEM:

Log File	Description
`/var/log/audit/audit.log`	Events generated by auditd
`/var/log/auth.log`	System authentication logs
`/var/log/cron`	Cron job activity
`/var/log/dpkg.log`	Package installation and removal
`/var/log/faillog`	Failed authentication attempts
`/var/log/messages`	Global system messages (mail, daemon, kern, auth)
`/var/log/secure`	Authentication and authorization events
`/var/log/sudo`	Sudo authentication and authorization
`/var/log/syslog`	Events forwarded to syslog facility
`/var/log/samba/`	Samba / Windows interoperability events

If any of these are absent from your SIEM index, that’s a gap. It’s either not being collected at the agent level, or it’s being filtered out before ingestion.

c. Network Devices (Routers, Switches, Firewalls)

For network infrastructure, you’re validating presence of:

User login/logout events (TACACS+, RADIUS)
Configuration changes — copy run/start, privilege escalations
Interface up/down events
Routing protocol updates (BGP, OSPF neighbour state changes)
Security alarms — SNMP auth failures, denied ACL hits

d. Web Proxies / Secure Web Gateways

User authentication attempts
Allowed and blocked HTTP/HTTPS requests
Malware/URL category alerts
Files flagged for inspection
Proxy bypass attempts

e. VPN / Remote Access

Successful and failed VPN logins
Geo-improbable logins (same account, different countries within a short timeframe)
Session disconnects and re-establishments
MFA/2FA results

f. Email / Messaging Security

Inbound phishing detections
Malware attachments flagged or quarantined
Spoofing and domain impersonation attempts
Outbound spam or mass mail attempts

g. Cloud Services (M365, Azure AD, AWS, GCP)

User sign-ins — both interactive and programmatic
Failed logins and MFA challenges
Admin role assignments and privilege escalations
Resource creation/deletion (VMs, storage buckets, groups)
Sharing and access policy changes

Step 4: Clock Synchronisation & Time Handling

This one catches people out constantly. The requirement is specific:

Timestamps must have millisecond precision
Format must be ISO 8601 with UTC offset – e.g., 2026-03-24T00:15:32.451Z
Timestamps must be normalized to UTC – not local time, not whatever the server’s timezone happens to be

In the validation record, you document:

Timestamp normalization: Y/N – is it being converted to ISO 8601 on ingestion?
Known issues: anything observed like clock drift, inconsistent timezone in logs, or events with future timestamps

This section also surfaces a common issue. Sources have @timestamp indicating when the SIEM received the event. It does not show when it occurred. The gap between the two is significant.

The Validation Output: Log Validation Document

Once the validation is complete for every log source, the output document looks like this:

Overview

Log Source Name: Active Directory
System Type: Microsoft-Windows-Security-Auditing
Vendor/Product: Microsoft
Ingestion Method: Winlogbeats Agent

Log Type	Log Format	Required Fields	Timestamp Format	Tech-Specific Compliance
Active Directory	JSON	Y	Y	Partial

Then each of the four sections is documented with findings, and the Gaps & Recommendations section captures:

Missing Required Fields – fields that are absent or only partially populated
Parsing Issues – any field extraction failures or data type mismatches
Recommended Enhancements – what needs to be fixed, reconfigured, or escalated

Reusable Log Validation Template

Here’s the template structure you can replicate for any log source. Adapt the field names to match your SIEM’s schema.

Available to download here

Log_Validation_Template Download

Log Validation Record – [Log Source Name]

Overview

Field	Value
Log Source Name
System Type
Vendor / Product
Ingestion Method	e.g., Winlogbeats, Syslog, API

Summary Status

Log Type	Log Format	Required Fields	Timestamp Format	Tech-Specific Compliance
		Y / N / Partial	Y / N / Partial	Y / N / Partial

Section 1 – Log Format (Ref: 5.3.1)

Format: (CEF / JSON / Syslog / Other)
Example Log Entry: (paste a sanitised sample)

Section 2 – Required Fields (Ref: 5.3.2)

Field Category	Field Name in SIEM	Present in Logs? (Y/N/Partial)	Notes / Mapping
Log received date/time (UTC)
Log creation date/time (UTC)
System type
Source address
User identity
Severity / Priority
Action / Message
Impacted object
Result of activity

Section 3 – Technology-Specific Requirements (Ref: 5.3.3)

Specific Events / IDs validated:

Category	Subcategory	Event ID	Present (Y/N)	Outcome Observed

Section 4 – Clock Synchronization & Time Handling (Ref: 5.3.4)

Timestamp precision: (millisecond / second / other)
Timestamp format: (ISO 8601 UTC with offset / local time / other)
Timestamp normalization: (Y / N)
Known issues: (e.g., drift, inconsistent TZ in logs, future-dated events)

Section 5 – Gaps & Recommendations

Missing Required Fields:
Parsing Issues:
Recommended Enhancements:

Wrapping up

The gap between “logs are ingesting” and “logs are compliant with ACSC standards” is often larger than teams realise. This issue is usually invisible until a detection fails or an incident investigation hits a dead end.

Building this SOP took time. The value is that every log source now goes through a consistent gate. This happens before it’s considered production-ready. The analysts doing the validation have a clear structure to follow. The output is documentable and auditable. The recommendations feed directly into engineering backlogs rather than getting lost in Confluence somewhere.

You must align to ACSC standards if you’re running a SIEM in an Australian organization. This is particularly true for those that fall under critical infrastructure or government. But beyond compliance, it’s just good practice. You want to know your logging is actually working, not just flowing.

Based on your SIEM capabilities, you can automate the validation process. Use custom or inbuilt AI Agents for this automation. This topic could be a whole new post.

First, take the template above. Next, adapt the field names to your platform’s schema. Finally, start running it against your highest-priority log sources first. You’ll find gaps within the first two runs, guaranteed.

Have questions about how this runbook integrates with your onboarding process or SIEM platform? Drop a comment below