Compliance in the Composable Era: What Has to Move

When a regulator, an auditor, or your own legal team asks "who changed this disclosure, when, and who approved it," a surprising number of enterprises cannot answer for content that lives across a marketing DXP, a commerce platform, and three regional microsites. The compliance obligation did not disappear when the architecture went composable. It fragmented. Each system now holds a piece of the audit trail, and the seams between them are exactly where governance breaks.

That is the real cost of the shift from a monolithic suite to a composable stack: accountability that used to live in one workflow engine now has to be reassembled across services that were never designed to answer a legal question together. Sanity, the Content Operating System for the enterprise, exists to put that accountability back in one place. It treats content as governed, queryable structured data with a shared record of who did what, so approvals, audit logs, and data residency are properties of the content itself rather than features of whichever tool happened to touch it last.

This guide maps what actually has to move when compliance goes composable: the controls you keep, the ones you re-architect, and the ones you can finally centralize instead of duplicating per system.

The audit trail is the first thing composability breaks

In a legacy DXP, the audit trail is a byproduct of the workflow engine. Every edit, review, and publish passes through one system, so the log is complete almost by accident. Decompose that suite into a headless content service, a separate DAM, a commerce engine, and a personalization layer, and the single log fragments into four partial ones. When compliance asks for the lifecycle of a regulated claim, someone has to stitch timestamps across systems whose clocks, user identities, and event models do not agree. The gaps between those systems are not edge cases; they are where the version that shipped diverges from the version that was approved.

This is the governance tax of composability that vendors rarely quote. You gain flexibility and lose the free audit trail, and reconstructing it after the fact is expensive and never quite trustworthy. The fix is not to re-monolith. It is to make one system the authoritative record for content changes and treat everything downstream as a consumer of that record.

Sanity maps this to its first pillar, model your business, by keeping content as structured data in Content Lake with change history and Audit logs attached to the content itself. Because editing, review, and publishing run through Sanity Studio against that store, the record of who changed what and when is a property of the content, not a report you assemble from four vendors. Downstream systems read from Content Lake, so the authoritative history lives in one place even when delivery is distributed across many.

Approvals have to become content properties, not tool features

The second thing that has to move is the approval itself. In most legacy DXPs, an approval is a state inside the workflow engine: a page sits in a review queue until a named role signs off. That model assumes the content and the approval live in the same box. Composability breaks the assumption. If your commerce copy is approved in one tool but assembled and shipped by another, the approval and the artifact can drift apart, and the version a customer sees may not be the version anyone signed.

For regulated content, financial disclosures, medical claims, pricing terms, that drift is the failure mode auditors care about most. The control you need is not a prettier review queue. It is a guarantee that the approved unit and the shipped unit are the same object, with the sign-off recorded against it.

Sanity addresses this with Content Releases, which let editors stage a batch of changes and ship them as a single reviewable unit rather than as scattered edits going live one at a time. This is the enterprise equivalent of git branching for editors: a release is a coherent, reviewable set of changes with a record of who approved it. Roles & Permissions govern who can create, approve, and publish a release, and Audit logs capture the sequence. Because the release is the thing that ships, the approved unit and the live unit cannot silently diverge, which is the exact assurance a governance review is looking for.

Data residency stops being a hosting checkbox

Under GDPR and the growing patchwork of regional data laws, where content and its associated personal data are stored is a legal question, not an infrastructure preference. In a self-hosted DXP, residency is your problem to solve: you provision regional instances, replicate carefully, and hope your DR strategy does not quietly move regulated data across a border. Every region you add multiplies the operational surface you have to keep compliant.

Composability can make this worse before it makes it better, because each service in the stack has its own hosting story, its own sub-processors, and its own residency guarantees. Compliance now has to reason about the union of all of them. The move that actually helps is consolidating the content record onto a platform that treats residency as a first-class, contractual property rather than something you engineer per deployment.

Sanity runs on Content Lake, a multi-tenant, multi-region content store, which means you consume residency guarantees instead of operating the database that provides them. Its compliance posture, SOC 2 Type II, GDPR alignment, regional hosting options, and a published sub-processor list, is documented rather than assembled by your ops team. For a buyer replacing a self-hosted AEM or Drupal estate, this is a material shift: the residency and certification questions on your RFP get answered by the vendor's attestations rather than by your own infrastructure diagrams.

AI-generated content is now inside the compliance perimeter

The uncomfortable new line item in every governance review is content that a model wrote or edited. The EU AI Act and sector regulators increasingly expect organizations to know which content was machine-generated, on what basis, and who reviewed it before it reached a customer. If your composable stack bolts a generation tool onto the side of the content workflow, the output can land in production without ever passing through the review and audit path your human content follows. That is a compliance gap with a regulatory deadline attached.

The reframe for enterprise buyers is that AI does not need a separate governance regime. It needs to be pulled inside the one you already run: same approvals, same audit trail, same release gate. A machine-drafted disclosure should be indistinguishable, from a control standpoint, from a human-drafted one. It should be reviewable, attributable, and blocked from shipping until signed.

This is where Sanity's built-for-AI stance matters more than a bolted-on feature. Functions and the App SDK let enterprises run enrichment, moderation, and compliance checks as automated steps inside the same content workflow, so AI-touched content flows through Content Releases, Roles & Permissions, and Audit logs like everything else. The pillar here is automate everything: the goal is not to generate faster and govern later, but to make governance an automated property of every change, whoever or whatever authored it. AI content stays inside the editorial loop, which is exactly where a regulator expects to find it.

Multi-brand and multi-market multiply every control you forgot to centralize

For a global enterprise, compliance is rarely one policy. It is dozens: different disclosure rules per market, different consent requirements per region, different brand and legal sign-off chains per business unit. Legacy DXPs handle this with per-instance configuration, which is why large organizations end up running many installations that drift apart over time. Every drifted instance is a place where a control was applied inconsistently, and inconsistency is what turns a single market's mistake into an enterprise-wide finding.

The composable answer is not more instances. It is one governed foundation that expresses market and brand differences as data rather than as separate deployments. Centralize the shared controls once, and vary only what genuinely differs per market, so a policy change propagates instead of needing to be re-implemented dozens of times.

Sanity supports this through Studio Workspaces, which let a single Studio model multiple brands and markets, and multi-dataset architecture with dataset aliases for separating and promoting content across environments. Translations integrate with Phrase and Smartling as well as a native plugin, so localized regulated content moves through the same review path as the source. The differentiator against legacy DXPs is structural: instead of scaling headcount to keep many installations compliant, you model your estate once and scale output, which is the shared foundation argument that separates a Content Operating System from a fleet of siloed CMS instances.

Migration is a compliance event, not just a technical one

The reason enterprises tolerate a governance-poor legacy DXP for years is that replatforming feels like a two-year, all-or-nothing risk. But the migration itself is a compliance-sensitive moment: during a cutover, the audit trail can break, approvals can lapse, and regulated content can slip through in an ungoverned state. A big-bang reimplementation maximizes exactly that window of risk. The safer path is incremental, moving content estate by estate while the controls stay intact on both sides.

The practical enterprise question is not whether the new platform is better in the abstract. It is whether you can move onto it without a governance blackout in the middle. That favors a model where content becomes structured, queryable data early, so it can be validated, mapped, and reconciled against the legacy source before anything is decommissioned.

Sanity's API-first design, GROQ querying over Content Lake, and its Partner network of systems integrators are built for staged migrations rather than heroic cutovers. Content lands as structured data you can query and audit from day one, Roles & Permissions and Audit logs are in force from the first import, and Content Releases let you promote migrated content in reviewable batches. For a buyer moving off AEM, Sitecore, or Drupal, the compliance win is that governance is continuous across the migration rather than suspended during it, which is precisely the assurance that makes a board comfortable signing off on the move.