Where your data lives

"Where does our data live" is asked as one question and is really three. Where is it stored and served from. Where is it processed when an AI model looks at it. And who else, outside your organisation and outside ours, receives any part of it. The three answers are different, and a vendor who gives you one answer for all three is telling you something they cannot support.

One production cell, and the home-region check that guards it

Your organisation record carries a home region, and that value is carried in the session token every one of your users holds. On every authenticated request the cell compares the token's home region against its own runtime region, and refuses when they differ. The comparison is against the token, never against the request's host header, which a caller controls. With one cell live, this check has nothing to disagree with today — it exists as a boundary the platform enforces by construction, not by promise, should that ever change.

A refusal, if the platform ever ran more than one cell, would be an HTTP 451 — Unavailable For Legal Reasons, the correct status for a jurisdictional refusal rather than an authorisation failure. The response shape is fixed so a caller can see where it should have gone:

HTTP/1.1 451 Unavailable For Legal Reasons
X-Qorionix-Home-Region: eu-central-1

{
  "error": "tenant home_region does not match this cell",
  "home_region": "eu-central-1",
  "cell_region": "eu-central-1"
}

The design choice worth explaining is that a mismatched request would be refused, not proxied. A cross-region proxy would be friendlier and would defeat the purpose: forwarding the request means the data crosses the boundary the binding exists to hold. You can confirm which cell you are talking to at any time; the endpoint is unauthenticated:

GET /api/v1/region
GET /.well-known/qorionix-region

{"cell_id": "...", "region": "eu-central-1"}

What is stored where

The split is an architectural rule, not a convention: global systems may answer "where does this tenant live", and may not serve a tenant's login or session from a remote region. An operator's default level of access is metadata and counts — there is deliberately no query in the diagnostic surface that selects an alert body, a user record or a log line.

If your assessment needs the physical location rather than the logical one, ask, because the two are named differently. The identifier your session carries and the region endpoint returns is a logical region code such as eu-central-1. The cell itself is hosted in the EU (Ireland), and AI inference runs in Sweden (EU) — a separate EU location, because it is the region carrying the model family in use. We name the underlying infrastructure provider only in the sub-processor list, in writing, on request, not in this article — get the specifics in writing rather than from a KB page.

Storage and AI inference are separate questions

Storage is ours to place. Inference is not. Everything Sentinel-Q sends to a model is security telemetry — alert text, process command lines, hostnames, usernames, sign-in addresses — and the model endpoint is a separate system with its own geography. The platform derives that geography from the deployment type and its region using documented rules rather than from the endpoint's hostname, because a resource in an EU region served by a globally distributed deployment runs inference wherever the platform has capacity. Where the derivation does not establish EU inference to a checkable standard, the AI system card reports the region as the literal string unverified. An operator typing a region in by hand does not change that; a declaration is not a measurement.

On the shipped configuration, EU inference now holds, and it holds as derived rather than as anything stronger. This paragraph previously said the opposite, and the correction is worth stating rather than editing quietly: the deployment was moved onto a model resource in Sweden (EU) with region-scoped deployments, so the documented deployment-type rules resolve the region and the region is an EU one. Two conditions ride with that claim. It holds only for that provider on that deployment type — the alternative model path is retained and reachable, has no EU inference geography on any platform, and selecting it re-requires an override which disclaims the residency claim rather than satisfying it. And the stronger provenance level, a geography observed from the model platform itself, is not reachable today because no provider we support reports it; every EU-holding configuration is therefore derived.

There was a quality cost, and it was paid deliberately: the EU-resident model on this configuration is measurably weaker on security-triage work than the one that could not be made EU-resident. If your organisation cannot accept either trade, the route through is to run without the model features — the posture assessment is deterministic checks and never calls a model, the detection library is rules, and the evidence bundle and audit chain are queries over your own data. AI inference, and where it actually runs sets out the provenance levels and the endpoints that are refused; The EU AI Act and your system card sets out the four cases the card distinguishes and the exact disclosure text for each.

Who else touches your data

The row customers forget is the last but one. A webhook you configured to a helpdesk in another jurisdiction is a transfer of security data out of your home region that no residency mechanism of ours prevents, because you asked for it. Inventory your own outbound routes before you write a transfer register.

What a data protection impact assessment needs from us

If you are assessing this platform as a processor, these are the inputs and where each comes from. The judgements remain yours — we do not determine your lawful basis, and security monitoring is the basis most often queried.

• Purposes and categories of personal data. Your records of processing are held here and exported in the GDPR section of the evidence bundle: GET /api/v1/organizations/{orgID}/compliance/gdpr/ropa.
• Recipients. The table above, plus the contractual list when you have it. Include your own outbound destinations.
• Retention. Your licence's period, described as a search-window clamp rather than a deletion schedule, plus a separately stated backup horizon.
• Security measures. TLS 1.2 minimum with 1.3 preferred in transit; AES-256-GCM with envelope encryption and a per-vault data key for privileged credentials, the key-encrypting key in a managed key service; bcrypt for passwords; API keys as one-way hashes; backups encrypted before upload under a key separate from production.
• Integrity of the record. Hash-chained audit trails, with the real guarantees described in Verifying the audit chain.
• International transfers. The home-region binding for storage, and the unverified inference position for the model. Two separate answers.
• Automated decision-making. High blast-radius action steps require human approval; grant-class privileged actions are not exposed to the model at all. If human sign-off is your Article 22 answer, the sign-off has to be real — a reviewer who cannot in practice override the recommendation is not a safeguard.

One more limit. Your impact assessment entries are readable at GET /api/v1/organizations/{orgID}/compliance/gdpr/dpia and are exported inside the evidence bundle, but there is no write route in this version — an entry carries the system it covers, the assessment text, a high-risk flag and a timestamp, and it is created outside the product. So the platform holds the register; your own store holds the document.

What we do not claim

• Not "EU data residency", unqualified. Your organisation is bound to a home region and a request from another region is refused rather than served. AI inference is a separate question and is reported as unverified where our provider offers no regional guarantee.
• Not that the binding is encryption. It is a jurisdictional refusal at the request boundary, not a cryptographic control over where bytes can be read.
• Not instantaneous global deletion. Backups exist, are encrypted before upload, and age out on their own schedule. Describe the backup horizon separately.

What to read next

1. The EU AI Act and your system card — the inference half of the residency question, in detail.
2. What an auditor will ask for — where each of these facts sits in a real evidence request.
3. GDPR: subject requests, export and erasure — what the export contains and what erasure actually removes.