1.1 On the timetable in MSA-IN-001 clause 22.7, DPA-GL-001 clause 14.4 and RBK-GL-026, Pensieve deletes:

1.2 Timetable. Production and non-production within thirty (30) days of the deletion instruction taking effect. Backups per <a href="#3">clause 3</a>. Keys after the backups. The dedicated project after the keys, under DM-1.

1.3 Certified. A Certificate of Data Deletion & Destruction (CRT-GL-011) is issued within ten (10) Business Days of the deletion completing, stating what was deleted, from where, when, by what method, and what was retained under this statement.

1.4 Nothing here is conditional. Deletion is not withheld pending payment and is not accelerated to avoid a cost. The export that precedes it is unconditional under WPR-GL-400 clause 7.

2.1 Three different things are commonly conflated, and this statement keeps them apart.

2.2 Residue is not retention. Pensieve does not use it, cannot read it once the keys are destroyed, does not restore it, and states the date on which it expires.

3.1 Backups are copies taken at points in time and kept for a rotation period. A backup taken before a deletion still contains that data until it expires. Pensieve does not edit backups, because a backup that can be selectively rewritten is a backup whose integrity cannot be relied on.

3.2 Outer limit. Backups containing the hospital's data are purged, or rendered unrecoverable by key destruction, within thirty-five (35) days of the deletion of the production data stores (DPA-GL-001 clause 14.4).

3.3 Under DM-1, the backups belong to the hospital's own dedicated project. They are deleted outright, and the project is deleted after them. There is no shared generation and no waiting on another customer's rotation.

3.4 No restore after deletion. Pensieve does not restore a backup of a terminated tenant for any purpose, except under a legal hold or a court order. The prohibition is enforced by removing the restore authorisation, not by policy alone.

3.5 Rotation periods are stated in DIS-GL-023 and are not restated here.

This list is closed. Nothing is added to it at the point of an exit. If a category emerges that is not here, DIS-GL-406 is amended with the citation and the hospital is told before the certificate is issued, not by finding a new paragraph in it. RBK-GL-026 Section 8.2 enforces that.

4.1 Item 1, stated more precisely. The retained log records that a record was accessed or changed, by whom, from where and when. Field-level changes are recorded as hashes of the old and new values, not the values themselves. The log is therefore not a second copy of the clinical record. It is held access-restricted and is used only for security, for statutory production, and to answer the hospital's own enquiries.

4.2 Item 2, and the honesty about it. [UNVERIFIED: whether CERT-In Direction (v) applies to a multi-tenant clinical platform. The Direction names "Cloud Service providers", which is undefined and was plainly aimed at infrastructure providers. Pensieve complies anyway: the record is the customer master, it contains no patient data, and the cost of retaining it is nil. Pensieve prefers over-compliance with a cheap obligation to an argument about scope.]

4.3 Item 7, and the limit on it. Aggregation and de-identification happen inside the hospital's tenant boundary before anything leaves it, with no re-identification key retained. Pensieve does not operate a research or statistical-purposes carve-out and does not build a business on one.

4.4 What is deliberately not on this list. Clinical records. Patient data. Images. Documents. Configuration. Tenant content. Pensieve does not retain a copy of a hospital's clinical archive for its own purposes, at any period, under any basis.

4.5 De-identified clinical data. Pensieve does not retain a de-identified copy of a hospital's clinical data after termination. Where a hospital has separately and expressly agreed to a research collaboration, that arrangement is its own written instrument with its own scope and its own end date, and it is not implied by this statement or by the MSA.

This is the clause that matters most and it is the one hospitals are least often shown.

5.1 The principle. The hospital is the Data Fiduciary and the custodian of the medical record. Pensieve is a Data Processor that held the records on the hospital's instructions. When Pensieve deletes, the hospital's statutory obligation to hold those records does not go with them; it attaches to whatever copy the hospital now holds.

Practically: the hospital must keep the export. A hospital that receives an export, instructs deletion, and then loses the export has not discharged its retention obligation. It has moved it and then failed it.

5.2 The Indian periods, with citations. These bind the hospital, not Pensieve. They are reproduced from the India regulatory research and are the same defaults the Platform ships with, so that a hospital recognises them.

5.3 The operating rule the Platform implements, and which the hospital should carry forward.

Retention equals the maximum of every applicable class period, and an indefinite statutory hold overrides any purge wherever a medico-legal flag, a legal notice, a consumer complaint or a regulatory proceeding is recorded against the record.

5.4 The three practical consequences for a hospital leaving Pensieve.

5.4.1 Keep the export, and keep it properly. Store it where it is backed up, access-controlled and readable, for the longest period in <a href="#5-hospital">Section 5.2</a> that applies to any record in it. The export includes a human-readable PDF of every encounter precisely so that the obligation can be met without any software at all (DIS-GL-401 Section 7.2).

5.4.2 Do not instruct Pensieve to delete before the export is verified. WPR-GL-400 clause 9 gives a 30-day verification window and RBK-GL-024 Section 8.1 requires it to close before deletion begins. The window is the hospital's protection, not Pensieve's process.

5.4.3 Carry the medico-legal flags across. rendered/index.csv in the export carries an is_mlc column for exactly this reason. A medico-legal record that arrives at the new system without its flag is a record that will be purged on a three-year rule when it should have been held indefinitely.

5.5 What Pensieve will do to help, at no charge.

• Deliver the complete export, in the formats in DIS-GL-401, before any deletion.
• Deliver the retention configuration the hospital had in force, as configuration/retention-policy.json, so the successor system can be configured the same way rather than from memory.
• Deliver the statutory registers in their statutory shape (DIS-GL-401 Section 7.5), so a register survives the migration as a register.
• Hold the data longer at the hospital's written instruction (FRM-GL-405), free for the first twelve months.

5.6 What Pensieve will not do. Give legal advice on which periods apply to the hospital. The matrix at <a href="#5-hospital">Section 5.2</a> is supplied so that the hospital does not have to build one, and it is cited so it can be checked. It is not legal advice and the hospital remains responsible for the periods it adopts, the same position as DPA-GL-001 clause 14.2.

5.7 Other markets. The same structure applies with different numbers, and the numbers are the hospital's, not Pensieve's.

Pensieve states these as unverified rather than asserting numbers it has not checked. The India rows are cited; the others carry a qualifier until they are.

6.1 The problem. Section 8(7) of the Digital Personal Data Protection Act, 2023 requires erasure on withdrawal of consent or when the purpose is no longer served: "unless retention is necessary for compliance with any law for the time being in force." Indian medical-record law mandates retention that frequently outlasts the purpose. A patient's erasure request and a hospital's retention duty can point in opposite directions on the same record.

6.2 How the Platform resolves it, and what survives an exit. Erasure is implemented as a policy engine that evaluates statutory holds per record class, not as a delete. The output is an Erasure Decision Record: the request, the records in scope, which were erased, which were retained and under which citation, and who approved. The Erasure Decision Records are in the export (relational/csv/quality/), because they are the hospital's evidence that it answered a Data Principal lawfully.

6.3 The consequence at exit. A record that could not be erased during the term because a statutory hold applied is still under that hold after the migration. The hold travels with the record, not with the software. Carry the flags across.

6.4 The reverse error. Deleting a record that a statutory floor required to be kept is a compliance failure in the opposite direction and is undetectable afterwards. RBK-GL-026 Section 9 test 9.12 verifies that the carve-outs survived the deletion, and it exists for this reason.

7.1 Instruction. A hospital instructs a hold on FRM-GL-405, stating the scope, the basis and either an end date or a review cadence. Pensieve confirms in writing what is held, on what basis and until when.

7.2 Effect. A record under hold is not deleted by a retention rule, by an erasure instruction, or by the offboarding timetable. A hold suspends deletion. It does not suspend the export, the transition support or the settlement.

7.3 Pensieve-side holds. Pensieve applies a hold only where a law binding on it, a court or regulatory order, or an actual or reasonably anticipated legal claim requires it. It is approved by Legal, recorded, reviewed every 90 days, and the hospital is told, unless Pensieve is legally prohibited from saying so, in which case POL-GL-067 governs and the prohibition is recorded.

7.4 Scope discipline. The scope of any hold is the narrowest that satisfies the requirement. A dispute about an invoice does not justify holding a clinical archive.

7.5 Release. On written release, deletion within 30 days and a supplementary CRT-GL-011.

7.6 Cost. None for the first twelve months. Beyond twelve months, where the held volume is material, Pensieve may charge storage at cost on 90 days' written notice with an itemised basis, and will offer the alternative of the hospital taking the held data into its own custody. Pensieve never charges to release a hold or to delete held data.

8.1 India. The hospital is the Data Fiduciary; Pensieve is a Data Processor acting on the hospital's instructions under DPA-GL-001. Pensieve's retention under <a href="#4">clause 4</a> items 1 and 2 is retention required of Pensieve by a law binding on Pensieve, which the DPA expressly permits at DPA-GL-001 clause 14.5. Items 3, 4 and 5 are Pensieve's own business records about the hospital as an organisation, in which Pensieve acts on its own account.

8.2 EU and EEA markets (Denmark, Norway). The hospital is the controller; Pensieve is the processor. Article 28(3)(g) of the GDPR requires the processor to delete or return personal data at the end of the provision of services save where Union or Member State law requires storage. Items 1 and 2 of <a href="#4">clause 4</a> rest on Indian law binding on Pensieve, and the transfer position for that data is DPA-GL-001 clause 12. A Danish or Norwegian hospital should read this clause together with DPA-GL-001 clause 12.3, which states the position without an adequacy decision.

8.3 Australia. APP 11.2 requires destruction or de-identification of personal information no longer needed, subject to a Commonwealth or state law or a court order requiring retention. Items 1 and 2 rest on Indian law binding on Pensieve; the hospital's own state retention minimum is at <a href="#5-hospital">Section 5.7</a> and is the hospital's obligation.

8.4 UAE. [UNVERIFIED: the interaction between the federal health data framework and a processor's retention under a foreign directive should be confirmed with local counsel before this statement is relied on in a UAE deal.]

8.5 Data Principal and data subject requests after termination. A request that reaches Pensieve about a hospital's patient after termination is referred to the hospital, because Pensieve no longer holds the record and the hospital is the Fiduciary or controller. Where a request concerns the retained logs at <a href="#4">clause 4</a> item 1, Pensieve answers it directly, through info@pensievelabs.org under POL-GL-066.

9.1 Under DM-3 and DM-4, most of the data is never Pensieve's to retain or delete. That is a genuine reduction in exposure to a Pensieve failure, and DIS-GL-407 says so. It is also a genuine increase in the hospital's own operational burden at exit, and RBK-GL-024 Section 12 says that.

Pensieve would rather a hospital checked than believed.

10.1 Ask for these during evaluation, not at exit. The specimen certificate is available on request before any contract is signed. A vendor that will not show you its deletion certificate in advance is telling you something.

11.1 Pensieve cannot verify physical media destruction. In a hosted model the storage belongs to a cloud provider. Pensieve deletes every logical copy and destroys the keys; it does not stand over a disk. The certificate says which of those it did and does not claim the one it cannot.

11.2 Residue in unexpired backups is real and is disclosed at <a href="#3">clause 3</a> rather than described as deletion.

11.3 Statutory retention may prevent complete deletion, and <a href="#4">clause 4</a> is the exhaustive list of where that bites.

11.4 Under DM-3 and DM-4 Pensieve certifies only its own acts. The larger part of the deletion is the hospital's, and Pensieve cannot certify it.

11.5 The applicability of CERT-In Direction (v) to Pensieve is unsettled and is marked so at <a href="#4">clause 4.2</a>. Pensieve complies conservatively.

11.6 The non-India rows at <a href="#5-hospital">Section 5.7</a> are unverified and are marked so.

11.7 This is a disclosure, not legal advice. The hospital remains responsible for the retention periods it adopts, both while it is a customer and afterwards.

11.8 This is a disclosure, not the contract. Its contractual force comes from MSA-IN-001 clause 22.7, DPA-GL-001 clause 14 and WPR-GL-400. Where this document and an executed agreement differ, the agreement governs, and Pensieve undertakes that no agreement it executes will retain more than this document describes.