> ## Documentation Index > Fetch the complete documentation index at: https://docs.generalvalidation.com/llms.txt > Use this file to discover all available pages before exploring further. # Security and the data boundary > Understand what the hosted application stores, what stays in your Azure subscription, and how identities separate metadata from customer data. General Validation is a hosted service with customer-owned Azure execution. The application coordinates validation using metadata. Your Azure Data Factory reads source and target data, runs the checks, and writes exact results and captured failed rows to your storage. ## Where information is processed | Information | Location | | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------- | | Organization and membership records | General Validation | | Dataset definitions, schemas, source coordinates, and validation rules | General Validation | | Run lifecycle, verdicts, counts, bounded reason codes, hashes, and validated artifact references | General Validation | | Source and target rows and customer data credentials | Your Azure environment | | Temporary staging, exact aggregate values, deltas, and authoritative Delta results | Your Azure environment | | Captured failed rows and browser result artifacts | Your Azure storage; read directly by an authorized browser | | Subscription and billing details | General Validation and its billing provider as required to manage your subscription | Metadata can still be sensitive. Dataset names, schema fields, source coordinates, and validation definitions are part of the hosted service's configuration; account for that when reviewing the service. Exact values, deltas, credentials, and row evidence do not traverse or persist in vendor APIs, background services, databases, logs, telemetry, support systems, or caches. The application does not use a vendor proxy to display customer evidence. ## How a result reaches the screen 1. Customer Data Factory reads the selected datasets and performs the validation in your subscription. 2. The runtime writes the authoritative result to customer Delta storage. 3. Customer-side delivery writes browser artifacts and sends the hosted application only the permitted result metadata and artifact references. 4. When you open the result, your browser uses your Microsoft identity to read exact metrics and captured failed rows directly from customer storage. Viewing detailed results requires access to the environment's customer storage as well as General Validation membership. Result previews are read directly by the browser and are not uploaded to the hosted application. An exact metric can be sensitive even without a failed-row sample. A minimum or maximum, for example, can reveal a value from a customer record. Exact metrics follow the same customer-side boundary as row evidence. ## Access in your Azure subscription You review and deploy the environment template under your Azure authority. It creates dedicated execution resources and scoped role assignments, then General Validation verifies that deployment before enabling the environment. | Identity | Responsibility | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- | | Customer execution Data Factory identity | Reads approved sources, stages inputs, executes validation, and writes customer results | | Customer callback identity | Authenticates bounded metadata delivery to the hosted application | | Customer user or reader group | Reads browser artifacts through customer Azure storage RBAC | | General Validation application in your directory | Reads approved metadata, manages execution factory content and runs, and manages constrained source-reader assignments | General Validation's Azure roles contain no customer-storage data actions, key-listing permission, or secret-reading permission. For supported ADLS Gen2 imports, a classified customer-side permission failure can trigger a **Storage Blob Data Reader** grant on the verified container for this environment's execution-factory identity. The delegation limits the role and recipient, and preparation verifies the resulting access with a new customer-side probe. Network or missing-file failures require their own fixes. Azure SQL permissions remain customer-managed. Fabric guided setup uses the signed-in user's authority to grant workspace **Viewer** access to the customer execution factory. That role allows workspace-wide reads, including Lakehouse and Warehouse SQL data. The customer factory performs Fabric discovery and table-access checks. Current setup and repair do not request a Fabric workspace role for the General Validation application. Existing connections may retain earlier grants; review those assignments with your Fabric administrator. The [Fabric connection guide](/connect-microsoft-fabric#disconnect-a-workspace) explains removal and retained access. Storage and Fabric tokens used by the browser are never submitted to the General Validation API. See [Azure resources and permissions](/what-general-validation-provisions) for the deployment inventory and source-specific grants. ## Identity and organization isolation Microsoft Entra authenticates users and workloads. The hosted API validates bearer tokens and derives organization scope from the verified directory and identity. Users need active organization membership; machine callers need a recognized API application role in a connected directory. Reader, Contributor, and Owner permissions are cumulative. Your organization controls access to its configuration and run history through these roles. Customer storage RBAC is a separate access boundary. Product membership alone does not permit reading exact values or failed rows. Review both application membership and customer Azure access when changing a colleague's permissions. See [Sign-in and team access](/single-sign-on-and-access). ## Network posture The hosted application and API use HTTPS. The standard customer execution template uses public Azure endpoints protected by Microsoft Entra and Azure RBAC. Customer result storage requires TLS 1.2 and disables anonymous and shared-key access. Browser CORS is restricted to the application origin. The standard setup does not create a customer VNet, private endpoints, private DNS, a WAF, or forced-egress inspection. Source access must be reachable from the execution factory, and authorized users need a route to customer storage. Review requirements for private-only access with [support@generalvalidation.com](mailto:support@generalvalidation.com) before deployment. ## Diagnostics and support Vendor operational logs contain bounded diagnostic metadata such as request IDs, operation states, and typed error codes. Browser diagnostics use fixed fields and are available locally in developer tools. They are not a channel for uploading customer evidence. For support, share the request ID, run or operation ID, timestamp, and displayed error code. Review screenshots and diagnostic material before sending them; keep source rows, exact metrics, failed-row contents, credentials, and tokens inside your customer environment. See [Troubleshooting and logs](/troubleshooting-and-logs). ## Retention and disconnect Your team controls retention of customer results, staging, and failed-row artifacts. Current staging folders do not have automatic cleanup. Preserve anything required for audit and account for active execution before removing customer artifacts. Environment disconnect drains active work, removes product-created source reader grants, and revokes the environment's operator and source-grant delegation assignments. Customer resources and data remain, along with preexisting grants and other retained installer grants. Azure resource deletion and subscription cancellation are separate actions. Follow [Set up your Azure environment](/installing-general-validation#disconnect-and-resource-removal) when retiring an environment.