1.1 Definitions. Terms defined in the MSA (MSA-IN-001), the DPA (DPA-GL-001) and the SLA (SLA-GL-001) have the same meaning in this Addendum. In addition:

**"Control"** means a technical or organisational measure stated in this Addendum or in a Pensieve policy referred to in it.

**"Critical Vulnerability"**, "High Vulnerability", "Medium Vulnerability" and "Low Vulnerability" mean a vulnerability classified at the corresponding severity under 8.3.

**"Privileged Access"** means access that permits configuration of the Platform or its infrastructure, access to production data other than through the Platform's own application interfaces, management of encryption keys, management of identities and permissions, or the ability to alter or delete audit records.

**"Production Environment"** means the environment in which the Customer's live operations are conducted, as distinct from development, test, staging and training environments.

**"Security Incident"** means an event that compromises, or that on reasonable assessment may have compromised, the confidentiality, integrity or availability of the Platform, the Production Environment or Customer Data. Every Personal Data Breach is a Security Incident; not every Security Incident is a Personal Data Breach.

1.2 Incorporation. This Addendum is incorporated into the MSA under clause 2.2 of the MSA and forms part of it.

1.3 Precedence. On the subject matter of information-security controls, this Addendum prevails over the MSA and over Pensieve's published policies. It is subordinate to the DPA on the processing of Personal Data and to the Order Form. Where ADD-GL-008 or ADD-GL-009 states a variation for the applicable Deployment Model, that variation prevails for that model.

1.4 Relationship to the published disclosures. The disclosures listed in the Related Documents table at the end of this Addendum describe how the controls in this Addendum are implemented and may change as implementation changes. This Addendum states the contractual floor. A disclosure may describe more than this Addendum requires; it may not describe less. Where a disclosure and this Addendum conflict, this Addendum governs the obligation.

1.5 No charge. Pensieve makes no separate charge for performing the obligations in this Addendum. Chargeable work is limited to what SLA-GL-001 clause 12.4 and 15.8 describe.

2.1 Accountability. A single named individual within Pensieve is accountable for information security, holds the authority to stop a release or suspend an access grant on security grounds, and reports directly to Director. The name and contact details are published at info@pensievelabs.org and are given to the Customer on request.

2.2 The policy set. Pensieve maintains, and applies to its own operations, the policies listed in Schedule A. Each is reviewed at least annually and on any material change to the Platform, the infrastructure or Applicable Law. The abridged published versions are available at https://trust.pensievelabs.org.

2.3 Control framework mapping. Pensieve's control set is mapped to:

2.3.1 ISO/IEC 27001:2022 Annex A control objectives, with a published Statement of Applicability (STM-GL-010);

2.3.2 the Cloud Security Alliance Consensus Assessments Initiative Questionnaire, self-assessed (QRE-GL-005);

2.3.3 CIS Controls v8 (CHK-GL-030); and

2.3.4 NIST Cybersecurity Framework 2.0 (CHK-GL-031).

2.4 No certification is claimed. Pensieve is not certified to ISO/IEC 27001, is not SOC 2 audited, holds no HITRUST certification and holds no other third-party certification of its information-security management system. Mapping to a framework is not certification against it, and Pensieve does not describe it as such in any document, proposal, questionnaire response or conversation. 18 states what the Customer receives instead.

2.5 Risk management. Pensieve maintains a Risk Register (REG-GL-202), assesses risks to confidentiality, integrity and availability at least quarterly and on any material change, records treatment decisions with named owners and dates, and reviews open high-rated risks at each quarterly management review.

2.6 Exceptions. A departure from a Control is recorded in the Exception & Waiver Register (REG-GL-210) with the reason, the compensating control, the approver and an expiry date not exceeding ninety (90) days, renewable once with fresh approval. Where an exception affects the Customer's tenancy, Pensieve notifies the Customer within five (5) Business Days and states the compensating control.

2.7 Annual review of this Addendum. Pensieve reviews this Addendum annually against the framework mappings in 2.3, the outcome of the assessments in 15, and the incidents of the preceding year, and publishes the reviewed version.

3.1 Segregation of duties. No single individual may both author a change to the Platform and approve its release to the Production Environment, save in the emergency circumstances in 10.7, which are recorded and reviewed. Where the size of the engineering team makes full segregation impracticable for a particular activity, the compensating control is recorded under 2.6 and disclosed to the Customer on request. Pensieve states this rather than asserting a segregation it may not always achieve.

3.2 Documented procedures. Every security-relevant operational activity (provisioning, access granting, key rotation, backup, restore, incident response, break-glass, deployment, offboarding) is performed to a written runbook, and the runbook records who performed the step and when.

3.3 Asset management. Pensieve maintains an Asset Register (REG-GL-201) covering the infrastructure, services, repositories, data stores, endpoints and third-party services used to deliver the Platform, with an owner for each entry, reviewed quarterly.

3.4 Data classification. Customer Data is classified and handled in accordance with DIS-GL-022. Patient-identifiable data is handled at the highest classification, is not copied to any environment other than the Production Environment except as 10.5 permits, and is not transmitted through any channel not listed in 10.6.

3.5 Clear desk, endpoint and removable media. Pensieve personnel work on managed endpoints with full-disk encryption, screen lock, automatic patching and endpoint protection. Removable media is disabled on managed endpoints by policy. Customer Data is not stored on an endpoint except transiently in the course of authorised diagnostic work, and is removed at the end of it.

3.6 Physical security of Pensieve's own premises. Pensieve's offices are access-controlled. Pensieve operates no data centre of its own. Physical and environmental security of the infrastructure on which the Platform runs is described at 7.9 and in DIS-GL-021.

3.7 Insurance. Pensieve maintains the cover recorded in the Insurance Schedule (ADD-GL-021), including cyber liability cover. MSA clause 18.13 records that insurance does not enlarge liability.

4.1 The principle. Security in a deployed system is a division of labour. The division moves with control of the infrastructure, and control of the infrastructure moves with the Deployment Model. A control that Pensieve performs under DM-1 may be the Customer's under DM-4, and neither Party should discover which at the time of an incident. Schedule B is the full allocation.

4.2 Reading the RACI. In Schedule B, R means the Party that performs the work, A means the Party accountable for it being done correctly, C means the Party that must be consulted, and I means the Party that must be informed. Where a cell shows R/A for one Party, that Party both performs and answers for it.

4.3 Summary by layer.

4.4 DM-2: what multi-tenancy means for responsibility. Under DM-2 the Customer's tenancy shares infrastructure with other customers. Isolation is enforced logically, as described at 7.7 and in DIS-GL-032. The Customer cannot be given infrastructure-level controls in a shared environment, including infrastructure-level network policy, host-level access, or the ability to run its own agents, because doing so would affect other customers. A Customer that requires infrastructure-level isolation should select DM-1.

4.5 DM-3: delegated administration. Under DM-3, Pensieve operates inside infrastructure the Customer owns, under the roles granted in ADD-GL-009. Pensieve is responsible for the security of what it deploys and configures; the Customer is responsible for the security of the account, the organisation policy, the billing relationship, the key service and anything else it or a third party places in the project. Every administrative action Pensieve takes is recorded in the Customer's own audit log, which Pensieve cannot alter or delete.

4.6 DM-4: the narrowing of Pensieve's commitments, stated plainly.

This sub-clause applies only where the Deployment Model is DM-4. It is retained in the published standard form so that the narrowing is visible before the model is selected.

4.7 The Customer is not left to guess. Pensieve issues the Security Hardening Checklist (CHK-GL-011) for the applicable Deployment Model at mobilisation, and the DPDP Compliance Checklist for the Customer as Data Fiduciary (CHK-GL-025). Both state, line by line, what the Customer must do and by when.

5.1 Identity for Pensieve personnel. Every Pensieve individual with access to any system used to deliver the Platform holds a unique, named identity. Shared, generic and service-team accounts are not used for human access. Multi-factor authentication is enforced on every such identity, and phishing- resistant authentication (a hardware security key or platform passkey) is enforced for every identity holding Privileged Access.

5.2 Least privilege. Access is granted on the basis of the role's need to perform its function, and no more. Standing access to the Production Environment is limited to the minimum number of individuals required to operate it. A list of the roles that hold Privileged Access, and the number of individuals in each, is provided to the Customer on request.

5.3 Just-in-time elevation. Privileged Access to a Customer's Production Environment is granted for a defined task and a defined period, and expires automatically. Elevation requires a recorded reason and, for access to Customer Data, the approval of a second individual. Where a Customer requires prior consent to each elevation, that requirement is recorded on the Order Form and honoured, subject to 5.5.

5.4 Access to Customer Data during support. Support access to Customer Personal Data is governed by DPA-GL-001 clause 6.4. In summary and without varying it: access is on the least-privilege basis, is logged with the identity, the time, the records touched and the Ticket reference, is available to the Customer through the Platform's access report, and is not used for any purpose other than the Ticket.

5.5 Break-glass. Emergency access outside the normal grant path is available only through a documented break-glass procedure (POL-GL-134, RBK-GL-022) which requires: a recorded justification at the time; automatic alerting to the accountable individual under 2.1; notification to the Customer's Authorised Support Contacts within twenty-four (24) hours in every case, and before the access where circumstances permit; session recording; and a post-event review within five (5) Business Days. Under DM-3 the break-glass procedure in ADD-GL-009 clause 6 applies in addition.

5.6 Joiner, mover, leaver. Access is provisioned on the basis of an approved role at joining, adjusted within two (2) Business Days of a role change, and revoked within four (4) hours of the end of employment or engagement, or immediately on a termination for cause. Revocation covers identity providers, cloud accounts, repositories, ticketing, communication tools and any Customer-granted access. POL-GL-321 governs the procedure and the Access Review Register (REG-GL-208) records the evidence.

5.7 Access reviews. Access to the Production Environment and to Customer Data is reviewed quarterly by the accountable individual under 2.1, and the review (including every grant confirmed, reduced or removed) is recorded in the Access Review Register. Under DM-3, Pensieve provides the Customer with the result of each review in respect of the Customer's project within ten (10) Business Days of completing it.

5.8 Authentication available to the Customer's users. The Platform provides: password authentication with configurable complexity and rotation policy; multi-factor authentication; passkey and WebAuthn authentication; and single sign-on by SAML 2.0 or OpenID Connect against an identity provider the Customer operates. Session lifetime, idle timeout, concurrent-session policy, IP allow-listing and failed-attempt lockout are configurable by the Customer's administrator. DIS-GL-012 describes the implementation.

5.9 What Pensieve requires of the Customer. The Customer configures and enforces authentication policy for its own users. Pensieve makes multi-factor authentication available; the Customer decides whether to require it. Pensieve will record in writing where a Customer chooses not to enforce multi-factor authentication for users with administrative privileges, and 17.9 allocates the consequence.

5.10 Role-based access within the Platform. The Platform enforces role-based access control with department, site and record-level scoping, and denies by default. The Customer defines its own role model. Pensieve provides a default role model at mobilisation; adopting it is the Customer's decision.

5.11 Access by Pensieve to the Customer's premises. Where Pensieve personnel attend the Customer's premises, they do so under the on-site personnel conduct and patient-confidentiality undertaking (POL-IN-318), comply with the Customer's own access, badging and infection-control requirements, and are supervised by the Customer's nominated contact.

5.12 Geography of access. The countries from which Pensieve personnel may access the Production Environment are disclosed in DIS-GL-033. Pensieve will notify the Customer at least thirty (30) days before adding a country, and the Customer may object on reasonable grounds, in which case Pensieve will not grant access from that country in respect of the Customer's tenancy.

6.1 The contractual floor. DIS-GL-011 is the source of truth for algorithms, key lengths, rotation intervals and key-management architecture, and may state stronger measures than this clause. This clause states the minimum Pensieve is contractually bound to, which may not be reduced without notice under 19.1.

6.2 In transit. All Customer Data transmitted between the Customer and the Platform, and between components of the Platform across any network boundary, is encrypted using TLS 1.2 or higher, with TLS 1.3 preferred, using cipher suites providing forward secrecy. Plaintext protocols are not offered. HTTP Strict Transport Security is enforced. Certificates are managed automatically and are not shared between customers.

6.3 At rest. All Customer Data at rest (in databases, object storage, backups, snapshots, message queues and search indexes) is encrypted using AES-256 or an algorithm of equivalent or greater strength.

6.4 Key management. Encryption keys are held in a managed key-management service. Key material is not held in application configuration, in source code, in environment variables, in container images or in a repository. Access to key material is limited to service identities and, for administrative operations, to identities holding Privileged Access under 5, and every key operation is logged.

6.5 Key separation by Deployment Model.

6.6 Rotation. Data-encryption keys are rotated at intervals not exceeding twelve (12) months, and immediately on a suspected compromise. Rotation does not require re-encryption of historic data where the key hierarchy permits envelope rotation. TLS certificates are rotated at intervals not exceeding ninety (90) days where automated issuance permits.

6.7 Customer-controlled keys, and the honest consequence. Where the Customer holds the key, always under DM-3 and DM-4, and by election under DM-1, the Customer can render its own data permanently unreadable by disabling or destroying the key. Pensieve cannot recover data encrypted under a key it cannot access, and no backup, escrow or support process changes that. SLA-GL-001 clause 5.3.6 excludes the resulting unavailability. The Customer accepts that consequence as the price of holding the key, and Pensieve states it here rather than in a footnote.

6.8 Application-level protection. Credentials, secrets and tokens supplied by the Customer under ADD-GL-007 are encrypted under a per-tenant key in a secret store, are never written to an application log, and are redacted in error reports, traces and support artefacts. ADD-GL-007 clause 5 states the full custody regime.

6.9 Cryptographic erasure. Destruction of the key material for a tenancy is used as one component of secure deletion under 16, and is evidenced in the Certificate of Data Deletion & Destruction (CRT-GL-011). Key destruction alone is not treated as sufficient deletion where the underlying storage can also be erased.

6.10 What is not encrypted, stated openly. Data in use in application memory during processing is not encrypted. Operational metadata necessary to route, bill and support the service (tenancy identifiers, timestamps, request paths and error codes) is retained in systems where it is encrypted at rest but is not itself tokenised or pseudonymised. DPA-GL-001 clause 3.5 governs what that metadata may be used for.

7.1 Deployment posture. The Platform runs on managed container services within a cloud provider's infrastructure. Pensieve does not operate physical infrastructure of its own. WPR-GL-002 describes the architecture and DIS-GL-006 the sanitised data-flow.

7.2 Ingress. Public ingress terminates at a managed load balancer with TLS termination, protection against volumetric denial of service, and a web application firewall configured to block the categories in the OWASP Top Ten. Rate limiting is applied per identity and per source, in accordance with POL-GL-057.

7.3 Private data plane. Databases, object storage, message queues and internal services are not reachable from the public internet. They are addressable only from within the private network of the Customer's environment, through private connectivity, and with identity-based authorisation in addition to network-level restriction.

7.4 Administrative access paths. Administrative access to infrastructure is by identity-aware proxy or equivalent brokered access, from managed endpoints, with multi-factor authentication and session logging. Pensieve does not operate a shared administrative jump host holding standing credentials, and does not permit direct database access from an unmanaged endpoint.

7.5 Egress control. Outbound network access from the Platform is restricted to the destinations required for the Services and for the integrations the Customer has enabled. A new outbound destination is a change under 10.7 and, where it is a Third-Party System, is governed by ADD-GL-007.

7.6 Hardening and configuration. Infrastructure is provisioned from version-controlled configuration. Manual change to a production resource outside that configuration is an exception under 2.6. Baselines follow POL-GL-130 and are checked automatically; drift raises an alert.

7.7 Tenant isolation.

Under DM-1 the Customer's tenancy occupies a dedicated cloud project with dedicated compute services, a dedicated database, dedicated storage and dedicated encryption keys. Isolation is at the infrastructure boundary and no other customer's workload executes within it.

7.8 Denial of service and capacity. Protection against volumetric attack is inherited from the cloud provider and supplemented by rate limiting. Capacity is monitored and scaled under POL-GL-126. Under DM-3 and DM-4 capacity is constrained by what the Customer has provisioned, and SLA-GL-001 clauses 5.6 and 11.4 allocate the consequence.

7.9 Physical and environmental security. For DM-1, DM-2 and DM-3, physical and environmental security of the data centres is provided by the cloud provider under its own certified control set, and Pensieve inherits rather than performs it; DIS-GL-021 states what is inherited and from whom. For DM-4, physical and environmental security is entirely the Customer's, and ADD-GL-008 clauses 4 and 5 state the requirements.

7.10 Data residency. Customer Data is stored and processed in Deal data region. DIS-GL-008 states residency per model and per jurisdiction, including the position on support access from outside the region under DIS-GL-033.

7.11 Anti-malware. Endpoints used by Pensieve personnel run endpoint detection and response software with central alerting. Container images are built from minimal base images, are scanned before release under 8.2, and are rebuilt rather than patched in place. Files uploaded by users into the Platform are scanned before they are made available for download.

8.1 The commitment. Pensieve identifies vulnerabilities in the Platform and in the infrastructure it manages, classifies them, and remediates them within the timescales in 8.4. DIS-GL-017 describes the operating detail; this clause states the obligation.

8.2 Detection. Pensieve performs, at not less than the following frequency:

8.3 Classification. A vulnerability is classified by its CVSS v3.1 base score, adjusted for exploitability in Pensieve's actual configuration and for exposure:

8.3.1 Critical: CVSS 9.0 or above; or any score where the vulnerability is reachable from the public internet in Pensieve's configuration and a working exploit is publicly available; or any vulnerability permitting unauthenticated access to Customer Data or cross-tenant access.

8.3.2 High: CVSS 7.0 to 8.9; or a lower score with a demonstrated path to privilege escalation or to Customer Data.

8.3.3 Medium: CVSS 4.0 to 6.9.

8.3.4 Low: CVSS below 4.0, and findings of hardening or hygiene character.

8.4 Remediation timescales. Measured from the earlier of Pensieve becoming aware and the vulnerability becoming public:

8.5 Mitigation counts, and is recorded as such. Where a fix is not available within the timescale, a documented compensating mitigation that removes the exploitable path, a configuration change, a network-level block, a feature disablement or a rule at the web application firewall, satisfies the timescale, provided that the residual finding is recorded in the Vulnerability Register (REG-GL-204) with an owner and a date for the permanent fix. Pensieve will not close a finding as mitigated without recording the mitigation.

8.6 Missing a timescale. Where a Critical or High timescale will be missed in respect of a vulnerability affecting the Customer's tenancy, Pensieve notifies the Customer before the timescale expires, states the reason, states the compensating mitigation in place, and states the revised date.

8.7 Emergency release. Pensieve may release a security fix outside the normal release cadence and, if necessary, outside a Maintenance Window, under SLA-GL-001 clause 10.5.

8.8 Patching under DM-4 and DM-3.

8.9 Software bill of materials. Pensieve maintains a machine-readable software bill of materials in CycloneDX format for each released version of the Platform, publishes it under DIS-GL-019, and provides the version applicable to the Customer's tenancy on request within five (5) Business Days.

8.10 Vulnerability disclosure. Pensieve operates a Vulnerability Disclosure Policy (POL-GL-059) and publishes security.txt. A report received under it is acknowledged within two (2) Business Days, triaged within five (5) Business Days, and remediated under 8.4. Pensieve does not pursue a good-faith researcher who complies with that policy. Pensieve does not operate a paid bug bounty programme, and says so rather than implying one.

8.11 Security bulletins. Where a vulnerability materially affects customers, Pensieve issues a Security Bulletin (NTC-GL-021) stating the affected versions, the impact, the fix, the workaround and the action required of the Customer.

8.12 The Customer's part. The Customer applies updates to browsers, endpoints and any locally installed component within thirty (30) days of Pensieve notifying that they are required, and maintains the components allocated to it in Schedule B. SLA-GL-001 clause 7.10.6 records the same obligation.

9.1 What is logged. Pensieve generates and retains logs sufficient to establish who did what, to which record, when, and from where. Logging covers at a minimum: authentication success and failure; session creation and termination; access to patient-identifiable records, including read access; creation, amendment and deletion of records; permission and role change; administrative and configuration change; Privileged Access grant, use and expiry; break-glass invocation; key management operations; data export; and infrastructure change.

9.2 Integrity. Logs are written to storage that is append-only for the retention period. Pensieve personnel, including those holding Privileged Access, cannot alter or delete an audit record within its retention period. Under DM-3 the cloud provider's own audit log records Pensieve's administrative actions and sits within the Customer's control; Pensieve cannot alter or delete it.

9.3 Retention and location: the Indian requirements, met explicitly.

9.3.1 Where the Processing is subject to Indian law, logs are retained for not less than three hundred and sixty-five (365) days and are stored within the territory of India.

9.3.2 That period and location satisfy, and exceed, the requirement in Direction (iv) of the CERT-In Directions of 28 April 2022, which obliges entities to enable logs of all their ICT systems, maintain them securely for a rolling period of 180 days, and maintain them within Indian jurisdiction, and to provide them to CERT-In on the reporting of an incident or when directed. (CERT-In Directions, 28 April 2022)

9.3.3 The 365-day period also satisfies the one-year retention floor in Rules 6(1)(e) and 8(3) of the Digital Personal Data Protection Rules, 2025. Where two obligations apply, Pensieve applies the longer.

9.3.4 DIS-GL-034 states the retention and localisation position per Deployment Model and per jurisdiction, and DPA-GL-001 clause 7.7 records the same commitment.

9.4 Clock synchronisation. The clocks of the ICT systems used to deliver the Platform are synchronised to the Network Time Protocol servers of the National Informatics Centre or the National Physical Laboratory, or to servers traceable to them, as required by Direction (iii) of the CERT-In Directions of 28 April 2022. Where infrastructure is located outside India for a non-Indian Customer, the equivalent national or accredited time source for that jurisdiction is used.

9.5 Monitoring and alerting. Pensieve monitors the Platform continuously by automated means, with alerting to an on-call engineer. Detection rules cover, at a minimum: authentication anomalies; privilege escalation; unusual volumes of record access or export; changes to identity, permission and key configuration; failed integrity checks; and infrastructure configuration drift. Pensieve does not operate a twenty-four-hour security operations centre staffed by human analysts, and does not claim to. Detection is automated; response is by an on-call rota with the escalation in SLA-GL-001 clause 7.7.

9.6 What the Customer can see for itself. The Platform provides the Customer's administrators with an access and audit report covering the events in 9.1 for the Customer's own tenancy, including access by Pensieve personnel, exportable by the Customer without asking Pensieve. DIS-GL-013 describes the report and its NABH relevance. A Customer that cannot see who looked at a record cannot govern its own data, so this is provided as a standard capability rather than on request.

9.7 Log content restrictions. Logs do not contain passwords, secrets, tokens, keys or full payment credentials. Patient-identifiable data appears in logs only as the identifiers necessary to make the audit record meaningful. Diagnostic traces and error reports are redacted before they leave the Production Environment.

9.8 Provision to authorities. Where CERT-In, a court, a regulator or another authority lawfully directs production of logs, Pensieve complies and, unless legally prohibited, notifies the Customer under POL-GL-067 and NTC-GL-018 before doing so.

10.1 Secure development lifecycle. Pensieve develops the Platform under the secure development lifecycle described in POL-GL-118 and DIS-GL-018, which includes threat modelling for new capabilities that process patient-identifiable data or introduce a new external interface, security review of design, and the automated controls in 8.2.

10.2 Code review and branch protection. Every change to production code is reviewed and approved by at least one engineer other than its author before merge. The default branch is protected; direct pushes are blocked; and history rewriting is disabled. POL-GL-133 governs the configuration.

10.3 Secrets. Secrets are held in a managed secret store, never in source, configuration files, container images or issue trackers. Secret scanning blocks a commit containing a detected secret. A secret exposed at any point is rotated and the exposure is recorded as a Security Incident.

10.4 Environment separation. Development, test, staging and production are separate environments with separate credentials, separate keys and no network path from a lower environment to production.

10.5 Production data in non-production. Customer Data is not copied into a development, test, training or demonstration environment. Where reproduction of a defect requires production data, the work is performed in the Production Environment under 5.3 and DPA-GL-001 clause 6.4, or on data that has been de-identified to the standard in DIS-GL-022. Where the Customer expressly requests a training environment seeded with its own data, that request is recorded in writing, the environment is treated as a Production Environment for the purposes of this Addendum, and the Customer is told so.

10.6 Channels. Customer Data is not transmitted through personal e-mail, consumer messaging applications, public file-sharing services or unmanaged devices. Where the Customer sends data through such a channel, Pensieve will say so and ask for it to be resent through the Platform or another agreed channel.

10.7 Change control. Every change to the Production Environment is recorded in the Change Register (REG-GL-205) with its author, approver, test evidence, deployment time and rollback position. Emergency change is permitted where a Severity 1 or a Critical Vulnerability requires it, and is recorded and reviewed within five (5) Business Days. DIS-GL-031 describes the release process and SLA-GL-001 clause 10 the notice periods.

10.8 Release integrity. Build artefacts are produced by an automated pipeline from version-controlled source. Artefacts deployed to production are the artefacts the pipeline produced. Dependencies are resolved from pinned versions.

10.9 Third-party and open-source components. Pensieve maintains the Open Source Licence Register (REG-GL-213) and the dependency disclosure in DIS-GL-019. A dependency that is unmaintained, or whose licence is incompatible with the Platform's distribution model, is replaced.

10.10 Artificial intelligence features. Where the Order Form enables a capability using machine learning or a large language model, ADD-GL-006 and DIS-GL-027 govern it. Customer Data is not used to train a model that serves any other customer, and DPA-GL-001 clause 3.3 records that as a processing restriction, not merely a policy.

11.1 The obligation. Pensieve detects, contains, investigates, remediates and reports Security Incidents affecting the Platform, the Production Environment or Customer Data, in accordance with POL-GL-112 and the Incident Response Runbook (RBK-GL-017).

11.2 Notification to the Customer.

11.2.1 Where the Security Incident is or may be a Personal Data Breach, the notification obligations in DPA-GL-001 clause 10 apply and are not varied by this Addendum. In summary and without varying them: initial notification within four (4) hours of Pensieve becoming aware; supplementary information within twenty-four (24) hours; a consolidated report within forty-eight (48) hours; and a final report within fifteen (15) Business Days of closure. Four hours is set deliberately inside the Customer's own six-hour CERT-In obligation.

11.2.2 Where the Security Incident is not a Personal Data Breach but affects the Customer's tenancy, Pensieve notifies the Customer's Authorised Support Contacts within twenty-four (24) hours of becoming aware, and raises a Severity 1 or Severity 2 Ticket under SLA-GL-001 according to its operational effect.

11.2.3 Where the Security Incident affects Pensieve's own systems but not the Customer's tenancy, and is material to the Customer's assessment of Pensieve, Pensieve notifies the Customer within five (5) Business Days and states what it has done.

11.3 Pensieve's own regulatory reporting. Pensieve is a body corporate with independent obligations. Where an incident is reportable to CERT-In under Direction (ii) and Annexure I of the CERT-In Directions of 28 April 2022, Pensieve reports it within six (6) hours of noticing it or being brought to notice of it, informs the Customer that it has done so, and coordinates so that the two Parties' filings are consistent. Pensieve's filing is not a substitute for the Customer's own.

11.4 Containment and preservation. Pensieve contains an incident before it optimises for restoration where the two conflict, preserves logs, images and forensic artefacts until the Customer confirms in writing that preservation may end or for twelve (12) months, whichever is later, and does not destroy evidence in the course of remediation.

11.5 Post-incident report. Pensieve issues a written post-incident report within ten (10) Business Days of closure of a Severity 1 Security Incident, containing the timeline, the technical cause, the contributing factors, the containment and remediation performed, the preventive actions with named owners and dates, and an assessment of whether any Customer Data was accessed, altered or exfiltrated.

11.6 Detection under DM-3 and DM-4, stated honestly.

11.7 Tabletop exercises. Pensieve runs an incident-response tabletop exercise at least annually and makes the resulting report (REP-GL-014) available under 15.6.

11.8 No public statement. Neither Party will make a public statement naming the other in connection with a Security Incident without the other's prior written consent, except where a statement is required by Applicable Law or by a regulator, in which case the Party required to make it will give the other as much notice as the circumstances permit.

12.1 Screening. Before an individual is given access to any system used to deliver the Platform, or to Customer Data, Pensieve carries out background verification proportionate to the role, comprising at a minimum: verification of identity; verification of the highest relevant educational qualification; verification of the immediately preceding employment; and a criminal-records check to the extent permitted by Applicable Law in the individual's jurisdiction. Verification is conducted with the individual's consent under POL-IN-304.

12.2 Where screening is limited. Where a check is not lawfully available, is not completed, or returns an adverse result that Pensieve nonetheless assesses as acceptable, the position is recorded, the individual is not given Privileged Access until the position is resolved, and the compensating control is recorded under 2.6. Pensieve records what it actually verified rather than asserting a uniform standard it cannot always meet.

12.3 Contractual obligations of personnel. Every employee and individual contractor is bound by a written confidentiality undertaking that survives the end of the engagement, an intellectual property assignment, and the Code of Conduct (POL-IN-305). DPA-GL-001 clause 6.1 records the confidentiality obligation as it applies to Personal Data.

12.4 Training. Every individual completes security and data-protection induction training before being granted access, and refresher training at least annually, covering at a minimum: phishing and social engineering; handling of patient-identifiable data; the incident-reporting duty; access hygiene; and the Acceptable Use Policy. Completion is recorded in the Training Register (REG-GL-209). Engineers with Privileged Access additionally complete secure-coding training annually.

12.5 Duty to report. Every individual is required to report a suspected Security Incident immediately and without fear of adverse consequence. Failure to report is a disciplinary matter under POL-GL-322.

12.6 Contractors. Individual contractors working under Pensieve's direction and control, on Pensieve's systems, are subject to the whole of this clause and are treated as Pensieve's personnel; they are not Sub-processors and are not separately listed as such, per DPA-GL-001 clause 8.8. Pensieve does not subcontract support or engineering work to a body-shop, staffing agency or offshore delivery centre operating under its own management, and would notify the Customer under ADD-GL-022 before doing so.

12.7 Leavers. Access is revoked under 5.6. Equipment is returned or wiped, and the confidentiality obligation is reconfirmed in writing at exit.

12.8 On-site personnel. Pensieve personnel attending the Customer's premises are additionally bound by POL-IN-318 and POL-IN-319, and comply with the Customer's own policies notified to them.

12.9 Key-person concentration, disclosed. Pensieve is a small organisation. STM-GL-324 states the key-person dependency position and what mitigates it, including the source-code escrow available under ADD-GL-011. Pensieve discloses this rather than allowing a hospital to assume a depth of bench it does not have.

13.1 The register. The Sub-processors engaged in delivering the Platform are listed in the Subprocessor Register (DIS-GL-009), which is published, dated and maintained. DPA-GL-001 clause 8 governs authorisation, notification, objection and liability, and this Addendum does not restate it.

13.2 Security requirements flowed down. Before engaging a Sub-processor with access to Customer Data or to the Production Environment, Pensieve assesses it under POL-GL-120 and POL-GL-135, and imposes by written contract obligations no less protective than those in this Addendum on the matters relevant to the Sub-processor's role.

13.3 Assessment cadence. Each Sub-processor with access to Customer Data is reassessed annually, and on any material change to its service, its ownership or its own security position. The assessment covers, at a minimum: its certifications or their absence; its incident history as disclosed; its sub-processing; its data location; and its own deletion commitments.

13.4 Suppliers who are not Sub-processors. Tools that Pensieve uses without giving them access to Customer Data (build systems, code hosting, project tracking and the like) are managed under the same policy but are not listed as Sub-processors. Where such a tool is configured in a way that would give it access to Customer Data, it becomes a Sub-processor and is added to the register before the configuration is made.

13.5 What is not a Sub-processor: the BYOK/BYOC boundary. A Third-Party System that the Platform connects to using the Customer's own credentials, on the Customer's own authority, is not a Sub-processor of Pensieve. DPA-GL-001 clause 8.6 and ADD-GL-007 state the position and the reasoning. Pensieve does not assess, warrant or accept responsibility for the security of those systems, and says so before integration rather than after an incident.

13.6 Infrastructure providers under DM-3 and DM-4. Under DM-3 and DM-4 the infrastructure provider is the Customer's supplier, not Pensieve's Sub-processor. DPA-GL-001 clause 8.7 records this.

13.7 Change of Sub-processor. Notification, the objection right and the emergency-replacement path are in DPA-GL-001 clauses 8.4 and 8.5, with the notice form at NTC-GL-001 and the approval schedule at ADD-GL-022.

14.1 Continuity of the Platform. The recovery objectives, the backup regime, the declaration of a Disaster and the restore-test cadence are in SLA-GL-001 clause 9, which is the source of truth for them. DIS-GL-015 describes the continuity arrangements and RBK-GL-020 the invocation procedure.

14.2 Continuity of Pensieve as a business. Pensieve maintains a business continuity plan under POL-GL-106 covering loss of premises, loss of key personnel, loss of a critical supplier and loss of access to a development or operational system. It is reviewed annually.

14.3 Testing. Continuity and recovery arrangements are tested at the cadence in SLA-GL-001 clause 9.2, and the outcome, including where a test failed to meet an objective, is recorded in the Business Continuity Test Register (REG-GL-211) and reported under SLA-GL-001 clause 11.6.8.

14.4 Vendor failure. The Customer's protection against Pensieve ceasing to trade is not a promise; it is the escrow available under ADD-GL-011, the exit and portability commitment in WPR-GL-400, the export specification in DIS-GL-401 and the business failure continuity plan in DIS-GL-407. Under DM-3 and DM-4 the Customer already holds the infrastructure, the data and the backups, which is a material resilience advantage of those models and is stated as such.

15.1 Independent penetration testing. Pensieve commissions an independent penetration test of the Platform, performed by a third party that is not involved in developing it, at least once every twelve (12) months, and additionally following any change of architecture that materially alters the attack surface. The scope covers the Platform's external interfaces, authentication and authorisation, tenant isolation, and the cloud configuration of a representative deployment.

15.2 CERT-In empanelled audit. For the Indian deployment of the Platform, Pensieve commissions a vulnerability assessment and penetration test by an auditor empanelled by CERT-In, at least once every twelve (12) months, and obtains the resulting report (REP-GL-003) and compliance certificate (REP-GL-004) where the auditor issues one.

15.3 Remediation and re-test. Findings are classified under 8.3 and remediated under 8.4, with the timescale running from the date of the report. Remediation of every Critical and High finding is verified by re-test, and the re-test outcome is recorded.

15.4 What Pensieve publishes. The attestation letter for each penetration test (REP-GL-001) and the safe-to-host or compliance certificate from the CERT-In empanelled audit (REP-GL-004) are published at https://trust.pensievelabs.org without a gate.

15.5 What Pensieve provides under confidentiality. The full penetration test report (REP-GL-002), the full VAPT report (REP-GL-003) and the remediation status are provided to the Customer under the confidentiality obligations in MSA clause 12 or the mutual NDA (NDA-GL-001). Pensieve does not publish full reports openly, because a report containing unremediated finding detail and internal architecture is a map for an attacker, and it says so rather than implying it has nothing to show.

15.6 The standing evidence pack. Pensieve maintains, and provides on request within five (5) Business Days, the pack listed in Schedule D, which includes the Statement of Applicability (STM-GL-010), the self-assessed CAIQ (QRE-GL-005), the SBOM (DIS-GL-019), the BC/DR test report (REP-GL-013), the tabletop exercise report (REP-GL-014), the restore verification report (REP-GL-015), the security grades snapshot (REP-GL-017) and the insurance certificate (STM-GL-023), each in the tier at which it is published.

15.7 The Customer's own testing. The Customer may, at its own cost, commission a penetration test of the Platform as deployed for it, once in any twelve (12) months and additionally following a Severity 1 Security Incident, subject to:

15.7.1 not less than fifteen (15) Business Days' prior written notice, with the scope, the method, the source addresses, the window and the identity of the tester;

15.7.2 the tester being bound by confidentiality, and not being a competitor of Pensieve in the supply of hospital software;

15.7.3 the test being confined to the Customer's own tenancy: under DM-2 a test may not target shared infrastructure or any path that could affect another tenant, and Pensieve will provide a dedicated test tenancy for that purpose;

15.7.4 no denial-of-service, volumetric or load testing without Pensieve's prior written agreement and an agreed window;

15.7.5 the Customer providing the findings to Pensieve within five (5) Business Days of receiving them; and

15.7.6 findings being remediated under 8.4, and the report being Confidential Information of both Parties.

Under DM-3 and DM-4 the Customer may test its own infrastructure at any time without notice; the notice requirement applies to testing directed at the Platform.

15.8 Chargeable assurance work. Responding to a security questionnaire in the Customer's own format, beyond the master answer set (QRE-GL-008), and participation in an on-site audit beyond the standing pack and beyond one (1) Business Day in any twelve (12) months, are chargeable under SLA-GL-001 clause 12.4. Provision of the standing pack, of the published artefacts, and of the CAIQ is never chargeable.

15.9 Questionnaire turnaround. Pensieve returns a completed CAIQ, CAIQ-Lite or its master answer set within two (2) Business Days of request, and a completed questionnaire in the Customer's own format within five (5) Business Days, or states within that period when it will be returned.

15.10 Audit rights for Personal Data. Audit and inspection rights in respect of the processing of Personal Data are in DPA-GL-001 clause 15 and are not varied by this Addendum.

15.11 No representation from the existence of a test. A penetration test, an audit or a questionnaire response describes a point in time. It is not a warranty of security, and neither Party will treat it as one. MSA clause 15 states the warranty position and MSA clause 16 the disclaimers.

16.1 Where the obligation lives. The right to export, the exit assistance and the deletion obligation are in MSA clause 22 and DIS-GL-023, and the format specification is in DIS-GL-401. This clause states how deletion is performed and evidenced.

16.2 Method. Deletion of Customer Data comprises: removal of the data from the live data stores; destruction of the encryption key material for the tenancy, rendering any residual ciphertext unreadable; expiry of the data from backups in accordance with the backup retention cycle; and removal of the tenancy's storage objects. Pensieve does not treat key destruction alone as deletion where the underlying storage can also be erased.

16.3 Timescales. Unless the Customer has instructed otherwise or a legal hold applies: live data is deleted within thirty (30) days of the end of the Exit Period; backups containing Customer Data expire within thirty-five (35) days thereafter, being the backup retention cycle; and logs are retained for the statutory minimum in 9.3 and then deleted. Pensieve issues the Certificate of Data Deletion & Destruction (CRT-GL-011) within ten (10) Business Days of completion, stating what was deleted, when, by what method, and what if anything is retained and why.

16.4 Media. For DM-1, DM-2 and DM-3, physical media sanitisation is performed by the cloud provider under its own controls; Pensieve does not take physical custody of media. For DM-4, media sanitisation and physical disposal of hardware are the Customer's, and Pensieve provides a written procedure aligned to the sanitisation methods in NIST SP 800-88 Rev. 1 for the Customer to follow or to give to its disposal contractor.

16.5 Legal hold. Where either Party is subject to a legal hold, a regulatory direction or a statutory retention obligation that prevents deletion, deletion is suspended in respect of the data affected, the data is isolated and access-restricted, and the position is recorded on the Certificate under 16.3. FRM-GL-405 records a hold instruction.

16.6 Statutory retention by the hospital. A hospital's own retention obligations for medical records are the Customer's to determine as Data Fiduciary. DPA-GL-001 clause 9.5 records the Erasure Decision Record mechanism by which a deletion instruction that conflicts with a retention obligation is resolved.

16.7 Return before deletion. Deletion never precedes delivery of the export the Customer has requested and accepted. CRT-GL-010 records the delivery, and MSA clause 22.5 makes deletion consequent on it.

17.1 Why this clause exists. A platform can be secure and a deployment insecure. The controls below are the Customer's under every Deployment Model, and Pensieve cannot perform them. Schedule C states them as a checklist per model, and CHK-GL-011 is issued at mobilisation.

17.2 User and identity administration. The Customer creates, reviews and removes its own users' accounts; assigns roles on a least-privilege basis; removes access within one (1) Business Day of a member of staff leaving or changing role; and does not permit shared or generic clinical accounts. Shared logins in a clinical setting defeat the audit trail on which the Customer's own accreditation and its DPDP position depend.

17.3 Authentication policy. The Customer configures password policy, session timeout, lockout and, where it elects, multi-factor authentication and single sign-on. Pensieve makes each available; the Customer decides.

17.4 Endpoints and network. The Customer maintains its own devices, browsers, operating systems, anti-malware, patching, network equipment, wireless security, firewall and internet access, and segregates its clinical network as its own policy requires.

17.5 Physical security of its own premises. Including screen placement at reception and nursing stations, workstation locking, and control of printed output containing patient data.

17.6 Data entered into the Platform. The Customer is responsible for the lawfulness, accuracy and appropriateness of what its users enter, for not entering categories of data outside the agreed scope (DPA-GL-001 clause 4.3), and for not using production patient data in training sessions.

17.7 Third-party credentials. The Customer supplies, warrants, scopes, rotates and revokes the credentials used for Third-Party Systems, under ADD-GL-007.

17.8 Incident reporting to Pensieve. The Customer notifies Pensieve without undue delay of any suspected compromise of a Customer user account, of a credential supplied under ADD-GL-007, or of the Customer Environment or Customer Infrastructure.

17.9 Consequence of a Customer election. Where the Customer elects not to implement a control Pensieve has made available and recommended in writing, including multi-factor authentication for administrative users, session timeout below a stated threshold, or IP restriction on administrative access, Pensieve records the election, and loss arising from the absence of that control is not attributable to Pensieve. This is not a device for shifting Pensieve's own failures; it applies only where Pensieve made the control available, recommended it in writing, and the Customer declined.

17.10 Additional responsibilities under DM-3.

17.11 Additional responsibilities under DM-4.

18.1 Purpose of this clause. A security document that lists only what exists is not evidence of anything. This clause states the gaps, so that the Customer's assessment is made on facts rather than on inference. Each item is accompanied by what compensates for it.

18.2 No claim will be made. Neither Pensieve nor any person acting on its behalf will state or imply, in a proposal, a questionnaire response, a tender submission, a website page or a conversation, that Pensieve holds a certification it does not hold. A statement that Pensieve's controls are "mapped to" or "aligned with" a standard is accompanied, in the same document, by the statement that Pensieve is not certified to it.

18.3 If this changes. Where Pensieve obtains a certification or an audit report, it will be published at https://trust.pensievelabs.org with its scope and its period, and this clause will be amended in the next version of this Addendum. Until it is published, it does not exist for the purposes of any statement made to the Customer.

19.1 Changes to Controls. Pensieve may change a Control, and will do so as technology and threat change. Pensieve will not make a change that materially reduces the level of protection provided to the Customer without giving the Customer at least thirty (30) days' prior written notice, and where the Customer objects in writing within that period on reasonable grounds, MSA clause 2.6 applies. A change required by Applicable Law takes effect on the date that law requires.

19.2 Notification of a material change. Pensieve notifies the Customer of: a change to the Deployment Model's isolation architecture; a new Sub-processor with access to Customer Data, under DPA-GL-001 clause 8.4; a change to the countries from which support is provided, under 5.12; and a change to the retention or location of logs, under 9.3.

19.3 Remedies. Breach of this Addendum is a breach of the MSA. Where the breach causes or is likely to cause a Personal Data Breach, it is a material breach for the purposes of MSA clause 21.3. Service Credits under SLA-GL-001 are not the sole remedy for breach of this Addendum; SLA-GL-001 clause 8.9.3 records that carve-out expressly.

19.4 No waiver by inspection. The Customer's review of a document, participation in an assessment, receipt of a report or failure to object to a Control does not waive any right, does not approve a deficiency and does not transfer responsibility to the Customer.

19.5 Survival. Clauses 9 (in respect of retained logs), 11 (in respect of an incident notified or discovered before termination), 15 (in respect of evidence relating to the period of the Agreement) and 16 survive termination.

19.6 Governing law. This Addendum is governed by, and disputes under it are resolved in accordance with, MSA clauses 25 and 26.