Privacy | Visitor data
Your data
Two different roles get confused constantly, so this page states them separately. Over a hospital’s data inside the Pensieve platform, the hospital is the Data Fiduciary and Edsol Edtech Pvt. Ltd. is its Data Processor, acting on instruction. Over what this website collects about you as a visitor, Edsol Edtech Pvt. Ltd. is the Data Fiduciary in its own right under the Digital Personal Data Protection Act, 2023, which is why the erasure below is self-serve rather than a request you have to make to somebody.
This site loads no advertising pixel, no chat widget and no external font. Two scripts are not ours alone, and both are named here. The forms that send mail, the erasure form on this page among them, carry Cloudflare Turnstile, an automated-traffic check loaded from challenges.cloudflare.com. And in production every page reports a page view to Vercel Web Analytics, our host’s analytics, through a script served from this site’s own origin: the address it reports has its query string removed, so no link’s secret travels with it, and the page a sign-in link opens is not reported at all. Vercel records with each view the site that referred you and the country and device type it derives from the request. That is not a promise you have to take on trust. Open the network tab.
What this site stores about you
All of it, not a summary. Nothing below is sold, enriched from a third-party source, or used to profile you or your organisation, and none of it is used for advertising.
| Surface | What it contains | Written when | Kept for |
|---|---|---|---|
| Email captures | Email address, organisation, the tier it was captured for, IP address, timestamp | When you clear the email gate, or when an access request is queued | 24 months from last contactPOL-GL-053 Section 7.2 |
| Access requests | Name, work email, organisation, role, what you asked for, any qualification answers you chose to give, IP address, user agent, the decision and its reason | When you submit the request-access form | 36 months from decision, approved and refused alikePOL-GL-053 Section 7.2 |
| NDA acceptances | Name, email, organisation, document ID and version, the SHA-256 digest of the exact text you accepted, timestamp, IP address, user agent | When you accept the click-through mutual NDA | 8 years: it is contract evidence, and the term it evidences is two yearsPOL-GL-503 Section 2 |
| Document access events | Document ID, action, your email if you have cleared a gate, tier at access, path (for a search that found nothing, the words searched for), IP, user agent | Every time a document is viewed, downloaded, printed or blocked | 365 days minimum, extended only while an investigation is openPOL-GL-503 Section 2, DIS-GL-034 |
| Update subscriptions | Email address, the categories you chose, when you confirmed them from your inbox, and the token behind your unsubscribe link | When you ask for bulletins or a sub-processor change feed, and again when you follow the confirmation link we email you | Until you unsubscribe, then 3 years of the withdrawal record only. An address never confirmed is deleted once its confirmation link has expiredPOL-GL-053 Section 7.2 |
| Questionnaire requests | Your name, work email and organisation, the questionnaire's title, format, question count and due date, the notes you wrote, and once the workbook arrives, its questions and our answers | When you send the security questionnaire intake form, or an administrator logs a questionnaire you sent us by email | As the record of what you asked and what we answered. No job deletes it on a timetable; erasure removes your name, address and organisation from it, the title and notes included, and where it still holds a name or an organisation you gave on another form, the confirmation email says so and the privacy team corrects it by handPOL-GL-053 Section 7.2 |
| Erasure requests | The address the request is for, when it was asked for, verified and carried out, how your identity was checked (the emailed link, or an administrator's note of the check), what the sweep cleared, and the reason if a request was refused | When you ask for erasure below, or an administrator raises a request for you | An unverified request loses the address when its link lapses. A request carried out keeps your pseudonym in place of the address once the confirmation has gone. A refused request keeps the address and the administrator's note, as the record of the answer, until a later request of yours is carried outPOL-GL-053 Section 7.2 |
| Sessions and sign-in codes | Email address, a hash of the session token (never the token itself), IP, user agent, expiry | When you sign in, or clear a gate on a device | 365 days for the authentication event; the session itself expires in 12 hours to 30 daysPOL-GL-503 Section 2 |
| Sent messages | Recipient address, subject, the full body, and the delivery state. A confirmation link is cut from our copy once the mail provider has the message | Every time this site emails you | As the underlying record: it is the proof of what we told you and when. On erasure the recipient becomes your pseudonym, the subject and body are removed, and so is the provider's reference to the message. The mail provider keeps its own delivery log for its standard retention periodPOL-GL-503 Section 2 |
| Audit log | Actor, action, subject, before and after, reason, IP, timestamp | Every access decision, gate acceptance, document view and administrative act | 8 years, append-only. See below: erasure pseudonymises your entries in place rather than deleting themPOL-GL-503 Section 2.1 |
Erase it
Enter the address you used on this site. You will receive a verification link, valid for 24 hours. Nothing changes until you follow it, because otherwise this form would be a way to erase somebody else’s record. When you confirm, the erasure runs at once: your identifiers are removed or replaced across every surface listed above, and also in the records that exist only once access is granted or a hospital adds you to its workspace (viewer grants, workspace seats, questions and plan acknowledgements). Any spelling of the address that reaches the same mailbox is covered: case, and for Gmail dots, a +tag and googlemail.com. Elsewhere, erasing an address also covers its +tag variants, but erasing a tagged address covers that exact address only, because some mail servers deliver it to a different person. A confirmation is sent to the address when it completes. If it cannot finish at once, it is retried automatically with the next daily run. If the confirmation cannot be sent, it is retried with the daily run once the site has room to send public mail, which can take up to two days, and the request keeps the address until it has gone.
What survives erasure, and why
The audit log is append-only, enforced by a database trigger. Every DELETE is refused, and so is every UPDATE but one: inside the transaction that carries out an erasure, and only there, the trigger lets that person’s address be replaced with their pseudonym, their IP address be removed from their own entries, and their name or address be cut out of the text of an entry. The rest of every entry must stay exactly as written, so an entry can lose a person but cannot be made to say something else. Any other change, a different pseudonym, and any change at all to a security incident entry are refused. That is not a convention we could quietly relax; it is the property that makes the log worth anything. A log that can be edited freely proves nothing about who was entitled to read which contract, which is the single question this whole system exists to answer.
So erasure does not delete audit rows. It applies keyed pseudonymisation: every occurrence of your address is replaced with a keyed digest of it, computed with a key generated for your erasure alone and destroyed when the sweep completes. Throughout that sweep you are one consistent pseudonym, so the sequence of events stays coherent and verifiable, and afterwards nobody, including us, can recompute the pseudonym from your address. One limit is worth stating plainly: a record the law requires us to keep (below) still names you, and it can be matched with the pseudonymised entries about the same thing. A contract you signed keeps your name and address, for instance, and the audit entry recording that signature now carries your pseudonym. The confirmation email lists every such record, and where it lists none, nothing links the pseudonym back to you.
Everything else goes: email captures, access requests, NDA acceptance identity fields, viewer grants and workspace seats, sessions, document access events (the words of your searches included), questions, questionnaire requests, subscriptions and the messages we sent you are cleared of your name, address, organisation and IP address; sign-in codes are deleted; access is revoked and subscriptions stop. A question you asked, or a questionnaire logged for you, loses the name and organisation it is certain are yours; where it still holds a name or an organisation you gave on another form, which could have been anybody’s typing, the confirmation email says so and the privacy team corrects it by hand. An administrator’s note on one of your erasure requests keeps its wording, since it records how your identity was checked or why a request was refused: where it still names you or your organisation, the confirmation email says so, and the privacy team corrects it by hand. Where the law requires a record to be kept (an executed contract you signed, a tax record, a security incident record), it is kept, and the confirmation email tells you which one and under which provision rather than giving you a vague refusal. If our own published content (a document, a bulletin, the sub-processor register) shows your address, it is not rewritten underneath its integrity record: the confirmation email says so, and our privacy team corrects and re-publishes it by hand. Where it, or any other record, names you without your address, the privacy team is sent it to check, and corrects it by hand once they are sure the name is yours and not somebody else’s.