Every machine-learning model that watches IT operations carries a quiet assumption: the data it receives is complete, correctly labelled and arrives on time. When that assumption fails, the model does not complain. It simply produces confident answers about a world that is partly missing. SecDataOps is the discipline that takes that assumption seriously on the security side, and its ideas translate surprisingly well to anyone running AI-assisted operations.

This explainer sticks to plain language and to evidence. It describes what SecDataOps covers, why its habits matter to teams who build smart operational tooling, and which small experiments let you test your own situation without buying anything.

What SecDataOps means, minus the jargon

Security tools consume logs: sign-in records, firewall flows, cloud audit trails, DNS queries. Somebody has to bring those logs in, give them a consistent shape, add context, send them to the right place and decide how long to keep them. SecDataOps is the name for treating that whole job as an engineering practice with owners and measurements instead of a side effect of buying a product. The Ops Atlas phrases it as data engineering for defenders, and the Atlas entry on SecDataOps is explicit that the goal is evidence that is complete, trustworthy and affordable at the same time.

Two honest caveats belong up front. The label itself is recent, pushed mostly by suppliers, and no standards body owns a definition. Yet the work underneath is old: official guidance has covered it for years as log management and event logging. Neither point makes the work less useful. It just means you can judge it by results rather than by branding.

Why an AIOps reader should care

Teams that adopt machine learning for operations tend to spend their first months on the model and their next months discovering data problems. Noisy duplicates, fields that change name after an upgrade, a collector that quietly stops, timestamps in three formats. Those are exactly the problems the security side catalogued. If you have already read about cutting event noise with smarter tooling, you know that noise reduction depends on knowing what normal traffic looks like. That knowledge lives in the pipeline, not in the model.

A useful way to hold the idea is a supply chain. Producers make events, collectors gather them, a pipeline cleans and routes them, storage tiers hold them, and consumers such as detectors, analysts and auditors use them. Each link needs a named owner and a way to show it is healthy. A model sitting at the far end is just one more consumer, and it inherits every weakness upstream.

The evidence behind the discipline

It helps to look at what happens when evidence is missing. In 2023 an intrusion into a government email environment was spotted because a particular mailbox-access log existed and a custom rule watched it. That log had been available only on a premium licence tier. Afterwards a review board recommended that such logs be free and retained for at least six months, and the vendor extended email-access logging and a 180-day default retention to its standard audit tier. The lesson is not about one vendor. It is that the ability to catch a problem can hinge on a single data source nobody thought to prioritise.

Dwell time tells a similar story. A 2026 industry report on the previous year’s investigations put the global median at 14 days, but espionage-style cases ran to 122 days and one long-running implant stretched to roughly 400. A 90-day retention default, still common, cannot answer questions about the beginning of those intrusions. If you plan to ask your analytics to explain an incident, the history has to exist first.

Five questions that expose gaps

The Atlas describes a coverage register where every source is scored from zero to five on five dimensions: how many devices report, how many fields are populated, how quickly data arrives, how consistent it is and how long it is kept. You do not need the full exercise to benefit. Start with five questions and see how many you can answer with evidence rather than confidence.

1. Which sources feed our models, and who owns each one by name?
2. What is the expected delay between an event happening and it being queryable?
3. If a collector stopped at midnight, how long until a person is told?
4. Which fields do our rules or models actually depend on?
5. How far back can we look at raw data, and is that long enough for our slowest realistic incident?

If question three draws a blank, the monthly silence test is a cheap cure. Switch off a lab source on purpose and time how long the alerting takes. The result is almost always longer than people predicted, and a measured number is a better argument than any opinion.

Shape, schema and the cost of translation

Different vendors name the same thing differently, which is why open schemas matter. The Open Cybersecurity Schema Framework, whose version 1.9.0 appeared in August 2026 under the Linux Foundation, defines classes of events and the fields they carry. Elastic’s common schema is converging with OpenTelemetry, and several platforms maintain their own models. For a model builder this is practical, not academic: a normalised field is a feature you can reuse across sources, while a free-text blob forces every new use case to start from scratch.

The Atlas adds a guardrail worth borrowing. Normalise going forward, but keep the raw record in the cheapest storage you have. Parsers make mistakes, schemas deprecate attributes between releases, and the original text is the only thing that lets you replay history after a fix. Record both the time an event occurred and the time you processed it, in UTC with milliseconds, or training data will quietly blur cause and effect.

Cost is part of the design

Collecting everything and deciding later sounds safe. Guidance from Australian authorities cautions that gathering too much leaves detection logic harder to build, because the useful signal sinks into volume. The Atlas offers an illustrative calculation: 400 GB a day of firewall flows kept entirely in expensive search storage costs roughly 400 units a day, whereas 8 GB a day of summaries in that tier plus raw data in a cheap lake for 400 days costs about 164 while raising raw retention from 90 days to 400. Treat the numbers as an example of the method, not a quote. The point is that tiering can buy both cost reduction and longer memory.

Anyone who has paid for the compute behind a large analytics platform will recognise the logic. Cheap storage for the bulk, premium storage for the slice that gets queried daily, and a replay check to confirm that nothing important was lost when you cut a stream.

Where it can go wrong

A few traps from the Atlas are easy to recognise from operations work in general. A parser that converts missing values to zero will turn garbage into legitimate-looking events, so a quarantine path for malformed lines beats forcing everything through. In-memory buffers in a collector are not durable across restarts, so anything you cannot afford to lose needs disk buffering. Syslog cannot acknowledge delivery, so replays must be de-duplicated on a stable identifier or counts inflate. None of that sounds glamorous, yet each one has silently damaged real dashboards.

For readers who want a gentler start, our own notes on bringing automated operations into a team cover the organisational side, and the data hygiene described here is the technical companion to it.

A thirty-sixty-ninety plan for a small team

The Atlas proposes a staged approach that fits a modest team. In the first month, list your sources, score them, set a retention policy and put health monitors on the ten that matter most. In the second, write a short contract for each of those ten, with owner, schema, freshness expectation, retention and known gaps, add test fixtures to your build process and price each stream. In the third, move the three largest streams into cheaper tiers, proving with a replayed week of raw data that every rule still fires, carry out a first silence test and write up a baseline.

A contract can be modest. One example in the sheet sets a 300-second freshness ceiling for most events, 99.5 percent of lines parsing cleanly, 98 percent field completeness, and a page to a human once fifteen minutes pass without data. Numbers like these matter less than the habit of writing them down and checking.

What to take away

If your operations lean on analytics, treat the evidence supply chain like a service that has named owners and measurable targets. Cheap experiments come first: a source inventory, a silence test and one replay. The first dependable data for a model is also dependable data for an auditor, and the same work serves both.

For deeper reading, the piece on supporting IT decisions with machine learning pairs well with the checklist above, since decisions are only as sound as the records beneath them.