Most SIEM blind spots are created at onboarding: a log source is switched on without an owner, a volume estimate, a working parser or a health check, and months later nobody notices it has gone quiet. This template is a per-source checklist that a SOC or detection engineering team can run every time a new log source is connected to the SIEM or the security data lake. It covers ownership and approval, volume and cost, collection and transport, time synchronisation, parsing and field mapping, detections, retention and integrity, and health monitoring, with a sign-off at the end. It is built on the 2025 ASD's ACSC and CISA practitioner guidance on implementing SIEM and SOAR platforms and on priority logs for SIEM ingestion, OMB memorandum M-21-31 and NIST SP 800-53 Rev. 5. It is written for SOC leads, SIEM engineers and detection engineers. The Log Source Coverage Matrix Template tracks which sources you have; this checklist is how each one gets onboarded properly.
How to use this template
- Create one copy per log source (for example "Domain controllers, Security log" or "Cloud provider audit log, production account"), linked to the change ticket. Replace text in square brackets, such as [Organisation], [SIEM], [data lake] and [source name], with your own details.
- Each line has an owner role. Mark it Done (with evidence such as a screenshot, query or ticket link), Not applicable (with a reason) or Exception (with the approver and an expiry date). A blank line means the source is not onboarded.
- A source counts as onboarded only when sections 1 to 9 are complete and section 10 is signed. Until then, record it in the coverage matrix as "collecting, not onboarded", so nobody assumes detections cover it.
- The ACSC and CISA guidance recommends adding new sources only once existing sources have been audited, and ingesting gradually rather than all at once. Use the reference table in the implementation guidance to decide order.
- Run sections 6, 7 and 9 again after any major upgrade of the source system, the collector or the SIEM.
1. Source record
| Field | Value |
|---|
| Source name and type | [source name], [product and version], [log type, e.g. Security event log, audit log, flow log] |
| Assets in scope | [number of hosts, accounts, tenants or devices]; link to [CMDB query] |
| Why it is being onboarded | [use case or threat], [regulatory requirement], [incident lesson] |
| Priority tier | [1 critical / 2 high / 3 supporting], from the reference table |
| Destination | [SIEM index or table], [data lake path], or both |
| Change ticket and onboarding owner | [ticket ID], [SIEM engineer] |
2. Ownership and approval
| Check | Owner | Done |
|---|
| A system owner for the source is named, and agrees to tell the SOC before changes that affect logging (upgrades, decommissioning, audit policy changes). | System owner | [ ] |
| A SOC owner for the data is named: the person who answers "is this source healthy and useful?" | SOC lead | [ ] |
| At least one documented use case or requirement justifies the source; sources with no use case go to the data lake only. | Detection engineer | [ ] |
| Privacy and legal review is complete where logs contain personal data, employee monitoring data or message content. | Data protection officer | [ ] |
| The source is added to the coverage matrix with status "onboarding". | SOC lead | [ ] |
3. Volume, cost and routing
| Check | Owner | Done |
|---|
| Daily volume is measured in a pilot (events per second and GB per day), not estimated from vendor sizing alone. Record: [EPS], [GB/day], [peak]. | SIEM engineer | [ ] |
| Licence and storage cost is calculated against the current [SIEM] pricing model and approved by the budget holder. Record: [monthly cost]. | SOC lead | [ ] |
| Routing is decided per event type: security-relevant events to the SIEM, the rest to [data lake] or cheaper storage. The ACSC and CISA guidance recommends a log repository first with the SIEM drawing from it, and discourages using the SIEM as the central store for all logs. | SIEM engineer | [ ] |
| Filtering is applied at the source, the forwarder or ingestion, and every filter is documented with the events it drops and why. No filter drops events a detection in section 7 needs. | SIEM engineer | [ ] |
| A volume alert is set at [x]% above the pilot baseline, so a misconfigured source cannot exhaust the licence. | SIEM engineer | [ ] |
4. Collection and transport security
| Check | Owner | Done |
|---|
| Logging is enabled at the source with the required audit settings (for Windows, the advanced audit policy and command line auditing; for cloud, the audit and data event logs agreed in section 7). | System owner | [ ] |
| Collection method is recorded: [agent / syslog / API pull / cloud-native export / event hub or queue]. | SIEM engineer | [ ] |
| Transport is encrypted (for example syslog over TLS, HTTPS APIs) and the collector authenticates to the destination. | SIEM engineer | [ ] |
| The collector's service account, API key or cloud role is inventoried with an owner, has read-only access to logs only, stores its secret in [vault] and is rotated on [schedule]. Its own activity is logged. | Identity team | [ ] |
| Buffering is configured so a network or SIEM outage does not lose events, and the buffer size covers at least [hours] of peak volume. | SIEM engineer | [ ] |
5. Time synchronisation
| Check | Owner | Done |
|---|
| The source synchronises to the organisation's approved, authenticated time source, not a public unauthenticated pool. OMB M-21-31 treats public unauthenticated NTP pools as a last resort. | System owner | [ ] |
| Timestamps carry a time zone or are in UTC, in ISO 8601 or RFC 3339 format, as M-21-31 requires for federal agencies. | SIEM engineer | [ ] |
| The SIEM records both event time and ingestion time, and an alert fires when the gap exceeds [minutes]. | SIEM engineer | [ ] |
| Clock drift on the source is checked against the time source and recorded: [offset]. | System owner | [ ] |
6. Parsing and field mapping
| Check | Owner | Done |
|---|
| A parser exists for every event type in scope; unparsed or partially parsed events are counted and below [x]%. | SIEM engineer | [ ] |
| Fields are mapped to the [common schema] so equivalent fields match across sources (for example source IP, user, host, action, outcome). | SIEM engineer | [ ] |
| The minimum fields are present where applicable: timestamp, event ID or status code, device identifier, user, source and destination address, session or transaction ID and executed command (based on the M-21-31 minimum fields). | Detection engineer | [ ] |
| User and host fields are enriched with identity and asset context (department, privileged flag, human or non-human, asset criticality). | SIEM engineer | [ ] |
| Parser tests with sample events run in the deployment pipeline and after every source or parser upgrade. | Detection engineer | [ ] |
7. Detections and use cases
| Check | Owner | Done |
|---|
| The detections this source feeds are listed by name and ATT&CK technique, for example DCSync (T1003.006) from domain controller event 4662 with directory replication rights, and clearing of Windows event logs (T1685.005) from event 1102. | Detection engineer | [ ] |
| Each detection is tested end to end with a safe, approved simulation and produces an alert with the expected fields. | Detection engineer | [ ] |
| Investigation queries and a dashboard for the source are published to analysts, with a short note on what the source can and cannot answer. | Detection engineer | [ ] |
| Expected benign noise is documented and tuned, with every exclusion owned and dated. | Detection engineer | [ ] |
| The coverage matrix is updated with the techniques this source now supports. | SOC lead | [ ] |
8. Retention and integrity
| Check | Owner | Done |
|---|
| Searchable retention is set: [days]. The ACSC and CISA guidance suggests at least one year for administrative and security event logs and 90 days for informational logs as a starting point; OMB M-21-31 sets 12 months active and 18 months cold storage for most categories for US federal agencies. | SOC lead | [ ] |
| Retention also meets [regulatory or contractual requirement] and your worst known dwell time, whichever is longest. | Compliance | [ ] |
| Logs are stored where administrators of the source system cannot alter or delete them, with write-once or immutability settings where available. | SIEM engineer | [ ] |
| Access to the stored logs is role-based and itself logged. | SIEM engineer | [ ] |
9. Health monitoring
| Check | Owner | Done |
|---|
| A heartbeat rule alerts when the source sends no events for [minutes] or drops below [x]% of its normal hourly volume. The ACSC and CISA guidance warns that the absence of logs should be a concern, and that an empty search result can be mistaken for a clean one. | SIEM engineer | [ ] |
| Per-asset coverage is measured: the number of assets sending logs against the number in the CMDB for this source type. | SOC lead | [ ] |
| Changes to audit policy at the source (for example Windows event 4719) and log clearing (event 1102) raise alerts. | Detection engineer | [ ] |
| Health alerts route to a named queue with a response time, not to a shared mailbox. | SOC lead | [ ] |
10. Sign-off
| Role | Name | Date |
|---|
| System owner | [name] | [date] |
| SIEM engineer | [name] | [date] |
| Detection engineer | [name] | [date] |
| SOC lead (accepts the source as onboarded) | [name] | [date] |
Review date for this source: [date, at least annually or after a major change].
Implementation guidance
What logs to send first. The ACSC and CISA priority logs guidance lists categories loosely in order of priority and recommends tailoring them to your environment. Use it to set the priority tier in section 1.
| Order | Source category | Examples of high-value events |
|---|
| 1 | Endpoint detection and response | Detections, process and network activity, scheduled tasks, registry and service changes |
| 2 | Network devices | Firewall denies and egress, VPN authentication, proxy logs, IDS alerts, NAC events |
| 3 | Active Directory and domain controllers | Kerberos 4768, 4769, 4771; DCSync 4662 (replication rights); account and group changes 4720, 4728, 4732; log cleared 1102 |
| 4 | Cloud | Control plane audit logs, identity and sign-in logs including service principals, secrets access, flow logs, break-glass use |
| 5 | Containers | Privileged access, RBAC and configuration changes, API audit logs |
| 6 | Databases | Privileged logons, role and permission changes, new privileged users, structure changes |
| 7 | Mobile device management | Enrolment and policy changes, app permission changes, threat detections |
| 8 | Windows hosts | Process creation 4688 or Sysmon 1, PowerShell 4103 and 4104, service installs 7045 and 4697, logons 4624, 4625, 4648, 4672 |
| 9 | Linux hosts | Audit configuration changes, sudoers and root changes, SSH sessions, user and group changes, cron and kernel module changes |
Rollout. Onboard in waves of a few sources at a time. For each wave: run sections 1 to 3 as a pilot on a small set of assets, measure volume, then expand to all assets once parsing (section 6) and heartbeat (section 9) work. If a source floods the licence or breaks parsing, roll back by disabling the forwarder route to the SIEM while keeping the data lake copy, fix it, and re-run section 3.
Small and large teams. A small team should onboard the first three or four categories completely before adding more, and rely on vendor-maintained parsers and a common schema. A large SOC should treat onboarding as a pipeline, with parser tests, detection tests and coverage updates automated through a detection as code workflow; see the Detection as Code Guide.
Measure it. Track the percentage of priority sources fully onboarded (all ten sections), the percentage of assets reporting per source type, mean time to detect a silent source, the share of events failing to parse and cost per GB against the detections each source feeds. The Top 10 SIEM Deployment Mistakes explains what goes wrong when these slip.
Framework mapping. The checklist supports NIST SP 800-53 Rev. 5 AU-2 Event Logging, AU-3 Content of Audit Records, AU-5 Response to Audit Logging Process Failures, AU-8 Time Stamps, AU-9 Protection of Audit Information, AU-11 Audit Record Retention, AU-12 Audit Record Generation and SI-4 System Monitoring, and NIST CSF 2.0 PR.PS-04 (log records are generated and made available for continuous monitoring) and DE.AE-03 (information is correlated from multiple sources). For retention policy across all logs, see the Log Management and Retention Guide.
Standards and references
Related NHI Mgmt Group resources: Log Source Coverage Matrix Template · SIEM Guide · Logging and Monitoring Policy Template · Security Data Lake Guide · Detection Engineering Guide