Search all 478 artefacts by title, document ID or content.
Printed on the standard letterhead. Page furniture, margins and repeating table headers come from the same stylesheet the PDF service uses.
Pensieve Labs
The operating system for hospitals
DIS-GL-011
v1.0.0 | 31 July 2026
DM-1 Dedicated |
DM-2 Shared |
DM-3 Customer Cloud |
DM-4 On-Premise |
|---|---|---|---|
Dedicated key ring, Pensieve Labs-held |
Per-tenant data keys, Pensieve Labs-held key ring |
Keys in the hospital's own key service. Hospital-held | Keys in the hospital's own key store. Hospital-held |
To state exactly what is encrypted, with what, and the question that actually decides a security
review, who holds the keys and what Pensieve Labs can therefore decrypt. Vendors are usually
precise about algorithms and vague about custody. This document is the other way round.
| Question | DM-1 |
DM-2 |
DM-3 |
DM-4 |
|---|---|---|---|---|
| Is data encrypted at rest? | Yes | Yes | Yes | Yes |
| Is data encrypted in transit? | Yes | Yes | Yes | Yes |
| Who holds the key encryption key? | Edsol Edtech Pvt. Ltd. |
Edsol Edtech Pvt. Ltd. |
Hospital | Hospital |
Can Pensieve Labs technically decrypt hospital data? |
Yes, through the approved, time-bound, logged access path | Yes, same basis | Only while the hospital's grant is in place | No, except inside a session the hospital opens |
| Can the hospital cut that off unilaterally? | Contractually, on request | Contractually, on request | Yes, immediately, by revoking the grant or disabling the key | Yes, by not opening a session |
Is there a customer-held-key architecture that makes decryption impossible for Pensieve Labs? |
No | No | Effectively yes | Yes |
The honest sentence. Pensieve must index, search, bill and report across the hospital's
data, so in the Pensieve Labs-hosted models it must be able to process that data in plaintext at
runtime. Claiming a zero-knowledge architecture in DM-1 or DM-2 would be false. What
Pensieve Labs offers instead is a controlled, approved, expiring and immutably logged access path
(Section 6), plus DM-3 and DM-4 for hospitals that require a structural rather than a procedural control.
Layer 1: platform default. Data stored in the cloud provider's services is encrypted at the storage layer with AES-256 using an envelope scheme: data encryption keys protect the data and are themselves wrapped by key encryption keys, with keys generated using the provider'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. Above the default, Pensieve Labs configures CMEK in
the cloud key management service, so that the key encryption key protecting a hospital's data is a key with
an identity, a rotation schedule, an access policy and its own audit trail. Cloud KMS software keys are
256-bit AES-GCM (Google Cloud: CMEK).
Layer 1 without Layer 2 is "the disk is encrypted": true, and nearly meaningless for an access-control question. Layer 2 is what makes the key a controllable object.
| Store | Contents | Encrypted at rest | Key |
|---|---|---|---|
| Relational database | Clinical records, orders, results, billing, masters, users, audit rows | AES-256, CMEK | Deployment's key |
| Object storage | Documents, scanned records, images, generated PDFs, exports | AES-256, CMEK | Deployment's key |
| Secret store | Hospital-supplied credentials for external systems | AES-256, CMEK | Deployment's key |
| Log bucket | Audit, access and application logs | AES-256, CMEK | Deployment's key |
| Backups and point-in-time recovery data | Copies of the above | AES-256: backups inherit the encryption of their source and stay in the deployment's region | Same key hierarchy |
| Container images | Application artefacts, no customer data | Provider default | Provider-managed |
No customer data is written to any unencrypted store, at any point, including temporarily. Exports are generated into encrypted object storage and delivered from there; they are not written to an application filesystem or an engineer's device.
| Model | Arrangement | Key ring owner | Rotation | Consequence of key destruction |
|---|---|---|---|---|
DM-1 |
Dedicated key ring and dedicated CMEK per hospital, covering database, object storage, secret store and logs | Edsol Edtech Pvt. Ltd. |
Automatic, on the schedule recorded in the Deployment Record | Pensieve Labs operates a key-protection policy; destruction requires two-person approval |
DM-2 |
Per-tenant data encryption keys wrapped by a key encryption key in a Pensieve Labs-managed key ring. Storage-level access to another tenant's ciphertext does not yield plaintext |
Edsol Edtech Pvt. Ltd. |
Automatic, same basis | Same |
DM-3 |
CMEK in the hospital's own key management service, in the hospital's project | Hospital | Hospital-controlled | If the hospital disables or destroys a key, Pensieve Labs cannot decrypt, restore or recover the data. This is correct behaviour for a key the hospital controls |
DM-4 |
Keys held by the hospital in the on-premise key store | Hospital | Hospital-controlled | Same, and irreversible |
The DM-3/DM-4 warning is stated in advance, not discovered. Key destruction is an irreversible act
and the hospital should protect it with its own two-person approval process. Pensieve Labs will
configure alerting on key state changes if the hospital grants the permission to do so.
| Path | Position |
|---|---|
| Hospital user → Platform | TLS 1.2 or TLS 1.3 required. Insecure cipher suites disabled at the load balancer. Plaintext HTTP served only as a permanent redirect to HTTPS |
| HTTP Strict Transport Security | Set with a long max-age and includeSubDomains |
| Between Platform components | Encrypted in transit inside the cloud project; service-to-service calls are authenticated with audience-scoped identity tokens |
| Platform → managed data services | TLS required on the database connection; storage and key service reached over HTTPS |
| Platform → hospital's external systems | TLS. Exceptions in Section 7.2 |
| Backup transfer and restore | Within the provider's encrypted internal transport, in-region |
Administrative access by Pensieve Labs |
HTTPS to the provider's authenticated API surface, from a managed device with phishing-resistant authentication |
Certificates. For Pensieve Labs-hosted deployments, TLS certificates are managed automatically with
renewal well ahead of expiry, and expiry is a monitored 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.
A hospital can verify this in thirty seconds with any public TLS scanner against its own tenant
hostname. Pensieve Labs publishes the grade rather than describing the configuration, because a
third-party scan is evidence and a description is not (WPR-GL-005 Section 4.6).
Credentials the hospital supplies for its own external systems (ABDM and NHCX participant credentials, payment gateway keys, messaging provider tokens, insurer portal logins, e-mail credentials, analyser and PACS credentials) are held in the managed secret store, encrypted under the deployment's key, with access bound to the specific workload that needs them.
| Property | Position |
|---|---|
| Write-only from the hospital's perspective | Once supplied, a credential is never rendered back to any screen, export, log or support view |
| Never logged | Redaction happens at the logging boundary, not by developer discipline |
| Tenant-scoped | A credential supplied by one hospital cannot be used by another tenant's workload |
| Rotatable by the hospital at any time | Yes, without Pensieve Labs's involvement in the source system |
| Revocable by the hospital at the source | Yes, unilaterally: they are the hospital's credentials, issued to the hospital |
| Deleted on offboarding | Yes, with the rest of the tenant's data, covered by the Certificate of Deletion (DIS-GL-023) |
The full treatment is DIS-GL-025; the contractual position is ADD-GL-007.
| Stage | Control |
|---|---|
| Generation | In the cloud key management service. Key material is generated in the service and is not exportable |
| Storage | In the service's key ring. Pensieve Labs never handles raw key material, and there is no exported copy in a password manager, a repository or a document |
| Access | IAM-bound. Workload identities hold encrypt/decrypt permission only. No workload identity holds key management permission. Key administration is a separate, human-only, second-approver path |
| Rotation | Automatic on a configured period recorded in the Deployment Record. Rotation generates a new key version; prior versions are retained so existing ciphertext remains readable |
| Auditing | Every key use and every key administration action is written to the deployment's log bucket, which the accessing identity cannot alter or delete |
| Destruction | Scheduled destruction with a provider-enforced delay before the material is unrecoverable. Requires two-person approval in Pensieve Labs-held models; in DM-3/DM-4 it is the hospital's action alone |
| Compromise response | A key suspected of compromise is disabled, data is re-encrypted under a new key, and the event is handled as an incident under DIS-GL-016 |
Pensieve Labs can decrypt, and the path it must takeThis is the control a hospital should interrogate rather than the algorithm list.
| Step | What happens |
|---|---|
| 1 | An engineer raises an access request naming the tenant, the reason, the scope and the duration |
| 2 | A second person approves. Self-approval is not possible |
| 3 | A time-bound, least-privilege role is granted. It expires automatically; there is no manual revocation step to forget |
| 4 | Every action under that grant is written to the immutable log bucket, which the engineer cannot alter or delete |
| 5 | The grant, the reason and the approver are retained and are disclosable to the hospital on request |
Per model: in DM-3 the hospital approves through its own identity and access management and sees every
action in its own audit logs; in DM-4 no access exists unless the hospital opens a session. Full detail is
in DIS-GL-033.
7.1 No zero-knowledge architecture in DM-1 and DM-2. Pensieve Labs holds the key encryption
key and can therefore decrypt, through the path in Section 6. The control is procedural and audited, not
cryptographic. A hospital that requires a structural control should choose DM-3 or DM-4.
WPR-GL-001 Section 17.4 states the same.
7.2 Some legacy device integrations cannot offer modern transport security. Certain 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.
7.3 No field-level or application-layer encryption of clinical content. Data is encrypted at rest at
the storage layer and in transit, not encrypted per-field under a key the application cannot use. A
platform that must search and report across clinical data cannot do so over ciphertext it cannot read, and
Pensieve Labs will not describe a control it does not implement.
7.4 No hardware security module or external key manager offering today. Keys are held in the cloud
provider's key management service using software-protected keys. Hardware-backed key protection and
external key management are available in the provider's platform but are not currently part of
Pensieve Labs's standard configuration. A hospital that requires them should raise it at
qualification; it is a configuration change with a cost and a schedule impact, not a product gap.
7.5 Encryption does not defeat an authorised user. Every control in this document is irrelevant against
a member of hospital staff who is entitled to see a record and misuses it. That risk is addressed by
authorisation (DIS-GL-012), audit trail (DIS-GL-013) and the hospital's own account hygiene, not by
cryptography.
7.6 Not independently verified. No assessor has confirmed this configuration.
WPR-GL-005 states the assurance position; a hospital may test its own tenant under
WPR-GL-001 Section 6.5, and can verify transport security itself with a public scanner.
| Question | Document |
|---|---|
| Where the encrypted data sits | DIS-GL-008 Data Residency Statement |
| How hospital-supplied credentials are handled end to end | DIS-GL-025, ADD-GL-007 |
| Who can reach production and under what approval | DIS-GL-033 Remote Access & Support Model Disclosure |
| Backups, restore and the key hierarchy over backups | DIS-GL-014 |
| Deletion, and what happens to key material on exit | DIS-GL-023 |
| The architectural placement of each store and key | DIS-GL-006, DIS-GL-007 |
| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0.0 | 31 July 2026 |
Pensieve Labs Security |
First published edition. Custody stated per model before algorithms. Absence of a zero-knowledge architecture, of hardware-backed keys and of field-level encryption published as limitations. |