Insight
SIEM Log Integration: An Acceptance Checklist Before Monitoring
Verify SIEM readiness in six stages: event generation, collection, field mapping, investigation, detection, and handoff. Define evidence, owners, and recovery checks.
Your SIEM shows a source as connected. Does that mean monitoring is ready to begin?
To decide, verify that the activities you need to investigate are recorded, that the information is searchable, and that the necessary detection and notification steps work. The arrival of logs alone does not establish what you can monitor.
In implementation discussions with Yagura, teams have needed to clarify changes to source settings, additional detection rules, and who would do that work. This article turns those questions into a checklist for deciding whether monitoring is ready.
For an introduction to the platform's role, see What is SIEM?
Start with the question you want to answer
A list of products to connect is not enough to identify the logs you need. First, write a short investigation question.
For example: “When administrator permissions change, we want to know who granted which permissions to whom.” You need the permission-change event and information linking the actor, target account, time, and details of the change.
With that question defined, check whether the source records the event, whether the collection account can read it, and whether the necessary fields reach the SIEM. This sequence helps avoid discovering after connection that the activity you care about was never recorded.
For example, AWS CloudTrail trails and event data stores do not log data events by default, and additional charges apply. Check the configuration for the events you need, such as S3 object operations. AWS documentation on data events.
Divide acceptance testing into six stages
Acceptance testing checks whether the implemented workflow can be used as intended. The following model is proposed by Yagura. Select the checks that fit your products and monitoring objectives.
Stage | What to check | Example evidence | Responsible role |
|---|---|---|---|
1. Generate the event | Does the intended activity create the required event at the source? | Action time and original event | Source system administrator |
2. Receive the event | Can you collect the required log types and scope? | Collection time, scope, and errors | Integration owner |
3. Map the fields | Are time, actor, target, and result mapped to the intended fields? | Original-to-ingested field mapping | Integration and investigation owners |
4. Investigate | Can you search using the required conditions and reconstruct what happened? | Search criteria and matching events | SOC or investigation team |
5. Detect | Does the rule trigger under the expected conditions and produce the intended notification? | Test conditions, detection result, and reasons for any miss | Detection rule owner |
6. Accept the handoff | Does the recipient receive the alert and start the next check or decision? | Recipient, contact route, and case record | Internal contact or response owner |
Before testing, define the expected result and acceptable limits for each check. Specify the maximum acceptable arrival delay, mandatory fields, and exclusions. Afterwards, record the actual result and mark it as passed, not passed, or not yet checked, with evidence. Receiving one event and meeting the planned acceptance criteria are separate outcomes.
You do not need a different person for every role. Even when responsibilities overlap, make ownership of each stage explicit. If an external operations provider is involved, specify which configuration changes, investigations, and decisions belong to the internal team or provider.
This checklist does not prove that every attack can be detected. It records which parts of the workflow have been verified under the tested scope and conditions.
Trace timestamps and targets back to the original record
A value on a screen is difficult to use in an investigation if you cannot identify its source. Distinguish event time from ingestion time, and the account performing an action from the account affected by it.
Across systems, clock differences and inconsistent device or user names can affect interpretation. Instead of looking only at arbitrary samples, choose a test action with a known time and target. This makes it easier to compare the source event with the ingested result.
Joint guidance published by ACSC and partner agencies covers an event-logging policy's collection scope, monitoring, retention, responsibilities, and timestamp consistency. The checklist above applies those principles and the issues raised in implementation discussions to acceptance testing. Best practices for event logging and threat detection.
Verify receipt by the owner, beyond the detection result
After a test alert triggers, check who will see it. Run through actual receipt, access to the supporting evidence, and recording the case in the intended location.
Separate an AI or rule-based finding from the business context. Detecting a permission change does not establish whether it was an approved task; you may need confirmation from someone who holds the request or work schedule. Generating an investigation result is not the same as completing the response.
Use approved actions or test events appropriate to the environment. Plan notification testing separately from real account suspension, endpoint isolation, or other response execution.
Replaying stored logs or sending a test notification verifies only the stages the test actually passes through. It does not prove that the source can record and forward a new event. To cover stages 1 and 2, trace a known action from the source system and record the scope you verified.
Worked example: accepting permission-change monitoring
The following is a fictional example to illustrate the method, not a customer deployment or claim of implementation experience.
A team wants to monitor administrator permission changes. At a scheduled time, an administrator changes a test account's permissions. The source records the event and the SIEM receives it, but the investigation view does not distinguish the actor from the account whose permissions changed.
Stage 2 has been verified, while stages 3 and 4 remain incomplete. Before adding more rules, correct the mapping between the source fields and the display, then repeat the same test. Once detection and notification work, verify that the internal contact can compare the event with the approved work schedule.
Record | Example entry |
|---|---|
Investigation question | Who changed administrator permissions, for whom, when, and what changed? |
Verified scope | Event generation, arrival, field mapping, and search |
Not yet verified | Receipt by the out-of-hours owner and correlation with another system |
Remaining work and owner | Operations owner to test receipt by the out-of-hours contact |
Condition for starting monitoring | Verify detection and receipt by the responsible person for the defined scope |
Record the tested scope and unverified conditions rather than simply writing “no issues.” This gives the next operator enough information to judge readiness.
Define what happens when logs stop or settings change
A connection that worked on day one may not keep working under the same conditions. Assign an owner to recheck it when collection permissions expire, destinations change, or log formats are updated.
No recent logs does not automatically mean ingestion has failed. A source that records only actual activity may simply have had no events. Assess collection results, normal event frequency, and the source's state together.
Include three points in the operational handoff:
How will the team detect collection errors or delays?
Who checks the source and the integration, and who must be contacted?
After recovery, can logs from the missing period be retrieved? If not, what must be recorded?
If the retention period differs from the period available for immediate search, tell the investigation team. Make it clear who can retrieve older records and from where.
Separate collection failure, delay, and missing records
When an anomaly is reported, record the integration, log type, last arrival time, and period checked. Yagura suggests the following triage sequence.
Check the original record. Establish whether activity occurred during the period and whether the source recorded it. If there was no activity, zero events alone does not prove collection failure. Check for changes to logging settings or scope.
Check arrival separately from content. If a source record exists but has not arrived, check collection permissions, collection errors, and the forwarding path. If records arrive late, compare event time with ingestion time. If required fields are missing from received records, check format changes and field mappings.
Communicate the affected scope. Identify detection rules and investigations that depend on the source, and the period you cannot verify. An absence of alerts during that period is not evidence that the environment was safe.
Microsoft Sentinel provides a data collection health monitoring workbook and the SentinelHealth table. SentinelHealth supports only selected connectors and requires health monitoring to be enabled. Alongside connector status, verify that the required data can actually be searched. Microsoft documentation: monitor data connector health.
Recovery requires more than the arrival of new logs
After recovery, check whether the missing period can be retrieved, confirm search results, and examine detection look-back windows. A late event may be stored but missed by a rule if it falls outside the rule's window. When extending that window, also check for duplicate notifications from the same event. Microsoft documentation: ingestion delay in scheduled analytics rules.
For a fictional outage in which permission-change logs could not be collected from 09:00 to 09:40, record three outcomes separately: new logs arriving, the missing 40 minutes being retrieved, and any required retrospective investigation being completed. For records that cannot be recovered, document the gap, affected investigations, alternative evidence, and decision owner. These times illustrate the method; they are not universal outage thresholds or recovery targets.
An operational record should include the log source, last known healthy time, affected period, cause and action, retrieval result, detection and duplication checks, unresolved questions, owner, and next review time. These fields make handoff decisions easier to reproduce.
Complete one workflow before expanding coverage
Finishing every log source at once can hide incomplete work. Start with one important system and one investigation question, then verify the process from recording to handoff. Use the result to distinguish reusable configuration from work specific to each additional source.
Some environments allow collection to start easily through standard integrations. Use the checklist to confirm the monitoring you need, without making an already simple acceptance process unnecessarily complex.
When consulting Yagura, bring your target systems along with the investigation questions, the stages already verified, and the owners of unfinished work. This makes the required support more concrete. Explore AI SOC implementation and operations.
After log acceptance, use the AI SOC proof-of-concept evaluation checklist to compare investigation quality and operational workload.
