Each tool sees its own slice of the infrastructure and generates its own signals. An attack, instead, crosses several systems and unfolds over time: often at night, often with valid credentials and legitimate tools, often without leaving obvious traces on any single device. Catching it takes someone who watches continuously, who can bring together signals from different sources and who, when something happens, can say clearly what needs to be done.

That is the job of a Security Operations Center. In recent years, however, the offering of managed SOCs has multiplied and the messages all sound alike: 24/7 monitoring, advanced detection and now, invariably, artificial intelligence. For those who have to choose — a CISO, an IT manager, a partner who has to propose the service to their own customers — it becomes hard to see where the real differences lie.

This article tries to make them explicit. It describes what Orizon Oversight is and how it works; it compares it with the two models the market proposes most often, the SOC built around an EDR and the so-called "AI SOC"; it explains why, in Oversight, artificial intelligence is a tool in the hands of the analysts and not a replacement for them; and it dwells on the point that, in our view, weighs most in a customer's real life: the moment after an incident is notified, when knowing that there is a problem is not enough, and what is needed is knowing how to solve it.

The detection chain is organised in a few steps, each with a precise role:

1. Collection. Data comes from endpoints and EDR, firewalls and network devices, Windows and Linux servers, identity providers and directories, cloud and SaaS environments (for example Microsoft 365, Google Workspace, AWS, Azure) and business applications. Forwarding happens through collectors and standard mechanisms — syslog, APIs — with no need to redesign the network. The platform currently integrates more than 500 different vendors.
2. Normalisation. Heterogeneous events are mapped to the open OCSF schema (Open Cybersecurity Schema Framework), so that a login on a firewall, a process on an endpoint and an access to Microsoft 365 can be compared in the same language.
3. Security Data Lake. Data is retained and remains searchable, both for day-to-day operations and for retrospective threat hunting.
4. Correlation and detection. Correlation engines powered by AI and machine learning, with rules mapped to the MITRE ATT&CK framework and threat-intelligence enrichment, bring the relevant signals out of the noise.
5. Validation and investigation. What the AI detects and correlates is checked by the analysts, who confirm it, discard it or dig deeper. Only then does it become an attack story: the coherent reconstruction of an attack, from the first trace to the last step observed.
6. Delivery and response. The customer — or the partner who looks after them — receives the investigation with the evidence and the mitigation and remediation recommendations. Automated playbooks (SOAR) support enrichment and escalation; containment actions on the integrated technologies, such as the EDR, are carried out as agreed with the customer.

So far, the description could fit more than one service on the market. The differences become clear when Oversight is compared with the two SOC models customers meet most often today.

The limit does not lie in the quality of the EDR, but in its perimeter. An EDR-based SOC sees where the agent is. And an attack rarely lives only on the endpoint; it often takes place elsewhere, or passes through somewhere else before getting there:

• identity: a VPN or Microsoft 365 login with stolen valid credentials, or with a session cookie taken by an infostealer, does not necessarily generate any suspicious event on a managed endpoint;
• e-mail: forwarding rules created on a compromised mailbox, internal phishing messages sent from a legitimate account;
• the perimeter: the exploitation of a vulnerability on a firewall or a VPN gateway happens on a device on which an EDR agent normally cannot be installed;
• cloud and applications: permission changes in a cloud tenant, anomalous access to a business application;
• unmanaged devices: legacy servers, OT systems, appliances, third-party machines.

There is also a second aspect, less technical but relevant: the SOC becomes dependent on that product. Changing EDR often means changing SOC provider too.

Oversight starts from the opposite assumption. It is agnostic with respect to the customer's technologies and does not replace the EDR: it extends its value, integrating it as one of the sources — CrowdStrike, SentinelOne, Microsoft Defender, Sophos and others — and correlating its telemetry with that of identity, e-mail, firewalls, cloud and applications in a single Security Data Lake. The EDR also remains the tool used to orchestrate containment directly on the endpoint. This is why, to the question "we already have an EDR, do we need a SOC?", the most accurate answer is not "yes, because the EDR is not enough", but "yes, because your EDR becomes far more useful when someone reads its signals together with everything else".

Today, however, having AI is no longer a differentiator: almost everyone claims it. What matters is rather what work it actually removes, and who remains responsible for the decisions. When AI is placed at the centre of the SOC, three problems tend to emerge.

In Oversight, artificial intelligence is a tool given to the analysts, not a replacement for them. It does what it does better and faster than a person: it correlates large volumes of events, gathers context, reconstructs sequences and carries out the repetitive investigation work. But what the AI detects is validated or verified by the analysts before it becomes an investigation delivered to the customer, precisely because AI can be wrong. The security decision stays with a person who has the competence and the responsibility for it.

The three models compared

A necessarily simplified summary: market offerings vary, and the comparison should always be checked against the specific case.

In the most common model, the SOC does its job well — it detects, qualifies, notifies — and then hands the customer an alert or a ticket along the lines of: "Suspicious activity detected on server X. We recommend isolating the machine and starting an investigation." From that point on, the customer's IT team, or the partner who supports them, is often on its own: it has to work out where the attack started, how far it got, which accounts and systems are involved and what needs to be fixed so that it does not happen again. These are exactly the hours when skills are scarce and pressure is at its highest.

Oversight is designed to reduce this gap to a minimum. What reaches the customer is not another alert, but an investigation already prepared: the attack story, built with the support of AI and validated by the analysts, which gives whoever has to act:

• the timeline of the attack, step by step, with each step mapped to MITRE ATT&CK techniques;
• the evidence on which the reconstruction is based, which can also be consulted independently with the DX Data Explorer add-on;
• the systems involved: hosts, accounts, addresses and services affected, and what instead turns out to be unrelated;
• why it matters: the severity, the potential impact and the stage of the attack reached;
• the mitigation and remediation recommendations: what to do immediately to contain, what to fix afterwards, on which systems, in what order, and how to verify that the action has worked.

The response remains in the hands of the partner or the customer, who keep control of their own environment and decide how and when to act. But they do not start from scratch: they start from an action plan that is already set out.

An example

An illustrative case helps convey the difference. At 02:14 a user account connects to the corporate VPN from an address never seen before. A few minutes later, the same account launches bulk queries against Active Directory; at 02:31 a PowerShell script is run on a file server, creating a scheduled task and attempting to stop the backup service.

A traditional notification might stop at the last event: suspicious PowerShell execution on SRV-FILE-02, verification recommended.

The Oversight attack story instead links the four steps into a single sequence — initial access with valid credentials, reconnaissance, execution, attempt to compromise the ability to recover — and, after the analyst's verification, accompanies it with recommendations such as:

• immediate mitigation: isolate SRV-FILE-02 through the integrated EDR, close the active VPN session, block the source address;
• reset the credentials of the account involved and revoke active sessions, including on cloud services;
• remove the scheduled task created at 02:31 and check for similar persistence mechanisms on other systems;
• verify the integrity of the backups before any restore;
• review the VPN authentication policy for the group the account belongs to;
• follow-up verification checks, which the customer can also run in DX Data Explorer, if active.

Illustrative example, built for explanatory purposes: the content and level of detail of the recommendations depend on the type of incident and on the integrated sources.

For the customer, it means moving from "what do we do now?" to a clear action plan. For the partner, it means being able to act immediately, with a defined scope of work, instead of reconstructing the incident from scratch.

DX Data Explorer: the customer sees their own data

The objection is a familiar one: "if I entrust monitoring to a third party, I am left in the dark". DX Data Explorer lets the customer query, in self-service, the same data lake the analysts work on: from the alert to the raw data, with structured queries, customisable dashboards and exportable data, via browser with SSO and MFA.

It does not replace the SOC; it makes it verifiable. The customer can dig into an event, check the evidence behind an investigation or produce evidence for an audit without opening a ticket and waiting for an answer. It is the add-on to propose when the customer has an in-house security team, or a CISO who does not want to depend on a third party to answer their own board's questions.

Cold Storage: the long-term memory of the logs

Here the objection arrives later: "when we need to reconstruct what happened, the logs are no longer there". It is a structural problem, not an oversight. The "hot" window of a SIEM — the data immediately available for detection and day-to-day investigation — is expensive to maintain, and for that reason it is kept short: often around 90 days. But a forensic investigation, a request from an authority or an audit can arrive months or years after the event, when the evidence no longer exists.

Cold Storage extends the life cycle of the data beyond that window. Once logs leave the "hot" phase they are moved to an encrypted "cold" archive, without weighing down — or driving up the cost of — the active analysis environment. Specifically:

• configurable retention, with horizons of up to 36 months, to be defined on the basis of the organisation's regulatory and contractual requirements;
• an encrypted, durable archive, with built-in integrity controls;
• on-demand restore and export: archived datasets come back in a searchable format when they are needed for an investigation, or are exported for an audit.

The point worth making to the customer is precisely the one about integrity. A log that is retained but can be altered has limited value: integrity controls are what make it possible to prove that records have not been modified, and it is this that gives them evidential value before an auditor, an authority or in a dispute.

It is the add-on to propose to those with obligations to retain evidence — NIS 2 or DORA scope, regulated sectors, organisations subject to periodic audits — and to those who, having already been through an incident, know what it costs not to be able to reconstruct what happened. It works well together with DX: Cold Storage retains, DX makes it possible to query what has been retained.

Dark Web Intelligence: beyond MFA

The third add-on concerns identity. Infostealers steal not only credentials but also already-authenticated session cookies, which make it possible to bypass multi-factor authentication. Dark Web Intelligence monitors forums, marketplaces and channels of the infostealer ecosystem for credentials and sessions linked to the organisation, filtering results down to real corporate identities and making it possible to invalidate sessions and rotate credentials before they are used. It is available in two tiers: a monthly scan, suited to compliance needs and low-risk organisations, and continuous 24/7 monitoring with immediate remediation.

Oversight brings the capabilities of an enterprise SOC — 24/7 monitoring, multi-source correlation, analysts who validate every detection — to organisations that cannot build one in-house. It differs from an EDR-based SOC because it sees beyond the endpoint and extends its value instead of depending on it. It differs from an "AI SOC" because artificial intelligence is a tool in the hands of the analysts: it removes the repetitive work, while the decision stays human. And, above all, it does not stop at the alert: it delivers an investigation already prepared, with the evidence, the systems involved and the recommendations for mitigation and remediation.

For the partner it is not "another service to sell": it is a recurring service that makes the most of the tools already in place at the customer, leaves the partner in control of the response and, at every incident, offers a clear scope of intervention.

The next steps are concrete: a qualification session to inventory assets and log sources; a demonstration of the console, of an attack story and of a live query in DX; and the definition of the scope and escalation procedures for onboarding.

Learn more: orizon.one/oversight