Before an institutional agreement, the other party asks one short question: where is the data held? The team gives three different answers, none verified on screen. The gap appears when technical information becomes contract language without evidence. A clinic owner needs a brief record supported by the visible account address, with a responsible person and date. The answer about a Zoho account needs the same verification.
An account living in one data centre does not make this only a server-address question. Its centre is assigned from location at registration and can affect feature availability. Technical verification and legal assessment therefore remain separate. The contract appendix records where the account resides, how that fact was observed, and which transfers are enabled. Any regulatory interpretation stays within its own specialist review.
One question has two audiences
The technical audience wants a verifiable system fact placed on record. The contract audience asks which document, date, and responsibility support that fact. Trying to satisfy both needs with one sentence creates ambiguity. One team may inspect a screen while another interprets conditions. They use the same words, yet answer different questions without noticing that the decision record remains incomplete.
A sound approach first states the observable technical finding, then defines its contractual use. The technical note declares no legal outcome, while the contract note relies on no unverified infrastructure assumption. A clinic manager can see where the evidence came from without having a technical team. The contract reviewer can trace the factual basis and request refreshed evidence when necessary.
Each account lives in one data centre
Zoho CRM is hosted across several data centres, but each account resides in only one. The default assignment follows the location applicable during registration. This arrangement cannot be described as a freely changeable preference. When another centre is required, the issue is an account transfer, not a simple setting. No estimate is made here about transfer timing, cost, interruption, or procedure.
An email address registered in one centre cannot be reused in another. The documented routes are deleting the existing registration or transferring the account to the target centre. The only documented interface switch uses the globe icon on the mobile sign-in screen for CN. No general centre selector is documented. The accurate language concerns an assigned location and, where needed, a transfer request.
Verify the centre on screen
Start verification by checking the address bar of an authenticated account. The documented domain for an account on the EU centre is crm.zoho.eu, showing that the domain exposes centre information. Do not infer your own result from this example. Read the domain in the active session, capture a screenshot, and note the verification date. The written answer then rests on the observed address.
The screenshot needs enough context to identify the account and make the domain readable, without carrying unnecessary personal details into the record. Naming the reviewed environment and observer supports later comparison. Do not announce in advance where an account opened from Türkiye will be assigned. The safe conclusion records only the address visible in that installation and refreshes the evidence after a change.
The centre also shapes feature availability
Full-disk encryption is available in IN, AU, and JP, while other locations enable it on request. Dashboard presentation generation is limited to US, AU, EU, IN, JP, and CN. Available on Enterprise and above, it permits ten presentations per user each month, with each presentation deleted after one month.
A manager cannot find a feature used by a colleague and assumes their editions differ. The editions are identical; the accounts were opened in different centres. Zia model-provider availability also varies by centre, and some Zia features are available only to US and EU users. A Zoho feature inventory must therefore verify both edition and centre instead of generalising from a single account.
Every integration creates another transfer point
Hosting data in a specific centre does not show that it never leaves that centre. Enabling an integration can transfer personal data to a third party. Zoho provides a separate control for restricting transfers to its applications and third-party applications. Managing that control requires the Manage Compliance Settings permission. Its existence does not remove the need to inspect every enabled connection separately.
The contract note treats each enabled integration as a distinct transfer point. It records which fields leave, which third party receives them, and whether the connection is enabled. The third-party processor's own legal obligations require separate assessment. This method places hosting location beside the transfer map without confusing them and prevents a review from stopping after it identifies only the account's data centre.
Keep technical facts separate from legal conclusions
Enabling a compliance setting does not itself create legal compliance. Organisations subject to HIPAA must separately sign a Business Associate Agreement with Zoho, whose product materials also state that these sections are not legal advice. The edition threshold for the relevant Compliance Settings tabs is unknown. The technical note records only the setting's status, leaving legal conclusions to authorised review.
The reviewed help material provides no assessment of Turkish legislation. That silence supports neither a positive nor a negative compliance conclusion. Data-centre information is a technical fact, and local legal interpretation does not follow automatically from it. This article makes no claim about Eksenium's infrastructure, servers, or customer installations. Because the evidence is general, it explains the verification method without claiming a result.
What belongs in the contract appendix
The appendix records the account's verified data centre alongside the domain from which that result was read. It identifies the screenshot date and responsible observer. It explains that changing centres is not a user preference but a separate action involving deletion of the existing registration or account transfer. Enabled integrations, exported fields, relevant third parties, and centre-dependent features appear with their verification sources.
Keep the thresholds together: data-centre rules are edition-independent. Dashboard presentation generation is available on Enterprise and above in the specified centres. Some Zia features require Professional or above and also depend on centre. No edition threshold is known for full-disk encryption or compliance settings; managing compliance settings requires the Manage Compliance Settings permission. Verify every centre-dependent capability against edition and centre before a proposal.
Who needs this information
This record is most useful during audit preparation, business handover, and supplier assessment. One party can ask about hosting location without forcing another to reconstruct where the account was opened or which features appear. A one-page note places the account's single centre, verified domain, evidence date, and enabled transfer points in one context. The next review inherits recorded findings instead of earlier assumptions.
The final line states which account and date the verification covers. Prepare the document again if the centre changes, the account is transferred, or the integration list is updated. Keep legal characterisation outside the technical record and route it to specialist review. This leaves the clinic owner a repeatable control instead of an uncertain promise: read the address, preserve the evidence, document transfers, and recheck centre-dependent features.
