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. [TO BE SUPPLIED] and [TO BE SUPPLIED] are not yet supplied, so Pensieve Labs publishes no PGP key today, and the Encryption field is left out of security.txt under 8.2.2 rather than pointing at an address that serves nothing. Until a key is published: where your report includes a working exploit, or any data you happened to see, say so in a first message without the detail, and an encrypted channel is agreed with you before you send anything. The Security owner agrees that channel within 1 business day of your first message. The moment a key is published at that address, this clause and the Encryption field carry it.

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.

4.11 Testing Scaffold. Scaffold is a live support channel. A hospital in an outage is on the other side of it, and a test that wakes an on-call engineer at three in the morning costs a real person a real night. These rules are additional to 4.1 to 4.10, not instead of them:

4.11.1 Use an account we issue you for the purpose. Ask at info@pensievelabs.org and we will provide one. Do not use a hospital's account, and do not use a hospital's Ticket to demonstrate anything.

4.11.2 Do not raise a Ticket to report a finding. A Ticket is read by support engineers, not by the security function, and it is the wrong queue. Report under 3.

4.11.3 Do not create load that reaches a person. No automated scanning that opens Tickets, triggers notifications, sends electronic mail to a nominated contact or pages the on-call rota.

4.11.4 The Severity 1 telephone line and the paging path are out of scope entirely. They ring a human who is expected to treat every call as a hospital in trouble. Testing them is not authorised research, and the safe harbour does not extend to it.

4.11.5 Tenancy separation is the finding worth having, and it is also the one most likely to expose another hospital's data by accident. Ask first. We will provide two accounts in two test tenancies for exactly this, and we answer that request within the two Business Days in 1.3.

4.11.6 Do not upload real personal data, real patient data or a live credential as an attachment, even your own. Use obviously synthetic content.

4.11.7 This clause and the Scaffold terms of use are one rule, not two. POL-GL-801 clause 6 prohibits interfering with the property, probing its access controls and using another person's account. Research inside this clause is authorised for the purposes of that prohibition and does not breach it. Activity outside this clause breaches both instruments, and neither the safe harbour in 1 nor anything in POL-GL-801 protects it. If the two ever appear to differ, this Policy governs the question of what a researcher may do, and POL-GL-801 governs everything else about the property.

5.1 Response targets.

5.2 Remediation timescales. The timescales are contractual and are published once, in ADD-GL-001 clause 8.4. This Policy does not restate them, and neither does DIS-GL-017 Section 2.1. Earlier versions of both carried their own tables, which produced three public documents and three different answers to one question; the tables are withdrawn and ADD-GL-001 clause 8.4 governs. A researcher reporting a confirmed finding gets those timescales, whichever property the finding is in.

5.2.1 What the clock is measured from, for a researcher. The contractual timescale runs from the earlier of Pensieve becoming aware and the vulnerability becoming public. For a report under this Policy, awareness is the date of your report, not the date we finish confirming it under 5.1.

5.2.2 Mitigation and fix are labelled distinctly, and we will tell you which you have. A mitigation removes the exploitable path without changing the code: a rule at the web application firewall, a disabled feature, a restricted network path, a revoked credential. A permanent fix removes the defect. A mitigation satisfies the contractual timescale under ADD-GL-001 clause 8.5 only where it is recorded with the residual risk, an owner and a date for the permanent fix. We will not tell you a finding is fixed when it is mitigated, and the notification under 5.1 says which of the two happened. DIS-GL-017 Section 2.2 carries the same distinction for a hospital reading it.

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, with the finding described at the level of detail you are comfortable with, unless you ask us not to. That page does not exist yet: it is published at [TO BE SUPPLIED] with the first acknowledged report, and the Acknowledgments field is left out of security.txt until it is, under 8.2.2.
• 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, served over TLS with content type text/plain; charset=utf-8, in accordance with RFC 9116. /security.txt on each property is a permanent redirect to the canonical path, for readers and scanners that still look there. Every property means each of these, and the list is exhaustive so that a missing file is visible rather than arguable:

Scaffold's file is part of the launch gate for the property: the file, this Policy and the rules of engagement in 4.11 are published together or the property does not open.

8.2 Contents. This is the file, reproduced as the Trust Center serves it. It is generated from the token registry at the moment of the request, so the text below and the bytes a researcher fetches cannot drift apart.

# Vulnerability disclosure for Pensieve Labs (Edsol Edtech Pvt. Ltd.)
# Governing policy: POL-GL-059, published in full at the Policy URL below.
# Read the policy before testing. Do not test a production tenant: it holds patient records.
# There is no paid bug bounty today. That is stated plainly rather than implied away.

Contact: mailto:info@pensievelabs.org
Contact: https://trust.pensievelabs.org/security/report
Expires: 2027-10-05T03:40:16Z
Preferred-Languages: en, hi
Canonical: https://trust.pensievelabs.org/.well-known/security.txt
Canonical: https://pensievelabs.org/.well-known/security.txt
Policy: https://trust.pensievelabs.org/security/vulnerability-disclosure

# Response targets, committed in POL-GL-059 Section 5:
#   Acknowledgement by a person, not an autoresponder ... 1 business day
#   Triage and severity, communicated to you .......... 3 business days
#   Confirm or dispute, with reasoning ................ 5 business days
#   Status update thereafter .......................... every 7 days until closure
# Coordinated disclosure default: 90 days from acknowledgement, or the day the fix ships.
# Safe harbour and its honest limits: POL-GL-059 Section 1.
# Machine-readable posture: https://trust.pensievelabs.org/trust-manifest.json

8.2.1 Every field in it resolves. RFC 9116 is a machine-readable format, and a field pointing nowhere is worse than an absent field: it sends a researcher to a 404 at the moment they are trying to help. https://trust.pensievelabs.org/security/report is the reporting section of this Policy as it is published on the Trust Center, and https://trust.pensievelabs.org/security/vulnerability-disclosure is this Policy in full. Both are served at the Public tier and need no account.

8.2.2 What is omitted, and why. A field whose value is not yet supplied is left out of the file rather than emitted empty. Three are omitted today, and their absence is a fact about Edsol Edtech Pvt. Ltd. rather than an oversight:

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

8.4 The Expires discipline. 2027-10-05T03:40:16Z 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 [TO BE SUPPLIED], 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.

9.4 A vulnerability in Scaffold itself is reported here and not through Scaffold, for the reason in 4.11.2. That includes a defect that lets one hospital see another hospital's Tickets, which is the finding we most want and the one we least want demonstrated against a real tenancy. DIS-GL-819 clause 13 routes Scaffold vulnerability reporting to this Policy.

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.