Enterprise security and operations

Fabric Experiments combines organization-scoped access control, governed test evidence, audit history, and production release policy. This guide explains the controls available to enterprise evaluators and the responsibilities that remain with the deploying organization.

Functional adoption versus independent assurance

The technical adoption gate answers whether the product works reliably for a real project. It covers published-package installation, CLI/API/Studio integration, tenant isolation, Databricks workload checks, browser-to-Delta delivery, Quality publication, load behavior, failure recovery, credential rotation, backup/restore, rollback, and repeated scheduled execution.

Independent certifications and organizational reviews answer a different question. They may be required by a customer's procurement policy, but Fabric does not treat a missing SOC 2 report as proof that a CLI command, Databricks check, or tenant boundary works. Teams can evaluate and pilot the product using the technical evidence while separately deciding which independent assurance they require before handling regulated or business-critical data.

The current Fabric-operated staging observation window is shown on Certification evidence. Customer acceptance must additionally exercise representative workloads, scale, identity, network, and recovery topology in the customer's own environment.

Available controls

Studio is not the security boundary. The API repeats authorization, tenancy, and Quality-policy checks for every protected operation.

Documentation content security policy

Every HTML response receives a cryptographically random nonce at the Cloudflare edge. The worker adds that nonce to executable <script> elements and inline <style> blocks, and the response CSP accepts only matching elements. script-src does not contain 'unsafe-inline', and inline script attributes are disabled with script-src-attr 'none'.

The static documentation framework uses inline style attributes for layout and interactive component positioning. Those attributes are narrowly isolated to style-src-attr 'unsafe-inline'; the broader style-src and style-src-elem directives do not grant an unscoped inline exception. This style allowance cannot authorize JavaScript execution. The deployment workflow checks the CSP and rewritten HTML after every production deployment, and the weekly hosted-security probe repeats the check.

Recommended enterprise setup

1. Use separate organizations for unrelated security boundaries.
2. Integrate the chosen IdP and exercise sign-in, sign-out, deactivation, and recovery before inviting production users.
3. Assign the lowest suitable Fabric role and least-privilege Databricks grants.
4. Create separate, expiring Quality publisher keys for each CI environment.
5. Use dedicated development, staging, and production Databricks resources.
6. Publish required suites to Quality Center and enable the production gate.
7. Configure retention and export audit/evidence to the organization's approved archive or SIEM when independent retention is required.
8. Exercise backup/restore, rollback, credential rotation, and access revocation on disposable resources.
9. Record the exact supported cloud, region, runtime, compute mode, and network topology in the deployment acceptance criteria.

Identity and access

Databricks Apps authenticates access to the hosted application. Fabric then authenticates the application session or API key, resolves organization membership, and enforces the Fabric role. Access to the Databricks App alone does not grant access to another Fabric organization.

For automation, prefer short-lived OAuth or workload identity at the Databricks boundary and an expiring organization-scoped Fabric API key for Quality publication. Do not share human credentials with CI.

The hosted API and Studio role selector continue to use the four fixed roles. Fabric's TypeScript assurance layer additionally evaluates versioned custom roles, case-insensitive IdP group bindings, permission simulations, separation-of-duties approval quorums, and ticket-bound break-glass grants. Enabling a customer-specific policy requires an explicit integration and access review; defining a policy file alone does not change hosted authorization.

Evidence, retention, and audit

Quality Center accepts Fabric BDD/live evidence and supported standard test formats. Evidence is associated with the authenticated organization and can be used by a server-enforced production promotion policy.

Retention and legal hold apply to Fabric-managed records. The recurring Fabric assurance job signs its technical evidence with Ed25519, generates a CycloneDX 1.6 production dependency SBOM, stores both in a dedicated R2 bucket with a seven-year retention lock, retrieves both objects, and verifies their SHA-256 digests. Customer evidence and audit exports should use the customer's approved archive or SIEM when independent control is required. Fabric does not represent legal hold as a complete e-discovery service.

Recurring technical assurance

The weekly enterprise job exercises these controls as one fail-closed suite:

• custom-role/group resolution, permission denial, two-person promotion, and short-lived break-glass access;
• Azure residency placement, tenant encryption context, complete-store deletion receipts, and cryptographic erasure;
• data inventory validation, subject export, and multi-system deletion proof;
• quota enforcement, configuration drift, and time-bound support access;
• SLO calculations, backup integrity, rollback, and measured RPO/RTO;
• customer offboarding completeness;
• hosted security headers and OAuth gateway boundaries;
• WCAG 2.2 A/AA browser scanning, dependency audit, coverage, and Databricks framework tests; and
• signed evidence/SBOM archival with retrieval verification.

Machine-readable artifacts include readiness.json, assurance.json, assurance.signed.json, sbom.cdx.json, archive-receipt.json, and hosted security evidence. CI artifacts are retained for one year; signed evidence and SBOMs are retained under the archive lock for seven years.

Reliability and recovery

The Databricks live suite includes performance, failure-recovery, secret-rotation, backup/restore, and rollback probes. These checks validate the configured test target; they do not replace the customer's service-level, regional recovery, or business-continuity program.

Before production adoption, test dependency failures involving Databricks, Lakebase/Postgres, Cloudflare, identity providers, email delivery, and audit destinations. Define customer-owned RPO/RTO objectives and verify restoration from backups stored outside the primary failure domain.

Fabric's recurring evidence is intentionally split by risk. Foundation checks run nightly, classic compute and advanced Databricks checks run weekly, and the enterprise readiness job reviews control freshness, package security, tenant tests, framework coverage, documentation headers, and the Studio OAuth gateway weekly. Failed checks retain machine-readable CI artifacts and do not silently convert an unavailable target into a pass.

Generated reports/ files are intentionally excluded from source control. Retained CI artifacts and tenant-scoped Quality Center history are the authoritative run evidence, preventing an old local result from being mistaken for the current certification state.

These automated checks cover technical regression detection. A formal assurance decision remains incomplete until the customer-required dated organizational evidence exists for an access/break-glass review, independent penetration test, regional recovery game day, privacy and subject-request review, assistive-technology review, SOC 2 readiness assessment, and complete customer lifecycle rehearsal. The weekly evidence records these external gates separately and never converts missing human evidence into an automated pass.

When formal assurance is part of the production decision, store the approved external-evidence manifest as the base64-encoded FX_EXTERNAL_ASSURANCE_MANIFEST_B64 CI secret and run the production assurance gate. Each record must use an HTTPS evidence location, remain inside the control's review cadence, and name two independent approvers. Missing, expired, future-dated, overlong, or singly approved evidence fails the gate. The weekly technical regression job continues to run while these external records are being collected; it reports them as incomplete rather than claiming an assurance pass.

Data and privacy responsibilities

Collect only identifiers and dimensions needed for the experiment or quality decision. Browser integrations should honor the organization's consent and tracking policy. Avoid placing production secrets, unrestricted personal data, prompts, model responses, or sensitive fixtures in test evidence.

Fabric maintains a versioned processing inventory and provides typed export, deletion-receipt, placement, and cryptographic-erasure validators. The deploying organization remains responsible for approving classification and lawful basis, confirming every external processor and region, and executing real subject requests against its configured systems.

Assurance boundary

Fabric provides implementation and operational evidence for the capabilities named in this documentation. It does not currently claim SOC 2, ISO 27001, HIPAA, FedRAMP, PCI, or another independent certification for the product. Customers requiring a formal attestation should treat that as an evaluation requirement rather than infer it from automated tests.

Azure Databricks is the current certified workload target. AWS and Google Cloud Databricks, private networking variants, customer-managed encryption keys, and regulated deployment profiles require customer-specific validation and are not currently certified by Fabric.

See Enterprise governance for configuration steps, Compatibility for precise supported and unsupported behavior, and Certification evidence for the named live target boundaries.