Why is it safer to keep analytics processing and result storage inside the customer tenant for managed security services?

Why Keeping Analytics Inside the Customer Tenant Reduces Exposure

When a managed security service processes telemetry and stores results inside the customer tenant, the provider does not need broad standing access to raw data or exported outputs. That reduces the chance of accidental disclosure, narrows the trust boundary, and keeps investigation artefacts closer to the customer’s own governance controls. It also helps avoid the common pattern where operational convenience slowly becomes data sprawl across tools, accounts, and support workflows. For teams managing sensitive logs, that distinction matters because the analytics layer often sees the same data that incident responders would treat as high-value evidence. In practice, many security teams only realise how much access was implied by a service design after the first audit request or cross-tenant data review.

For a practical lens on the wider non-human identity and credential exposure problem, the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful because it connects access scope, ownership, and revocation to real operational control.

How It Works in Practice

In a tenant-local model, the managed service typically reads data from sources already approved inside the customer environment, runs analytics under constrained permissions, and writes alerts, detections, or case notes back into customer-owned storage. The key design point is that the provider should not need to copy the full telemetry set into a separate multi-tenant repository just to operate the service. That reduces the number of places where sensitive events, identifiers, and investigative outputs can be inspected or retained.

Good implementations separate three things clearly: ingestion permissions, processing permissions, and storage permissions. Ingestion should be narrowly scoped to the data sources the service actually needs. Processing should run under a workload identity with limited rights to transform or correlate records. Storage should remain under customer control so retention, deletion, and export rules stay aligned with the customer’s policy. This is especially important where logs include account names, IPs, host metadata, token traces, or incident artefacts that can support lateral movement if exposed.

• Keep the customer as the owning tenant for workspaces, outputs, and retention policy.
• Use tightly scoped app registrations or managed identities rather than broad delegated access.
• Limit provider support access to time-bound, auditable operations.
• Prefer short-lived access paths for maintenance and troubleshooting.

The most relevant external control lens here is the NIST Cybersecurity Framework 2.0, because its governance and protect functions map well to ownership, access limitation, and recovery expectations. For evidence of why this matters operationally, NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, which is a strong reminder that moving data out of the tenant usually increases handling risk rather than reducing it. These controls tend to break down when the service is built for cross-customer convenience, because shared operational tooling makes it harder to prove where data lives and who can reach it.

Common Variations and Edge Cases

Tighter tenant-local processing usually increases operational effort, so organisations need to balance data minimisation against support complexity and integration overhead. That tradeoff becomes sharper when the provider wants centralised analytics, global case management, or shared model training across customers.

Not every function has to stay fully local, but any exception should be explicit and narrowly justified. Current guidance suggests treating exported telemetry, debug dumps, and analyst workbenches as separate risk objects rather than assuming they are harmless because they are “just operational data.” If the service requires data to leave the tenant, the customer should expect a more demanding review of retention, encryption, support access, and deletion controls. This is also where governance often fails in practice: a service may be marketed as tenant-isolated while secondary systems still copy logs, enrichments, or summaries into provider-owned tooling.

A useful decision rule is simple: if the service can still function without centralising the raw data, keep the raw data and durable outputs inside the customer boundary. If a centralised exception is unavoidable, constrain it to the smallest dataset and shortest retention period that actually supports the use case. The same principle applies to alerts and case notes, because those can reveal detection logic, response priorities, and incident context if they are broadly shared.

Practitioner takeaway: The safest tenant model is the one that prevents the provider from needing standing access to customer evidence in the first place, because once telemetry or results leave the boundary, governance becomes a copy-control problem instead of an access-control problem.

Related resources from NHI Mgmt Group

• What is the difference between keeping AI gateway analytics in customer-owned object storage and running a managed logging database in the provider cloud?
• What breaks when customer identity, app access, and third-party services are not controlled in one place?
• What happens when privileged accounts are managed without a layered security strategy?
• How should security teams reduce cross-tenant risk when using Power Platform HTTP connectors?