Enterprise trust documentation

Hosting & Data Residency

CardIQ supports different deployment responsibility models. This page explains what the current documentation establishes and what must still be confirmed in the customer-specific hosting and contractual scope.

What is established today

CardIQ documentation distinguishes the standard managed SaaS service from enterprise-scoped dedicated-cloud and self-hosted arrangements. Availability, topology, operational ownership and data-location commitments can differ by deployment model.

Managed SaaS

CardIQ operates the application service while the customer administers its company users, employee identity data, permissions and lifecycle actions. The public documentation does not currently establish one universal hosting region for every SaaS tenant.

Dedicated cloud

Where offered, dedicated-cloud deployments require an enterprise scope that defines infrastructure isolation, hosting responsibilities, support access, updates and data-location requirements. These terms are not automatic entitlements.

Self-hosted

Where offered and contracted, the enterprise controls the hosting environment and takes additional infrastructure responsibility. Supported topology, updates, backup ownership, support access and data location must be agreed before deployment.

Data residency is a contractual deployment property

A customer should not infer data residency from the CardIQ brand, a sales region, or the existence of an enterprise plan. Residency depends on the actual deployment and the written customer scope.

Region must be confirmed

The hosting country, cloud region, datacenter location or customer-controlled environment must be confirmed for the specific customer deployment before making a residency claim.

Backups and replicas also matter

Residency review should cover primary application data, database replicas, backups, disaster-recovery copies, logs and support/evidence stores where applicable. This page does not assert where those are located for every deployment.

Subprocessors can affect data location

Any third-party infrastructure, email, notification, monitoring, storage or support service that processes customer data should be included in enterprise due diligence. A complete public subprocessor register is not claimed by this page.

What enterprise buyers should confirm

Hosting provider and region

Confirm the actual infrastructure provider, hosting country/region and whether the deployment is shared SaaS, dedicated or customer-controlled.

Data categories and flows

Document which employee identity data, administrator data, logs, security evidence, integration metadata and uploaded assets are processed in each component.

Backup and recovery locations

Confirm where backups and disaster-recovery copies are stored and which party operates them. RTO, RPO and retention should be defined separately rather than assumed from hosting location.

Support and administrative access

Confirm which CardIQ or customer personnel may administer the environment, from which operational locations, under what controls, and how that affects residency or cross-border requirements.

What this page does not promise

No universal country or cloud-region claim

This page does not state that every CardIQ customer is hosted in Egypt, Saudi Arabia, the UAE, Europe, the United States or any other specific jurisdiction.

No automatic sovereignty/compliance claim

Hosting in a particular location does not by itself establish compliance with a customer’s legal, regulatory, sovereignty or sector-specific obligations.

No implied SLA, HA, RTO or RPO

Data location and service resilience are separate topics. Availability targets, redundancy, backup frequency, recovery objectives and disaster-recovery commitments require explicit evidence or contract terms.

For enterprise procurement, request a deployment-specific architecture and data-flow statement before relying on residency or sovereignty assumptions.

Frequently asked questions

Where is CardIQ data hosted?

The public documentation does not establish one universal hosting region for every CardIQ deployment. The actual hosting provider, country/region, backup locations and support model should be confirmed for the specific customer deployment.

Can CardIQ be deployed in a customer-controlled environment?

The current enterprise documentation describes self-hosted deployment as an option where offered and contracted. Availability, supported topology, operational ownership, updates and support access must be agreed before design or purchase.

Does a local hosting region automatically satisfy regulatory requirements?

No. Data residency is only one part of compliance. Customers should assess the complete processing model, subprocessors, support access, security controls, contracts, backups and applicable legal requirements.

Control how employees represent your company externally

Explore the CardIQ Identity platform or review the workflow from verification through identity deactivation.

See how CardIQ Identity works View pricing