POL-GL-059PolicyGL1234Public31 July 2026
Vulnerability disclosure
Report a vulnerability
Edsol Edtech Pvt. Ltd. operates software that hospitals run their entire operation on. A defect found by a researcher and reported to us is worth more than a defect found by an attacker. This page tells you how to report one, what we will do about it, how quickly, and what we commit not to do to you. It is published because a vendor that makes reporting difficult gets fewer reports, not fewer vulnerabilities.
Safe harbour: read this first
If you make a good-faith effort to comply with this policy while researching and reporting a vulnerability, Edsol Edtech Pvt. Ltd. will not initiate or support any civil claim or criminal complaint against you in connection with your research; will not report you to any authority, and where a third party or an authority raises the matter with us, will state that your activity was authorised under this policy; will not seek to have your account, your hosting, your domain or your employment interfered with; will treat your report as a contribution rather than an attack; and will work with you on disclosure timing rather than trying to suppress publication.
The honest limits of that.We can speak only for ourselves. We cannot grant immunity from criminal law, and we cannot bind a hospital customer, a cloud provider, another vendor or a public authority. In India, unauthorised access to a computer resource may engage sections 43 and 66 of the Information Technology Act, 2000; this policy is our authorisation for the activity it describes, which is the element those provisions turn on, but the assessment is ultimately a court’s, not ours. Stay inside the rules below and the question does not arise. If your activity goes outside them (in particular if you access, copy or retain patient data), the safe harbour does not apply, and we may be legally obliged to report it.
If you are unsure whether something is in scope, ask first. Write to info@pensievelabs.org and describe what you propose to do. We answer scope questions within two business days, and asking is never held against you.
Scope
What is in, and what is out
In scope
- pensievelabs.org
- The public website and its subdomains
- trust.pensievelabs.org
- This Trust Center
- The Pensieve platform
- Only a tenant you are authorised to test: see the rules below
- Published APIs
- Using credentials issued to you
- Published clients
- Including their update mechanism
- Public repositories, container images and published artefacts
- Including a secret leaked in one
The platform holds patient records. Do not test a production tenant. Ask for a test environment, or, if you are a customer, test your own tenant with prior written consent under the data processing agreement.
Out of scope
- A third-party service Pensieve consumes. Report it to that provider, and tell us, and we will chase it too. The providers are listed on the sub-processor register.
- A hospital customer's own network, devices, staff or premises.
- Any tenant you are not authorised to test.
- Physical security of any site.
- Social engineering of Pensieve personnel, customers or suppliers.
- Denial-of-service and resource-exhaustion testing.
- Automated scanner output submitted without a demonstrated impact.
We also accept, and usually rate low: missing security headers with no demonstrated impact, cookie flags on a non-sensitive cookie, self-XSS, a rate-limit observation with no exploited consequence, version disclosure, and clickjacking on a page with no state-changing action. Send them anyway. We would rather triage a low finding than miss a high one, but expect the severity to reflect the impact.
Rules of engagement
Seven rules, and the safe harbour depends on them
- 01Access only the minimum necessary to demonstrate the issue. Stop at proof of concept.
- 02Do not access, view, copy, download, retain, modify or delete personal data, and never patient data. If you encounter it, stop, do not save it, tell us in general terms what you saw, and delete anything you inadvertently retained.
- 03Do not degrade availability. No denial of service, no load testing, no scanning at a rate that affects service.
- 04No social engineering, phishing, physical intrusion or theft.
- 05Do not pivot from a finding into further systems, and do not install a backdoor, a persistence mechanism or a scheduled task.
- 06Do not modify or destroy data. Use your own accounts and test data, not another person's credentials, even if you find them.
- 07Do not demand payment and do not condition disclosure on it. A report that arrives with a payment demand and a deadline is handled as an extortion attempt, not as a disclosure, and the safe harbour does not apply to it.
How to report
Write to info@pensievelabs.org
What to include
- The affected asset, URL or endpoint, and the environment.
- The vulnerability class, and a CVE or CWE reference if you have one.
- Reproduction steps precise enough for us to follow without guessing.
- Evidence: a request and response, a short recording, or a minimal proof of concept.
- Your assessment of impact, and what an attacker would gain.
- Whether you accessed any data, and if so exactly what.
- How you would like to be credited, or that you would prefer not to be.
Practicalities
- One address. info@pensievelabs.org. It is monitored, and it is the address published in /.well-known/security.txt under RFC 9116.
- Encryption. A published PGP key is not yet available at this address. If your report includes a working exploit or any data you happened to see, say so in a first message without the detail, and we will agree an encrypted channel before you send anything.
- Languages. English or Hindi.
- Anonymity. You may report anonymously and we will still fix it. We cannot credit you, answer you, or confirm the safe harbour applies to a person we cannot identify.
- Do not open a support ticket, post to a public forum, message an employee on social media, or use a website contact form. Those channels are not monitored for this and the report will be slower to reach the right person.
The clock
What we commit to, and by when
Response targets
Acknowledge receipt, by a human, not an autoresponder1 business day
Initial triage and severity assessment, communicated to you3 business days
Confirm or dispute the finding, with reasoning5 business days
Status update thereafterEvery 7 days until closure, without you having to ask
Notify you when the fix is deployedSame day as deployment
Remediation targets, from confirmation
CriticalMitigate within 24 hours; fix within 7 days
Remote code execution, authentication bypass, cross-tenant data access, mass data exposure
High30 days
Privilege escalation, access-control failure within a tenant, stored credential exposure
Medium90 days
Exploitable with meaningful preconditions, limited impact
LowNext scheduled release
Minimal impact, or requiring improbable conditions
- If we are going to miss a target, we tell you before it passes, say why, and give a revised date. We do not go quiet.
- If we dispute a finding, we explain the reasoning and the evidence. If you disagree, a disputed finding is reviewed by a second person.
- Every report is recorded in the vulnerability register: accepted, disputed or duplicate.
- Where a confirmed vulnerability materially affects a hospital’s tenant or data, affected customers are notified inside four hours of our awareness, and we do not wait for public disclosure to do it.
- Where a finding indicates an incident reportable under the CERT-In Directions of 2022, Pensieve reports it within 6 hours of noticing it. That obligation runs independently of this policy and is not deferred by a disclosure timeline agreed with a researcher.
Coordinated disclosure
Ninety days, and we will not ask for silence
| Term | Position |
|---|---|
| Default embargo | 90 days from our acknowledgement, or the date the fix is deployed, whichever is earlier. After that you may publish. |
| Extension | We may ask for more time where a fix requires a customer-side upgrade (the usual position under DM-4), and we will say why and give a date. We will not ask for an open-ended extension. |
| Early publication | If the issue is being actively exploited we may ask you to publish sooner, or publish ourselves, so hospitals can protect themselves. |
| What to leave out | Customer names, tenant identifiers, any data you saw, and a working exploit against an unpatched deployment. |
| No NDA, no suit | We will not ask you to sign a non-disclosure agreement as a condition of fixing the issue, and we will not sue you for publishing in accordance with these terms. |
Payment
There is no bug bounty. Saying so is better than implying one.
The plain position
Edsol Edtech Pvt. Ltd. does not currently operate a paid bug bounty programme. There is no published schedule, no platform, no points and no leaderboard. If that changes, this section changes and the change is dated.
For a critical finding with a demonstrated cross-tenant or mass-data impact, Pensieve may make a discretionary payment. There is no entitlement, no published amount and no negotiation. Do not rely on it, and do not report in expectation of it.
What is offered instead
- Public credit on the security acknowledgements page, at the level of detail you are comfortable with, unless you ask us not to. That page is published with the first acknowledged report.
- A written confirmation of the finding, its severity and the date it was fixed, for your own portfolio or a CVE submission.
- Our cooperation with a CVE request, including engaging a CNA where appropriate.
- Direct access to the engineer who fixed it, if you want to discuss the fix.
- The first complete report of an issue is credited. A duplicate is acknowledged as such, with the date of the original.
Applicability
Which deployment model you found it in changes what happens next
- DM-1, DM-2
- Pensieve operates the infrastructure. A report reaches the people who can fix it and deploy the fix.
- DM-3
- Pensieve maintains the software; the hospital owns the cloud project. A finding in the platform is Pensieve's. A finding in the hospital's own cloud configuration is the hospital's, and Pensieve will tell the hospital.
- DM-4
- The same split, and deployment of a fix depends on the hospital's own patching window. The remediation targets below are targets for producing a fix, not for installing it on infrastructure Pensieve does not control.
Sources
The documents behind this page
DIS-GL-017DisclosureGL1234NDACritical path31 July 2026
Accept the mutual NDA to request access to this tier. Your acceptance is recorded at once and protects both sides; an administrator then grants access, with a target of four business hours.Accept the mutual NDAWait: target 4 business hours
POL-GL-121PolicyGL1234NDA31 July 2026
Accept the mutual NDA to request access to this tier. Your acceptance is recorded at once and protects both sides; an administrator then grants access, with a target of four business hours.Accept the mutual NDAWait: target 4 business hours
DIS-GL-016DisclosureGL1234PublicCritical path31 July 2026
This page is a rendering of POL-GL-059. Where the two differ, the policy governs. Machine-readable contact details are at /.well-known/security.txt, and every advisory Pensieve publishes appears in the updates feed.