Data Processing Agreement

Under UK GDPR and the Data Protection Act 2018, where one party processes personal data on behalf of another, a written Data Processing Agreement must be in place. The care home operator (the ‘Controller’) is the data controller for personal data relating to its residents, staff, and other data subjects. Care-Meter (the ‘Processor’) processes that data on the Controller’s behalf to provide the Services.

This DPA supplements and forms part of the Subscription Agreement. In the event of conflict on data protection matters, this DPA prevails.

Full processing details are set out in Schedule 1 below.

4.1 Lawful Basis

The Controller confirms it has a lawful basis under UK GDPR Art. 6 and Art. 9 for each category of Personal Data it instructs the Processor to process. For resident health data: Art. 6(1)(c) (CQC Regulation 17) and Art. 9(2)(h) (provision of health or social care).

4.2 Instructions

The Controller instructs the Processor to process Personal Data only as necessary to provide the Services. Additional written instructions may be given; processing outside this DPA’s scope may be charged at standard rates.

4.3 Controller Compliance

The Controller is responsible for its own UK GDPR obligations, including privacy notices, data subject requests, and maintaining its own record of processing activities.

4.4 Recognised Legitimate Interests

The Controller may instruct the Processor to support processing in reliance on a Recognised Legitimate Interest under UK GDPR Article 6(1)(ea), in particular for the safeguarding of vulnerable individuals (Annex 1 condition). Where the Controller relies on this basis, the Processor will give effect to the Controller’s documented instructions in accordance with Section 5 and will not require a Legitimate Interests Assessment from the Controller for such processing.

5.1 Documented Instructions Only

The Processor will process Personal Data only on documented Controller instructions, except where required by law (in which case the Processor will notify the Controller before processing unless prohibited).

5.2 Confidentiality

The Processor will ensure all persons authorised to process Personal Data are subject to appropriate confidentiality obligations.

5.3 Security

The Processor will implement and maintain appropriate technical and organisational measures as described in Schedule 2.

5.4 Sub-processors

The Controller grants general authorisation to engage the sub-processors listed in Schedule 3. The Processor will: (a) enter written agreements with sub-processors imposing equivalent obligations; (b) notify the Controller of proposed changes with 30 days’ notice; (c) remain fully liable for sub-processor acts and omissions.

5.5 Data Subject Rights

The Processor will assist the Controller in fulfilling UK GDPR Chapter III obligations. The Processor will forward data subject requests received directly to the Controller within 3 business days.

5.6 Deletion

On termination, and subject to any applicable legal-hold or statutory-retention obligation, the Processor will delete or irreversibly anonymise all Personal Data across the care-record, staff, and AI-assistant data stores, retaining tamper-evident audit metadata for its statutory period, and confirm in writing within 30 days.

5.7 Audit Rights

The Processor will make available information reasonably necessary to demonstrate compliance and permit audits by the Controller or appointed auditor on not less than 30 days’ written notice and at the Controller’s expense.

5.8 Automated Decision-Making

The Processor confirms that the Services do not make Significant Automated Decisions about Data Subjects. AI features (OCR, classification, risk scoring, copilot, governance flagging, PIR drafting, and operational-retrieval tools that surface staff personal data) generate suggestions that require meaningful human involvement by an Authorised User of the Controller before any record is finalised, any compliance status is set, any alert is treated as confirmed, or any regulatory submission is approved. The Processor maintains an audit record of human review for each such decision and will make this record available to the Controller on request.

The Processor will not introduce any feature that constitutes a Significant Automated Decision involving Special Category Data without the Controller’s prior written consent and a Data Protection Impact Assessment shared with the Controller.

5.9 Staff-Data Tool Surface — Purpose Limitation

Where the Services surface staff personal data through the Copilot (operational-retrieval tools covering shifts, training status, NMC revalidation status, and supervisions due), the Processor confirms that this surface exists solely to support: (i) operational visibility; and (ii) statutory compliance evidencing (CQC Regulations 18 and 19, NMC revalidation where applicable). The Processor warrants that this surface does notexist to evaluate individual employee performance, produce comparative staff rankings, inform disciplinary action, or feed automated decisions affecting an employee’s job. The Processor enforces this limitation at the code level via build-blocking safety evaluations and at the tool-contract level via a documented purpose declaration for every staff-data tool. Any future feature that crosses this boundary is out of scope and requires the Controller’s prior written consent and a Data Protection Impact Assessment shared with the Controller.

The Processor will notify the Controller without undue delay, and in any event within 24 hours of becoming aware, of any Security Incident. The notification will include:

• Nature of the incident and categories of data affected
• Approximate number of data subjects affected
• Data protection contact: privacy@care-meter.co.uk
• Likely consequences of the incident
• Measures taken or proposed

The Processor will not transfer Personal Data outside the UK except as set out in this Section and Schedule 3, or with the Controller’s prior written consent. All processing of care records by the AWS sub-processors takes place in the UK (London); care records are never transferred outside the UK. Stripe (subscription billing) and Resend (transactional email) process limited Personal Data outside the UK (Ireland/USA) under UK-approved IDTAs/SCCs, as set out in Schedule 3. Google Sign-In verifies identity via Google infrastructure under UK-approved SCCs.

This DPA takes effect on the date of acceptance and remains in force for as long as the Processor processes Personal Data under the Subscription Agreement.

Care-Meter may update this DPA. For material changes, at least 14 days’ notice will be given by email and via a prominent in-platform notice. Previous versions are available on request from privacy@care-meter.co.uk.

This Agreement and any dispute or claim arising out of or in connection with it (including non-contractual disputes) shall be governed by and construed in accordance with the laws of England and Wales.

The parties irrevocably agree that the courts of England and Wales shall have exclusive jurisdiction over any dispute or claim arising out of or in connection with this Agreement, save that nothing prevents either party from seeking emergency injunctive relief in any court of competent jurisdiction.

Access Control

• Role-based access control: Administrator, Manager, Carer, Family — least-privilege
• Multi-factor authentication (TOTP) enforced in-application for every Administrator, Manager, Registered Manager, Deputy Manager, Nominated Individual and Clinical Lead account, as a non-dismissible gate at sign-in. Where a user signs in through Google federation the second factor is delegated to their Google account. Identity-provider-level enforcement (Cognito MFA_REQUIRED) is scheduled once all active accounts have completed enrolment
• Authenticated sessions end automatically after 30 minutes without activity, and a new sign-in terminates any other active session for that account (single active session)
• All service-to-service calls are authenticated; no unauthenticated API endpoints except the signature-verified Stripe webhook, pre-authentication invite-token validation, and public marketing forms, which are rate-limited and expose no personal data
• Tenant scoping is applied to every read. For the most sensitive record types it is enforced server-side, derived from the verified orgId claim in the authenticated session rather than from any client-supplied parameter. The Processor is migrating the remaining record types onto the same server-side enforcement and does not represent that migration as complete; until it is, those reads are scoped by the application query layer, which a compromised authenticated client could in principle widen. No cross-tenant access path is exposed to an unauthenticated party, and the migration is tracked as a pre-live engineering commitment
• Staff access revoked immediately on departure

Encryption

• In transit: HTTPS/TLS 1.2+ for all data transfers
• At rest: cloud object storage and database storage encrypted at rest by default
• Customer-managed KMS keys, with automatic annual key rotation, on the evidence and audit-vault object stores that hold special-category material. The primary care-record database currently uses AWS-managed keys; moving it to a customer-managed key is a tracked pre-live commitment and is not represented as complete

Infrastructure Security

• All data storage and processing hosted in the UK (London); static assets delivered via CDN edge
• Infrastructure defined as code; all changes require peer review and automated approval checks before deployment
• Backend functions require authenticated invocation (Cognito/IAM), accept no public unauthenticated ingress, and communicate over TLS; rate limiting is applied to AI and assistant endpoints

Audit and Logging

• Tamper-evident audit record for all governance-critical actions, with write-protection on storage
• Application logs: metadata only, no Personal Data in application logs

Incident Response

• Documented Incident Response Plan: detection, containment, notification, post-incident review
• ICO notification within 72 hours; Controller notification within 24 hours of becoming aware

AI-Specific Safeguards

• Meaningful human involvement required for every AI output (clause 5.8) — no AI suggestion is recorded as confirmed, used to trigger an alert, or referenced in a regulatory submission without explicit human review by an Authorised User
• Staff-performance prohibition (clause 5.9) enforced by merge-blocking automated tests over the AI tool registry and its purpose declarations, which run on every change and fail the build on regression, supplemented by a scheduled evaluation suite that exercises the prohibition end-to-end against a deployed environment and fails on regression
• Aggregate-cohort minimum for operational and analytical aggregate queries: a hard minimum cohort size (default of five subjects) is enforced to defeat deanonymising filter combinations. The guard is verified by a continuous-integration test that asserts the threshold cannot be bypassed by tool-call construction
• No vector or semantic retrieval tier exists. Care-evidence retrieval uses a deterministic ontology-tag projection; operational retrieval uses structured queries against the Personal Data store. This bounds the surface area for model hallucination
• No training on Customer Data. The Processor does not use Customer Data, in identifiable, pseudonymised, or anonymised form, to train third-party AI or machine-learning models. AWS Bedrock terms commit Anthropic and Amazon Nova to the same; the Processor verifies these terms annually
• Manager-correction audit trail: every human override of an AI suggestion is captured as a structured record that cannot be altered after creation, providing both an evidentiary trail and a feedback loop into the evaluation corpus

Organisational Measures

• All staff and contractors subject to confidentiality obligations
• Annual data security awareness training for all personnel with production access
• Master Care-Meter Data Protection Impact Assessment maintained and reviewed annually; sibling DPIAs maintained per processing surface and reviewed on the same cadence

Region commitment.All processing by the AWS sub-processors above takes place in the UK (London), and no care-record content is processed outside the UK by any sub-processor. Stripe (subscription billing) and Resend (transactional email) process limited Personal Data outside the UK (Ireland/USA) under UK-approved IDTAs/SCCs, as set out in the table above and in Section 7. Google Sign-In verifies the identity of users who choose it via Google infrastructure under UK-approved SCCs. The Processor will not invoke a sub-processor in any other region without first updating this Schedule and giving the Controller 30 days’ notice.

Retired sub-processor (v1.1 → v1.2). Amazon OpenSearch Service is no longer engaged as a sub-processor. The legacy vector-search retrieval path it supported has been retired in favour of a deterministic ontology-tag projection and structured queries against the Personal Data store. No customer data remains in OpenSearch.

Added sub-processors (v1.2 → v1.3, June 2026).Stripe Payments Europe Ltd (payment processing / subscription billing) and Resend (transactional email delivery) are newly listed. Both transfer personal data to the USA under UK-approved International Data Transfer Agreements (IDTAs). Existing Controllers were sent an Article 28 advance notice with 30 days’ right to object; new Controllers receive general authorisation for these sub-processors at the point of accepting this DPA.

Care-Meter will notify the Controller of any proposed addition to or replacement of sub-processors with 30 days’ notice. The Controller may object on reasonable grounds within that period.