1.1 Our commitment. If you make a good-faith effort to comply with this Policy while researching and reporting a vulnerability, Edsol Edtech Pvt. Ltd. will:

1.1.1 not initiate or support any civil claim or criminal complaint against you in connection with your research;

1.1.2 not report you to any authority, and where a third party or an authority raises the matter with us, state that your activity was authorised under this Policy;

1.1.3 not seek to have your account, your hosting, your domain or your employment interfered with;

1.1.4 treat your report as a contribution, not as an attack; and

1.1.5 work with you on disclosure timing under 6 rather than trying to suppress publication.

1.2 The honest limits of that commitment.

1.2.1 We can speak only for ourselves. We cannot grant you immunity from criminal law, and we cannot bind a hospital customer, a cloud provider, another vendor or a public authority.

1.2.2 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 4 and the question does not arise.

1.2.3 If your activity goes outside 4, 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.

1.3 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 (2) Business Days, and asking is never held against you.

2.1 In scope.

2.2 Out of scope.

• A third-party service Pensieve consumes. Report it to that provider; tell us and we will chase it too. The providers are listed in DIS-GL-009.
• 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.

2.3 Testing the Platform. The Platform holds patient records. Do not test a production tenant. Either request a test environment at info@pensievelabs.org, or, if you are a customer, test your own tenant with prior written consent under DPA-GL-001 clause 15.6.

2.4 Findings we will accept but usually rate low. Missing security headers with no demonstrated impact; cookie flags on a non-sensitive cookie; a self-XSS; a rate-limit observation without an exploited consequence; software version disclosure; a report of an email configuration issue without a demonstrated spoofing path; and a clickjacking report 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.

3.1 Where. info@pensievelabs.org. This is the only reporting address, it is monitored, and it is published in security.txt at 8.

3.2 Encryption. Our PGP key is published at Pensieve security pgp key URL with fingerprint Pensieve security pgp fingerprint. Use it for anything that includes a working exploit or any data you happened to see.

3.3 What to include.

• The affected asset, URL or endpoint, and the environment.
• The vulnerability class and, if you have one, a CVE or CWE reference.
• Reproduction steps precise enough for us to follow without guessing.
• Evidence: a request and response, a short screen 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.

3.4 Language. English or Hindi.

3.5 Anonymity. You may report anonymously. We will still fix it. We cannot credit you or answer you, and we cannot confirm the safe harbour applies to a person we cannot identify.

3.6 Do not. Do not open a support ticket, post to a public forum, message an employee on social media, or use a website contact form for a security report. Those channels are not monitored for this and the report will be slower to reach the right person.

4.1 Access only the minimum necessary to demonstrate the issue. Stop at proof of concept.

4.2 Do not access, view, copy, download, retain, modify or delete personal data, and in particular never patient data. If you encounter it, stop immediately, do not save it, tell us what you saw in general terms, and delete anything you inadvertently retained.

4.3 Do not degrade availability. No denial of service, no load testing, no resource exhaustion, no automated scanning at a rate that affects service.

4.4 Do not use social engineering, phishing, physical intrusion or theft.

4.5 Do not pivot from a finding into further systems.

4.6 Do not install a backdoor, a persistence mechanism, a web shell or a scheduled task.

4.7 Do not modify or destroy data, and do not create test data in production beyond a single minimal, clearly-labelled artefact, which you must tell us about.

4.8 Use your own accounts and test data. Do not use another person's credentials, even if you find them.

4.9 Do 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.

4.10 Comply with the law of your own jurisdiction and of India.

5.1 Response targets.

5.2 Remediation targets. Measured from confirmation, for the Platform and Pensieve-operated properties. The full vulnerability management position, including targets for findings from other sources, is in DIS-GL-017.

5.3 If we will miss a target. We tell you before the target passes, say why, and give a revised date. We do not go quiet.

5.4 If we dispute the finding. We explain the reasoning and the evidence. If you disagree, tell us; a disputed finding is reviewed by a second person.

5.5 Every report is recorded in the Vulnerability Register (REG-GL-204), whether accepted, disputed or duplicate.

5.6 Customers are told. Where a confirmed vulnerability materially affects a customer's tenant or data, Pensieve notifies affected customers under DIS-GL-016 and DPA-GL-001 clause 10, and does not wait for public disclosure to do it.

5.7 Our own regulatory clock. Where a finding indicates an incident of a type reportable under Direction (ii) of the CERT-In Directions of 2022, Pensieve reports it to CERT-In 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.

6.1 Default. 90 days from our acknowledgement, or the date the fix is deployed, whichever is earlier. After that you may publish.

6.2 Extension. We may ask for more time where a fix requires a customer-side upgrade, which is the usual position under DM-4, and will tell you why and give a date. We will not ask for an open-ended extension, and we will not ask you to withhold indefinitely.

6.3 Early publication. If the issue is being actively exploited, we may ask you to publish sooner, or publish ourselves, so that customers can protect themselves.

6.4 What to leave out. Please do not publish customer names, tenant identifiers, any data you saw, or a working exploit against an unpatched deployment.

6.5 We will not sue you for publishing in accordance with this clause, and we will not ask you to sign a non-disclosure agreement as a condition of us fixing the issue.

6.6 Our own disclosure. Where a vulnerability materially affected customer data, Pensieve publishes a summary in its Transparency Report (POL-GL-068) and, where the circumstances warrant, a standalone advisory.

7.1 No bug bounty today. Edsol Edtech Pvt. Ltd. does not currently operate a paid bug bounty programme. Saying so directly is better than implying one exists. If that changes, this clause changes and the change is dated.

7.2 What we do offer.

• Public credit in the Security Acknowledgements page at Pensieve security acknowledgements URL, with the finding described at the level of detail you are comfortable with, unless you ask us not to.
• A written confirmation of the finding, its severity and the date it was fixed, which you may use in your own portfolio or CVE submission.
• Our cooperation with a CVE request, including acting as or engaging a CNA where appropriate.
• Direct access to the engineer who fixed it, if you want to discuss the fix.

7.3 Discretionary payment. 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 schedule and no negotiation. Do not rely on it, and do not report in expectation of it.

7.4 Duplicates. The first complete report of an issue is credited. A duplicate is acknowledged as such, with the date of the original.

8.1 Publication. The file below is published at /.well-known/security.txt on every Pensieve property (the public website, the Trust Center, the Support Center and the Platform's public hostnames), served over TLS with content type text/plain; charset=utf-8, in accordance with RFC 9116. A copy is also served at /security.txt for compatibility.

8.2 Contents.

# Vulnerability disclosure for Pensieve Labs (Edsol Edtech Pvt. Ltd.)
# Policy: POL-GL-059 v1.0.0. See the Policy field below.
# Please read the policy before testing. Do not test a production tenant.

Contact: mailto:info@pensievelabs.org
Contact: https://trust.pensievelabs.org/security/report
Expires: Computed security txt expires
Encryption: Pensieve security pgp key URL
Policy: https://trust.pensievelabs.org/security/vulnerability-disclosure
Acknowledgments: Pensieve security acknowledgements URL
Preferred-Languages: en, hi
Canonical: https://trust.pensievelabs.org/.well-known/security.txt
Canonical: https://pensievelabs.org/.well-known/security.txt
Hiring: https://pensievelabs.org/careers

8.3 Required fields. RFC 9116 makes only Contact and Expires mandatory; every other field above is recommended and is included deliberately. Expires must be a future date-time in the format RFC 9116 requires.

8.4 The Expires discipline. Computed security txt expires is computed as twelve months from the file's last publication, and a scheduled task re-publishes the file and re-computes the value at least thirty (30) days before it lapses. An expired security.txt is worse than none, because it tells a researcher the programme is unmaintained.

8.5 Signing. Where the file is signed with the PGP key at Pensieve security pgp key URL, the detached signature is published at /.well-known/security.txt.sig and the Canonical fields above must match the URLs the file is served from, or the signature is meaningless.

8.6 Ownership. The Security owner maintains this file. Its currency is checked in the standing Trust Center review under POL-GL-502.

9.1 A customer reporting a suspected vulnerability uses the same address, info@pensievelabs.org, and gets the same response targets, in addition to any incident process under SLA-GL-001.

9.2 A customer wishing to conduct its own penetration test does so under DPA-GL-001 clause 15.6, prior written consent, agreed scope and window, own tenant only, and this Policy's safe harbour applies to the testers it engages for that agreed scope.

9.3 A suspected incident, as opposed to a vulnerability, is reported through the incident channel in SLA-GL-001 and handled under DIS-GL-016. If you are unsure which it is, use info@pensievelabs.org and say so; we will route it.

This Policy is reviewed annually and after any incident that reveals a gap in it. The review date is 31 January 2027. The security.txt file is re-published at least annually under 8.4 regardless of whether this Policy changes.