Search all 478 artefacts by title, document ID or content.
Printed on the standard letterhead. Page furniture, margins and repeating table headers come from the same stylesheet the PDF service uses.
Pensieve Labs
The operating system for hospitals
DIS-GL-008
v1.0.0 | 31 July 2026
Position as at 31 July 2026. Read the section for your market. Do not infer a residency
position for one market from another. They differ, and one of them is a hard architectural constraint.
DM-1 Dedicated |
DM-2 Shared |
DM-3 Customer Cloud |
DM-4 On-Premise |
|---|---|---|---|
Pensieve Labs selects and controls the region, recorded as Deal data region |
Same, per regional estate | The hospital selects the region. Pensieve Labs deploys where told |
Residency is the hospital's server room. The strongest residency answer available |
To state, per market and per deployment model, where hospital data is stored, where it is processed,
where its logs live, and who can reach it from where, including the markets where
Edsol Edtech Pvt. Ltd. cannot currently meet a legal requirement, which are named rather than omitted.
Residency has four distinct components and vendors routinely answer only the first. This document answers all four:
| Component | The question it answers |
|---|---|
| Storage residency | Where the data sits at rest: database, object storage, backups |
| Processing residency | Where computation on that data happens |
| Log residency | Where system and audit logs are stored, which is separately regulated in India |
| Access residency | Which countries a human being can reach the data from: the component that defeats the other three when it is ignored |
| Component | DM-1 |
DM-2 |
DM-3 |
DM-4 |
|---|---|---|---|---|
| Storage | The region recorded as Deal data region, in Pensieve Labs's cloud project |
The regional shared estate for the market | The region the hospital selects in its own project | The hospital's own premises |
| Processing | Same region. Compute runs in the project holding the data | Same region | Same region as the hospital's project | The hospital's own hardware |
| Backups | Same region. Backups do not leave Deal data region |
Same region | The hospital's project and the hospital's configured location | The hospital's media, wherever the hospital keeps it |
| Logs | Regional log bucket in the same region, retention per DIS-GL-034 |
Same | The hospital's project; Pensieve Labs configures, the hospital owns |
The hospital's own log storage |
| Access | Pensieve Labs personnel under DIS-GL-033, from the countries listed there |
Same | The hospital grants and revokes access through its own identity and access management | Only within a session the hospital opens |
| Who can change the answer | Pensieve Labs, only by an agreed change |
Pensieve Labs |
The hospital | The hospital |
The honest ranking. If residency is the hospital's controlling concern, DM-4 answers it absolutely,
DM-3 answers it structurally, and DM-1/DM-2 answer it contractually and technically but with
Pensieve Labs holding the configuration. WPR-GL-004 sets out what each model costs in schedule and
money, and DM-4 costs the most of both.
In every model, in every market:
DIS-GL-011).Pensieve Labs does not maintain a central copy, warehouse, analytics extract or training corpus of
any hospital's data in any other location. There is no global data lake. This is stated because it is
the assumption a reviewer should test.Three categories cross a border, and none of them is patient data. They are listed exhaustively.
| Category | What it is | Where it goes | Why |
|---|---|---|---|
| Trust Center business contact data | Names and work e-mail addresses of the hospital's authorised users; which documents they opened and when; the contract and disclosure documents themselves | The Trust Center stack in DIS-GL-009 Section 3 |
The Trust Center is a separate application, not connected to any Platform instance. It holds no patient data |
| Support correspondence | Ticket text, identifiers, error references: never record contents, never screenshots containing patient data, which are refused and deleted if received | Pensieve Labs's support channel per SLA-GL-001 |
Support cannot function without correspondence. The data-minimisation rule that keeps patient data out of it is in WPR-GL-001 Section 12.4 |
| Aggregate operational telemetry | Service availability, error rates, latency, job success, resource utilisation. Counts and timings, keyed to a tenant identifier, containing no personal data | Pensieve Labs's monitoring, per DIS-GL-030 |
Operating a service requires knowing whether it is up |
Human access is the fourth category and it is treated separately, because it is the one that matters
most and the one most often hidden. See Section 7 and DIS-GL-033.
Position: all hospital data is stored, processed, logged and backed up inside India, in the Google Cloud
India region recorded as Deal data region on the Order Form. No Customer Personal Data is transferred
outside India.
Pensieve Labs does| Requirement | Source | Pensieve Labs's position |
|---|---|---|
| Logs of all ICT systems maintained for a rolling 180 days and within Indian jurisdiction | CERT-In Directions of 28 April 2022, Direction (iv), issued under s.70B(6) of the Information Technology Act, 2000 | Met and exceeded. Logs are retained for not less than 365 days in a regional log bucket in the Indian region. Global log buckets are not used, because a global bucket may place data in any of the provider's data centres and would fail the localisation requirement. Configuration detail is in DIS-GL-034 |
| Processing logs and associated traffic data retained for 1 year | Digital Personal Data Protection Rules, 2025, Rule 6(1)(e) and Rule 8(3) | Met by the same 365-day configuration. One configuration satisfies both requirements |
| Cross-border transfer permitted except to countries on a notified negative list, and subject to any sectoral restriction | Digital Personal Data Protection Act, 2023 and the Rules | Not engaged. Pensieve Labs makes no transfer of Indian hospital personal data outside India, so the negative-list analysis does not arise |
| Subscriber and customer records retained for 5 years after termination by data centre, cloud and similar service providers | CERT-In Directions of 28 April 2022, Direction (v) | Applied conservatively. The hospital's validated legal name, contract period, allotted tenant identifiers, onboarding e-mail, IP and timestamp, stated purpose, validated address, contacts and ownership pattern are retained for five years after termination. This is customer master data, not patient data |
Pensieve Labs does not rely on "the cloud provider is empanelled"Google Cloud services in the India regions have been empanelled by the Ministry of Electronics and
Information Technology following an independent audit. Edsol Edtech Pvt. Ltd. is not itself empanelled.
Empanelment at the infrastructure layer says nothing about the application layer, which is
Pensieve Labs's responsibility. WPR-GL-001 Section 16.4 states this precisely; it is repeated here because a
residency conversation is exactly where the misrepresentation usually occurs.
Ask to see three configuration facts, which Pensieve Labs will show:
Position: hospital data is stored and processed in an Australian region recorded as
Deal data region. There is one constraint that is not about storage at all, and it is the one that
matters.
Google Cloud operates Australian regions and a DM-1 or DM-2 Australian deployment is provisioned in
one. Backups and logs remain in the Australian region. Under DM-3 the hospital selects the region; under
DM-4 the data is on the hospital's premises.
Section 77 of the My Health Records Act 2012 prohibits a registered repository operator, registered portal operator or registered contracted service provider that holds or has access to My Health Record system records from holding or taking those records outside Australia, or from processing or handling information relating to those records outside Australia. The penalty is criminal as well as civil (My Health Records Act 2012 s.77).
This bites Edsol Edtech Pvt. Ltd. only if Pensieve becomes a registered contracted service
provider, that is, if it is the software through which a hospital views or uploads My Health Record
content.
The consequence is not a hosting constraint. It is a support constraint. Australian hosting satisfies the first limb; the second limb, processing or handling information relating to the records outside Australia, is not satisfied by a contractual promise, an encryption control or a data processing agreement. It requires that no person outside Australia processes or handles that information, which constrains who may open a support session.
Pensieve Labs's position, stated plainly:
Edsol Edtech Pvt. Ltd. operates its support and engineering function from India. See DIS-GL-033.Pensieve Labs therefore does not today offer My Health Record connectivity, and will not
represent to an Australian hospital that it does.WPR-GL-005 carries the status.DM-4 Australian deployment satisfies s.77's localisation limb by definition; the remote-access limb
still applies to any session Pensieve Labs is invited into, and DIS-GL-033 Section 4 states how that is
handled.Related, and separately consequential. From 1 July 2026, pathology and diagnostic imaging written
reports authored by or on behalf of a pathologist or radiologist must be uploaded to My Health Record
within 24 hours of being provided, subject to four documented exceptions. The duty falls on the
reporting provider, not on the software vendor. An Australian hospital that authors its own pathology
or imaging reports therefore has a statutory upload obligation that Pensieve cannot currently
discharge, and must retain a system that can. Pensieve Labs raises this at qualification rather than
at cutover.
Position: Edsol Edtech Pvt. Ltd. cannot serve a UAE hospital from its default infrastructure. This is a
hard legal constraint, not a preference, and it changes the architecture rather than the paperwork.
This section is a summary. The operative UAE statement is
DIS-AE-008, which gives the per-model availability position, the rejected architectures, the access-residency restriction and the unmet requirements. SendDIS-AE-008to a UAE prospect, not this section.
Federal Law No. 2 of 2019 Concerning the Use of Information and Communication Technology in Health Fields, Article 13, provides that health data related to health services provided in the UAE may not be stored, processed, generated or transferred outside the UAE, except upon a decision issued by the relevant health authority in coordination with the Ministry of Health and Prevention. Article 2 applies the law to all information and communications technology used in health fields in the UAE, including the free zones. Establishing in a financial free zone does not escape it.
Note the four verbs: stored, processed, generated, transferred. "Processed" and "generated" close the workaround of keeping the database in the UAE while running compute elsewhere.
| Question | Answer |
|---|---|
| Can a UAE hospital be served from an Indian region? | No. Not with encryption, not with pseudonymisation, not with a data processing agreement. The obligation is territorial, not risk-based |
| Does the default cloud provider have a UAE region? | No. Its Middle East regions are outside the UAE, and a region in another Gulf state does not satisfy a rule that says "outside the UAE" |
| Can the exemption be obtained? | The carve-out requires a decision of the health authority in coordination with the Ministry. There is no published self-service procedure, fee or timeline, and the application is made by the licensed facility, not by the vendor. Pensieve Labs does not build a plan around obtaining it [UNVERIFIED: no public procedure identified] |
What does Pensieve Labs do instead? |
Deploys on infrastructure physically located in the UAE. For an early UAE deployment this is DM-4 on the hospital's own premises or in a UAE colocation facility, which satisfies Article 13 trivially. At scale it is a UAE-resident cloud region operated by a provider other than the default, named per deal and recorded as a separate entry in DIS-GL-009 Section 6 |
| Does support access from India comply? | No. "Processed" covers a human being in India operating on the data. DIS-GL-033 Section 4 sets out the constraint; a UAE deployment requires the access model described there |
Because of Section 6.2, Pensieve Labs's hosting claim is market-conditional, not global. No document in
this Trust Center should be read as asserting that every deployment runs on the default cloud provider. For
a UAE deployment the infrastructure provider is named on the Order Form and in DIS-GL-009.
The operative document for an EEA hospital is
DIS-EU-008(Data Residency Statement for the EEA), which states the region rule, three key-custody options and the plaintext boundary in the vocabulary a European data protection officer uses. This section is the summary;DIS-EU-008is the detail and neither contradicts the other.
Position: hospital data is stored and processed in a European Union region recorded as
Deal data region. No transfer to India occurs for storage or processing. Remote access from India is
a restricted transfer and is handled as one.
| Element | Position |
|---|---|
| Storage and processing | An EU region. For a Danish or Norwegian deployment Pensieve Labs does not use a region outside the European Economic Area |
| Backups and logs | Same region |
| Controller / processor roles | The hospital is the controller; Edsol Edtech Pvt. Ltd. is the processor. DPA-GL-001 uses controller/processor vocabulary for these markets, not the Indian Data Fiduciary/Data Processor terms |
| Transfer basis for remote access | Remote access by Pensieve Labs personnel in India is a restricted transfer under Chapter V of the General Data Protection Regulation. It is made under the European Commission Standard Contractual Clauses incorporated into DPA-GL-001, together with a transfer impact assessment and the supplementary measures recorded there, including that encryption keys remain in the EU region and are not accessible from India in the models where the hospital holds them |
| Norway specifically | Norway applies the Regulation through the European Economic Area. Where a Norwegian hospital flows down the health sector information security norm through its data processor agreement, Pensieve Labs responds against that norm's requirements; Pensieve Labs holds no certification and says so |
| The honest position on remote access | A hospital that will not accept any processing from India should choose DM-3 or DM-4, where it controls Pensieve Labs's access itself. Pensieve Labs will not claim that Standard Contractual Clauses make offshore access invisible to a Danish or Norwegian data protection authority |
Pensieve Labs cannot currently meet a requirementThis table exists because a residency statement that lists only successes is not a residency statement.
| Market | Requirement | Status | What a hospital should do |
|---|---|---|---|
| Australia | s.77 My Health Records Act: no processing or handling of My Health Record information outside Australia | Not met. Support is operated from India | Do not contract for My Health Record connectivity. Treat it as a dated roadmap item; WPR-GL-005 carries status |
| Australia | Statutory 24-hour upload of pathology and imaging reports by the authoring provider | Not met: Pensieve does not upload to My Health Record |
If the hospital authors its own reports, retain a system that can upload |
| United Arab Emirates | Federal Law No. 2 of 2019 Article 13 in-country storage, processing and generation | Not met on default infrastructure. Met by a UAE-resident deployment provisioned per deal | Expect DM-4 or a UAE-resident cloud, priced and scheduled accordingly. WPR-GL-004 explains what that costs in days |
| All markets | An independently audited residency attestation | Not held. Edsol Edtech Pvt. Ltd. holds no certification of any kind |
Verify the configuration directly, per Section 4.3. WPR-GL-005 states the assurance position |
A region is chosen at contracting and recorded as Deal data region. Changing it later is a data
migration, not a setting:
| Model | Feasibility | Mechanism |
|---|---|---|
DM-1 |
Feasible with planned downtime | Change Order (ADD-GL-015), backup-and-restore into a new project in the target region, verification, cutover, then deletion of the source per DIS-GL-023 |
DM-2 |
Feasible only by moving the tenant to a different regional estate, or by converting to DM-1 |
Change Order |
DM-3 |
The hospital's decision and the hospital's project | Pensieve Labs executes on instruction |
DM-4 |
Not applicable: the region is the server room | None |
Pensieve Labs does not move a hospital's data to a different region for its own operational
convenience. Region changes happen on a Change Order, with the hospital's written instruction.
10.1 Region is a configuration, and configurations can drift. The control is infrastructure-as-code
with reviewed changes (WPR-GL-001 Section 7.2) and configuration-drift alerting, not a certificate. A hospital
should verify the region rather than assume it.
10.2 Cloud provider internal operations. The provider may operate global control planes for its own
service management. Pensieve Labs relies on the provider's published documentation and contractual
commitments about what data those planes carry, and does not independently verify them.
DIS-GL-009 Section 9.1 states this.
10.3 Access residency is procedural in DM-1 and DM-2. Where Pensieve Labs holds the keys, the
constraint on who can reach the data from where is enforced by process, approval and logging, not by
cryptography. DIS-GL-033 describes the controls; WPR-GL-001 Section 17.4 states the limitation.
10.4 The UAE position depends on a per-deal infrastructure selection. Until a UAE deployment exists, the register entry for its infrastructure provider does not exist either. A UAE prospect should treat Section 6.2's answer as the architecture, and the specific provider as a contracting decision.
10.5 [UNVERIFIED] items are marked as such. Where this document marks a regulatory point unverified,
it is because the primary source was not confirmable in the research pass behind it. Those points carry a
qualifier and should be re-verified before being relied on commercially.
| Question | Document |
|---|---|
| Who else touches the data, and where they are | DIS-GL-009 Subprocessor Register |
| Where encryption keys live and who holds them | DIS-GL-011 Encryption Disclosure |
| Which countries a human can reach the data from | DIS-GL-033 Remote Access & Support Model Disclosure |
| Log retention and localisation configuration | DIS-GL-034 Log Retention & Localisation Disclosure |
| Transfer mechanisms, Standard Contractual Clauses and jurisdiction annexures | DPA-GL-001 clause 12 and the jurisdiction annexures |
| What each deployment model changes | WPR-GL-004 Deployment Models Explained |
| Backup location and restore | DIS-GL-014 |
| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0.0 | 31 July 2026 |
Pensieve Labs Security |
First published edition. Four-component residency model published. India, Australia, UAE, Denmark and Norway positions stated per model. Unmet requirements published in Section 8. |