The Consent Management Platform Built for CTOs Who Care About Speed, Security, and Scalability

Yes. Enzuzo is SOC 2 Type 1 certified and is actively working toward Type 2 certification. We proactively share the SOC 2 report, security documentation, and our Data Processing Agreement during the evaluation process so your IT security and legal teams can review in parallel with any technical assessment.

If your vendor review process requires specific documentation beyond what we provide upfront, we'll work with your team to fill gaps. We've also completed Google CMP certification, which requires its own compliance submission and testing process.

If most of your consent-gated services are loaded through Google Tag Manager, the core integration is straightforward: add Enzuzo's GTM template, set firing triggers based on consent, and you're covered.

For tools that don't play nicely with GTM, like certain enterprise marketing platforms that need to be hardcoded into the site, our technical team writes custom code snippets during onboarding to bring those into the consent framework. That's included in the subscription, not an extra cost.

For framework-specific concerns like React DOM conflicts or CMS-level geolocation services, we set up a dedicated technical call with our architect to map out the right deployment approach before you commit to anything.

If your current CMP runs through GTM with consent-triggered tags, the migration is mostly changing triggers to point to Enzuzo instead of OneTrust. The deployment work you've already done carries over. You're not rebuilding consent logic from scratch.

Our geofencing defaults are more granular out of the box (state-level for the US, not just country-level), so you may want to review and trim those defaults to match your current approach.

We recommend overlap between your old and new CMP contracts, so you have runway to test on staging before cutting over to production.

If GTM is clean and your tags are already organized with consent triggers, the technical work will take an afternoon. We tell enterprise partners to budget one to two weeks to be conservative, since most teams want to deploy to a staging environment first and coordinate across engineering, legal, and marketing before going live.

You can absolutely phase it. Start with everything out of the box: banner configuration, geofencing, cookie categorization, consent logs. Then in phase two, explore the API for custom consent flows, programmatic banner control, or deeper integration with your own systems. Most enterprise customers take this approach.

This is the most common compliance gap we see. If you deploy the CMP through GTM and a portion of your audience blocks GTM entirely, the consent banner never fires and you have no consent record.

For audiences like that, we recommend loading the CMP script directly in the page head alongside GTM, not inside it. That way consent is defined on page load regardless of whether GTM is blocked.

Within GTM, all non-essential tags get consent-based firing triggers so they only execute after the consent signal is set. For scripts injected directly into theme code or loaded outside GTM, our team writes the consent checks as part of onboarding so nothing fires out of order.

We also run a cookie scan during onboarding to catch anything that's writing cookies before consent is established.

The goal is to get engineering out of the loop for day-to-day maintenance. Banner design, copy changes, regional settings, cookie categorization, and consent reporting are all managed through the dashboard without touching code.

If your marketing or compliance team wants to adjust which states are opt-in versus opt-out, or run A/B tests on banner UX, they can do that directly in the interface.

For GTM-managed tags, your marketing ops team can publish new tag changes with the correct consent triggers without filing engineering tickets.

Engineering only needs to get involved if you add a new tool that loads outside GTM or if you want to build custom consent flows through the API.

We count primary root domains, not subdomains. Subdomains share consent with their parent domain, so if a visitor consents on yoursite.com, that consent carries to app.yoursite.com, resources.yoursite.com, and any other child domains automatically.

Each root domain gets its own banner configuration, cookie scan, geofencing rules, and preference center, and you can toggle between them in the dashboard.

For third-party hosted subdomains like resource centers or booking engines running on a different server, you can set those up as separate entities and deploy via GTM or a direct script, as long as you can add either to the page.

Cross-domain consent between completely separate root domains is a known industry limitation. We handle that by running separate consent instances with consistent configurations.

We provide an enterprise Subscription Service Agreement, a Data Processing Agreement with a sub-processor appendix, and SLA documentation as part of the contract package.

The DPA covers standard data processing terms including data residency, retention, and transfer provisions for US, UK, EU, and Canadian frameworks. If your legal or procurement team needs contracts with individual sub-processors, we can pull those from our compliance platform.

We send all of this proactively once you're ready for vendor review so your legal team can work in parallel with technical evaluation rather than sequentially. Most enterprise customers run legal and technical review at the same time and close within two to four weeks.