Insights

From countless partner engagements and customer transitions, we see the same mistakes repeated by MSSPs delivering managed security using Microsoft Sentinel. These missteps leave organisations exposed, locked out of their own data, or paying far more than they should for log ingestion. They are a major reason customers move to Chorus Cyber for a more mature, transparent, and high-performing service.

Microsoft Sentinel is a logical choice for organisations already invested in the Microsoft ecosystem. It is a cloud-native SIEM and SOAR platform built on Azure, designed to sit within your own Azure tenant rather than in an MSSP’s datacentre. But the way Sentinel is deployed and operated varies wildly between providers, and in recent months we have seen a number of delivery models that should not be in place.

How Sentinel is designed to work

Sentinel lives within your Azure tenant, not the MSSP’s. All logs, analytics rules, incidents, and workbooks are processed and stored in your chosen Azure region, giving you full control over data residency. An MSSP such as Chorus Cyber connects securely into your Sentinel environment using delegated permissions (via Azure Lighthouse) to deliver monitoring, detection, and response. Ownership of the data and the platform remains with you at all times.

This matters for three reasons. First, data sovereignty and compliance: you choose the region (for example, UK South, Sweden Central, Australia East), ensuring alignment with the regulations you need to meet. Second, transparency and control: because the environment sits in your tenant, you maintain full visibility into analytics rules, incident history, and configuration. Third, security and isolation: your Sentinel instance is unique to you, with no shared infrastructure risks.

That is how it should work. Here is what we keep finding instead.

Mistake 1: Sentinel deployed in an MSSP-controlled CSP subscription

This is the most common issue we encounter during customer transitions, and it is worth understanding how it works in practice.

Many MSSPs are Cloud Solution Providers (CSPs). When they onboard a customer, they provision an Azure subscription under their own CSP agreement. That subscription sits inside the customer’s Entra ID tenant, so at first glance it looks like everything is where it should be. But the MSSP retains billing ownership and full administrative control of the subscription itself, because it was provisioned through their CSP agreement, not the customer’s.

This is the critical distinction. The subscription is technically in your tenant, but you do not own it, you do not control it, and in most cases you are either locked out entirely or given very limited read-only access. Your Sentinel workspace, Log Analytics data, analytics rules, and all associated resources live inside this MSSP-controlled subscription. You can see your tenant, but you cannot see or manage the security infrastructure that is supposed to be protecting you.

This creates several serious problems.

Loss of visibility and control. Your security data sits in a subscription that lives in your tenant but is controlled by your MSSP. You cannot meaningfully audit what analytics rules are running, what data is being retained, or how incidents are being managed. The MSSP decides what you can and cannot see.
Data residency risks. The MSSP chooses which Azure region the subscription and workspace sit in. This may not align with your compliance requirements, and you may not even know where your data is being stored.

Lock-in and loss of historical data. When you decide to change MSSP, you lose access to all the historical log data that has been built up in that workspace, potentially spanning years of retention. This data is critical for incident response, threat hunting, and meeting compliance obligations such as demonstrating audit trails to regulators. Because the subscription was provisioned under the MSSP’s CSP agreement, they retain ownership of it. They have no obligation to hand over the data, and migration of historical Log Analytics data out of a subscription you do not control is impossible. In practice, many organisations walk away from years of useful security telemetry when they switch providers.

Cost opacity. Sentinel consumption is billed through the MSSP’s CSP agreement, often with additional margins added. You have limited ability to verify actual consumption against what you are being charged.

By contrast, Sentinel should always be deployed in a subscription that the customer owns, controls, and is billed for directly. The MSSP should access it through delegated permissions via Azure Lighthouse, not by provisioning your security infrastructure under their own CSP billing agreement.

Mistake 2: Running parallel Sentinel workspaces instead of using Azure Lighthouse

One of the most damaging misconfigurations we see is when an MSSP deploys two separate Sentinel environments instead of using Azure Lighthouse for proper multi-tenant management.

In practice, this means there is one Sentinel workspace in the customer’s tenant (often minimally configured, with incidents auto-closed and little operational value) and a second workspace in the MSSP’s own tenant, where they perform most of their actual monitoring and detection work.

This “dual Sentinel” approach is typically done for two reasons: to simplify the MSSP’s internal operations across their customer base, and to retain their proprietary detection IP (analytics rules, playbooks, and custom logic) by keeping it in their own environment where the customer cannot see it.

The consequences are significant.

PII and CII leaves your tenant boundary. For the MSSP to monitor effectively in their own workspace, your data has to be ingested there. This means sign-in logs containing user identities, endpoint telemetry from your devices, email metadata, and other sensitive information is being copied outside your Entra tenant boundary. Personally identifiable information and commercially identifiable information is leaving the environment you control, potentially without your full awareness. Depending on your regulatory obligations, this may represent a serious compliance breach.

Fragmented visibility. Incidents are often auto-closed in the customer-facing workspace and managed exclusively in the MSSP’s environment. This strips away the telemetry benefits of your own XDR technology, masks true SLA performance, and removes your ability to review how your security operations are actually being delivered.

Data residency risks. The MSSP’s Sentinel instance could be in a completely different Azure region to your own, raising additional compliance concerns and breaking the core architectural principle of keeping your security data within your tenant.

Lack of operational governance. Running parallel Sentinel instances is the opposite of Microsoft’s architectural best practice. It typically points to an immature service that is not built to deliver scalable, transparent 24/7 security operations.

Mistake 3: No data collection rules for non-Microsoft log sources

This mistake is less visible but often the most expensive.

When ingesting logs from non-Microsoft sources into Sentinel (firewalls, SaaS applications, network appliances, identity providers, and similar), Microsoft provides Data Collection Rules (DCRs) as the mechanism to filter and transform data at the point of ingestion. DCRs allow you to drop unnecessary fields, parse and normalise data, and reduce the volume of what lands in your Log Analytics workspace before you are billed for it.

Many MSSPs do not implement DCRs. Instead, they ingest raw, unfiltered log data directly into the workspace. Every field, every redundant entry, every low-value log line is stored and billed at the full Sentinel ingestion rate.

The result is massively inflated costs. Organisations end up paying for gigabytes of data that adds no detection value, no investigative context, and no compliance benefit. In many cases, proper DCR configuration could reduce ingestion volumes (and therefore costs) significantly, while actually improving detection quality by ensuring analysts are working with clean, normalised data rather than wading through noise.

This is particularly common with legacy collection methods where the MSSP has not moved to the Azure Monitor Agent (AMA) and modern DCR-based pipelines. If your MSSP is ingesting Syslog, CEF, or custom logs without any transformation layer, it is worth asking what you are actually paying for.

The Chorus Cyber Approach

At Chorus Cyber, we deliver managed security operations using Microsoft’s architectural best practice.

We deploy Sentinel into your Azure tenant, in a subscription you own and control. We access it securely through Azure Lighthouse with delegated permissions, meaning you retain full visibility into your analytics rules, incident history, and configuration at all times. There is no data copied or exported to third-party tenants, no fragmentation, no duplication, and no shadow environments.

We implement Data Collection Rules across all log sources to ensure efficient, cost-effective ingestion. You get clean, normalised data that drives better detection outcomes, and you are not paying for noise.

The result is a single, authoritative incident timeline with full customer ownership, clean governance, and transparent billing. This is what allows us to scale and deliver high-performing MXDR services with the transparency our customers and partners expect.