#Trust & Assurance Overview

WPR-GL-005 v1.0.0, Last Modified On 31 July 2026, Tier: Public

This is the register. Where any other Pensieve Labs document describes what assurance exists, this document is authoritative and more current. It is reviewed quarterly and re-dated in public when a target moves.

---

#Purpose

You are considering running your hospital's entire operation on software from a company you had not heard of last month. The reasonable question is: on what basis?

This document answers it in three columns.

Edsol Edtech Pvt. Ltd. holds no security certifications. No ISO/IEC 27001. No SOC 2. No HITRUST. No ABDM milestone certification. That sentence appears in the first screen of this document rather than in a footnote, because a hospital that finds it in a footnote will reasonably wonder what else is in a footnote.

The rest of this document explains what exists instead, why it is worth something, and exactly what you should do with it during your evaluation.

---

#Table of contents

1. The answer on one page
2. How to read a credential: the four classes
3. Why an unknown vendor with no certificates can still be a safe choice
4. Column 1: Held today
5. Column 2: In progress, with dates and owners
6. Column 3: Not held
7. The sentences Pensieve Labs will and will not say
8. Questions worth asking every vendor in your evaluation
9. How this document is kept honest
10. Related documents
11. Change history

---

#1. The answer on one page

1.1 Edsol Edtech Pvt. Ltd. holds zero certifications and says so first. Not as a disclosure obligation but as a positioning decision. An unknown vendor asking to run a whole hospital cannot survive a single discovered overstatement, so Pensieve Labs does not make any.

1.2 What exists instead is a published evidence surface, not a promise. Every security control Pensieve Labs operates is described specifically enough to be tested: named algorithms, named retention periods, named notification windows, named responsibilities per deployment model. That is the Security Whitepaper (WPR-GL-001), and it is public, versioned and dated.

1.3 Several items on that surface are independently checkable without Pensieve Labs's cooperation. Anyone can score Pensieve Labs's transport security with a public scanner. Anyone can send a vulnerability report and time the response against the published commitment. Anyone can verify that every entity in the Subprocessor Register is a real company doing what is claimed. A hospital can ask for a data export during evaluation and watch it happen. None of those tests requires trusting anybody.

1.4 The commitments are contractual, not aspirational. The four-hour breach notification, the export obligation, the deletion certificate and the security schedule are in DPA-GL-001 and MSA-IN-001, which Pensieve Labs publishes before you ask for them. A published contract is a stronger artefact than an unpublished certificate, because you can read it and your advocate can hold Pensieve Labs to it.

1.5 The certification programme is real, sequenced and dated (Section 5), and the dates are published so they can be missed in public. A target that slips is re-dated with a reason, not quietly deleted.

1.6 Two things Pensieve Labs has decided never to buy, because pretending they are on a roadmap would be dishonest: HITRUST, which is a United States health-plan artefact with no demand in Pensieve Labs's markets; and medical-device conformity (ISO 13485, IEC 62304), because Pensieve is deliberately not a medical device and buying device credentials would assert otherwise. Section 6.4.

1.7 The ABDM and NHCX boundary is deliberate and it has operational consequences. Pensieve Labs is not an ABDM-certified system and does not onboard to NHCX in its own name. The hospital is the registered participant and holds its own credentials. This is an architectural decision, stated affirmatively, and it is the one item in this document that can affect a go-live, so it has its own document: the Integration Boundary Statement (DIS-GL-024). Read it before signing.

1.8 The single most useful thing you can do with this page: take Section 8 into your meetings with every other vendor you are evaluating. The questions there are the ones that separate a real security posture from a certificate on a wall, and Pensieve Labs is content to be judged by the same standard.

---

#2. How to read a credential: the four classes

Buyers are routinely shown four categorically different things and told they are all "certifications". They are not, and the difference decides how much weight each deserves.

Two rules follow, and Pensieve Labs applies both to itself.

Rule 1: a SELF artefact must say it is self-assessed, in the artefact, not in a footnote. Every Pensieve Labs self-declaration carries its class on its face. The moment a buyer discovers that a "certification" page was self-written, every other claim on the page becomes suspect.

Rule 2: a certificate at the infrastructure layer is not a certificate at the application layer. Pensieve runs on Google Cloud, which holds its own independent certifications and audit reports and whose India-region services are empanelled by the Ministry of Electronics and Information Technology following an independent STQC audit. Edsol Edtech Pvt. Ltd. is neither empanelled nor certified. Any vendor, including Pensieve Labs, who compresses that into "we are MeitY empanelled" is misrepresenting. WPR-GL-001 Section 16.4 carries the exact permitted sentence.

---

#3. Why an unknown vendor with no certificates can still be a safe choice

This section is the argument. It is offered without embellishment, and a reader who disagrees with it should say so during the evaluation rather than after.

#3.1 A certificate is a statement about a management system on a date

ISO/IEC 27001 certifies that an information security management system exists, is risk-driven, is documented and is operating. It does not certify the product, it does not certify the absence of vulnerabilities, and it does not tell you what happens to your data at 3 a.m. on a Sunday. It is genuinely valuable (Pensieve Labs is pursuing it, Section 5), but it is frequently asked for as a substitute for understanding, and it does not perform that function.

#3.2 The things that actually protect a hospital are checkable without a certificate

Five of them, all in WPR-GL-001, all testable during an evaluation:

A vendor with a certificate and no answer to those five is a worse choice than a vendor with no certificate and a good answer to all five. Pensieve Labs invites the comparison.

#3.3 Publishing openly is itself evidence

Pensieve Labs publishes, without an email gate and without an NDA: the security whitepaper, the architecture diagrams, the subprocessor register, the standard Master Services Agreement, the Data Processing Agreement, the Service Level Agreement, the deletion and exit commitments, the deployment model comparison, the integration boundary statement, and this document.

Larger vendors gate several of those. They can afford the friction. Pensieve Labs cannot, and the consequence is that a hospital can evaluate Pensieve Labs's legal and security position completely before it speaks to a salesperson. That is a structural advantage for the hospital, and it is deliberate.

#3.4 Pensieve Labs starts clean on the current standard

The ISO/IEC 27001:2013 edition reached the end of its transition period on 31 October 2025, and non-transitioned 2013-edition certificates were withdrawn. A vendor showing a 2013-edition certificate today is showing an expired one, and would be treated as a new client requiring a full initial audit (SGS, September 2025; A-LIGN: ISO 27001 transition).

Pensieve Labs holds nothing and says so. When it certifies, it will certify against the 2022 edition with no transition debt. Ask every vendor in your evaluation for the edition year printed on their certificate, and for the accreditation body of the certifying organisation. Both questions are free, and both are more informative than the certificate itself.

#3.5 The incentive structure

Pensieve Labs is asking a hospital to place its entire operation, clinical, financial, pharmacy, stores, HR, on software from a company with no track record. One discovered overstatement would end that conversation permanently and would end most of the conversations after it. The incentive to be accurate is therefore stronger than the incentive to look impressive. That is not a character claim; it is arithmetic, and it is the reason Section 6 of this document exists at all.

---

#4. Column 1: Held today

Each entry: what it is, class, why it is credible, what you should do with it.

#4.1 Pensieve Security Whitepaper (WPR-GL-001)

Class: SELF. A public, versioned, dated description of how Pensieve is built, hosted, operated and defended, with a per-deployment-model treatment throughout, a section stating that no independent validation exists, and a section listing what is not implemented.

Why it is credible. It is specific enough to be wrong. It names algorithms, retention periods, notification windows, severity-based remediation targets and the exact split of responsibility between Pensieve Labs and the hospital for each of DM-1 to DM-4. A document written to be unfalsifiable reads differently, and a reviewer can tell.

What to do with it. Give it to your IT head and ask him to find something in it he can disprove. Then read Section 17 (the limitations) and decide whether the gaps listed there are acceptable for your hospital. That is the whole evaluation, compressed.

#4.2 Architecture and data-flow diagrams (DIS-GL-006)

Class: SELF. One diagram set per deployment model, showing trust boundaries and every point at which patient data crosses one.

Why it is credible. It commits Pensieve Labs to an architecture that either matches the running system or does not. A hospital's technical reviewer can compare the diagram against what he observes.

What to do with it. Take it into the technical review and ask where the diagram is wrong. Ask specifically about the boundary between Pensieve and every external system you intend to use: that boundary is DIS-GL-024 and it is the one that causes go-live surprises.

#4.3 Subprocessor Register (DIS-GL-009) and change log (DIS-GL-010)

Class: SELF, but falsifiable. Every sub-processor named, with its legal entity, the service provided, the data categories processed, the processing location and the date added, plus a commitment to notify before adding a new one.

Why it is credible. Because you can check it. Every named entity either exists and does what is claimed or it does not. Very few artefacts a vendor can produce for free are this easy for a buyer to verify.

What to do with it. Check three entries at random. Then confirm which entries apply to the deployment model you are choosing: in DM-3 and DM-4 the hosting sub-processor leaves the chain entirely, because you own the infrastructure.

#4.4 The contract stack, published before you ask

Class: SELF, but contractual, which is stronger. The Master Services Agreement, the Data Processing Agreement with its DPDP Rule 6 security schedule mapped clause by clause, the Service Level Agreement and the standard Order Form are published on the Trust Center.

Why it is credible. A published standard contract cannot be quietly weaker for the next hospital, and your advocate can review it before a single meeting. The four-hour breach notification commitment, the export obligation, the deletion certificate and the audit rights are terms, not marketing.

What to do with it. Have your advocate read DPA-GL-001 Section on breach notification and compare the four-hour commitment against every other vendor's. Most say "promptly". Under CERT-In's six-hour reporting window, "promptly" is not a number a hospital can plan around.

#4.5 Vulnerability Disclosure Policy and security.txt

Class: SELF, but externally testable. Published scope, safe harbour for good-faith researchers, and response commitments: acknowledge within 3 business days, triage within 10, status update at least every 30 until closure. Published at /.well-known/security.txt per RFC 9116.

Why it is credible. Anybody can test it. Send a report and time the response. A vendor that publishes response times and then misses them has created evidence against itself, which is why most do not publish them.

What to do with it. If your organisation has a security function, have it send a low-severity report during the evaluation and measure the acknowledgement time.

#4.6 Transport security grades

Class: independent, in the narrow sense that the scanner is not Pensieve Labs's. Public scanners score Pensieve Labs's own endpoints on TLS configuration, cipher suites and security headers.

Why it is credible. It is the only item in this column that a third party generates and that anybody can re-run at any moment, including after Pensieve Labs changes something.

What to do with it. Run the scan yourself against https://trust.pensievelabs.org before your first meeting. A vendor whose own trust site scores poorly on transport security has told you something useful about its engineering discipline, and it costs you thirty seconds to find out.

#4.7 Inherited cloud provider assurance

Class: ATT and CERT, but they are Google's, not Pensieve Labs's. The physical security, environmental controls, hardware lifecycle and data-centre operations underlying DM-1, DM-2 and DM-3 are covered by Google Cloud's own independently audited controls, and Google Cloud's India-region services are MeitY-empanelled following an STQC audit.

Why it is credible, and precisely how far it goes. It is credible for the infrastructure layer and worthless for the application layer. Pensieve Labs reviews the provider's audit reports annually and records the review (DIS-GL-021), and states the boundary in the exact words set out in WPR-GL-001 Section 16.4.

What to do with it. Do not accept it (from Pensieve Labs or anyone else) as an answer to a question about application security. And note that it does not apply at all in DM-4, where the physical layer is yours.

#4.8 Software bill of materials (DIS-GL-019)

Class: SELF, machine-checkable. CycloneDX and SPDX, produced per release.

Why it is credible. It is operational rather than decorative. When the next widely exploited library vulnerability is announced, a hospital can determine in minutes whether Pensieve is affected.

What to do with it. Ask what the SBOM was used for the last time a major vulnerability was disclosed. The answer distinguishes a generated file from a working process.

#4.9 Published boundary statements

Class: SELF. Three documents that state, in advance, what Pensieve does not do:

• Integration Boundary Statement (DIS-GL-024): where Pensieve Labs's responsibility begins and ends for every class of external integration, with the ABDM/NHCX responsibility matrix (DIS-GL-026).
• Clinical Safety Boundary Statement (DIS-GL-028): why Pensieve is not a medical device, and what it will therefore never do.
• AI/ML Feature Disclosure (DIS-GL-027): where machine learning is used, where it is not, and the human review step.

Why they are credible. They constrain the product roadmap, publicly. A boundary a vendor publishes is a boundary it has to keep.

What to do with them. DIS-GL-024 is the one that can affect your go-live date. Read Section 3 of it before you commit to any ABDM or NHCX obligation with a state authority, an insurer or an accreditation body.

#4.10 Live operational dates

Class: SELF, but dated in public. The Trust Center publishes the date of the most recent restore drill, the most recent incident-response exercise, the most recent penetration test and the current SBOM release.

Why it is credible. Because a stale date is visible. Pensieve Labs publishes the date rather than the claim, and if the date is old, it is old in public. That is the intended pressure.

What to do with it. Look at the dates before you look at anything else. Four current dates on a trust page tell you more about a vendor's operating discipline than thirty undated PDFs.

---

#5. Column 2: In progress, with dates and owners

Every item below has a named owner and a target date. Both resolve from the Assurance Roadmap and both are published. When a target moves, this document is re-dated with the reason in Section 11, and the old target remains visible in the change history.

#5.1 The sequence, and why it is in this order

The order is chosen for what it unlocks per rupee and per day, not for what looks most impressive.

flowchart LR
  P0["Phase 0: free, days<br/>Publish the evidence surface"] --> P1["Phase 1: weeks<br/>Independent VAPT, CAIQ<br/>insurance, escrow"]
  P1 --> P2["Phase 2: months<br/>SoA, international pen test<br/>market-specific declarations"]
  P2 --> P3["Phase 3: year one<br/>ISO/IEC 27001:2022<br/>then SOC 2 I → II → 3"]

Text description. Phase 0 publishes the free evidence surface in days. Phase 1 adds, in weeks, an independent vulnerability assessment and penetration test, a published self-assessed CAIQ, insurance and source-code escrow. Phase 2 adds, over months, the ISO 27001 Statement of Applicability published without certification, an international penetration test attestation, and market-specific declarations. Phase 3, in the first year, delivers ISO/IEC 27001:2022 certification followed by SOC 2 Type I, Type II and a publishable SOC 3.

Why ISO 27001 before SOC 2. The management system produces the control environment, the evidence repository and the policy set that a SOC 2 readiness phase would otherwise build from scratch. Running SOC 2 first wastes that overlap. It also happens that ISO is the credential Pensieve Labs's actual markets ask for, and SOC 2 is the one asked for by markets Pensieve Labs reaches later.

#5.2 The programme

#5.3 What Pensieve Labs commits to about this table

1. Dates are published so they can be missed in public. A slipped target is re-dated here with a reason in the change history. It is not removed.
2. Owners are named individuals, not departments. A credential owned by "the team" is a credential nobody is delivering.
3. A certification project will never delay a publication. The correct order is publish, sell, then certify with the revenue, because a hospital's decision is made in days and a certificate arrives in months. Pensieve Labs will not withhold a security document because the certified version is coming.
4. Pensieve Labs will not describe an in-progress item as held. Item 9 is not "we are ISO 27001 aligned" until the SoA is published, and it is not "certified" until a certificate exists with an accreditation mark on it. Section 7 sets out the exact language.

---

#6. Column 3: Not held

This section is deliberately longer than the previous one.

#6.1 Certifications and attestations Edsol Edtech Pvt. Ltd. does not hold

#6.2 ABDM and NHCX: deliberately out of scope, and what that means for you

This is the most important entry in this document, because it is the only one that can affect a go-live date.

Edsol Edtech Pvt. Ltd. does not hold ABDM M1/M2/M3 milestone certification, is not an ABDM-certified hospital management system, and does not onboard to the National Health Claims Exchange as a participant in its own name. This is a decision, not a backlog item.

The architecture instead. The hospital is the registered health facility. The hospital holds its own Health Facility Registry identifier; its clinicians hold their own Healthcare Professionals Registry identifiers; the hospital holds its own NHCX participant credentials. Pensieve operates a bring-your-own-credential model: the hospital supplies its credentials, Pensieve Labs stores them encrypted in a per-tenant vault, and the Platform calls those systems as the hospital, on the hospital's own authority. Pensieve Labs is therefore not the regulated participant and does not represent that it is.

Why this is a defensible position and not a gap. The registrations in question are facility registrations and participant registrations. They belong to the hospital by design: a Health Facility Registry identifier identifies a facility, and an NHCX participant code identifies a claims participant. A software vendor holding them on a hospital's behalf inserts a dependency between the hospital and its own regulator. The hospital keeps its credentials, keeps its relationships, and can change software without re-registering.

Where this could hurt you, stated plainly. If your state, your accreditation programme or an incentive scheme requires that your hospital's software itself holds ABDM milestone certification, Pensieve Labs does not satisfy that requirement, and no amount of the above changes it. That is a real constraint and it must be checked at qualification, not at cutover.

What to do about it. Read the Integration Boundary Statement (DIS-GL-024) in full, and the ABDM/NHCX Responsibility Matrix (DIS-GL-026) within it. It states, per integration class, who holds the credential, who is the regulated participant, what Pensieve does technically, what it does not do, and what you must provide and by when. Pensieve Labs surfaces this in the first qualification conversation rather than at go-live, and if a hospital tells Pensieve Labs that certified-vendor status is a hard requirement, Pensieve Labs will say so and stop rather than discover it later.

#6.3 Market-specific credentials not held

DIS-GL-008 states the residency position per market, including where it is not met. Pensieve Labs would rather decline a market than describe a capability it does not have.

#6.4 What Pensieve Labs has decided never to pursue

Publishing this is unusual and it is deliberate. A roadmap that contains everything is a roadmap that contains nothing.

HITRUST, in any tier. It is a United States health-plan and health-system vendor artefact, driven by US-specific contractual requirements. No Indian, Australian, Danish, Norwegian or Emirati hospital procurement process asks for it. Pursuing it would consume more cash than Pensieve Labs's entire certification programme and would unlock nothing. If a United States buyer ever appears, the decision will be revisited on the record.

ISO 13485, IEC 62304 and medical-device conformity. Pensieve is deliberately outside the software-as-a-medical-device boundary: it does not diagnose, triage, score clinical risk, calculate patient-specific doses or recommend treatment. Buying device credentials would be an implicit assertion that Pensieve is a device, which invites regulatory questions to which Pensieve Labs currently has a clean answer. The Clinical Safety Boundary Statement (DIS-GL-028) is published instead, and it constrains the product roadmap rather than merely describing it.

The corollary, stated because it is the honest one. This position permanently constrains what Pensieve can become. If a hospital needs interaction-severity scoring, patient-specific dose calculation, imaging triage or an early-warning score, Pensieve does not provide it and will not provide it without first undertaking the device-conformity route. Pensieve Labs would rather say that in a sales meeting than discover it in a regulator's letter.

Cyber Essentials and Cyber Essentials Plus. United Kingdom credentials; Pensieve Labs does not sell in the United Kingdom.

A speculative SIG licence. The Shared Assessments questionnaire is licensed rather than free. Pensieve Labs will answer one reactively from its CAIQ evidence base rather than licensing it against a demand that has not materialised.

#6.5 Operational limitations

These are restated from WPR-GL-001 Section 17 because a hospital reading only this document should still see them.

• No independent audit of the controls described in WPR-GL-001.
• No 24×7 staffed security operations centre.
• Limited separation of duties: at Edsol Edtech Pvt. Ltd.'s size, the same small group builds and operates the Platform. Compensating controls are mandatory peer review, second-person approval for production access, and immutable audit logs the accessing engineer cannot alter.
• In DM-1 and DM-2, Pensieve Labs can technically decrypt hospital data through an approved, time-bound, logged path. There is no customer-held-key architecture in the hosted models. Hospitals requiring a structural rather than procedural control should choose DM-3 or DM-4.
• DM-2 isolation is logical, not physical.
• Some legacy laboratory and imaging devices cannot support modern transport security; where one is in scope the limitation is recorded rather than accepted silently.
• No availability commitment for DM-4, and no RTO or RPO commitment for infrastructure Pensieve Labs does not control.

#6.6 No customers to reference yet

Pensieve Labs does not publish a customer list, logos or reference letters, because it does not yet have consented references to publish. It will not manufacture them, will not describe a pilot as a deployment, and will not name a hospital without written consent.

What a buyer should do with that. Treat it as a real risk and price it. Ask to speak to the engineering team rather than to a reference. Ask for a proof of concept against your own data. Ask for the first-customer commercial terms. Being early should be worth something, and Pensieve Labs treats it as worth something.

---

#7. The sentences Pensieve will and will not say

This table is binding on every Pensieve Labs document, proposal, questionnaire response, sales conversation and web page. It is published so that a hospital can hold Pensieve Labs to it, and so that a hospital can apply the same test to every other vendor in its evaluation.

If you ever receive a Pensieve Labs document, proposal or e-mail containing a sentence from the left column, it is wrong. Send it to info@pensievelabs.org and it will be corrected and the correction recorded.

---

#8. Questions worth asking every vendor in your evaluation

Take these into every vendor meeting, including Pensieve Labs's. They are ordered by how quickly they separate a real posture from a decorative one.

Pensieve Labs has published answers to all ten. Question 10 is WPR-GL-001 Section 17 and Section 6.5 of this document.

---

#9. How this document is kept honest

---

#10. Related documents

---

#11. Change history

Target changes are recorded in this table with the previous target, the new target and the reason. No target is removed.

---