A log source inventory is a table listing every system that should produce security logs, which events it records, where they go, how long they are kept, and who owns the source. Build it once, review it quarterly, and the gaps in your detection become visible before an incident finds them.
Why you need one
Teams usually discover missing logs in the middle of an investigation. OWASP's Top 10 entry on logging failures describes the pattern: auditable events not logged, logs not watched, logs kept only locally, and no alerting thresholds or escalation. An inventory turns those from surprises into a to-do list.
The columns
- Source: Identity provider, cloud account, API gateway, database, CI system
- Owner: Named person or team
- Events recorded: Logins, admin actions, data access, config changes
- Events not recorded: Known gaps, such as data access off by default
- Destination: Central store, local only, third party
- Transport: TLS agent, API pull, none
- Retention: Hot, warm and archive periods
- Integrity: Append-only, shared account, none
- Alerting: Which rules read it
- Last verified: Date a real event was traced end to end
The gap column is the valuable one. Cloud services often leave some audit categories off until enabled, as in our notes on GCP data access logs.
Where to start listing
Walk the places an intruder or an auditor would care about:
- Identity. Directory, single sign on, multi-factor, privileged access tooling.
- Cloud control plane. Audit trails for every account and project.
- Network edge. Load balancers, gateways, web application firewalls, DNS.
- Workloads. Application security events, container platform audit logs, host audit logs.
- Data stores. Authentication and administrative activity on databases.
- Delivery pipeline. Source control, CI, artifact registries and deployment tools.
- Endpoints and SaaS. Email, file sharing, collaboration tools.
- The logging system itself. Collector, archive and access to both.
How to fill it quickly
Use asset discovery or your cloud account list as the seed so you do not rely on memory. Then for each row, run one real action, such as a failed login, and confirm the event appears centrally within a stated time. Record the date.
Reading the result
Sort by risk. A critical system with local-only logs is a top priority. A low value system with no logs may be an accepted gap, which you should write down with an owner and a review date.
Keep it alive
- Add a row when a new system is approved.
- Remove a row only when a system is decommissioned.
- Review it with the silence checks from detecting quiet sources.
- Keep the table as evidence. Auditors ask where logs come from and how you know it is complete.
Where Safeguard fits
Safeguard's asset discovery and compliance evidence automation can help seed the list of systems and keep the evidence behind each row. It is not a log platform, so the destination and retention columns still describe your own stack.
Quick check
How many columns are enough?
Start with source, owner, events, destination and last verified. Add the rest as you need them.
Who should own the inventory?
Security or platform engineering, with each source's owner responsible for their row.
Sources
- OWASP Top 10 2021, A09 Security Logging and Monitoring Failures
- Best practices for event logging and threat detection, CISA
Last reviewed: 19 October 2026.
