Data Processing Agreement

This Agreement forms part of the agreement between Marlmed Limited, a company incorporated in England and Wales (company number 17127171), trading as Marlmed (the "Processor"); and the customer identified in the applicable order form, subscription, or acceptance of the Marlmed Terms of Service (the "Controller"). Together, the "Parties".

1. Definitions

1.1 Capitalised terms not otherwise defined have the meanings given in the UK GDPR, the Data Protection Act 2018, and the Marlmed Terms of Service.

1.2 "UK GDPR" means the United Kingdom General Data Protection Regulation as incorporated into UK law by the Data Protection Act 2018.

1.3 "Personal Data" has the meaning given in the UK GDPR. "Special Category Data" means the categories described in Article 9 UK GDPR (including health data).

1.4 "Sub-Processor" means any third party engaged by the Processor that processes Personal Data on the Processor's behalf in connection with the services.

1.5 "Personal Data Breach" means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Personal Data transmitted, stored or otherwise processed.

2. Scope and purpose of processing

2.1 The Processor will process Personal Data for the Marlmed products and functionality purchased, enabled or otherwise made available to the Controller from time to time, as identified in the applicable Order or subscription account. A Controller only commissions processing for the products it has purchased or enabled. The Marlmed platform currently includes:

• Marlmed Stock - clinical inventory management with controlled-drug register
• Marlmed Asset - equipment and asset tracking, including check-in/check-out and maintenance events attributed to staff
• Marlmed CRM - patient/contact record-keeping, communications, and pipeline
• Marlmed Portal - patient-facing booking and clinic information surface
• Marlmed Auth - central authentication, role/permission management, and billing (used by all of the above)

2.2 The subject matter, duration, nature, and purpose of the processing, together with the types of Personal Data and categories of Data Subjects, are described in Annex A.

2.3 The Controller represents that it has a lawful basis for instructing the Processor to process the Personal Data described in Annex A. Where the Controller is itself a processor acting on behalf of another controller (for example a laboratory or an outsourced clinic administrator), references to the Controller include that underlying controller as appropriate, and the Controller warrants that it is authorised to appoint the Processor as a processor or sub-processor.

3. Controller instructions

3.1 The Processor will process Personal Data only on documented instructions from the Controller, including with regard to transfers to a third country or international organisation, unless required to do so by applicable law.

3.2 The Controller's use of the Marlmed platform - including the data entered, the configuration choices made, and the Controller's acceptance of this Agreement - constitutes the Controller's documented instructions to the Processor.

3.3 Where the Processor is required by law to process Personal Data otherwise than on the Controller's instructions, it will inform the Controller of that legal requirement unless prohibited by law from doing so.

4. Confidentiality

4.1 The Processor will ensure that persons authorised to process Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.

4.2 Access to Controller Personal Data within the Processor's organisation is restricted to personnel with a documented operational need, and is logged in the application audit trail.

5. Security of processing

5.1 The Processor will implement and maintain appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing.

5.2 Such measures are described in Annex B and are reviewed at least annually.

5.3 The Marlmed platform implements a tamper-evident SHA-256 hash chain over the audit log, scoped per organisation and product. The Controller may request a chain-integrity report at any time.

6. Sub-processors

6.1 The Controller authorises the Processor to engage Sub-Processors to process Personal Data, including those listed in Annex C.

6.2 The Processor will impose data protection obligations on Sub-Processors, by a written contract, that are no less protective than those set out in this Agreement. Where a Sub-Processor fails to meet its data protection obligations, the Processor remains fully liable to the Controller for the performance of that Sub-Processor's obligations.

6.3 The Processor will maintain an up-to-date list of Sub-Processors at marlmed.com/sub-processors. The Processor will give written notice, including by email to the Controller's nominated account administrator, at least 14 days before a new Sub-Processor begins processing Controller Personal Data, and will also update that page. If the Controller objects on reasonable grounds, it may terminate the affected services on written notice, with a pro-rata refund of pre-paid fees; no further compensation is owed.

7. International transfers

7.1 Data location. Personal Data for UK Controllers is stored and processed on servers located in the United Kingdom. Personal Data is not transferred outside the UK except where (a) required for a specific Sub-Processor service identified in Annex C; and (b) an appropriate UK transfer mechanism is in place. Where a restricted transfer is not covered by UK adequacy regulations, the Processor will ensure a valid UK mechanism applies, such as the UK International Data Transfer Agreement (IDTA) or the UK Addendum to the EU Standard Contractual Clauses, together with any required transfer risk assessment. The mechanism used for each non-UK Sub-Processor is identified in the Sub-processor Register.

7.2 The Processor will inform the Controller in advance of any change to data residency.

8. Assistance to the Controller

8.1 Taking into account the nature of the processing, the Processor will assist the Controller, by appropriate technical and organisational measures, to fulfil the Controller's obligations to respond to requests from Data Subjects exercising their rights under Chapter III of the UK GDPR.

8.1a Taking into account the nature of processing and the information available to the Processor, the Processor will also provide reasonable assistance to the Controller in ensuring compliance with the Controller's obligations under Articles 32 to 36 of the UK GDPR, namely: security of processing; notification of a Personal Data Breach to the Information Commissioner's Office and communication of a Personal Data Breach to affected Data Subjects; carrying out data protection impact assessments (DPIAs); and prior consultation with the Information Commissioner's Office.

8.2 Audit log retention. Application audit logs of user activity (logins, record changes, controlled-drug movements, etc.) are retained for the lifetime of the Controller's account. The Controller may export the audit log in CSV or JSON via the Marlmed admin interface.

8.3 Data export. The Controller may export its organisation's full data set (stock, contacts, audit log, configuration) in a common format (CSV/JSON) at any time during the subscription term and for 30 days after termination.

8.4 Right to erasure. Upon Controller request to fulfil a Data Subject erasure request, the Processor will support deletion of the specified individual's record from the live system, provided such deletion is consistent with the Controller's obligations (e.g. no overriding legal or regulatory requirement to retain the record, such as the Misuse of Drugs Regulations 2001 retention period for controlled-drug movements).

8.5 Where applicable law requires information to be retained (for example, controlled-drug register entries), the Processor will not erase or alter the required record. Instead it will restrict further processing to the extent appropriate and retain the information only for the applicable legal or regulatory period, acting on the Controller's documented instructions. Where the Controller instructs it, and only to the extent lawful, personal identifiers in non-statutory fields may be pseudonymised so that identifying information does not persist beyond what the record legally requires. Whether a particular identifier can lawfully be pseudonymised is a matter for the Controller to determine.

9. Personal Data Breaches

9.1 The Processor will notify the Controller without undue delay and in any event within 24 hours of becoming aware of a Personal Data Breach affecting the Controller's data.

9.2 The notice will include, to the extent then known: (a) the nature of the breach including, where possible, the categories and approximate number of Data Subjects and records concerned; (b) the likely consequences; (c) the measures taken or proposed to address it and mitigate adverse effects; and (d) the name and contact details of the Processor's data protection contact.

9.3 The notification under 9.1 is intended to enable the Controller to comply with its statutory 72-hour notification obligation to the Information Commissioner's Office. The Processor does not report breaches to the ICO on the Controller's behalf - the Controller, as Data Controller, retains that obligation. The Processor will provide reasonable follow-up information and technical context to support the Controller's reporting.

9.4 Subsequent to the initial notification, the Processor will provide regular updates (at minimum daily during an active investigation) until the breach is contained and resolved.

10. Deletion or return of Personal Data

10.1 Upon termination of the services, at the Controller's choice the Processor will either return all Personal Data (in the export format in 8.3) or delete it. The Controller's choice will be exercised in writing within 30 days of termination. Absent a written choice, the Processor will provide an export and then delete after a further 60 days (90 days after termination in total).

10.2 When a record is deleted upon Controller request, it is expunged from production systems within 24 hours and immediately placed beyond ordinary use. Any remnants in encrypted backups are removed as those backups expire on the rolling retention cycle (currently 14 days). Backups are used only for disaster recovery and are not restored to production after a deletion request without explicit re-instruction from the Controller; if a backup is restored, any records deleted before the restore are deleted again.

10.3 Audit-log entries that reference a deleted record are retained for the regulatory period applicable to the underlying activity (e.g. controlled-drug movements). The reference is redacted in place per 8.5 where personal identifiers would otherwise persist.

11. Audits and compliance

11.1 The Processor will make available all information reasonably necessary to demonstrate compliance with this Agreement.

11.2 The Processor will permit audits, conducted by the Controller or an independent auditor mandated by the Controller, subject to: (a) reasonable advance notice (no less than 30 days, except on regulator instruction); (b) auditor confidentiality undertakings reasonably acceptable to the Processor; (c) audit scope limited to compliance with this Agreement; and (d) audit costs borne by the Controller, except where the audit identifies material non-compliance by the Processor.

11.3 Where available, the Processor will satisfy audit requests by providing an existing third-party security report (e.g. SOC 2, ISO 27001) or hosting-provider compliance certificates in lieu of an on-site audit, where these reasonably address the Controller's objectives.

12. Liability

12.1 Liability under or in connection with this Agreement is subject to the limitations and exclusions in the Marlmed Terms of Service, save that nothing in this Agreement or the Terms will limit either Party's liability where it cannot be limited under applicable law (including liability under Article 82 UK GDPR for data subject compensation claims, allocated between the Parties in accordance with their respective responsibility for the breach).

13. Term and termination

13.1 This Agreement takes effect on the date the Controller accepts it (or, if no formal acceptance, on the date the Controller first uses the services) and continues for as long as the Processor processes Personal Data on behalf of the Controller.

13.2 Termination does not release the Processor from continuing obligations regarding deletion or return of Personal Data (section 10) and breach notification (section 9) in respect of any Personal Data still held.

14. Governing law and jurisdiction

14.1 This Agreement is governed by, and construed in accordance with, the laws of England and Wales.

14.2 The courts of England and Wales have exclusive jurisdiction to settle any dispute arising out of or in connection with this Agreement.

Annex A - Description of processing

Categories of Data Subjects

Categories of Personal Data

Special Category Data

Where the Controller chooses to store health data in CRM treatment notes or Portal patient records, that data is Special Category Data within the meaning of Article 9 UK GDPR. The Controller is responsible for ensuring an Article 9 lawful basis applies. The Processor processes such data only on the Controller's instructions and applies the Annex B measures with no distinction in protection between Special Category and other Personal Data.

Purpose and duration

Provision of the Marlmed software platform: clinical inventory management, controlled-drug register and witness sign-off, contact relationship management, patient booking, audit trail for regulatory compliance, and the supporting authentication and billing services. Processing continues for the duration of the Controller's subscription, plus the deletion / return window described in section 10.

Annex B - Technical and organisational measures

B.1 Infrastructure and hosting

• Personal Data is hosted on secure cloud infrastructure in the United Kingdom (current provider listed in Annex C).
• Hosting environments are protected by network firewalls, traffic monitoring, and regular system maintenance.
• Underlying hosting providers maintain ISO 27001, PCI DSS Level 1, and equivalent certifications; current certificates available on request.

B.2 Encryption

• In transit: TLS 1.2 or higher across all public endpoints, with automatically renewed certificates.
• At rest: full-volume encryption of the storage holding the production database, and AES-256 encryption of database backups.

B.3 Access control and authentication

• Role-based access control with fine-grained permissions per product (e.g. co-signing a controlled-drug movement requires a specific sign-off permission).
• Argon2id password hashing with a per-instance pepper.
• Versioned session tokens, allowing instant revocation of all sessions for a compromised user.
• Multi-factor authentication available on all accounts, with enforced MFA rolled out for privileged administrator roles.
• Account lockout and rate-limiting on authentication endpoints.

B.4 Application-level security

• Tenant isolation: every database query filters by the authenticated user's organisation scope, enforced at the data-access layer.
• Tamper-evident audit chain: a SHA-256 hash chain scoped per organisation and product; any post-hoc modification, insertion, or deletion of audit rows is detectable via a chain-verification endpoint the Controller may run at any time.
• Strict input validation: requests with unknown fields are rejected; required fields are explicitly checked rather than silently defaulted.
• Concurrency-safe writes: stock adjustments and audit-log inserts are serialised per organisation to prevent race conditions in a multi-user clinic environment.

B.5 Payment security

Payment card data is processed exclusively through Stripe, a PCI DSS Level 1 provider. The Processor does not store full card numbers, security codes, or expiry dates.

B.6 Backup and recovery

• Automated daily database backups, each encrypted with AES-256 and integrity-checked (SHA-256) after it is written.
• Backups are retained on a rolling 14-day cycle on UK infrastructure and are used only for disaster recovery. Extended retention is available on request.
• Our recovery targets are a Recovery Point Objective of under 24 hours and a Recovery Time Objective of under 4 hours. These are internal targets and not a guaranteed service level unless separately agreed in writing.

B.7 Monitoring and incident response

• Automated uptime and error-rate monitoring with alerting to the on-call responder.
• Documented incident response procedure with severity classification and post-incident review.
• Personal Data Breach notification process per section 9.

B.8 Organisational measures

• Personnel with access to Personal Data are subject to written confidentiality obligations.
• Access to production systems is restricted, key-based, and logged.
• Security practices reviewed at least annually and following any material incident.

B.9 Software development lifecycle

• All code changes are version-controlled and pass an automated regression test suite before reaching production.
• Production releases are gated behind a manual approval step.
• Schema changes are versioned and content-hash-gated to prevent accidental destructive re-runs.

Annex C - Approved Sub-Processors

The current list of Sub-Processors, what each does, and where it processes data is maintained at marlmed.com/sub-processors. The Processor may engage additional Sub-Processors from time to time, notified in accordance with section 6.3.

Annex D - Contact for data protection matters

Processor data-protection contact: Peter Irvine, Data Protection Lead - [email protected]. (Marlmed has not appointed a statutory Data Protection Officer under Article 37 UK GDPR; the Data Protection Lead is the point of contact for data protection matters.) For routine support: [email protected]. For breach notifications and urgent matters: [email protected].