The DPO's Operating System: How the IQWorks Suite Fits Together

A DPO running a privacy program typically ends up running a small IT estate of their own: a notice builder, a consent banner vendor, a discovery scanner, a spreadsheet for data subject requests, and now an AI assistant that knows nothing about any of it. Each tool has its own login, its own copy of the data principal's record, and its own idea of what "the org" contains. Keeping them in sync becomes a second job.

IQWorks was built to avoid that outcome by design, not by integration project. ComplyIQ, ConsentIQ, DiscoverIQ, ClassifyIQ, ConsultIQ, and ChatIQ are separate products with separate jobs, but they sit on one identity layer and one data layer underneath. The rest of this piece is about what that actually means in the product, not as an architecture diagram.

One org, one login

Every product in the suite authenticates against the same Auth0 tenant. A user signs in once, and the JWT that comes back carries the organization ID and role claims that every app reads. There is no separate account to provision in ConsentIQ after a user already exists in ComplyIQ, and no second password to rotate.

The same JWT also carries the role — Super Admin, Admin, Team Member, or Viewer — and that role means the same thing everywhere. An Admin who can approve a DPIA in ComplyIQ has the equivalent write access in ConsentIQ; a Viewer who can read incidents in ComplyIQ is read-only in DiscoverIQ too. A product switcher lets a user move between the products their org has licensed without a fresh login, because the session already establishes who they are and which org they belong to.

One data spine underneath

Underneath the login sits Row Level Security: every query is scoped to the organization ID in the JWT, enforced at the database, not just checked in application code. That is what keeps one customer's data activities, consent records, and incidents invisible to another customer, regardless of which product is asking.

The products also share a common code layer rather than each reimplementing the same concepts. Data subject request handling, consent records, the data inventory model, and the read tools that power AI features all live in one shared package that every app imports. A "data activity" is the same entity whether it was created in ComplyIQ's inventory or read by ConsultIQ's advisor — not a lookalike record that has to be reconciled later.

Where the products actually meet

The shared spine shows up as concrete wiring between products, not just a shared login screen.

A privacy notice built and published in ComplyIQ's Notices module is the basis for the live consent page ConsentIQ serves to the data principal — the purposes and data items in the notice reach the person as a consent capture point, rather than as a second document someone has to keep in sync by hand.

When a data subject request comes into ComplyIQ, the DSR workflow can deep-link a DiscoverIQ scan pre-filled with the requester's identifiers — email, name — so whoever is fulfilling the request starts a targeted scan instead of retyping the same search terms into a separate discovery tool. DiscoverIQ's scan results, in turn, are what ClassifyIQ applies its labeling rules against, turning detected attributes into policy-driven classification levels.

ConsultIQ, the AI compliance advisor, reads that same live data. Its org-scoped read tools query the data activities, assessments, and incidents ComplyIQ manages, so its chat answers and its drafts inside Word, Excel, and PowerPoint are grounded in the organization's actual compliance record rather than a generic knowledge base. ConsultIQ also has knowledgebase search built in; ChatIQ, the suite's embeddable chat widget, does not — the two serve different jobs, and neither is described as doing the other's.

Why the operating system matters more than any one feature

None of these products needs the others to function. ComplyIQ runs a compliance program on its own; ConsentIQ runs a consent program on its own. The difference the shared spine makes shows up in what a DPO does not have to do: re-enter the same principal, re-explain the same notice, or re-export a scan result to hand to another tool. The record created in one product is the record the next product reads.

That is also what keeps the suite auditable as a whole. Because access is enforced by the same JWT and Row Level Security everywhere, an auditor reviewing who could see what does not need a separate answer per product — the answer is the same organization boundary, checked the same way, on every query.

The suite runs on one Auth0 tenant, one JWT, and Row Level Security enforcing organization isolation on every product, every query. See the suite fit together in your own environment: book a demo.