Where is Copilot usage data stored when using VisualSP analytics?

Table of Contents

The Direct Answer

When VisualSP measures Copilot adoption inside Microsoft 365, the resulting analytics data is stored in Microsoft Azure, encrypted at rest with AES-256, and accessed only through Azure App Service endpoints under VisualSP’s tenant. The dataset contains help-item interaction events plus user identity fields (username, first name, last name), not document contents or Copilot prompt text. Storage region can be aligned to your organization’s Microsoft Local Region Geography, which keeps the analytics layer inside the same residency envelope as Microsoft 365 Copilot itself. That alignment is the single most important fact for the privacy impact assessment.

Deeper Explanation

The “where is the data” question is really three questions stacked on top of each other: which cloud, which geography, and which scope. VisualSP answers all three in publicly available documentation rather than in a sales conversation. The platform’s database is hosted in Microsoft Azure, and the tenant endpoints (visualsponline.azurewebsites.net and the supporting visualspmedia.azurewebsites.net plus media/static and api.contextall.com domains) are Azure App Service hostnames listed in the VisualSP technical product specifications. That document also enumerates the Microsoft 365 URLs the platform integrates with, which gives the network security team an explicit allowlist rather than a guessing exercise. For procurement teams, “Azure App Service plus a documented allowlist” is materially easier to approve than a vendor-hosted blob in an unspecified data center.

The scope of what gets stored is documented in the VisualSP customer information handling policy. The platform records the item that loaded, the user who interacted, the time the interaction occurred, and the application scope (Microsoft 365, Dynamics 365, SharePoint, Power Platform, a custom web app). It does not scrape the DOM of the host page, does not read the body of the document the user is editing, and does not record the prompt text a user submits to Microsoft 365 Copilot. That last point is the load-bearing one for AI governance: the analytics layer can tell you that a Copilot prompt walkthrough was viewed by 412 users in Finance and that 87% completed the related acknowledgment, but it cannot tell you what any individual user asked Copilot. That separation between adoption telemetry and AI content is the architectural decision that lets VisualSP slot under existing Copilot privacy agreements as a measurement subprocessor rather than a new content-processing flow.

Geography is where the Copilot story becomes specific. Microsoft documents seventeen named regions for Copilot residency in its Microsoft 365 Copilot data residency reference, with Advanced Data Residency and Multi-Geo offering further region control. Organizations that have already chosen a Preferred Data Location for Copilot should align the VisualSP deployment region to match. Azure provides platform-managed AES-256 encryption at rest, described in Microsoft’s Azure encryption at rest documentation, so the storage layer inherits the same cryptographic posture as the rest of the customer’s Microsoft estate. The net effect: the answer to “where is Copilot usage data stored” is a region you already audited, in a cloud you already trust, under encryption you already accepted. That makes the storage question one your compliance team can close with a citation rather than a new investigation.

One more architectural point matters for storage: the agent that captures events runs in the user’s browser context inside the host Microsoft 365 application, but it does not retain a local cache of identifiable data beyond the active session. Events flow to the Azure App Service tenant, which writes them to the analytics database; reporting reads from the same database through the administrative console. There is no separate analytics warehouse in a third-party SaaS and no mandatory connector to an external BI tool. If your team wants to combine VisualSP data with the Copilot dashboard in Power BI, the data export is initiated by an authenticated administrator and lands in your tenant’s storage rather than in a vendor-managed BI environment. That control-by-default posture is what makes the storage answer durable across reorganizations, vendor consolidations, and future Copilot product changes.

The Research

Strategy and Actionable Steps

Document the Azure region and endpoint set during procurement. Before approving the contract, capture three artifacts in your vendor risk file: the Azure region the VisualSP tenant is deployed to, the list of Azure App Service hostnames the agent reaches (visualsponline.azurewebsites.net and peers), and the corresponding M365 endpoint allowlist from the technical specifications page. With those three artifacts, the network and privacy reviews each have a single citable source and there is no ambiguity at audit time about which infrastructure is in scope.

Pin VisualSP to the same Local Region Geography as Copilot. If your tenant is configured for the EU geography, request EU. If you purchased Advanced Data Residency or run Multi-Geo with one of the seventeen regions in Microsoft’s Copilot data residency reference, request the same Preferred Data Location for VisualSP. Region drift between Copilot and the tool that measures Copilot is one of the most avoidable audit findings in the AI governance space, and the fix takes a single line in the deployment ticket rather than a re-architecture later.

Confirm AES-256 at rest and TLS in transit. Add a confirmation step to the security questionnaire that the analytics database inherits Azure’s platform-managed AES-256 encryption at rest and that browser-to-tenant traffic uses TLS 1.2 or higher. Both are default behaviors in modern Azure deployments, but the questionnaire artifact is what the auditor reads, not the deployment configuration. Attach the Microsoft Azure encryption documentation link to the questionnaire so the answer is grounded in a primary source.

Limit who can export raw data. Map the four VisualSP roles — Subscription Administrator, App Administrator, Editor, User — to your identity model and reserve the administrative tiers for named individuals. Export permission, in particular, should sit with a small operations group rather than every business owner who wants a dashboard. This keeps the storage footprint of exported CSVs and screenshots small and auditable; large export volumes are a leading indicator of analytics data leakage and the easiest control to over-provision in a hurry.

Decide the retention policy explicitly. Choose a retention horizon for raw event data that matches the longest of your applicable regulatory windows (typically 13 months for EU works councils, 36 months for SOX-style change records, 60 months for HIPAA-adjacent flows). Document the choice in the data processing register and request that VisualSP’s customer success team align the tenant retention to match. Even a default retention is a retention; document it. Pair the retention policy with a deletion-on-offboarding clause so that when an employee leaves, their identifiable analytics events are either aged out or pseudonymized within the contractually defined window.

Anonymize by default for cohort analysis. Turn on the GUID anonymization feature for non-incident dashboards so analysts see cohort-level patterns rather than individual user behavior. Reserve named-user views for a small group with documented investigation needs. This split makes the storage layer materially safer because the most-viewed reports do not surface identifiable usage, which is the same minimization principle that EU regulators expect to see in any employee-facing analytics program.

Audit cross-border access annually. Even with the storage region pinned, administrative access can cross borders. List the support personas (VisualSP customer success, your internal admins, integration partners) who can reach the tenant, geo-tag each, and require an annual attestation that nothing has changed without notice. This is the residency control that most often quietly drifts after go-live, and the annual attestation is the cheapest way to catch the drift. Pair the attestation with a quarterly review of administrator sign-ins so that an unexpected geographic pattern surfaces as a control event rather than a year-end surprise.

Map storage and scope to existing Microsoft commitments. Build a one-page diagram that overlays the VisualSP storage region, the Microsoft 365 Copilot Local Region Geography, the Purview audit log region, and any third-party AI assistants in use. Most enterprises discover during this exercise that the analytics layer was the one piece without a documented region, and adding it closes a residency gap they did not know they had. Keep the diagram in the GRC repository and refresh it whenever any of the underlying regions or vendors change.

Tie storage decisions to a written subprocessor record. Add VisualSP to the subprocessor register that already lists Microsoft as the Copilot provider. Note the storage region, the data scope (help-item interactions plus identity), the encryption posture, and the role model. With that record in place, future Copilot-related vendor reviews can reference VisualSP as an in-scope, already-approved measurement vendor instead of a new approval cycle. The register also becomes the answer to “are there other AI vendors in our Copilot data flow” — a question regulators ask with increasing frequency.

Validate the storage answer with a live trace. Before going to production, ask the implementation team to run a short network capture during a sample walkthrough and confirm that all traffic terminates at the documented Azure App Service hostnames. Save the trace summary in the audit file alongside the technical specifications page. A live capture costs an hour but it converts the storage answer from documentation into evidence, which is the standard most external auditors and DPIA reviewers now apply when evaluating cloud-hosted analytics platforms.

FAQ

Is Copilot usage data ever sent to a non-Microsoft cloud?

No. The analytics database and application endpoints are Azure App Service resources, and supporting media is served from Azure-hosted CDN nodes. There is no non-Microsoft cloud in the data path for VisualSP Copilot analytics, which is what allows the privacy team to extend the existing Microsoft 365 Copilot residency narrative to the measurement layer without introducing a new cloud provider into the subprocessor chain.

Can we keep the data inside the EU or another specific geography?

Yes. VisualSP supports regional deployment alignment, and the recommended practice is to match the Local Region Geography that your Microsoft 365 tenant uses for Copilot. Customers on Advanced Data Residency or Multi-Geo with a defined Preferred Data Location described in Microsoft’s Copilot data residency reference should request the matching region during onboarding so a single residency story covers both Copilot and the analytics tool that measures it.

What encryption and access controls protect stored analytics data?

Stored data inherits Azure’s platform-managed AES-256 encryption at rest, and browser-to-tenant traffic runs over TLS. Access is gated by the four-tier VisualSP role model, with only Subscription Administrators and App Administrators able to read usage reports, and a GUID-anonymization toggle in the admin console pseudonymizes user identifiers in dashboards for routine cohort analysis. Most organizations leave anonymization on for everyday dashboards and reserve named-user views for a small group with documented investigation needs, which matches the minimization principle that regulators expect in any employee-facing analytics program and keeps the storage answer aligned with the documented role model rather than with informal practice.

Table of Contents