Security and the data boundary

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

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.

The browser accepts artifacts only from the registered customer storage binding and validates their format and size. Preview contents stay in clearable browser memory. Changing the selected result, signed-in identity, or storage binding clears the prior preview and stops its pending reads. 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. 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 delegated authority to reconcile the required workspace Viewer memberships. Storage and Fabric tokens used by the browser are never submitted to the General Validation API. See Azure resources and permissions 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. Resource access, asynchronous operations, and database access remain organization-scoped. Results are matched to their customer environment, run, and submission before their metadata is accepted. 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.

​

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 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.

​

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 when retiring an environment.