#Subprocessor Register

Register version 1.0.0 | Position as at 31 July 2026 | Next scheduled review 31 October 2026 | Total entries: 5

---

#Applicability

Section 3 (Trust Center and corporate) applies in all four models, because every hospital that buys Pensieve also uses the Trust Center to receive documents, and no deployment model changes that.

---

#Purpose

This register names every third party that Edsol Edtech Pvt. Ltd. engages which processes data belonging to, or relating to, a hospital customer. It exists so that a hospital's IT head, privacy officer or lawyer can answer the question "who else touches our data?" without sending an e-mail and waiting three days.

It is the source of truth. Annexure III of the Data Processing Agreement (DPA-GL-001) records the position a Customer accepted on signature; this register records who is engaged today. Where the two differ, this register is current and the Annexure is historical. Notification and objection rights are governed by DPA-GL-001 clause 8.4 and the running record of changes is the Sub-Processor Change Log (DIS-GL-010).

---

#How to read this register

The register is deliberately falsifiable. Every entry names a real legal entity, a real service, a real processing location and a publicly retrievable data processing agreement. Each of those can be checked without trusting Pensieve Labs. A register that cannot be checked is a marketing page.

Three tiers of entry are used, and the distinction is material:

---

#1. The one-sentence answer

In DM-1 and DM-2, exactly one sub-processor processes hospital patient data: the cloud infrastructure provider named in Section 2. In DM-3 and DM-4 there is none, because the hospital owns the infrastructure.

Everything else in this register handles business contact data for the Trust Center and for corporate administration. Pensieve Labs does not use a third-party hosted error-tracking, session-replay, product-analytics, customer-messaging, data-warehouse or artificial-intelligence service that receives Customer Personal Data. If that changes it changes under the notice procedure in Section 6, and this register is republished on the day it changes.

---

#2. Platform Sub-processors: process Customer Personal Data

There is no second platform sub-processor. Pensieve Labs does not engage a separate provider for monitoring, alerting, search, backup, e-mail delivery, document rendering or machine learning that receives Customer Personal Data. Every one of those functions runs on the infrastructure above, inside the deployment's own cloud project, under the same encryption keys and the same access controls.

The PDF render service is not a sub-processor. Documents are rendered to PDF by a containerised service that Edsol Edtech Pvt. Ltd. builds and operates itself, running on Cloud Run inside Pensieve Labs's own cloud organisation. It is Pensieve Labs's own software on Pensieve Labs's own infrastructure, so the sub-processor for it is the cloud provider already named above, and nothing further. This is stated explicitly because "we use a document rendering service" is exactly the kind of phrase that hides a third-party vendor, and here it does not.

---

#3. Trust Center and corporate Sub-processors: no patient data

These process the business contact data described in DPA-GL-001 clause 3.6: the names, work e-mail addresses, and document access records of the hospital's authorised users, plus the contract and disclosure documents exchanged during a deal. No patient record, no clinical record and no Data Principal record is processed by any entity in this section. The Trust Center is a separate application from the Platform and is not connected to any hospital's Platform instance (WPR-GL-001 Section 5.7).

Why these three and no more. The Trust Center is deliberately a small stack. It holds Pensieve Labs's document library and the deal lifecycle record. It does not hold patient data, it does not connect to a Platform instance, and it does not need an analytics vendor, a chat widget, a session replay tool or a marketing automation platform, none of which is used.

A hospital's realistic exposure through this section is that its authorised users' work e-mail addresses and the record of which documents they opened are processed in the United States. That is stated plainly rather than buried. A hospital that objects to this can receive its documents by e-mail attachment or on physical media instead of through the Trust Center, at the cost of the speed the Trust Center exists to provide; the request goes to info@pensievelabs.org.

---

#4. Not yet engaged: entries that will appear here when they exist

Publishing an empty row is more useful than publishing nothing, because it tells a reviewer where the register will grow.

[TO BE SUPPLIED] here means exactly what it says: Pensieve Labs has not selected a provider. It does not mean a provider exists and is being withheld.

---

#5. Not Sub-processors, and why the distinction matters

#5.1 The hospital's own connected systems

Every external system Pensieve talks to is reached using credentials the hospital holds and supplies: ABDM registries and the health information exchange, NHCX, insurers and third-party administrators, payment gateways, SMS, WhatsApp, voice and e-mail providers, laboratories and analyser vendors, PACS providers, accounting systems and government reporting portals.

Pensieve calls those systems as the hospital, on the hospital's authority. Edsol Edtech Pvt. Ltd. does not contract with them, does not pay them, cannot obtain credentials for them in its own name, and is not their customer. They are therefore the hospital's processors or independent controllers, not Pensieve Labs's sub-processors. The reasoning, and the full list of what this covers, is in the Integration Boundary Statement (DIS-GL-024); the custody rules for the credentials themselves are in DIS-GL-025 and ADD-GL-007; the responsibility split for ABDM and NHCX is in DIS-GL-026.

This is not a technicality invented to shorten a register. It is the reason the hospital, not Pensieve Labs, is the regulated participant in those systems, and it is stated affirmatively in 00-BRIEF.md Section 5 and throughout the contract stack.

#5.2 The cloud provider under DM-3 and DM-4

Under DM-3 the hospital owns and pays for the cloud project, contracts with the cloud provider directly, and holds its own agreement with it. The cloud provider is the hospital's supplier. Edsol Edtech Pvt. Ltd. operates inside that project under the Delegated Cloud Access & Administration Agreement (ADD-GL-009) and is not in a position to sub-contract infrastructure it does not buy.

Under DM-4 there is no cloud provider at all. The hardware is the hospital's.

Consequence, stated so nobody has to work it out: a hospital on DM-3 or DM-4 has zero Pensieve Labs sub-processors touching its patient data. That is one of the two legitimate reasons to choose those models, and it is a stronger answer than any assurance Pensieve Labs could give about a provider it selects.

#5.3 Pensieve Labs personnel and contractors

Individuals engaged by Edsol Edtech Pvt. Ltd. (employees and contractors) act under Pensieve Labs's direction and are not separately listed as sub-processors. They are subject to the controls in DIS-GL-020 and the access path in DIS-GL-033. The countries from which they work, and the constraints on that, are stated in DIS-GL-033 Section 2, including the Australian constraint that makes offshore support impermissible for certain data.

---

#6. Market-specific infrastructure

The default infrastructure in Section 2 does not satisfy every market's law, and this register says so rather than implying a single global answer.

---

#7. How a sub-processor is engaged

The register is the output. The process behind it is:

Edsol Edtech Pvt. Ltd. remains fully liable to the hospital for each sub-processor's performance of its data protection obligations, as if their acts and omissions were Pensieve Labs's own (DPA-GL-001 clause 8.3). Engaging a sub-processor moves work, not responsibility.

The urgent-replacement exception. Where a sub-processor must be replaced without notice to preserve the security or availability of the Platform, DPA-GL-001 clause 8.5 permits it and requires notice as soon as practicable afterwards, with the objection right preserved. That exception has not been used. If it is ever used, DIS-GL-010 will record it as such, including the fact that notice was retrospective.

---

#8. How to verify this register yourself

A hospital should not take this document on trust. Five checks, none of which requires Pensieve Labs's cooperation:

1. Check each entity exists. Every named entity in Section 2 and Section 3 is a real company with a public corporate record and a public web presence. Confirm the legal entity name, not the brand.
2. Read each data processing agreement at its published URL. They are public documents. Confirm the terms are what this register says they are, and confirm each incorporates Standard Contractual Clauses where a transfer arises.
3. Check the processing location claim. For an Indian deployment, ask for the cloud project's region configuration and the log bucket location; DIS-GL-034 states what should be there and Pensieve Labs will show it.
4. Ask for the annual review record for the Section 2 sub-processor. It is disclosable.
5. Test the notification mechanism. Subscribe to DIS-GL-010 and check that it produces an entry when this register changes. A change log that never changes and a register that never dates itself are the two symptoms of a register maintained for show.

---

#9. Limitations

9.1 The cloud provider has its own sub-processors. Edsol Edtech Pvt. Ltd. does not control, audit, or individually approve the entities the cloud provider engages beneath it. Pensieve Labs relies on that provider's published sub-processor list and its own contractual flow-down. No vendor of Pensieve Labs's size audits a hyperscale cloud provider, and this register does not imply otherwise.

9.2 This register is self-published and not independently audited. No third party verifies that it is complete. What makes it credible is that every entry is checkable (Section 8) and that omitting an entry would be a breach of DPA-GL-001 clause 8, which is contractually actionable, not that anyone has certified it.

9.3 It is accurate as at its date, not continuously. The register is republished on the day an engagement changes. Between changes it carries the date at the top of this page. If that date is old, the register is old, and that is visible rather than hidden.

9.4 Section 4 entries are genuinely undecided. Where a provider is marked [TO BE SUPPLIED], Pensieve Labs has not selected one. A hospital signing today should read Section 4 as a list of engagements that will trigger a notification later, and should note that the e-signature and stamping providers, when selected, will handle signatory identity data.

9.5 Business contact data in Section 3 is processed outside India. For an Indian hospital this is not Customer Personal Data under DPA-GL-001 and is not patient data, but it is personal data about the hospital's own staff. The opt-out in Section 3 exists for hospitals that will not accept it.

---

#10. Related documents

---

#11. Change history

---