[object Object]

“Where does our data live” is a question that procurement, legal, and your CISO ask in slightly different ways. The Freshworks Neo platform supports multiple regional data centres, and most teams pick one at onboarding and never think about it again. That works until the day a regulator, a customer audit, or a data subject request asks something specific. Here is the operational reality of Neo regions, not the marketing page version.

The regions available

Freshworks Neo operates regional data centres in EU (Frankfurt), US, India, and Australia. Your tenant lives in exactly one region. The choice is generally made at provisioning and is non-trivial to change — migrating between regions is a project, not a setting toggle.

What “lives in region” means in practice:

  • Primary data at rest — tickets, contacts, attachments, audit logs.
  • Active processing — agent UI traffic, automation rule execution.
  • Backups taken from the primary store, replicated within the region.

What does not necessarily stay in region:

  • AI processing for Freddy features unless explicit regional Freddy is enabled.
  • Telemetry and operational logs that may flow to a Freshworks global observability stack.
  • Some third-party integrations you wire up — Slack, Zoom, Teams, custom webhooks — that send data wherever the integration’s vendor processes it.

That split is the source of every awkward conversation. Read on.

What your contract actually says

The DPA (Data Processing Addendum) is the load-bearing document. Read three sections specifically:

  • The list of sub-processors. Freshworks publishes this; it changes. Each sub-processor is a third party that may process your data, and the list includes regional infrastructure providers, monitoring vendors, and AI suppliers.
  • The transfer mechanism for any cross-border flow (SCCs, adequacy decisions, IDTA depending on jurisdiction).
  • The breach notification SLA. Forty-eight hours is common, your industry may require shorter — confirm in writing.

Print the current sub-processor list dated, store it in your compliance binder, and re-pull quarterly. Sub-processor additions are notifiable changes; new appearances are worth a moment of attention.

Choosing a region

For most teams the region choice maps to the dominant data subject location. Three frequent patterns:

  • EU operations — Frankfurt. Lowest friction for GDPR. Article 30 records of processing list one primary processor location, not a global mesh.
  • US operations or globally distributed with no EU concentration — US region.
  • India-domestic operations under Digital Personal Data Protection Act — India region.

Mixed-geography customers (e.g. EU customers and US support agents) have a harder choice. Region is tenant-wide, not per-customer. The pragmatic answer is to host in the region of the data subjects, and ensure agents in other regions are operating under appropriate transfer mechanisms.

See freshworks-gdpr-data-residency for the GDPR-specific decision tree.

Where Freddy actually runs

This is the question that most often gets answered wrong. Freddy AI features — copilot, suggested replies, autoresolve, summary generation — historically processed through model infrastructure not co-located with your tenant. Freshworks has been improving on this with regional Freddy, but the configuration matters:

  • Check whether Freddy regional processing is available and enabled for your tenant.
  • For each Freddy feature in use (copilot, intents, sentiment, summarisation), check the data flow documentation, not the high-level marketing.
  • If your DPA was signed before Freddy was added, the addendum likely needs updating.

Disabling Freddy at the feature level is a legitimate posture if your data flow constraints cannot accommodate the processing. Do not disable broadly — disable per feature based on what the feature actually does with the data.

Backups, exports, and replication

Backups stay within region under standard Neo terms. Replicated backups across regions are a paid option some enterprise customers buy for resilience and may break a strict residency commitment — confirm before enabling.

Exports are user-initiated and flow wherever the requester downloads from. An EU-region tenant whose admin downloads a CSV from a US office has just moved the data. Restrict admin export permissions and log exports.

# Pull recent export activity from the audit log
curl -s -u "$FRESHDESK_KEY:X" \
  "https://acme.freshdesk.com/api/v2/audit_logs?action=export&since=2026-04-14" \
  | jq '.logs[] | {actor, action, target, at, source_ip}'

Anything unusual — unfamiliar IP, large export at odd hours, an admin who normally does not export — warrants a follow-up.

Integrations: where data leaks

The integrations layer is where residency commitments quietly weaken. A webhook fires on every ticket update and sends the payload to a third-party service running in a different region. The Freshworks Marketplace app integrates with a vendor whose infrastructure is global.

Inventory every integration. For each one:

  • What data does it send out (full ticket payload, just metadata, just IDs)?
  • Where does the receiving service host its infrastructure?
  • Is there a DPA in place with that vendor, and does it include SCCs if needed?
  • Can the integration be scoped down to send less?

The lowest-leakage default is to send IDs and let the receiving service pull the detail it needs through a scoped API call from the appropriate region.

See freshworks-webhook-reliability-patterns for the lower-coupling webhook design that helps with this.

Data subject requests

A subject access request lands in your inbox. The subject is an EU citizen. Your tenant is in EU. The request still requires you to identify every place their data sits, and the integrations layer is in scope.

Build a mapping ahead of time, not during the 30-day response window:

{
  "data_subject_inventory": {
    "primary": "Freshworks EU tenant (tickets, contacts, attachments)",
    "backups": "Within-region backup, 35-day retention",
    "integrations": [
      { "name": "Slack notifier", "data": "ticket subject, requester name", "region": "US" },
      { "name": "Internal data warehouse", "data": "ticket metadata only", "region": "EU" },
      { "name": "QA recording tool", "data": "chat transcripts", "region": "US" }
    ],
    "ai_processing": "Freddy regional EU enabled for summary; intent detection disabled"
  }
}

The doc lives in compliance, gets updated when integrations change, and is the thirty-minute answer to a request that would otherwise take a week.

Migration between regions

You can request a region migration. It is rarely fast. Typical timeline:

  • Discovery and approval — weeks.
  • Cutover window scheduling — depends on tenant size.
  • Actual migration — usually a downtime or read-only window.
  • Integration reconfiguration — every webhook URL, every API endpoint changes.

Plan for two to three months end to end on a non-trivial tenant. The decision is reversible at high cost; treat the initial choice as binding for several years.

Bottom line

Data residency on Neo is a stack, not a setting. The tenant region is the foundation; Freddy, integrations, exports, and backups are separate decisions that can each leak data across borders. Audit them, document them, and revisit them when sub-processors, integrations, or laws change. The team that survives the next data residency audit is the one that already knows the answers, not the one rebuilding the inventory at the deadline.

[object Object]
Share