#Pensieve Security Whitepaper

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

---

#Applicability

---

#Purpose

This whitepaper describes how Pensieve is built, hosted, operated and defended. It is written for two readers at once: the hospital's IT head or security reviewer, who needs named algorithms, named services and named retention periods; and the medical director or managing trustee, who needs to understand what happens to patient data and who can see it, without a networking background.

It is the document Pensieve Labs expects a hospital to read instead of asking for a certification. Edsol Edtech Pvt. Ltd. holds no security certifications today. Section 16 says exactly what independent validation exists, what does not, and what is planned. Section 17 lists what is not yet implemented. Both sections are load-bearing: a hospital that reads them and still proceeds is a hospital that has made an informed decision, which is the only kind of decision worth having.

Scope. Pensieve, the hospital operating system, in all four deployment models, together with the systems Pensieve Labs uses to build, deploy and support it. The Trust Center (https://trust.pensievelabs.org) is a separate property and is covered in Section 5.7.

---

#Table of contents

1. Executive summary
2. Security philosophy
3. Architecture and isolation, per deployment model
4. Identity and access management
5. Encryption and key management
6. Network security
7. Application security and the secure SDLC
8. Vulnerability management
9. Logging, monitoring and detection
10. Incident response
11. Business continuity and disaster recovery
12. Data protection and privacy
13. Personnel security
14. Sub-processors and supply-chain security
15. Physical and environmental security
16. Assurance and evidence
17. Limitations: what is not yet implemented
18. Customer responsibilities
19. Contacting the security team
20. Related documents
21. Change history

---

#1. Executive summary

Pensieve is the operating system a hospital runs its whole operation on. That is a larger claim on a hospital's trust than a departmental module makes, and it carries a correspondingly larger security obligation. This section states the position in one page.

1.1 The hospital owns its data. Pensieve Labs processes it. In every deployment model the hospital is the Data Fiduciary and Edsol Edtech Pvt. Ltd. is the Data Processor. Pensieve Labs does not use hospital data to train models, does not sell it, does not aggregate it into a product, and does not process it for any purpose other than delivering the Platform under the Data Processing Agreement (DPA-GL-001).

1.2 Isolation is a deployment decision the hospital makes, not a default it inherits. Four models are offered and all four are supported. DM-1 gives the hospital a dedicated cloud project, dedicated database, dedicated storage and dedicated encryption keys. DM-2 shares infrastructure with logical isolation. DM-3 puts everything in the hospital's own cloud account. DM-4 puts everything on the hospital's own hardware. The security consequences of each are set out in Section 3 and, in more commercial terms, in the Deployment Models paper (WPR-GL-004).

1.3 Data stays in India for Indian hospitals. For Indian deployments the Platform runs in Google Cloud India regions and all customer data and all system logs remain within Indian jurisdiction. This satisfies the ABDM Health Data Management Policy's localisation expectation and CERT-In Direction (iv), which requires ICT system logs to be maintained within India. The exact region for a given deployment is recorded as Deal data region on the Order Form. See the Data Residency Statement (DIS-GL-008).

1.4 Encryption is not a marketing word here. Data at rest is encrypted with AES-256 by the cloud platform as a floor, and above that floor Pensieve Labs applies customer-managed encryption keys (CMEK) in Cloud KMS: a dedicated key ring per hospital in DM-1 and DM-3, and per-tenant keys in DM-2. Data in transit uses TLS 1.2 or 1.3 with modern cipher suites; plaintext HTTP is served only as a redirect to HTTPS. Details, including key rotation periods and what Pensieve Labs can and cannot decrypt, are in Section 5 and in the Encryption Disclosure (DIS-GL-011).

1.5 Every access to a patient record is logged, and the log is immutable and retained for at least 365 days. That number is chosen to satisfy the longest of three overlapping obligations: DPDP Rules 2025 Rule 6(1)(e) and Rule 8(3) (one year), and CERT-In's 180-day rolling requirement, so that one configuration satisfies all of them. Logs are held in regional log buckets inside India with retention lock applied. See Section 9 and the Log Retention Disclosure (DIS-GL-034).

1.6 External systems are called on the hospital's own credentials. Pensieve Labs deliberately does not act as the registered participant in ABDM, NHCX, payment networks, insurer portals or messaging gateways. The hospital holds its own facility registration and its own credentials; Pensieve stores them encrypted in a per-tenant vault and uses them to act as the hospital, on the hospital's authority. This is an architectural boundary, not a gap, and it is documented in full in the Integration Boundary Statement (DIS-GL-024).

1.7 Pensieve is not a medical device and makes no clinical decisions. It does not diagnose, triage, score, calculate patient-specific doses or recommend treatment. The boundary is stated formally in the Clinical Safety Boundary Statement (DIS-GL-028) and it constrains the product roadmap, not merely the marketing copy.

1.8 Edsol Edtech Pvt. Ltd. holds no security certifications. No ISO/IEC 27001. No SOC 2. No HITRUST. No ABDM milestone certification. The company does not claim otherwise anywhere, and any document that appears to claim otherwise is not a Pensieve Labs document. What exists instead is set out in Section 16 and in the Trust & Assurance Overview (WPR-GL-005), together with target dates and named owners for what is being obtained.

1.9 The commitment that matters most. Pensieve Labs will tell a hospital about a security incident affecting its data within 4 hours of becoming aware of it, with enough content for the hospital to make its own CERT-In report inside CERT-In's 6-hour window. That number is in the DPA, not only in this whitepaper. See Section 10.

---

#2. Security philosophy

Five principles. Each one has a consequence you can check.

#2.1 The hospital must be able to leave

A hospital operating system that cannot be exited is not a platform; it is a hostage situation, and every experienced hospital owner in India knows it. Pensieve Labs therefore treats exportability as a security property rather than a commercial concession. The hospital's data is available for export in documented, non-proprietary formats throughout the relationship, not only at termination, and the deletion and return process is published in advance in DIS-GL-023, with a Certificate of Deletion issued at the end of it.

How to check this: ask for an export during the evaluation, before signature. The capability either exists or it does not, and a demonstration takes minutes.

#2.2 Isolation is chosen, priced and documented, never assumed

Most hospital software vendors describe a single architecture and let the buyer assume it is dedicated. Pensieve Labs publishes four architectures and states plainly which one a given hospital is buying. DM-1 appears on the Order Form. The isolation properties of the chosen model appear in the Security Addendum. A hospital never has to infer its own architecture.

How to check this: read Section 3, then read WPR-GL-004, then look at the deployment model recorded on the Order Form. All three must agree.

#2.3 Least privilege, including for Pensieve Labs

Pensieve Labs personnel do not hold standing access to hospital production data. Access to a production environment is time-bound, requested against a reason, approved, logged and expired. In DM-3 the hospital grants that access itself and can revoke it without contacting Pensieve Labs. In DM-4 Pensieve Labs has no access at all except through a session the hospital opens.

How to check this: ask for the access request record for the most recent support intervention on your tenant. In DM-1, DM-2 and DM-3 it exists and is retrievable.

#2.4 Evidence over adjectives

Every security claim in this document is written so that it can be falsified. Where a number exists, a key length, a retention period, a notification window, a restore time, the number is given. Where a control does not exist yet, Section 17 says so. Pensieve Labs would rather be caught being honest about a gap than be caught overstating a control, because a hospital that discovers one overstatement will reasonably discount every other statement in the document.

#2.5 Defence in depth, because a single control will eventually fail

The Platform assumes that any one control can fail: a credential can leak, a dependency can carry a vulnerability, a person can be deceived. Controls are layered so that no single failure exposes a hospital's entire dataset: network isolation, then identity, then per-tenant authorisation, then per-tenant encryption keys, then immutable audit logging that makes the failure visible. Section 3 through Section 9 describe the layers in order.

---

#3. Architecture and isolation, per deployment model

#3.1 The common architecture

Pensieve is a set of containerised services running on Google Cloud Run, backed by a managed PostgreSQL database, object storage for documents and images, a managed secret store, and Cloud KMS for key management. The same application code runs in all four deployment models; what changes is who owns the project, where the boundary sits, and how many hospitals share a component.

flowchart TB
  subgraph EDGE["Edge"]
    U["Hospital users<br/>browser / device"]
    LB["HTTPS load balancer<br/>TLS 1.2+, WAF"]
  end
  subgraph APP["Application tier: Cloud Run"]
    API["Pensieve API services"]
    WRK["Background workers<br/>jobs, exports, integrations"]
  end
  subgraph DATA["Data tier"]
    DB[("PostgreSQL<br/>encrypted at rest")]
    OBJ[("Object storage<br/>documents, images")]
    VAULT[["Secret store<br/>hospital-supplied credentials"]]
    KMS[["Cloud KMS<br/>encryption keys"]]
  end
  subgraph OBS["Observability"]
    LOG[("Regional log bucket<br/>immutable, ≥365 days")]
  end
  EXT["External systems<br/>ABDM, NHCX, payments, labs, PACS"]

  U -->|HTTPS| LB --> API
  API --> DB
  API --> OBJ
  API --> VAULT
  WRK --> DB
  WRK -->|hospital's own credentials| EXT
  KMS -.encrypts.-> DB
  KMS -.encrypts.-> OBJ
  KMS -.encrypts.-> VAULT
  API --> LOG
  WRK --> LOG

Text description of the diagram. Hospital users reach the Platform over HTTPS through a load balancer that terminates TLS and applies web application firewall rules. The load balancer forwards to the Pensieve API services running on Cloud Run. Those services, and a set of background workers, read and write a PostgreSQL database and an object store, and read hospital-supplied credentials from a secret store. Cloud KMS holds the keys that encrypt the database, the object store and the secret store. Background workers are the only components that call external systems, and they do so using credentials the hospital supplied. Every service writes to a regional, immutable log bucket with a retention period of at least 365 days.

#3.2 Isolation properties by model

#3.3 DM-1: dedicated, and the recommended default

Each hospital gets its own Google Cloud project. That project contains its own Cloud Run services, its own database instance, its own storage buckets, its own KMS key ring and its own log bucket. Nothing inside it is shared with another hospital, and there is no code path in which a request authenticated to one project can read data in another, because the projects are separate cloud tenancies with separate IAM boundaries.

This is the model Pensieve Labs recommends and the one it can deploy fastest. The isolation argument is short enough to be checked in one meeting, which is worth several days on the deal clock.

#3.4 DM-2: shared, and how it is defended

DM-2 is the hardest model to defend honestly, so it is described in more detail than the others. The Multi-Tenancy Isolation Disclosure (DIS-GL-032) carries the full treatment; this is the summary.

Isolation in DM-2 is logical, not physical. It rests on four layers:

1. Tenant binding at authentication. Every session is bound to exactly one tenant identifier at sign-in. A tenant identifier cannot be supplied by the client, changed by a parameter, or inferred from a URL. It is derived from the authenticated principal on the server side.
2. Row-level security in the database. Tenant scoping is enforced by PostgreSQL row-level security policies attached to the tables themselves, not only by application WHERE clauses. A query that omits the tenant predicate returns nothing rather than returning another hospital's rows. This matters because application-layer-only scoping fails the moment one developer forgets one clause.
3. Per-tenant data encryption keys. Each tenant's data is encrypted with its own data encryption key, wrapped by a key encryption key in Cloud KMS. Storage-level access to another tenant's ciphertext does not yield plaintext.
4. Per-tenant object storage prefixes with key-scoped access. Object access is authorised per tenant prefix and the objects are encrypted under the tenant's own key.

The honest statement about DM-2: shared infrastructure means an application-layer flaw has a larger potential blast radius than in DM-1. The four layers above are designed so that a single flaw is not sufficient: an attacker would need to defeat tenant binding and row-level security or obtain another tenant's key material. Pensieve Labs does not claim that a multi-tenant system is equivalent to a dedicated one. A hospital that wants the shorter argument should choose DM-1.

#3.5 DM-3: the hospital's own cloud project

The hospital owns and pays for the cloud project. Pensieve Labs deploys and operates Pensieve inside it under a delegated-access arrangement documented in the Delegated Cloud Access & Administration Agreement.

What changes:

• The hospital is the infrastructure owner. It sets the organisation policy, the billing account, the VPC design and the retention configuration, and it can inspect every action Pensieve Labs takes in its own Cloud Audit Logs, logs Pensieve Labs cannot alter or delete.
• Pensieve Labs's access is granted by the hospital and revocable by the hospital, without notice and without Pensieve Labs's cooperation. Roles are least-privilege and named in the agreement.
• A break-glass path exists for a production emergency: a separately named, alerting, time-boxed role that the hospital is notified about on use. It is not a standing role.
• Availability commitments change. Pensieve Labs cannot commit to an availability figure for a project whose quotas, budget and organisation policy it does not control. SLA-GL-001 states the DM-3 position explicitly.

#3.6 DM-4: on-premise

Pensieve runs on hardware the hospital owns, in a room the hospital controls, on a network the hospital operates. Pensieve Labs supplies the software, the deployment, the upgrade path and support.

What Pensieve Labs does not control in DM-4, stated plainly: the physical security of the room; who has console access; power and cooling; the network perimeter; the hypervisor and host operating system, where the hospital chooses to manage them; the backup media and where they are stored; whether patches are applied when they are shipped; and whether the environment is monitored at 03:00.

Consequently:

• Pensieve Labs publishes no availability commitment for DM-4 hardware. SLA-GL-001 limits the DM-4 commitment to Pensieve Labs's own response times, not to uptime.
• RTO and RPO in DM-4 are a function of the hospital's backup practice. Pensieve Labs can configure and test a backup regime and will do so; it cannot commit to a restore time for media it never sees. DIS-GL-014 carries the per-model position.
• Remote support requires a mechanism the hospital opens. There is no persistent Pensieve Labs tunnel into a hospital's server room. The Offshore/Remote Access Disclosure (DIS-GL-033) describes the mechanism, the logging and the hospital's ability to observe and terminate a session.
• DM-4 materially extends the go-live timeline and Pensieve Labs says so at qualification rather than at cutover. See WPR-GL-004 Section 7.

The On-Premise Supplement to the MSA covers hardware specification, environmental requirements, physical security expectations, backup custody, patching windows and the remote-access mechanism. It is a prerequisite to a DM-4 deployment, not an afterthought.

#3.7 Environments

Pensieve Labs operates separate development, staging and production environments. Production data is never copied into development or staging. Where realistic data is needed for testing, Pensieve Labs uses generated data. Where a defect can only be reproduced with production data, it is investigated in the production environment under the time-bound access process in Section 4.5, and never by exporting a copy to a laptop.

---

#4. Identity and access management

Two populations of identity exist and they are kept entirely separate: hospital users, who use the Platform, and Pensieve Labs personnel, who build and operate it. They authenticate through different systems, hold different credentials, and appear differently in the audit log.

#4.1 Hospital user authentication

On shared logins. The single most common security failure in Indian hospital deployments is not an attacker; it is a ward terminal with one login shared by six people across three shifts. Pensieve is designed to make individual login practical: fast switching, device-bound convenience factors and role-appropriate session lifetimes, because a control that makes clinical work slower will be defeated by the people doing clinical work. This is discussed further in Section 18.2, where it is a hospital responsibility.

#4.2 Authorisation inside the Platform

Access is role-based, with permissions granted to roles and roles granted to users. Roles are scoped by function (registration, nursing, pharmacy, laboratory, billing, stores, HR, administration) and, where the hospital requires it, by organisational unit: a ward, a department, a site.

Three properties matter to a hospital reviewer:

1. Default deny. A permission that has not been granted is denied. New features do not become visible to existing roles without an explicit grant.
2. Separation of duties is expressible. The permissions that create a purchase order, approve it and record its receipt can be held by different roles, and the same applies to billing adjustments and refunds. Pensieve Labs configures this during onboarding; the hospital decides the split.
3. Sensitive record access is separately controlled and separately logged. Access to categories that a hospital designates as restricted (for example psychiatric records, HIV status, or medico-legal cases) can be limited to named roles, and every access is recorded with the accessing user, the record, the time and the access reason where the hospital configures reason capture.

Full detail is in the Authentication & Access Control Disclosure (DIS-GL-012).

#4.3 Administrative accounts inside the hospital

The hospital nominates its own administrators. Pensieve Labs does not create hospital user accounts after go-live except at the hospital's written request through the support channel. Administrator actions (creating a user, changing a role, resetting a credential, changing a masters record) are logged and are visible to the hospital in its own audit trail, not only to Pensieve Labs.

#4.4 Pensieve Labs personnel identity

#4.5 How Pensieve Labs reaches production data: the control a hospital should actually interrogate

This is the control that decides whether everything else in this document matters, so it is stated precisely.

Per deployment model:

DM-3 and DM-4 give the hospital structural control over Pensieve Labs's access. DM-1 and DM-2 give it contractual control plus disclosure. A hospital for whom "we can cut them off ourselves" is non-negotiable should choose DM-3.

---

#5. Encryption and key management

The Encryption Disclosure (DIS-GL-011) is the source of truth for this area. What follows is the summary a security reviewer needs.

#5.1 Encryption at rest

All customer data at rest is encrypted. Two layers apply.

Layer 1: platform default. Data stored in Google Cloud is encrypted at the storage layer with AES-256 using an envelope scheme: data encryption keys (DEKs) protect the data and are themselves wrapped by key encryption keys (KEKs), with KEKs generated using Google's cryptographic library and a NIST SP 800-90Ar1 CTR-DRBG random number generator (Google Cloud: Default encryption at rest). This layer requires no configuration and cannot be switched off.

Layer 2: customer-managed encryption keys (CMEK). Above the default, Pensieve Labs configures CMEK in Cloud KMS so that the KEK protecting a hospital's data is a key with an identity, a rotation schedule, an access policy and an audit trail. Cloud KMS keys are 256-bit AES-GCM (Google Cloud: CMEK).

The consequence a hospital should understand. In DM-3 and DM-4 the hospital holds the keys. If the hospital disables or destroys a key, Pensieve Labs cannot decrypt the data, cannot restore it, and cannot recover it. That is the correct behaviour for a key the hospital controls, and it is stated here so it is never a surprise. Key destruction in DM-3/DM-4 is an irreversible act the hospital should protect with its own approval process.

#5.2 Encryption in transit

• External connections to the Platform require TLS 1.2 or TLS 1.3. Insecure cipher suites are disabled at the load balancer. Plaintext HTTP is served only as a permanent redirect to HTTPS.
• HSTS is set with a long max-age and includeSubDomains.
• Traffic between Platform components inside the cloud project is encrypted in transit.
• Connections to external systems (Section 14, DIS-GL-024) are made over TLS. Where a hospital's existing system (a legacy analyser, an older PACS node) cannot offer TLS, the connection is confined to the hospital's own network segment and the limitation is recorded in the deployment record rather than quietly accepted. See Section 17.6.

#5.3 Credential and secret handling

Hospital-supplied credentials for external systems (ABDM client credentials, NHCX participant credentials, payment gateway keys, SMS and WhatsApp provider tokens, insurer portal logins, e-mail credentials) are held in a managed secret store, encrypted under the tenant's key, with access restricted to the specific Platform service that needs them.

Specifically:

• Credentials are write-only from the hospital's perspective: once supplied they are not rendered back to any screen, log, export or support view.
• Credentials are never written to application logs. Log redaction is applied at the logging boundary rather than relying on developers to remember.
• Credentials are scoped to the tenant that supplied them and cannot be used by another tenant's workload.
• Credentials are rotatable by the hospital at any time, and revocable by the hospital at the source system without Pensieve Labs's cooperation, because they are the hospital's credentials, issued to the hospital.
• On offboarding, credentials are deleted with the rest of the tenant's data and the deletion is covered by the Certificate of Deletion.

The full treatment is the BYOK/BYOC Credential Handling Disclosure (DIS-GL-025).

#5.4 What Pensieve Labs can decrypt

Stated plainly, because vendors are usually vague here.

Pensieve does not implement client-side encryption under a key Pensieve Labs cannot reach in DM-1 and DM-2. Claiming otherwise would be false: a platform that must index, search, bill and report across the hospital's data must be able to process it. What Pensieve Labs offers instead is a controlled, approved, logged and time-bound access path, plus the DM-3 and DM-4 options for hospitals that require structural rather than procedural control. This is listed again in Section 17.

#5.5 Backups

Backups inherit the encryption of their source and are encrypted under the same key hierarchy. Backup storage location follows the deployment's data region. Restore testing is covered in Section 11.

#5.6 Certificate management

TLS certificates for Pensieve Labs-hosted deployments are managed automatically with renewal well ahead of expiry and monitored for expiry as a production alert. In DM-3 and DM-4 certificate issuance may be the hospital's, depending on the ingress design; the deployment record names the owner.

#5.7 The Trust Center itself

https://trust.pensievelabs.org is a separate application from the Platform. It contains Pensieve Labs's document library and deal-lifecycle records; it does not contain patient data and is not connected to any hospital's Platform instance. It runs on a different stack (see DIS-GL-009 for the sub-processors) and is held to the same transport-security standard: TLS 1.2+, HSTS, a content security policy, and /.well-known/security.txt per RFC 9116.

---

#6. Network security

#6.1 Ingress

All hospital traffic enters through an HTTPS load balancer. In front of the application there is a web application firewall with rules covering the OWASP Top 10 classes: injection, cross-site scripting, path traversal, protocol anomalies, plus rate limiting and bot controls. Requests are size-limited and timeout-bounded.

Pensieve Labs supports IP allow-listing for administrative roles where a hospital wants Platform administration restricted to its own network ranges. This is configured per hospital and is not on by default, because a hospital with clinicians on mobile networks will find it obstructive; it is offered, and the hospital chooses.

#6.2 Segmentation and egress

• Application services run without public IP addresses; the load balancer is the only public entry point.
• The database is not reachable from the public internet in any deployment model. It accepts connections only from the Platform's own service identities inside the project's network.
• Egress is restricted. Background workers make outbound connections only to destinations on an allow-list: the external systems the hospital has configured (Section 14) and Pensieve Labs's own monitoring endpoints. A compromised component cannot casually exfiltrate to an arbitrary host.
• Administrative interfaces are not exposed on the public internet.

#6.3 Denial of service

Volumetric and protocol-level attack absorption is inherited from Google Cloud's edge infrastructure. Application-layer rate limiting is applied at the load balancer per source and per authenticated principal. Pensieve Labs does not claim immunity from a determined denial-of-service attack; it claims a mitigation posture and an incident path (Section 10).

#6.4 Per-model network position

In DM-4 the network security of the deployment is the hospital's network security. Pensieve Labs supplies a recommended segmentation design in the On-Premise Supplement and will review the hospital's implementation on request, but it does not operate it and does not warrant it.

#6.5 Customer-initiated security testing

Hospitals may test their own deployment. The rules are published in the Customer Penetration Testing Policy and are summarised here because reviewers look for them:

Permitted, with at least seven days' written notice to info@pensievelabs.org, against the hospital's own tenant only: port scanning and banner grabbing; automated vulnerability scanners and manual tooling against the hospital's own deployment infrastructure and web application; testing detection and alerting within the hospital's own tenant; and attempts to escape process sandboxing or containerisation.

Prohibited: denial-of-service testing of any kind; targeting resources or data belonging to any other tenant; social engineering or phishing of Pensieve Labs personnel or hospital staff; attacks against infrastructure that is not part of the hospital's tenant; and moving beyond proof of concept for code execution, container escape or lateral movement.

Pensieve Labs will respond to Medium severity findings and above. Low and Informational findings are recorded but not individually responded to.

---

#7. Application security and the secure SDLC

The Secure Software Development Lifecycle Disclosure (DIS-GL-018) is the source of truth. This is the summary.

#7.1 How code reaches production

flowchart LR
  A["Design<br/>threat consideration"] --> B["Branch<br/>protected main"]
  B --> C["Peer review<br/>mandatory, second person"]
  C --> D["Automated checks<br/>SAST, dependency scan, secret scan, tests"]
  D --> E["Build<br/>immutable, versioned artefact"]
  E --> F["Staging<br/>no production data"]
  F --> G["Change record<br/>approval, rollback plan"]
  G --> H["Production<br/>progressive rollout"]
  H --> I["Monitor<br/>error rate, latency, alerts"]
  I -->|regression| J["Roll back<br/>to previous artefact"]

Text description. A change is designed, developed on a branch off a protected main branch, reviewed by a second person, and put through automated static analysis, dependency scanning, secret scanning and tests. A passing change produces an immutable versioned build artefact, which is deployed to staging (which never holds production data), then released to production under a change record with an approval and a rollback plan, using a progressive rollout. Production is monitored, and a regression triggers a roll back to the previous artefact.

#7.2 Controls in the pipeline

#7.3 Application-layer controls that matter in a hospital

• Injection. Database access uses parameterised statements. Dynamic SQL construction from user input is prohibited by review and detected by static analysis.
• Cross-site scripting. Output is contextually escaped by the rendering framework; a strict content security policy is applied.
• Cross-site request forgery. State-changing requests require an anti-forgery token; cookies are Secure, HttpOnly and SameSite-scoped.
• Broken object-level authorisation: the flaw class that actually causes healthcare data breaches. Every record fetch is authorised server-side against the authenticated principal's tenant and role. In DM-2 the database's row-level security is the backstop (Section 3.4) precisely because this class of flaw is the one an application layer is most likely to get wrong.
• Mass assignment and over-posting. Request payloads are validated against explicit schemas; fields not in the schema are rejected rather than silently bound.
• File upload. Uploaded documents and images are content-type validated, size-limited, stored in object storage rather than on an application filesystem, and served with headers that prevent them being interpreted as active content.
• Rate limiting is applied to authentication, export and search endpoints.

#7.4 Audit trail as an application feature

Clinical and financial records in Pensieve are append-only at the audit layer. An amendment creates a new version and preserves the prior one with the amending user, timestamp and reason. A medication order is not edited in place; it is discontinued and re-issued. This is a NABH information management expectation (a system to keep track of changes made to records) and it is also the property that makes a medico-legal record defensible three years later. Section 9 covers retention.

#7.5 The AI boundary

Pensieve uses machine learning for non-clinical functions only. It does not diagnose, triage, score clinical risk, calculate patient-specific doses or recommend treatment. Where a feature uses a model, the AI/ML Feature Disclosure (DIS-GL-027) names the function, the data used, the human review step and the hospital's opt-out. Hospital data is not used to train models offered to other hospitals. The regulatory boundary is set out in DIS-GL-028.

---

#8. Vulnerability management

The Vulnerability Management & Patching Disclosure (DIS-GL-017) carries the full policy.

#8.1 How vulnerabilities are found

#8.2 Remediation targets

Severity is assigned using CVSS v3.1 base score adjusted for exploitability in Pensieve's actual configuration: a critical CVE in a code path that is not reachable is triaged accordingly, and the reasoning is recorded rather than assumed.

"Mitigate" includes a virtual patch at the WAF, disabling a feature, or restricting a network path, where a code fix will take longer. A mitigation is recorded with the residual risk and a date for the permanent fix. Missed targets are recorded rather than reclassified.

#8.3 Patching the platform

• DM-1, DM-2: Pensieve Labs patches everything: application, container base images, managed service versions, inside the windows above. The hospital has no patching obligation.
• DM-3: Pensieve Labs patches the Platform. The hospital's cloud organisation policy, quotas and maintenance windows can delay a patch; where that happens Pensieve Labs records the delay and notifies the hospital.
• DM-4: Pensieve Labs ships the patch; the hospital applies it, or authorises Pensieve Labs to apply it in a scheduled window. A DM-4 hospital that defers patches carries the residual risk, and Pensieve Labs records the notification and the deferral. This is the single largest security difference between DM-4 and the other three models and it is the reason DM-4 requires a contractual patching window.

#8.4 Vulnerability disclosure

Pensieve Labs publishes a Vulnerability Disclosure Policy and a /.well-known/security.txt per RFC 9116. Commitments: acknowledge a report within 3 business days, complete triage within 10 business days, and give the reporter a status update at least every 30 days until closure. Pensieve Labs will not pursue legal action against a researcher acting in good faith within the published scope. Reports go to info@pensievelabs.org.

Pensieve Labs does not currently operate a paid bug bounty programme. See Section 17.

#8.5 Software bill of materials

A software bill of materials is produced per release in CycloneDX and SPDX formats and published alongside the Third-Party & Open Source Dependency Disclosure (DIS-GL-019). Its purpose is operational, not decorative: when the next widely exploited library vulnerability is announced, a hospital can determine in minutes whether Pensieve is affected, and so can Pensieve Labs.

---

#9. Logging, monitoring and detection

#9.1 What is logged

#9.2 Retention, location and immutability

≥ 365 days, inside India for Indian deployments, immutable.

The number is the highest of three overlapping requirements, so that one configuration satisfies all of them:

Configuration specifics that a reviewer should verify, because the cloud defaults do not satisfy the requirement out of the box:

• Log buckets are created as regional in the deployment's India region. Global log buckets may place data in any Google data centre and would therefore fail CERT-In Direction (iv).
• The default 30-day retention on the standard log bucket is replaced, not supplemented.
• Retention lock is applied where available, so logs cannot be shortened or deleted inside the retention period, including by Pensieve Labs.
• Cloud Audit Logs, including Data Access logs, are routed to the same bucket.
• Application-level record-access logs are routed to the same bucket, so the clinical trail and the infrastructure trail have the same retention and the same immutability.

The Log Retention & Localisation Disclosure (DIS-GL-034) carries the configuration in full, and the Audit Logging & Traceability Disclosure (DIS-GL-013) covers what the hospital can query itself.

Per-model position: in DM-3 the log bucket is in the hospital's project and the hospital controls retention; Pensieve Labs configures the above and tells the hospital if the hospital changes it. In DM-4 log retention is entirely the hospital's responsibility; Pensieve Labs configures the application to emit the logs and specifies the required retention in the On-Premise Supplement, but cannot enforce it on hardware it does not control.

#9.3 What is deliberately not logged

Credentials, secrets, API keys, session tokens, full payment card numbers and passwords are never written to any log. Redaction happens at the logging boundary. Where a diagnostic genuinely requires a payload, the payload is redacted before it is written, not after.

#9.4 Monitoring and alerting

Production is monitored continuously for availability, error rate, latency, saturation, job failure, certificate expiry, backup success and integration failure. Alerts route to an on-call engineer. The severity model and response times are in SLA-GL-001.

Security-relevant detections include: repeated authentication failure and credential stuffing patterns; anomalous administrative activity; access outside a granted window; unusual bulk record access or export volume; unexpected egress; and cloud configuration drift from the infrastructure-as-code baseline.

Honest statement: Pensieve Labs operates monitoring and alerting with an on-call rotation. It does not operate a 24×7 staffed security operations centre, and it does not describe its alerting as one. See Section 17.

---

#10. Incident response

The Incident Response & Breach Notification Commitment (DIS-GL-016) is the binding statement; this is the summary and it does not vary from it.

#10.1 The three clocks

An incident affecting an Indian hospital starts three clocks that run in parallel. Pensieve Labs's commitments are designed so the hospital can meet the ones that bind it.

flowchart LR
  D["T0<br/>Pensieve Labs becomes aware"] --> P["≤4 hours<br/>Pensieve Labs notifies the hospital<br/>with reportable content"]
  P --> C["≤6 hours from the hospital<br/>noticing the incident<br/>Hospital reports to CERT-In"]
  P --> B["Without delay, then 72 hours<br/>Hospital reports to the<br/>Data Protection Board"]
  P --> R["Without delay<br/>Hospital notifies affected<br/>Data Principals"]

Why the 4-hour commitment is the number that matters. CERT-In's window is six hours from the moment the hospital notices. If a vendor takes a day to tell the hospital, the hospital cannot comply. A four-hour commitment leaves the hospital two hours to act, and it is checkable after the fact against the incident record. Pensieve Labs states it contractually rather than aspirationally.

#10.2 What the notification contains

Enough for the hospital to file its own report without a second round trip: what happened; when it was detected and when it is believed to have started; which systems and which categories of data are affected; the number of affected records or a bounded estimate; whether the incident is contained; what Pensieve Labs has done; what the hospital should do; and a named contact. Where a fact is not yet known, the notification says so rather than delaying until everything is known.

#10.3 The response process

Hospitals receive the post-incident review for incidents affecting their data.

#10.4 Per-model responsibilities

In DM-4 Pensieve Labs will support an investigation and will provide application-level analysis, but it cannot detect an incident on hardware and a network it cannot see. A DM-4 hospital needs its own detection capability, and this document says so before the contract is signed rather than after the incident.

#10.5 Rehearsal

Pensieve Labs runs an incident-response tabletop exercise on a scheduled cadence and publishes a two-page summary: the date, the scenario, participants by role, the decisions taken, the clock performance against each statutory window, and the remediation actions with owners. The current status of this programme, including whether an exercise has been run yet, is in WPR-GL-005.

---

#11. Business continuity and disaster recovery

The Backup, Retention & Recovery Disclosure (DIS-GL-014) and the BC/DR Statement (DIS-GL-015) are the sources of truth. This is the summary a reviewer needs.

#11.1 Backup design

#11.2 RTO and RPO by deployment model

Pensieve Labs publishes targets only where it controls the infrastructure. Contractual values for a specific deal are Deal RTO hours and Deal RPO minutes on the Order Form.

This table is the honest version. A vendor that offers the same RTO for on-premise hardware it has never seen as for its own cloud is either not thinking or not telling the truth.

#11.3 Testing

A restore drill is worth more than a continuity policy, so Pensieve Labs runs drills and publishes the measurements: the date, the tenant restored, the source backup, the measured RTO against the commitment, the measured RPO against the commitment, and any defects found and fixed. The cadence is quarterly. The date of the most recent drill and its results are published on the Trust Center; if that date is stale, it is stale in public, which is the point.

DM-4 drills are run jointly with the hospital, because the hospital holds the media.

#11.4 Continuity of the vendor, not just the service

Two questions a hospital's advocate will ask, answered in advance:

• "What if Edsol Edtech Pvt. Ltd. stops trading?" Source code escrow is available, with a master deposit and beneficiary accession by joinder rather than a fresh tripartite negotiation per deal. The Escrow Policy & Beneficiary Accession Note states the agent, the deposit scope, the release conditions and the date of the last verification.
• "What if we simply want to leave?" The Exit & Data Portability Commitment (WPR-GL-400) and the Data Deletion & Return Disclosure (DIS-GL-023) state the export formats, the timeline, the cost and the verification, in advance and in public.

---

#12. Data protection and privacy

The Data Protection & Privacy Whitepaper (WPR-GL-003) and the Data Processing Agreement (DPA-GL-001) are the sources of truth. This section states the security-relevant parts and does not restate the DPA.

#12.1 Roles

In all four deployment models: the hospital is the Data Fiduciary. Edsol Edtech Pvt. Ltd. is the Data Processor. In GDPR jurisdictions the equivalent roles are controller and processor. Pensieve Labs processes personal data only on the hospital's documented instructions, which are the Platform's configured functions plus anything the hospital instructs in writing.

Pensieve Labs does not determine the purposes of processing, does not use hospital data for its own purposes, does not use it to train models offered to others, and does not disclose it to any third party except the sub-processors listed in DIS-GL-009 or where compelled by law, in which case, unless legally prohibited, Pensieve Labs notifies the hospital first so the hospital can seek relief.

#12.2 Data residency

A note on honesty here. Pensieve Labs does not have infrastructure in every market it can sell in. Where a market requires in-country hosting that Pensieve Labs cannot yet provide, DIS-GL-008 says so in that market's section rather than describing residency in general terms. Do not infer residency for a market from this whitepaper; read the statement for the market.

In DM-3 residency is determined by the region the hospital selects for its own project. In DM-4 the data is wherever the hospital's server room is, which is the strongest residency answer available and is one of the two legitimate reasons to choose DM-4.

#12.3 Retention and deletion

Pensieve implements a configurable retention schedule per record class, because Indian retention obligations are not uniform: in-patient medical records carry a three-year minimum under the professional conduct regulations, DPDP processing logs carry a one-year minimum, and a hospital's own policy or its accreditation body may require longer. The Data Classification & Handling Disclosure (DIS-GL-022) and the retention matrix set out the classes.

On termination, DIS-GL-023 governs: the hospital receives its data in documented formats, then Pensieve Labs deletes it from live systems and from backups on the stated schedule, and issues a Certificate of Deletion. Backup deletion is not instantaneous (it follows the backup rotation) and the disclosure states the actual period rather than implying immediacy.

#12.4 Data minimisation in support

Pensieve Labs's support process is designed to avoid moving patient data. Support staff work from identifiers and error references, not from record contents. Where a defect can only be understood by looking at a record, the access is made under Section 4.5 in the production environment, and no copy is taken. Screenshots containing patient data are not accepted through the support channel and are deleted if received.

#12.5 The hospital's own obligations under DPDP

Pensieve Labs builds the mechanisms; the hospital operates them. Consent notices, the grievance officer, responses to Data Principal rights requests, and the decision about what data to collect at all are the hospital's. Pensieve provides the consent notice engine, the rights-request workflow and the evidence trail; WPR-GL-003 describes the split. Section 18 restates the security-relevant parts.

---

#13. Personnel security

The Personnel Security & Background Verification Disclosure (DIS-GL-020) is the source of truth.

Scale statement. Edsol Edtech Pvt. Ltd. is a small company. That has two consequences worth stating rather than hiding. First, the number of people who can reach production is small, which is a genuine security advantage: the population to control is small enough to enumerate. Second, full separation of duties between development and operations is not achievable at this size, and Pensieve Labs does not claim it. The compensating controls are mandatory peer review (Section 7.2), the second-approver requirement on production access (Section 4.5), and immutable audit logs that the accessing engineer cannot alter (Section 9.2). This appears again in Section 17.

---

#14. Sub-processors and supply-chain security

#14.1 Sub-processors

The Subprocessor Register (DIS-GL-009) is public, versioned and dated. For each entry it names the sub-processor, its legal entity, the service it provides, the categories of data it processes, the processing location, and the date it was added. It is deliberately falsifiable: a hospital can check that the named entities exist and do what is claimed.

Change notification. Pensieve Labs notifies hospitals in advance of adding a sub-processor that will process customer personal data, within the notice period stated in DPA-GL-001, and the hospital may object. The Sub-Processor Change Log (DIS-GL-010) is the running record.

Per model: in DM-3 and DM-4 the hosting sub-processor disappears from the chain entirely, because the hospital owns the infrastructure. The register marks which entries apply to which models.

#14.2 Supply chain in the build

#14.3 Third-party assessment

Pensieve Labs relies on the major cloud provider's own published independent audit reports for the infrastructure layer and reviews them annually. It does not re-audit a hyperscale cloud provider, and it does not present the provider's certifications as its own, a distinction Section 16.4 makes precisely, because it is the most commonly misrepresented point in vendor security documentation.

---

#15. Physical and environmental security

Almost all of this is inherited, and Pensieve Labs says so rather than implying it operates data centres.

#15.1 Hosted models: DM-1, DM-2, DM-3

The Platform runs in Google Cloud data centres. Physical access control, perimeter security, visitor management, environmental controls, power redundancy, fire suppression and secure media destruction at those facilities are operated by Google, not by Edsol Edtech Pvt. Ltd.. Pensieve Labs personnel have no physical access to any data centre holding hospital data, and cannot obtain it.

Pensieve Labs's obligations at this layer are therefore: to select a provider with independently audited physical controls; to review that provider's audit reports annually; and to state accurately that these controls are inherited. DIS-GL-021 records the review.

#15.2 DM-4: on-premise

Physical security is entirely the hospital's. The server room, its lock, its access list, its cameras, its air conditioning, its UPS, its fire suppression and the custody of its backup media are the hospital's responsibility. Pensieve Labs specifies minimum requirements in the On-Premise Supplement: controlled access to the room, an access log, environmental control adequate to the hardware specification, power protection, and off-site backup custody, and will review the hospital's arrangements on request. It does not operate them and does not warrant them.

This is not a minor caveat. In a DM-4 deployment, an unlocked server-room door defeats every cryptographic control in Section 5.

#15.3 Pensieve Labs's own premises

Pensieve Labs does not hold hospital patient data on premises. Work is done against cloud environments from managed devices (Section 13). Paper records containing customer confidential information are not held routinely; where they exist (executed contracts, for example), they are held securely and are covered by the retention schedule.

---

#16. Assurance and evidence

This is the section a sceptical reviewer should read first. It is written to be checked.

#16.1 The position in one sentence

Edsol Edtech Pvt. Ltd. holds no security certifications and no independent security attestations today. Everything in Section 2 to Section 15 of this document is Pensieve Labs's own description of its own controls. That description is detailed and specific precisely so that it can be tested, but it has not been independently audited, and this document does not pretend otherwise.

#16.2 What exists today

The live status of every item, including anything obtained since this document was last modified, is maintained in the Trust & Assurance Overview (WPR-GL-005), which is the register. Where WPR-GL-005 and this whitepaper differ, WPR-GL-005 is correct, because it is updated more often.

#16.3 What does not exist

#16.4 The statement Pensieve Labs is careful about

A hospital reviewer will see "Google Cloud" in this document and may reasonably ask what that inherits. The precise position:

Pensieve is deployed on Google Cloud Platform. Google Cloud services in the India regions are empanelled by the Ministry of Electronics and Information Technology following an independent audit by STQC, and Google Cloud holds its own independent certifications and audit reports for its infrastructure. Edsol Edtech Pvt. Ltd. is not itself empanelled and is not itself certified. Empanelment and certification at the infrastructure layer say nothing about the security of the application layer, which is Pensieve Labs's responsibility.

Any vendor, including Pensieve Labs, who compresses that into "we are MeitY empanelled" or "we are ISO 27001 certified through our cloud provider" is misrepresenting. If you are evaluating other vendors alongside Pensieve Labs, this is a useful question to put to all of them.

#16.5 The ABDM and NHCX position

Pensieve Labs does not hold ABDM milestone certification and does not onboard to NHCX in its own name. The hospital is the registered health facility, holds its own facility registry identifier, and holds its own NHCX participant credentials; Pensieve integrates using those credentials and acts as the hospital, on the hospital's authority.

This is a deliberate architectural boundary and it is stated affirmatively. It is also the single most likely source of a go-live surprise in this business, so it is documented in full, with a responsibility matrix naming who does what, in the Integration Boundary Statement (DIS-GL-024). A hospital in a state that mandates an ABDM-certified system, or a hospital pursuing an accreditation criterion that requires one, must read DIS-GL-024 Section 3 before signing.

#16.6 What is planned, with dates and owners

Pensieve Labs publishes target dates rather than intentions. A target that is missed is re-dated in public with a reason, not quietly removed.

WPR-GL-005 carries the live version of this table with current status against each date.

#16.7 Why this should increase rather than reduce confidence

Three arguments, offered without embellishment.

1. A certificate is a statement about a management system on a date. This document is a statement about controls you can test today. A hospital can verify the transport security itself in thirty seconds, can send a vulnerability report and time the response, can ask for a data export before signature, can ask for the access record for its own tenant, and can check that every named sub-processor is a real company doing what is claimed. None of those tests requires trusting Pensieve Labs.
2. Pensieve Labs starts clean. The ISO/IEC 27001:2013 edition was withdrawn on 31 October 2025 and non-transitioned certificates are dead. A vendor showing a 2013-edition certificate today is showing an expired one. Pensieve Labs holds nothing and says so; when it certifies, it will certify against the current edition with no transition debt. It is worth asking every vendor in your evaluation for the edition year on their certificate.
3. Candour is the only durable position for an unknown vendor. Pensieve Labs is asking a hospital to run its entire operation on software from a company it has not heard of. One discovered overstatement would end that conversation permanently. The incentive to be accurate here is stronger than the incentive to look impressive, and this document is written accordingly.

---

#17. Limitations: what is not yet implemented

Everything below is true as at 31 July 2026. This section is maintained, not written once.

17.1 No independent audit of these controls. No certification body, licensed practitioner or independent assessor has examined the controls described in Section 2 to Section 15. Section 16.6 gives the plan.

17.2 No 24×7 staffed security operations centre. Monitoring and alerting run continuously and route to an on-call engineer, but there is no staffed watch floor. Detection of a slow, quiet intrusion outside business hours depends on automated alerting rather than on human observation. Pensieve Labs describes this as monitoring with on-call response, and does not describe it as a SOC.

17.3 Limited separation of duties. At Edsol Edtech Pvt. Ltd.'s current size, the same small group both 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. Pensieve Labs does not claim a segregated operations function.

17.4 Pensieve Labs can technically decrypt hospital data in DM-1 and DM-2. There is no customer-held-key architecture in the Pensieve Labs-hosted models that would make this impossible; the Platform must process the data to do its job. The control is procedural and audited (Section 4.5), not cryptographic. Hospitals that require a structural control should choose DM-3 or DM-4.

17.5 DM-2 isolation is logical. See Section 3.4. A hospital that will not accept logical isolation should choose DM-1, and Pensieve Labs will not argue.

17.6 Legacy device integrations may not support modern transport security. Some laboratory analysers and older imaging nodes speak protocols that predate TLS. Where such a device is in scope, the connection is confined to the hospital's own network segment and the limitation is recorded in the deployment record. It is not silently accepted and it is not described as encrypted.

17.7 No paid bug bounty programme. Vulnerability disclosure is handled under the VDP with the response commitments in Section 8.4. A funded bounty programme attracts more scrutiny than an unfunded policy, and Pensieve Labs does not currently operate one.

17.8 No formal, tested disaster-recovery site failover for DM-4. Pensieve Labs cannot test failover for infrastructure it does not control. DM-4 continuity depends on the hospital's own arrangements (Section 11.2).

17.9 Availability figures are not published as a general claim. SLA-GL-001 carries availability commitments with their measurement method, exclusions and the deployment models they apply to. This whitepaper deliberately does not quote an uptime percentage, because a percentage without a measurement method is not a commitment.

17.10 No formal internal audit programme yet. There is no independent internal audit function reviewing the controls in this document against a schedule. This is a normal consequence of company size and it is a gap; the ISMS work in Section 16.6 introduces it.

---

#18. Customer responsibilities

Security is shared. The table below is the summary; the binding allocation is in the Security Addendum and, for data protection, in DPA-GL-001.

#18.1 Responsibility matrix

#18.2 The five that actually decide the outcome

Everything above matters. These five are the ones that determine whether a Pensieve deployment is secure in practice, and all five are the hospital's.

1. Individual logins. A shared ward login destroys attribution, and attribution is the foundation of every clinical, medico-legal and audit control in this document. Pensieve Labs will make individual login as fast as it can be made; the hospital must require it.
2. Prompt de-provisioning. The account of a nurse who resigned four months ago is the most common real attack path in a hospital. Removal should happen on the last working day, and the hospital should reconcile Platform accounts against its HR register at least quarterly.
3. Role hygiene. Granting everyone an administrative role because it is easier on day one is the second most common. Roles should be reviewed on a schedule and the review recorded.
4. Endpoint control. Pensieve cannot defend a reception workstation that is shared, unpatched and running unrelated software downloaded from the internet.
5. Owning the external credentials. ABDM, NHCX, payment, messaging and insurer credentials belong to the hospital, must be issued to the hospital, and must be rotated and revoked by the hospital. DIS-GL-024 and DIS-GL-025 set out exactly what the hospital must supply and when.

#18.3 What the hospital should ask for before signing

A short list, offered because a hospital with no security staff often does not know what to ask:

• The deployment model recorded on the Order Form, and the isolation properties that go with it (Section 3.2).
• The named data region (Deal data region) and the residency statement for the hospital's market.
• The RTO and RPO that will appear on the Order Form, and the date of the most recent restore drill.
• A demonstration of data export.
• The Subprocessor Register, and confirmation of which entries apply to the chosen model.
• The Integration Boundary Statement (DIS-GL-024), read in full, before any ABDM or NHCX commitment is made to a state authority, an insurer or an accreditation body.
• This document's Section 16 and Section 17.

---

#19. Contacting the security team

Pensieve Labs acknowledges vulnerability reports within 3 business days and completes triage within 10 business days (Section 8.4). Security questionnaires are answered from the published evidence base; where a question is not covered by a published artefact, the answer is written and then published, so the next hospital does not have to ask.

---

#20. Related documents

---

#21. Change history

---