#Incident Response & Breach Notification Commitment

This document states commitments, not intentions. Each one is measurable after the fact against the incident record, and the incident record is disclosable to the affected hospital.

---

#Applicability

---

#Purpose

To state, in advance and in public, how fast Pensieve Labs will tell a hospital that something has happened, what it will tell them, and why the number is what it is.

The number matters because of arithmetic, not sentiment. An Indian hospital must report a reportable cyber incident to CERT-In within six hours of noticing it. If its software vendor takes a day to tell it, the hospital cannot comply. Pensieve Labs's four-hour commitment exists to leave the hospital two hours to act, and it is contractual rather than aspirational.

---

#1. The commitment, in one table

"Aware" means the point at which any Pensieve Labs person or system has information indicating an incident may have occurred. It does not mean the point at which the incident is confirmed, triaged, scoped or understood. The clock starts at awareness, not at certainty, because a clock that starts at certainty can be started whenever it is convenient.

---

#2. The three clocks

An incident affecting an Indian hospital starts three statutory clocks in parallel. Pensieve Labs's commitment is designed so that the hospital can meet the ones that bind it.

flowchart LR
  D["T0<br/>Pensieve Labs becomes aware"] --> P["≤4 hours<br/>Pensieve Labs notifies the hospital<br/>with reportable content"]
  P --> C["≤6 hours from the hospital<br/>noticing the incident<br/>Hospital reports to CERT-In"]
  P --> B["Without delay, then 72 hours<br/>Hospital reports to the<br/>Data Protection Board"]
  P --> R["Without delay<br/>Hospital notifies affected<br/>Data Principals"]

Text description. At time zero Pensieve Labs becomes aware of an incident. Within four hours it notifies the hospital with content sufficient for the hospital's own filings. That notification feeds three separate hospital obligations that run in parallel: a report to CERT-In within six hours of the hospital noticing; an initial report to the Data Protection Board without delay followed by a detailed report within 72 hours; and notification of each affected Data Principal without delay.

The hospital reports, not Pensieve Labs. In all four deployment models the hospital is the Data Fiduciary and holds the regulatory reporting obligation. Edsol Edtech Pvt. Ltd. is the Data Processor: it supplies the content, the technical analysis and the evidence, and it has its own independent obligation to report incidents affecting its own systems to CERT-In. Pensieve Labs does not report on the hospital's behalf and does not represent that it can.

#2.1 Other markets

For an EEA hospital the operative document is DIS-EU-016 (Breach Notification Commitment: GDPR), which maps all six clocks: the processor clock, the Article 33 clock, the Article 34 communication and the three NIS2 clocks, and states which Pensieve Labs output feeds each filing. The commitment value is identical; only the clock map differs.

Pensieve Labs operates one notification standard rather than a per-market one, because the tightest clock in the portfolio is six hours and a per-market standard would eventually be applied to the wrong market.

---

#3. What the notification contains

Enough for the hospital to file its own report without asking a second question:

1. What happened: in plain description, not a severity code.
2. When it was detected, and when it is believed to have started.
3. Which systems and which categories of data are affected, referencing the categories in DPA-GL-001 Annexure I and DIS-GL-022.
4. The number of affected records, or a bounded estimate stated as an estimate.
5. Whether the incident is contained, and if not, what is still in progress.
6. What Pensieve Labs has done so far.
7. What the hospital should do, including anything only the hospital can do, such as forcing credential resets or notifying its own users.
8. A named contact with a direct channel, available for the duration.
9. Whether the incident is, in Pensieve Labs's assessment, of a type listed in CERT-In Annexure I, because that determines whether the hospital's six-hour clock is running.

Where a fact is not yet known, the notification says so. Pensieve Labs does not delay a notification until everything is known; it notifies with what it has and updates. A complete notification sent after the hospital's clock has expired is worthless.

---

#4. Severity and the response process

Evidence handling. Logs, images and artefacts relevant to an incident are preserved in immutable storage (DIS-GL-013 Section 2) and are not modified during the investigation. Where a hospital may need them for its own regulatory filing or a legal proceeding, Pensieve Labs provides them on request.

---

#5. The post-incident review

Every hospital affected by an S1 or S2 incident receives the written review, within 10 business days of containment or a dated interim review stating why the final one is delayed. It contains:

• The timeline, with the actual clock performance against the 4-hour commitment, stated as a number.
• Root cause, and contributing factors, including process and organisational ones, not only technical.
• What was changed, with named owners and dates.
• What would have prevented it, including anything the hospital could do on its side.
• Where a commitment in this document was missed, the fact that it was missed, and why.

A missed target is recorded, not reclassified. A review that never reports a missed target is a review nobody is reading.

---

#6. Rehearsal

Pensieve Labs runs an incident-response tabletop exercise on a scheduled cadence and publishes a two-page summary: the date, the scenario, participants by role, the decisions taken, the clock performance against each statutory window, and the remediation actions with owners.

Stated plainly: as at 31 July 2026 no tabletop exercise has yet been run and published. WPR-GL-005 Section 5 carries the owner and target date. The commitment in Section 1 stands regardless; the exercise is how Pensieve Labs demonstrates it can meet it before it has to.

---

#7. Per-model responsibilities

---

#8. Sub-processor incidents

Where an incident originates with a sub-processor listed in DIS-GL-009, Pensieve Labs's 4-hour clock starts when Pensieve Labs becomes aware, which may be later than when the sub-processor became aware. Pensieve Labs cannot commit to a notification time it does not control, and does not pretend to. What it commits to is: notifying inside 4 hours of its own awareness; passing through the sub-processor's own account of the incident; and stating in the notification when the sub-processor says it became aware, so the hospital can see the gap.

---

#9. Limitations

9.1 The 4-hour clock runs from Pensieve Labs's awareness. An incident that is not detected does not start a clock. Section 9.2 is therefore the limitation that matters.

9.2 No 24×7 staffed security operations centre. Detection is by automated alerting routed to an on-call engineer, not by a staffed watch floor. A slow, quiet intrusion outside business hours depends on the alerting rules being right. Pensieve Labs describes this as monitoring with on-call response and does not describe it as a SOC. WPR-GL-001 Section 17.2.

9.3 No DM-4 detection. Section 7.

9.4 No forensic retainer in place today. For an incident requiring independent digital forensics, Pensieve Labs would engage a firm at the time rather than under a standing retainer, which costs hours. WPR-GL-005 Section 5 carries the status.

9.5 No cyber liability insurance certificate published yet. WPR-GL-005 Section 5 carries the owner and target date. A hospital for whom vendor insurance is a procurement gate should raise it at qualification.

9.6 Untested. Section 6. The commitment is contractual and the process is documented; neither has been exercised against a clock.

9.7 Pensieve Labs does not report to a regulator on the hospital's behalf, and cannot. The obligation is the Data Fiduciary's.

---

#10. How to reach Pensieve Labs about an incident

Use both channels for a suspected incident. Redundancy costs nothing and a single channel eventually fails.

---

#11. Related documents

---

#12. Change history

---