Yes, in the sense that security and IT operations should share data, even if they keep separate tools. AIOps applies analytics to operational telemetry to spot anomalies, and security teams need the same logs and inventory. Shared asset records and a common incident timeline remove blind spots and duplicate triage.
What is AIOps, and what does it have to do with security?
AIOps means using statistical or machine learning methods on operational data such as metrics, logs and traces, to find unusual behavior, group related alerts and suggest causes. Its aim is availability: find the failing link or the saturated queue before users do.
Security uses much of the same data. A sudden spike in outbound traffic from a server is a performance anomaly to one team and a possible exfiltration signal to the other. A configuration change that breaks a service may also be an attacker loosening a control. If each team sees only its own view, each spends time rediscovering what the other already knows.
NIST SP 800-137 describes information security continuous monitoring as a program that gives visibility into assets, awareness of threats and vulnerabilities, and insight into whether controls are working. That is the overlap: asset visibility and change awareness serve both operations and security.
Why does the network make this harder?
The network used to be a place with a perimeter. NIST SP 800-207 on zero trust notes that enterprise networks now include remote users, personal devices and cloud assets outside any enterprise-owned boundary, and that trust should not depend on network location. Telemetry therefore comes from many places: branch devices, cloud flow logs, identity providers, endpoints and applications.
Each source has its own format and its own owner. Without a shared inventory, the same device appears under three names, and an alert about one cannot be tied to another.
What should actually be shared?
Not everything. A useful split is:
- Asset and ownership records. One list of what exists and who answers for it.
- Change events. Who changed what and when, available to both teams.
- Log sources. Collected once, with access controlled by role. NIST SP 800-92 gives guidance on log management planning, including what to collect and how long to keep it.
- Incident timeline. One record that both teams add to during an event.
What should stay separate is access. Operations staff rarely need raw security investigation data, and security staff should not hold standing admin rights on production just because they read its logs.
What can go wrong with integration?
Three things come up often. A tool that promises a single view can hide the source detail you need during an investigation, so keep a path to raw logs. Anomaly models trained on normal traffic can learn an attacker's slow behavior as normal, so review what the model treats as baseline. And a merged alert queue can bury a security signal under a flood of performance noise unless severity and routing stay distinct.
A constructed example: a retail chain notices checkout latency climbing at one store. Operations sees a slow uplink. Security, reading the same flow records, sees a steady upload to an unfamiliar address. With a shared timeline, both teams look at the same device within minutes and agree it needs isolation, not a bandwidth upgrade.
How to check or apply this
- Build one asset inventory and give every record an owner.
- List your top ten telemetry sources and note which team can read each.
- Decide which events must appear in both teams' views, such as configuration changes and new outbound destinations.
- Define one incident channel and timeline used by both.
- Test with a tabletop: invent a latency issue that is really an intrusion and see how long the teams take to connect it.
- Review model baselines and alert routing quarterly.
Quick check
Do we need one product that does both?
No. What matters is shared inventory, shared change data and a shared incident record. Separate tools can feed the same data store.
Does AIOps replace security monitoring?
No. It is tuned for availability. Security monitoring needs different detections and different access controls, though it can reuse the same telemetry.
Sources
- NIST SP 800-137, Information Security Continuous Monitoring
- NIST SP 800-207, Zero Trust Architecture
- NIST SP 800-92, Guide to Computer Security Log Management
Last reviewed: 18 October 2026.
