Clay Governance
Operate Clay safely and predictably — across workspace, data, cost, workflows, integrations and operations.
Governance is what separates a Clay deployment that scales from one that quietly becomes an operational risk. We implement governance as a working operating model — not a policy document nobody reads.
| Domain | What it covers | Minimum standard | Typical owner |
|---|---|---|---|
| Workspace | Roles, permissions, admins/builders/users, environment separation | Who can build, who can deploy, who can touch production — reviewed quarterly | Admin |
| Data | Canonical fields, validation, normalization, taxonomies, approved sources | Every enriched field has one defined source of truth | Data/RevOps |
| Cost | Provider hierarchy, waterfalls, credit budgets, AI usage | Credit spend mapped to workflows with per-provider ceilings | RevOps |
| Workflow | Naming, documentation, testing, deployment, rollback, ownership | No production workflow without a named owner and docs | GTM Engineering |
| Integration | API keys, CRM writes, webhooks, warehouse access | Scoped, inventoried, rotated credentials; audited CRM writes | IT/Security |
| Operational | Logging, monitoring, error handling, incident response | Failures alert a named owner within minutes, not weeks | Ops |
Maturity levels we assess against
Ad-hoc
Workflows built by individuals, undocumented; permissions accumulate; costs visible only on the invoice.
Defined
Naming, ownership and source-of-truth rules exist and are mostly followed; environment separation is partial.
Managed
Change management, monitoring and cost controls operate across all six domains; reviews happen on a cadence.
Optimized
Governance is automated where possible; new use cases inherit standards by default; audits are routine.
Most enterprise deployments we assess sit between Ad-hoc and Defined — usually with cost and integration governance furthest behind. The full framework, including the ownership matrix and policy examples, is in the Governance Framework resource.