Logging you will actually use when it matters
Most teams collect too much of the wrong thing and too little of the right thing. A practical review of what to keep, how long to keep it, and how to check your pipeline before an incident tests it for you.
There is a reliable pattern in cloud estates. Logging volume grows every quarter, the bill grows with it, and the ability to answer a question about what happened last Tuesday does not improve at all. The two things are not related as closely as the invoice implies.
The useful way to approach this is backwards. Start from the questions you will need to answer during an incident, then keep the data that answers them and let most of the rest go.
The questions worth designing for
- Who authenticated as this identity, from where, and did anything about that change recently?
- What did this identity do after authenticating, in order, with timestamps?
- What data left the environment, to where, and how much of it?
- What changed in the infrastructure, who changed it, and was that change reviewed?
- Which other identities share a property with this one, so we know where else to look?
If your pipeline answers those five, you are in a better position than most organisations spending several times as much on telemetry.
What to keep, and for how long
Retention matters more than breadth. The median time to discover an intrusion is measured in weeks, and thirty days of retention means that by the time you know, the beginning of the story has already expired.
- Authentication and identity events, including failures, from every system that has them. Thirteen months if you can afford it, twelve at minimum, because that covers an annual audit window as well.
- Control plane and infrastructure changes across every cloud account, including the ones nobody uses. Twelve months.
- Network flow records at the boundary, sampled if necessary. Ninety days is usually enough to answer the exfiltration question.
- Application-level events for anything touching customer data: exports, permission changes, invitations, impersonation. Twelve months.
- Endpoint process and persistence telemetry, if you have it. Ninety days.
What to stop collecting
Debug-level application output, health check traffic, load balancer noise from monitoring probes, and duplicated copies of the same events arriving through two different agents. In most estates we review, these account for the majority of volume and almost none of the investigative value.
Cutting them is not only a cost exercise. Noise has a real operational cost: it slows queries during the exact hour you need them fast, and it hides the events you were looking for.
Test the pipeline before an incident does
A logging pipeline is a system like any other and it fails silently. Agents stop reporting after an image change. A destination bucket policy is tightened and writes begin failing. A parsing rule breaks and a whole source becomes unsearchable while continuing to arrive.
- Generate a benign, distinctive event on a schedule, and alert if it does not appear in the search index within an agreed number of minutes.
- Alert on the absence of a source, not only on the content of events. Silence is the most common failure mode and the easiest to miss.
- Once a quarter, take a real question and answer it end to end. Pick an identity, reconstruct a day of its activity, and time yourself.
- Check that the people who would need access during an incident have it now, including out of hours and from a device that is not the one that might be compromised.
That last exercise is the one that changes things. It reliably reveals whether you have a logging capability or merely a logging expense, and it takes an afternoon to find out.
Working on this
If this describes something you are dealing with, a scoping call costs nothing and takes about half an hour. We will tell you honestly whether it needs an engagement or an afternoon of your own team's time.
Request a Security Assessment