Search all 478 artefacts by title, document ID or content.
Disclosure | Family 14, Jurisdiction Variant Sets
This statement varies the global Data Residency Statement DIS-GL-008 for a hospital established in the EEA. It does not change the encryption specification (DIS-GL-011), the sub-processor list (DIS-GL-009), the recovery objectives (DIS-GL-014) or the remote-access model (DIS-GL-033). Those are the same everywhere and…
This document is the source of truth for: eea-residency-position, marketing:/eu/trust/data-residency
Those surfaces render this text from here. They do not keep their own copy, so they cannot drift from it.
Artefacts this one references or cannot be issued without.
Artefacts that would be blocked if this one were missing or out of date.
DIS-EU-008 v1.0.0, Last Modified On 01 August 2026, Tier: Public
| DM-1 Dedicated | DM-2 Shared | DM-3 Customer Cloud | DM-4 On-Premise |
|---|---|---|---|
EEA region, Pensieve Labs-operated |
EEA region, shared platform | Hospital's own EEA project | Hospital's premises |
This statement varies the global Data Residency Statement DIS-GL-008 for a hospital established in the
EEA. It does not change the encryption specification (DIS-GL-011), the sub-processor list
(DIS-GL-009), the recovery objectives (DIS-GL-014) or the remote-access model (DIS-GL-033). Those
are the same everywhere and are not restated. What is forked here is the region rule, the key-custody rule,
the plaintext boundary, and the vocabulary a European data protection officer reads in.
The contractual expression of everything below is DPA-EU-001 clause 12 (supplementary measures S1 to
S13); the legal assessment is REP-GL-021.
Deal data region. It is not stored in India and it is not replicated outside the EEA.Pensieve Labs personnel is a restricted transfer under Chapter V of
the GDPR and is handled as one, not treated as if EEA hosting made it disappear.Pensieve Labs does it because it is the only architecture under which the transfer assessment
works, not because a statute compels it.There is no cloud region in Denmark and none in Norway for the infrastructure provider
Pensieve Labs uses. A data centre building in a country is not a cloud region, and a vendor that
implies otherwise should be asked for the region identifier. Pensieve Labs states the region
identifier in the Order Form and the hospital can verify it from its own console under DM-3.
| Preference | Region | Why |
|---|---|---|
| 1 | A Nordic EEA region | Lowest latency to Danish and Norwegian sites; power profile with a high renewable share, which several public buyers score |
| 2 | A second Nordic EEA region | Failover pair for the primary, keeping recovery inside the EEA |
| 3 | A central-European EEA region | Where the hospital's group standard requires it, or where a specific service is not yet available in a Nordic region |
Multi-region is inside the EEA only. Where a service Pensieve Labs uses is not available in the
elected region, Pensieve Labs either does not enable it or substitutes an equivalent that is. It does
not silently fail over to a non-EEA region. Where no EEA-resident equivalent exists, the function is
disabled for EEA hospitals and the fact is recorded in Section 8.
| Component | DM-1 | DM-2 | DM-3 | DM-4 |
|---|---|---|---|---|
| Primary database | EEA region | EEA region, logically isolated tenant | Hospital's EEA project | Hospital's premises |
| Object storage (documents, images, exports) | EEA region | EEA region | Hospital's EEA project | Hospital's premises |
| Backups | Same EEA region | Same EEA region | Hospital's EEA project | Hospital's custody |
| Application logs containing record identifiers | EEA region | EEA region | Hospital's EEA project | Hospital's premises |
| Encryption keys | EEA key service; customer-managed or customer-held available | EEA key service, per-tenant key | Hospital's key service | Hospital's custody |
| Administrative jump host | EEA | EEA | EEA, plus the hospital's own identity gate | Hospital's network |
| Support ticketing metadata | Sub-processor per DIS-GL-009 |
Same | Same | Same |
| Aggregate operational metrics | Reachable from India, no direct identifiers | Same | Same | Same |
| Plaintext clinical content | Break-glass only | Break-glass only | Break-glass only, hospital-gated | Break-glass only, hospital can physically disconnect |
The row that matters is the last one. Everything above it is architecture; the last row is the one a supervisory authority would examine.
| Option | Who holds the key | What Pensieve Labs can do |
Models | Effect on the transfer assessment |
|---|---|---|---|---|
| K1 (default) | Pensieve Labs, in an EEA key service |
Decrypt within the EEA boundary; no key access from India | DM-1, DM-2 | Sufficient with S3 to S8 |
| K2 | The hospital, in its own EEA key service, granting the Platform a scoped decrypt permission | Decrypt only while the grant is live; the hospital can revoke unilaterally | DM-1, DM-2, DM-3 | Stronger: the hospital holds a kill switch |
| K3 | The hospital, in a key manager external to the cloud provider | Decrypt only while the external key manager responds | DM-1, DM-3 | Strongest; adds a latency and availability dependency the hospital owns |
K2 is the option most European hospitals should take and it is the one Pensieve Labs recommends
in a Danish or Norwegian deal. The trade is real and is stated rather than hidden: under K2 and K3 a key
revocation renders the deployment unavailable immediately, and the availability commitment in
SLA-GL-001 is suspended for the period of a hospital-caused revocation.
European supervisory guidance is consistent on one point: where the importer needs access to data in the clear in order to provide the service, encryption-based supplementary measures do not rescue the transfer. The whole weight then falls onto the assessment of the destination country's law, and for India that assessment does not support the transfer.
Pensieve Labs's architecture is therefore built so that plaintext access from India is exceptional:
| Control | Implementation | Verifiable by the hospital? |
|---|---|---|
| Pseudonymisation by default | Support tooling resolves records by internal identifier; the mapping to the national patient identifier is under a key the hospital controls | from the hospital's own audit view |
| Named individuals only | A closed register of individuals eligible for break-glass, available on request | on request |
| Just-in-time grant | No standing production privilege; the grant is created per session | from the access log |
| Hospital approval per session | The hospital's named approver must approve before the session opens | : the hospital performs the approval |
| Time-boxed and auto-expiring | The grant expires without action | from the access log |
| Full session recording | Recorded and available to the hospital | on request |
| Immutable log | The engineer cannot alter the record of their own access | from the hospital's own audit view |
Test this claim during evaluation. Ask to see the approval flow and to open the audit view. A residency statement that cannot be verified from the hospital's own console is a marketing document.
| Leg | From → to | Location | Basis |
|---|---|---|---|
| 1 | Hospital (controller) → Edsol Edtech Pvt. Ltd. (processor) |
India, remote access only | SCCs Module Two plus the measures in DPA-EU-001 clause 12, assessed in REP-GL-021 |
| 2 | Edsol Edtech Pvt. Ltd. → cloud infrastructure provider |
EEA region | Intra-EEA processing; no Chapter V transfer where the region and the contracting entity are in the EEA |
| 3 | Edsol Edtech Pvt. Ltd. → any sub-processor outside the EEA |
Per DIS-GL-009 |
SCCs Module Three plus a per-destination assessment |
Leg 3 is the one vendors forget, and the one for which European public bodies have been criticised by
their own supervisory authority, specifically for not assessing transfers to sub-processors in third
countries, India among them. Pensieve Labs is that kind of sub-processor in someone else's supply
chain, and it publishes the register and the verification evidence precisely so that its own customers do
not inherit the same criticism.
Pensieve Labs cannot meet a requirementA residency statement that lists only successes is not a residency statement.
| Requirement | Status | What the hospital should do |
|---|---|---|
| A cloud region physically in Denmark or Norway | Not available. No such region exists for the infrastructure Pensieve Labs uses |
Accept a Nordic EEA region, or elect DM-3/DM-4 if in-country hardware is a requirement |
| No processing of any kind outside the EEA, including support | Not met on the default support model. Support is operated from India under the controls in Section 6 | Elect DM-3 or DM-4, or contract for EEA-only support at the uplift in the Order Form. Pensieve Labs will quote it |
| An independently audited residency attestation | Not held. Edsol Edtech Pvt. Ltd. holds no certification of any kind |
Verify the configuration directly per Section 6 and Section 9. WPR-GL-005 states the assurance position |
| Sovereign-cloud or EU-controlled-entity hosting | Not offered. The infrastructure provider is not an EU-controlled entity | If a sovereign requirement is a qualification criterion in a tender, Pensieve Labs cannot meet it and will say so in the bid/no-bid decision rather than qualify a bid it will lose |
| A commitment that no non-EEA person can ever see plaintext | Not met. Break-glass exists because a platform nobody can repair is not a safe platform | Use K2 or K3 key custody, and require per-session approval, which gives the hospital the veto rather than the vendor |
Pensieve Labs| # | Check | How |
|---|---|---|
| 1 | The region identifier matches the Order Form | Ask for the region identifier in writing; under DM-3 read it from the hospital's own console |
| 2 | Backups are in the same region | Ask for the backup configuration; verify the retention and location fields |
| 3 | Keys are in the EEA | Under K2 and K3 the hospital owns the key service and can see it directly |
| 4 | No standing access from India | Ask for the access register and then read the audit log for a month with no break-glass entries |
| 5 | The break-glass approval flow works | Ask for a live demonstration during evaluation, not a screenshot |
| 6 | Sub-processors are as stated | Read DIS-GL-009, then subscribe to DIS-GL-010 |
| 7 | The region has not drifted | Configuration drift alerting is described in WPR-GL-001; ask for the alert configuration |
A region is elected at contracting and recorded at Deal data region. Changing it later is a data
migration, not a setting: it proceeds on a Change Order (ADD-GL-015) with planned downtime, verification
and deletion of the source under DIS-GL-023. Pensieve Labs does not move a hospital's data to a
different region for its own operational convenience.
11.1 Region is a configuration and configurations can drift. The control is infrastructure-as-code with reviewed changes and drift alerting, not a certificate.
11.2 Cloud provider control planes. The infrastructure provider may operate global control planes for
its own service management. Pensieve Labs relies on the provider's published documentation and
contractual commitments for that layer and does not independently audit it. The provider is named in
DIS-GL-009.
11.3 Metadata is not nothing. Ticket subjects, log record identifiers and operational metrics leave the
EEA. They are minimised and identifier-suppressed, but a hospital user who pastes clinical content into a
support ticket has made a transfer no vendor control prevents. Brief users; CHK-GL-004 carries the item.
11.4 DM-4 does not remove the transfer. On-premise removes the storage transfer. It does not remove
the remote-access transfer unless the hospital also removes remote access, which it can, at the cost of
the support response times in SLA-GL-001.
| ID | Artefact |
|---|---|
DIS-GL-008 |
Data Residency Statement (global master) |
DPA-EU-001 |
Data Processing Agreement: EU/EEA, clause 12 |
REP-GL-021 |
Transfer Impact Assessment: EU/EEA to India |
DIS-GL-009, DIS-GL-010 |
Subprocessor Register and change log |
DIS-GL-011 |
Encryption Disclosure |
DIS-GL-033 |
Remote Access & Support Model |
WPR-GL-004 |
Deployment Models |
WPR-GL-005 |
Assurance Overview |
| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0.0 | 01 August 2026 |
Privacy | First issue. EEA fork of DIS-GL-008: region rule, three key-custody options, the plaintext boundary as the load-bearing control, and an explicit list of requirements not met. |