Support teams inherit logging setups they did not design. A managed-services engineer opens a new client's environment and within an hour has to answer one blunt question: if something bad happened here last month, could we prove it? This checklist turns that question into an audit you can run in a day. It is built around SecDataOps, the discipline of managing security telemetry as a supply chain with owners, written agreements and tests. Work through it top to bottom, mark each line pass, partial or fail, and you will end with a punch list ranked by risk.

Before you start: the framing

The Ops Atlas, in its entry on SecDataOps and the security evidence pipeline, defines the aim as complete, trustworthy and affordable evidence for detections, investigations and audits. Keep those three words on the audit sheet. Every finding should be tagged by which of them it threatens: missing data, untrustworthy data or unaffordable data.

Section 1: inventory and ownership

• A written list exists of every system that should emit security logs, including identity, cloud accounts, network devices, servers and key applications.
• Each source has a named human owner, not a team alias.
• Each source carries a coverage score from zero to five on five dimensions: device count, field completeness, timeliness, consistency and retention.
• Sources added in the last ninety days are on the list.

What failure looks like. The list lives in one engineer's head, or contains systems that were decommissioned. Mark it fail and fix it first, because every later check depends on it.

Section 2: telemetry contracts

• For the top ten sources, a one-page contract exists.
• Contracts name required fields, expected freshness, tiers, retention, cost and known gaps.
• A canary event exists for each contracted source, so that absence is visible.
• Service-level targets are numeric. For a starting point the Atlas sketches targets along these lines: events landing within five minutes for 95 percent of traffic, almost every line parsing cleanly, completeness near 98 percent, and an alarm after a quarter-hour of nothing.

What failure looks like. Targets are phrased as wishes such as near real time. Convert them to numbers or mark the line fail.

Section 3: parsers and schemas

• Parsing logic is in version control with fixtures.
• A contract test runs in the build and fails when a field disappears or changes type.
• Bad lines go to a quarantine path instead of being coerced. Check specifically for the null-becomes-zero behaviour the Atlas describes in one widely used collector, where garbage turns into a denied connection to port 0.
• Event time and processing time are both stored, in UTC, in ISO 8601 with milliseconds.
• The team can say which schema (an open one such as OCSF or ECS, or a vendor model) each consumer expects.

On the engineering side, the habits here echo our own article on core principles for dependable software delivery: version everything, test everything, automate the boring bits.

Section 4: delivery guarantees

• Collectors buffer to disk, not memory only. The Atlas notes that in-memory buffers in a popular forwarder are not durable.
• Sources that use plain syslog are flagged, because it cannot acknowledge receipt.
• Every event carries a stable identifier and downstream de-duplication exists, so a replay does not double-count.
• Backpressure behaviour is documented: what happens to events when the destination is slow or down?

What failure looks like. A restart or an outage causes a hole, and the team only learns about it weeks later.

Section 5: retention and tiers

• Retention per source is a recorded decision with a reason, not a vendor default.
• The default is not simply ninety days. The Atlas cites investigations where intruders stayed far longer, including a 2026 report quoting a 14-day global median but a 122-day figure for some categories and roughly 400 days for one malware family.
• External obligations have been checked. Examples listed in the Atlas include a US federal memo with 12 months active and 18 months cold minimums, guidance led by Australian agencies whose starting point is a year of admin and security records, and an Indian rule of 180 days.
• Raw originals are kept in the cheapest tier, with normalisation applied forward.
• Any plan with an included retention window has been read closely. A certain cloud monitoring service bundles the first month, which means shortening below it earns no discount.

Section 6: cost

• Each stream has a price tag per day.
• The top three streams have been examined for a tiering option, such as hot summaries plus raw in a lake.
• Before any cut, a list of dependent rules and fields exists, and a replay of a week of raw data has been run to confirm every rule still fires.
• Nobody assumes the SIEM licence covers collection and storage design.
• Platform quirks are documented: object-level cloud audit events are opt-in and billed separately, and one warehouse access view lags up to 180 minutes, needs a higher edition and excludes failed queries.

Section 7: monitoring the pipeline itself

• Health is tracked per source, not as one aggregate, since averages can hide the stream that matters.
• Alerts reach a person who can act, verified by a test message.
• A silence test is scheduled monthly and the last result is recorded.
• Changes to hosts, such as upgrades and certificate rotations, pass through change control. The Atlas gives an example where an upgrade reset DNS logging on two hosts and certificate rotation affected two more, with neither going through the board.

If your support practice also owns reliability work, our write-up on moving from scripted infrastructure toward reliability engineering offers complementary habits for watching systems that change often.

How to run the day

Block six to eight hours and bring two people: one who knows the infrastructure and one who owns security. Spend the first hour on the inventory, because you will keep returning to it. Give sections 2 through 4 about ninety minutes together, sampling two or three sources rather than trying to cover all of them. Sections 5 and 6 need someone with access to billing and retention settings, so book them for after lunch. Save the last hour for section 7 and, if the client agrees, a live silence test on a harmless lab source.

Evidence to collect as you go

A checklist without screenshots is an opinion. Keep a folder with a copy of each contract, a sample of parser test output, the retention setting for each source, the last invoice line for each stream and the timestamp of the last canary. When the client questions a finding in three months, the folder settles the matter calmly. It also gives the next engineer a head start, which is part of what managed services should provide.

Scoring your audit

1. Count the fails in sections 1 and 7 first. Missing inventory and missing monitoring undermine everything else.
2. Next, treat any fail in section 5 as urgent if the client faces regulatory duties.
3. Finally, rank cost findings by pounds, rupees or dollars per day, whichever matches the invoice.

Write the result on one page. List the top five fixes, an owner and a date for each, then agree on a re-audit in ninety days. The Atlas describes five maturity stages, from reactive to optimising, so you can also label the client honestly: most first audits land at reactive or inventoried.

A thirty, sixty, ninety follow-up

Offer the client a plan they can actually finish. In the first thirty days: the register, the scores, a retention policy and monitors on the ten sources the business leans on most. In the next thirty: contract sheets, fixtures, test jobs and canaries for the same ten, plus prices per stream. By day ninety: three large streams re-tiered with replay checks, a first silence test completed and a baseline report delivered. That sequence is modest, repeatable and easy to explain to a manager.

A final scope note: this audit covers the supply of evidence. It does not cover writing detections, triaging alerts, containing incidents or hunting threats, and it should not be sold as if it did.