Search all 478 artefacts by title, document ID or content.
Disclosure | Family 3, Security, Privacy & Trust Disclosures
DPA-GL-001 is the contract. POL-GL-053 is the notice. This document explains the architecture behind both: for a hospital's privacy officer, its counsel, a group CIO, or a regulator who wants to understand how personal data moves through the Platform and who is answerable for what.
This document is the source of truth for: privacy-architecture-narrative, role-allocation-explainer, data-principal-rights-routing, marketing:/why-pensieve/privacy
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.
Position as at 01 August 2026 | Public | DPDP-anchored, GDPR-compatible
DM-1 Dedicated |
DM-2 Shared |
DM-3 Customer Cloud |
DM-4 On-Premise |
|---|---|---|---|
| Yes | Yes | Yes | (Section 7 records what changes when the hospital holds the infrastructure) |
DPA-GL-001 is the contract. POL-GL-053 is the notice. This document explains the architecture behind
both: for a hospital's privacy officer, its counsel, a group CIO, or a regulator who wants to understand
how personal data moves through the Platform and who is answerable for what.
It is written for India first, because that is where the centre of gravity is, and in vocabulary that translates: Data Fiduciary and Data Processor where the Indian statute is the reference, with the controller/processor equivalence noted where a European reader needs it.
What this document does not do: it does not restate the DPA's obligations, the residency table, the subprocessor list, the encryption specification, the breach timelines or the deletion process. Each of those has an owner and is linked.
| Party | Role | What that means in practice |
|---|---|---|
| The hospital | Data Fiduciary (Controller) | Decides why patient data is collected, what is collected, how long it is kept, who inside the hospital may see it, and on what basis it is shared. Answers the Data Principal |
Edsol Edtech Pvt. Ltd. |
Data Processor | Processes only on the hospital's documented instructions. Decides nothing about purpose |
| The Data Principal | The patient, the clinician, the employee | Holds the rights. Exercises them against the hospital |
| A third-party system the hospital connects | Its own controller, on its own terms | ABDM, NHCX, payers, gateways, messaging providers: the hospital's relationships, on the hospital's credentials (DIS-GL-024) |
Why Edsol Edtech Pvt. Ltd. will not accept a controller role, in any deployment model. A processor
that begins to decide purposes acquires its own lawful-basis obligations, its own notice obligations and
its own retention decisions over patient data, and the hospital loses the ability to answer its own
patients. The architecture is built to keep the role clean:
| Architectural commitment | Consequence |
|---|---|
| No cross-tenant dataset exists | There is nothing Edsol Edtech Pvt. Ltd. could analyse that would make it a controller |
No training on Customer Data, in any form (ADD-GL-006 5) |
The most common route by which a processor becomes a controller is closed |
| No secondary use for research, benchmarking, marketing or product analytics | Same |
| Retention is configured by the hospital | Retention is a purpose decision, and it stays with the hospital |
Pensieve Labs holds no participant status in ABDM or NHCX |
The hospital remains the participant, and the regulator's counterparty |
Edsol Edtech Pvt. Ltd. is a Data Fiduciary for exactly one thing: the business contact data of the
hospital's staff whom it deals with commercially, and the visitors to its own websites. That is
POL-GL-053, and it is a small and separate matter.
The classification scheme is DIS-GL-022. In summary:
| Class | Examples | Who decides it is collected |
|---|---|---|
| Patient identity and demographic | Name, contact, identifiers the hospital records | Hospital |
| Clinical record | Encounters, observations, notes, orders, results, prescriptions, discharge summaries | Hospital's clinicians |
| Images and documents | Scanned records, consent forms, reports, generated PDFs | Hospital |
| Financial | Bills, tariffs applied, payments, claims, payer correspondence | Hospital |
| Staff and user | User accounts, roles, roster, access records | Hospital |
| Operational | Inventory, procurement, scheduling | Hospital |
| Audit and access records | Who viewed or changed what, and when | The Platform generates these; the hospital owns them |
Pensieve Labs support records |
Tickets and the correspondence in them | Pensieve Labs, as processor, and the hospital should avoid putting record content in a ticket |
Data the Platform does not hold: payment card data (payment is through the hospital's own gateway on the hospital's credentials), and any dataset combining hospitals.
| Stage | What happens | Where the detail is |
|---|---|---|
| Collection | At the hospital, by the hospital's staff, into the hospital's tenant. Pensieve Labs collects nothing directly from a patient |
DPA-GL-001 |
| Notice and consent | The hospital gives the notice and manages consent. Section 4 | POL-GL-053 for Pensieve Labs's own processing |
| Processing | Only on the hospital's documented instructions. Configuration of the Platform by the hospital constitutes instructions | DPA-GL-001 4 |
| Storage | Encrypted at rest, in the region recorded on the Order Form | DIS-GL-011, DIS-GL-008 |
| Access | Role-based, tenant-scoped, logged. Pensieve Labs access is second-person approved, time-bound and immutable-logged |
DIS-GL-012, DIS-GL-033, DIS-GL-013 |
| Sharing | Only to systems the hospital connects, using the hospital's own credentials | DIS-GL-024, ADD-GL-007 |
| Retention | Configured by the hospital against its own statutory and accreditation obligations | DIS-GL-034 for logs |
| Deletion and return | Free, unconditional, in specified formats, on a published timetable | DIS-GL-023, ADD-GL-017 |
The two commitments that matter most to a hospital's counsel, stated where they cannot be missed:
Edsol Edtech Pvt. Ltd. claims no right in it.MSA-IN-001 20.4.Consent under the Indian regime is the hospital's obligation, not Pensieve Labs's. The Platform
supports it; it does not discharge it.
| Function | Platform's part | Hospital's part |
|---|---|---|
| Giving notice at collection | Renders the notice the hospital authors, in the languages the hospital supplies, and records that it was shown | Authoring the notice, and its legal adequacy |
| Recording consent | Records what was consented to, when, by whom, and against which notice version | Deciding what requires consent |
| Withdrawal | Records withdrawal and the time of it, and stops the processing the hospital has mapped to that consent | Mapping consent to processing, and deciding the consequences of withdrawal |
| Consent Manager interaction | Where the hospital uses a registered Consent Manager, the Platform integrates using the hospital's own credentials | The relationship with the Consent Manager |
| Children's data and verifiable guardian consent | Records the guardian relationship and the consent as the hospital configures it | Determining what verification is adequate. Pensieve Labs does not decide this |
| Legitimate uses not requiring consent | Configurable, so that a lawful basis other than consent can be recorded | Determining which apply |
The candid statement. A supplier that claims its software makes a hospital consent-compliant is selling a legal conclusion it is not in a position to give.
Pensievegives the hospital the mechanism and the evidence trail. The lawful basis is the hospital's.
Every right is exercised against the hospital. Edsol Edtech Pvt. Ltd. assists and does not respond
directly to a Data Principal about a hospital's data.
| Right | What the Platform does | Pensieve Labs's assistance |
|---|---|---|
| Access to their data | The hospital retrieves and produces it through the Platform | Assistance where a retrieval is beyond the interface (DPA-GL-001 9) |
| Correction and completion | The hospital corrects; the prior value and the correction are both retained in the audit trail, because a clinical record is corrected by amendment and not by erasure | None |
| Erasure | The hospital erases where its own retention obligations permit. Where a statutory or accreditation retention period applies, the record is not erased, and the Platform records the refusal and its ground | Not applicable |
| Grievance | To the hospital first. Pensieve Labs's own Grievance Officer handles grievances about Pensieve Labs's own processing (POL-GL-066) |
info@pensievelabs.org |
| Nomination | Recorded as the hospital configures | None |
| Withdrawal of consent | Section 4 | None |
Where a request reaches Edsol Edtech Pvt. Ltd. by mistake, it is redirected to the hospital and the
hospital is told, without Edsol Edtech Pvt. Ltd. acting on it (DPA-GL-001 9).
The authoritative statement is DIS-GL-008. The architectural summary:
| Item | Position |
|---|---|
| Where data rests | The region recorded on the Order Form as Deal data region |
| Where data is processed | The same region. Compute and storage are co-located |
| Where logs rest | The same region, retention-locked (DIS-GL-034) |
| Backups | The same region unless the Order Form records otherwise |
| Support access | DIS-GL-033 records the countries from which Pensieve Labs personnel may access a tenancy. Support access is access, not transfer of custody, and it is logged in the tenant's own audit trail |
| Onward transfer | None, other than to the subprocessors in DIS-GL-009, each in the region recorded there |
| Transfers to the hospital's own connected systems | The hospital's own transfers, on the hospital's credentials (DIS-GL-024) |
| Transfer impact assessment | REP-GL-021 for hospitals whose own framework requires one |
| European transfers | The Standard Contractual Clauses are incorporated where applicable (DPA-GL-001 Annexure V) |
A hospital that requires data never to leave its own premises is describing DM-4, and should be told
so at qualification rather than discovering at contracting that no hosted model satisfies the requirement:
WPR-GL-004.
| Item | DM-1 |
DM-2 |
DM-3 |
DM-4 |
|---|---|---|---|---|
| Who owns the infrastructure account | Pensieve Labs |
Pensieve Labs |
Hospital | Hospital |
Role of Pensieve Labs |
Processor | Processor | Processor with delegated administrative access (ADD-GL-009) |
Supplier and support; limited or no access to data |
| Isolation | Dedicated project | Logical, per-tenant keys and datastore-level tenant scoping | Hospital's own project | Hospital's own hardware |
| Subprocessors touching personal data | As DIS-GL-009 records |
As DIS-GL-009 records |
Materially fewer: the hospital's cloud provider is the hospital's own supplier, not Pensieve Labs's subprocessor |
Typically none |
| Who holds backups | Pensieve Labs |
Pensieve Labs |
Hospital's project | Hospital (ADD-GL-008) |
| Who can see the audit trail | Hospital, in its tenant | Hospital, in its tenant | Hospital, plus its own cloud audit log | Hospital |
| Breach detection | Pensieve Labs monitors |
Pensieve Labs monitors |
Shared: the hospital's own monitoring covers its account | Largely the hospital's, and it must be resourced |
| Physical security | The cloud provider's | The cloud provider's | The cloud provider's | The hospital's |
The honest observation about DM-4. On-premise deployment moves custody to the hospital but does not
by itself improve privacy outcomes. It moves patching, backup verification, physical security, monitoring
and key custody to the hospital's own team. Where that team is well resourced it can be a strong position;
where it is not, it is weaker than DM-1. Pensieve Labs says this before a hospital chooses, not
afterwards.
WPR-GL-001 is the security document and is not repeated. The five controls a privacy reviewer specifically
asks about:
| Control | Position | Detail |
|---|---|---|
| Encryption at rest and in transit | Implemented in every model | DIS-GL-011 |
Who at Pensieve Labs can reach patient data |
Nobody by standing entitlement. Access is requested, second-person approved, least-privilege, time-bound and expiring | DIS-GL-033, DIS-GL-012 |
| Record-level access logging | Every read and write of a record is logged, immutably, and the hospital can read and export the log | DIS-GL-013 |
| Breach notification | To the hospital, on the timetable in DPA-GL-001 10; the hospital notifies the regulator and the Data Principals |
DIS-GL-016 |
| Deletion on exit | Free, unconditional, verified, with a certificate | DIS-GL-023 |
No feature makes, supports or influences a clinical decision. DIS-GL-028 is the boundary and
ADD-GL-006 makes it contractual. For privacy specifically:
| Question | Answer |
|---|---|
| Is there solely automated decision-making with a legal or similarly significant effect on a Data Principal? | No. Every model-assisted feature has a named human decision point, and no output has autonomous effect, per ADD-GL-006 3.2 |
| Is hospital data used to train models? | No, in any form, including de-identified and aggregated, and it is not available for purchase, consent or configuration to change that (ADD-GL-006 5) |
| Is there a third-party AI provider receiving hospital data? | None as at 01 August 2026 (DIS-GL-027 Section 5). If that changed, it would be a subprocessor with thirty days' notice and an objection right |
| Is a DPIA needed? | That is the hospital's assessment. REP-GL-020 is the template and exemplar, and Pensieve Labs supplies the information within ten Business Days (ADD-GL-006 8.4) |
Edsol Edtech Pvt. Ltd.| Item | Position |
|---|---|
| Policy set | POL-GL-110 (data protection and privacy), with the wider internal policy framework at POL-GL-000 |
| Grievance Officer | Published, as the Indian regime requires: [TO BE SUPPLIED], info@pensievelabs.org (POL-GL-066) |
| Data protection officer | Not appointed. Edsol Edtech Pvt. Ltd. is not a designated Significant Data Fiduciary. Where a hospital requires a named contact, it is the Grievance Officer, and this is stated rather than dressed up |
| Training | Annual, for every person with access (POL-GL-122) |
| Records of processing | Maintained, and provided to a hospital on request |
| Law enforcement requests | POL-GL-067. Edsol Edtech Pvt. Ltd. does not disclose a hospital's data to an authority without telling the hospital, unless the law forbids telling it |
| Transparency reporting | POL-GL-068 |
| Significant Data Fiduciary obligations | Not applicable as at 01 August 2026; several are applied voluntarily: the algorithmic due-diligence discipline in DIS-GL-027 Section 8 is one |
11.1 Edsol Edtech Pvt. Ltd. holds no privacy certification or third-party privacy audit. No ISO/IEC
27701, no independent privacy assurance report. What exists is the published control set, the DPA, this
document and the evidence in WPR-GL-005.
11.2 The commencement position of the Indian rules is a moving one. DPA-GL-001 carries a dated table
of what is in force. This document does not restate it, precisely so that it cannot become the stale copy.
11.3 Pensieve Labs cannot make a hospital compliant. The lawful basis, the notice, the retention
schedule, the internal access decisions and the response to a Data Principal are the hospital's. Any
supplier claiming otherwise is describing a product that does not exist.
11.4 Support tickets are a weak point, and it is a shared one. Where hospital staff paste record content
into a ticket, that content leaves the tenant's controls. Pensieve Labs asks that they do not, redacts
what it finds, and applies the same retention to tickets as to other records, but the control is partly the
hospital's behaviour.
11.5 De-identification is not offered as a privacy claim. Pensieve Labs does not de-identify
hospital data for any purpose, and therefore makes no claim about the strength of any de-identification
technique. This is a narrower position than most suppliers take, and deliberately so.
11.6 In DM-4, most of this document describes what the hospital does. The architecture is the same;
the accountability is not. Section 7 states it plainly.
| Identifier | Artefact | Relationship |
|---|---|---|
DPA-GL-001 |
Data Processing Agreement | The contract. Prevails over this document in every respect |
POL-GL-053 |
Privacy Policy | Pensieve Labs's own processing, as a Data Fiduciary |
POL-GL-066 |
Grievance Redressal Policy | The statutory grievance route |
POL-GL-067 |
Legal & Law Enforcement Request Policy | Section 10 |
POL-GL-110 |
Data Protection & Privacy Policy (internal) | The internal control set |
DIS-GL-008 |
Data Residency Statement | The authoritative residency position |
DIS-GL-009 |
Subprocessor Register | Who else is involved |
DIS-GL-016 |
Incident Response & Breach Notification | The breach timetable |
DIS-GL-022 |
Data Classification & Handling | The classification scheme in Section 2 |
DIS-GL-023 |
Data Deletion & Return Disclosure | Exit |
DIS-GL-024, DIS-GL-025, DIS-GL-026 |
Integration boundary; credential handling; ABDM/NHCX matrix | The BYOK/BYOC position |
DIS-GL-027, ADD-GL-006 |
AI disclosure; AI Addendum | Section 9 |
DIS-GL-034 |
Log Retention & Localisation | Log residency |
REP-GL-020, REP-GL-021 |
DPIA template; transfer impact assessment | Hospital-side assessments |
WPR-GL-001, WPR-GL-002, WPR-GL-004, WPR-GL-005 |
Security; architecture; deployment models; assurance | The companion set |
| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0.0 | 01 August 2026 | Security | Initial issue. Explains why the processor role is architecturally protected rather than merely asserted, divides consent obligations honestly between hospital and supplier, routes every Data Principal right through the hospital, states the per-model accountability shift including the candid observation that on-premise moves custody without automatically improving privacy, and records six limitations including the absence of any privacy certification and the weakness of support tickets. |