1. Parties
This agreement is between:
- The Customer, the organisation named on the order form, acting as Controller; and
- RB Stackworks Ltd, a company registered in England and Wales (company number 17485375, registered office Suite RA01, 195-197 Wood Street, London, E17 3NU), acting as Processor ("Care360", "we", "us").
2. Definitions
Data Protection Law means the UK GDPR, the Data Protection Act 2018, and any other data protection law applying in the United Kingdom, as amended.
Controller, Processor, Data Subject, Personal Data, Special Category Data, Processing and Personal Data Breach have the meanings given in the UK GDPR.
Customer Personal Data means personal data we process on the Customer's behalf under the Terms of Service, as described in Schedule 1.
Sub processor means any processor we engage to process Customer Personal Data.
3. Roles and scope
The Customer is the Controller of Customer Personal Data and we are the Processor. The Customer determines the purposes and means of processing; we act only as set out in this agreement.
The Customer confirms that it has a lawful basis under Article 6 and, for Special Category Data such as health and care information, a condition under Article 9, and that it has given any privacy information its Data Subjects are entitled to. We do not determine those matters and cannot do so on the Customer's behalf.
4. Our instructions
We process Customer Personal Data only on the Customer's documented instructions, which are: the Terms of Service, this agreement, the configuration the Customer chooses in the application, and any further written instruction the Customer gives us.
We will tell the Customer if, in our opinion, an instruction infringes Data Protection Law. We may refuse to act on an instruction that would put us in breach.
Where we are required by law to process Customer Personal Data other than on instruction, we will tell the Customer before doing so unless the law prohibits it.
We will not sell Customer Personal Data, use it for our own marketing, or use it to train machine learning models.
5. Confidentiality
We ensure that every person authorised to process Customer Personal Data is bound by a duty of confidentiality, whether by contract of employment or by a written confidentiality undertaking, and that the duty survives the end of their engagement.
Access is limited to those who need it to provide or support the service, and is removed when it is no longer needed.
6. Security
We implement appropriate technical and organisational measures under Article 32, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing, as well as the risk to Data Subjects. Those measures are set out in Schedule 2.
Because Customer Personal Data includes Special Category Data, we treat the risk profile as high and the measures in Schedule 2 reflect that.
7. Sub processors
The Customer gives general authorisation for us to engage sub processors. The current list is in Schedule 3.
Before adding or replacing a sub processor we will give the Customer at least 30 days written notice. The Customer may object on reasonable data protection grounds within that period. If we cannot resolve the objection, the Customer may terminate the affected part of the service without penalty and receive a pro rata refund of prepaid fees.
We impose on every sub processor written obligations that are no less protective than those in this agreement, and we remain fully liable to the Customer for the performance of each sub processor.
Apple is the one exception to the written obligations. It provides the Apple Push Notification service to every app developer on its own standard terms, which we cannot vary, and those terms include no data processing terms for that service. Schedule 3 and clause 11 set out what Apple receives and what its terms say.
8. Assisting with Data Subject rights
The application lets the Customer read, export and correct records directly, which will usually be enough to answer a Data Subject request without our involvement.
Where it is not, we will assist the Customer by appropriate technical and organisational measures, so far as is possible, in responding to requests to exercise rights of access, rectification, erasure, restriction, portability and objection.
If a Data Subject contacts us directly about Customer Personal Data, we will not respond substantively. We will refer them to the Customer and tell the Customer promptly.
The one standing instruction: when a member of the Customer's staff asks for their own account to be deleted (in the application, through "Delete my account", or by email), we pass the request to the Customer and, once the Customer has acted, confirm that to the person, normally within one month.
Note on erasure. Care records in the application are immutable by design, which is what makes them credible evidence. Erasing an entry is therefore not a routine operation and may conflict with the Customer's own retention duties under the Records Management Code of Practice and CQC Regulation 17. We will act on a written instruction to erase, but the Customer decides whether erasure is lawful and appropriate.
9. Personal Data Breach
We will notify the Customer without undue delay, and in any event within 24 hours of becoming aware of a Personal Data Breach affecting Customer Personal Data.
The notification will include, so far as we know it at the time: the nature of the breach, the categories and approximate number of Data Subjects and records affected, the likely consequences, the measures taken or proposed, and a point of contact. We will provide further information as it becomes available rather than delaying the first notification until everything is known.
We will assist the Customer in meeting its own obligations to report to the Information Commissioner's Office within 72 hours and, where the risk is high, to inform affected Data Subjects. The decision whether to report is the Customer's, as Controller.
10. Data protection impact assessments
We will provide reasonable assistance with any data protection impact assessment or prior consultation with the Information Commissioner's Office that relates to our processing, taking into account the information available to us. This includes completing security and information governance questionnaires, including those needed for the Data Security and Protection Toolkit.
11. International transfers
Customer Personal Data is stored in the United Kingdom. See Schedule 3 for the location of each sub processor.
Two categories of processing take place in the European Economic Area. Transactional email is delivered through infrastructure in Ireland. This carries the recipient's email address and the message content, such as a sign in code or a support request. We put no care records in the emails we send, but a support request carries whatever the person raising it writes or attaches. The email provider keeps a delivery log for a limited period. Our platform service is hosted in Ireland. It passes the Customer's support requests and staff welcome emails to the email provider without storing them. The EEA is designated as adequate by the UK government, so no additional transfer safeguard is required.
Push notifications to the Android, iPhone and iPad apps are delivered through Google's network, which can include the United States. This carries each device's push address, the notification text, which can include a shift's type, time and house name, and a reference to the shift it is about. No care records are sent in notifications. Google LLC is certified under the UK Extension to the EU-US Data Privacy Framework (the UK-US data bridge), which the UK government has recognised as providing adequate protection for transfers to certified US organisations, so no additional transfer safeguard is required.
For the iPhone and iPad apps, Google passes each notification to the Apple Push Notification service, which runs on Apple's global network and can include the United States. It carries the address Apple issued for the device, the notification text and a reference to the shift it is about. Apple Inc. is not certified under the Data Privacy Framework, and Apple's terms for the service contain no transfer clauses. Under those terms Apple will not access or disclose the content of a notification unless it believes that is reasonably necessary to comply with the law, enforce its terms, address security, fraud or technical issues, or protect rights, property or safety. Apple's privacy policy states that its international transfers of personal data collected in the United Kingdom are governed by Standard Contractual Clauses.
Apart from the Apple Push Notification service described above, we will not transfer Customer Personal Data to a country without UK adequacy unless we put in place the UK International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses, together with a transfer risk assessment, and we will tell the Customer before doing so.
12. Deletion and return
On termination, at the Customer's choice, we will delete or return all Customer Personal Data.
The Customer may request a full export within 30 days of termination, and we will provide it in a commonly used, readable format within 30 days of the request. After that period we will delete Customer Personal Data from live systems within 30 days, and from backups within 90 days as backups expire on their normal cycle.
We will confirm deletion in writing on request. We may retain data where UK law requires it, in which case we will keep it only for as long as required and continue to protect it under this agreement.
13. Audit
We will make available to the Customer all information reasonably necessary to demonstrate compliance with Article 28, and will allow for and contribute to audits, including inspections, conducted by the Customer or an auditor it appoints.
In practice we expect this to be satisfied by written responses to security questionnaires and by the documentation we make available. An on site audit may be carried out no more than once in any twelve month period, on 30 days written notice, during business hours, subject to confidentiality, and without unreasonably disrupting our operations. The Customer may audit more frequently following a Personal Data Breach affecting its data, or where a regulator requires it.
14. Liability and general
Each party's liability under this agreement is subject to the limitations and exclusions in the Terms of Service.
This agreement is governed by the law of England and Wales, and the courts of England and Wales have exclusive jurisdiction. Where this agreement and the Terms of Service conflict on the processing of personal data, this agreement prevails.
If any provision is found unenforceable, the rest continues to apply.
Schedule 1. Details of the processing
| Item | Detail |
|---|---|
| Subject matter | Provision of the Care360 care management application, accessed through the web at the Customer's provider-specific address under care360.cloud, and through the Care360.Cloud apps for iPhone, iPad and Android |
| Duration | The term of the subscription, plus the deletion and return period in clause 12 |
| Nature and purpose | Hosting, storage, retrieval, structuring and display of care and staff records so the Customer can record care, manage medicines, run rotas, manage resident finances, and produce records for audit and inspection |
| Categories of Data Subject | People receiving care from the Customer; the Customer's staff; in some records, named relatives, advocates and visiting professionals |
| Types of Personal Data | Names, dates of birth, photographs, contact details, house or location assignment; care and support records across twelve categories; medication records including prescriptions, administration, refusals and controlled drugs; incident records including body maps; resident financial records and receipt images; staff names, work contact details, roles, shifts, clock in and clock out times and pay related information; documents such as care plans and policies, records of who viewed or downloaded them, and read confirmations with a drawn signature, each with a description of the device and browser used (user agent); support requests raised from the application, including any text and screenshot the person adds; for staff who allow notifications in the iPhone, iPad or Android app, an identifier the app creates for their device and a push address for it |
| Special Category Data | Yes. Health data, including physical and mental health, medication and clinical observations, and free text, such as dietary requirements, that can reveal religious or philosophical beliefs. Processed on the Customer's instruction under the Customer's Article 9 condition. |
| Criminal offence data | Not intended. The Customer should not use free text fields to record criminal offence data unless it has a lawful basis under section 10 of the Data Protection Act 2018. |
| Frequency | Continuous, for the duration of the subscription |
Schedule 2. Technical and organisational measures
These are the measures in place at the date of this agreement. We may change them, provided the level of protection is not reduced.
Access control
- Authorisation is enforced in the database, not only in the interface. Row level security is enabled on every table in the schema, so a request that should not return a record does not return it regardless of how it is made.
- Access is assignment based. A support worker is granted specific houses or individuals and can see only those. Managers see the service.
- Passwordless authentication for staff. Staff sign in with a one time code sent to their named work email address. Customer staff accounts are created without a password, so there is none to share, reuse or leak. The only accounts with a password are in our own demonstration environment, such as the account we give app store reviewers.
- Web sessions do not persist. On the website the session is held in browser session storage, does not survive the browser closing, and ends after an hour without activity. In the iPhone, iPad and Android apps the session is kept on the device so that staff are not sent a new code at every launch, and the app locks behind a PIN each time it starts and after 20 minutes without use.
- Staff accounts can be revoked without deletion, so access ends immediately while historical records remain attributable, which the Customer needs for its audit trail.
- Server side documents. Printed and exported medicines documents are generated on the server with the permission check applied there, and the document layout is not shipped to the browser. Server functions run as the calling user, never with a privileged key, so row level security remains the inner check.
Integrity of records
- Submitted records are immutable, enforced by database triggers rather than by convention. They cannot be edited or deleted through the application by anyone, including administrators.
- Corrections are additive. A medicines entry is corrected by voiding it with a written reason; the original stays visible alongside its replacement.
- Every record is attributed and carries four timestamps: when the event happened, when it was first entered, when it was submitted and frozen, and whether it was recorded late.
- Back dating is capped at 30 days and must fall inside a shift the worker actually worked.
Storage and transmission
- Encryption in transit using TLS for all connections to the application and between the application and its data stores.
- Encryption at rest for the database and file storage, provided by our hosting sub processor.
- Photographs and receipts are held in private storage, not publicly addressable, and are retrieved through short lived signed links. File uploads are restricted by content type and size.
- Backups are taken by our hosting sub processor and are subject to the same access controls and encryption.
Organisational
- Access to production data is limited to personnel who need it, under confidentiality obligations.
- Changes to the database schema are applied through reviewed, sequential migrations rather than ad hoc edits.
- Security defects found in review are fixed and shipped with a test that would catch a regression.
- Sub processors are assessed before engagement and bound by written terms no less protective than these, except Apple, whose standard terms are described in clause 7 and clause 11.
Stated plainly, because a reviewer will ask. There is no multi factor authentication beyond the one time sign in code itself, and none for the password accounts in our own demonstration environment. The application has no offline mode; it requires a live connection. Our Content Security Policy is currently deployed in report only mode rather than enforcing. We would rather set these out here than have them discovered during an assessment.
Schedule 3. Sub processors
| Sub processor | Purpose | Location |
|---|---|---|
| Supabase | Database and file storage for the application. Holds care records. Also hosts our platform service, which holds the directory of organisations (each organisation's name, code, web address and access token) and passes support requests and staff welcome emails to Resend without storing them. | United Kingdom (London) for the application and care records; Ireland (EEA) for the platform service |
| Vercel | Application and website hosting, and serverless functions | United Kingdom (London) origin, global edge network |
| Resend (delivering via Amazon Web Services) | Transactional email: sign in codes, welcome emails, service notifications and support requests. Carries email addresses and message content. We put no care records in these emails; a support request carries whatever the person raising it writes or attaches. | Ireland (EEA) |
| Google (Firebase Cloud Messaging) | Delivers push notifications to the Android, iPhone and iPad apps (to iPhones and iPads through Apple, below): rota changes and shift reminders. Carries each device's push address, the notification text (shift type, time and house name) and a reference to the shift, not care records. Its component in the apps also sends Google an identifier for the app's installation and device details (such as model, language, time zone and system version). | Google's global network, which can include the United States (Google LLC is certified under the UK Extension to the EU-US Data Privacy Framework) |
| Apple (Apple Push Notification service) | Delivers push notifications to the iPhone and iPad apps, passed on from Firebase Cloud Messaging: rota changes and shift reminders. Carries the address Apple issued for the device, the notification text (shift type, time and house name) and a reference to the shift, not care records. Provided on Apple's standard developer terms (clause 7). | Apple's global network, which can include the United States (Apple Inc. is not certified under the EU-US Data Privacy Framework; see clause 11) |
| Microsoft 365 | Our business mailboxes. Processes Customer Personal Data only where the Customer includes it in correspondence with us, for example a support request. | United Kingdom |
Signature
Where a signed copy is required, this agreement is executed by the authorised representatives of each party. Otherwise it takes effect on the start date of the subscription, without signature, as part of the Terms of Service.
| The Customer | RB Stackworks Ltd | |
|---|---|---|
| Signature | | |
| Name | ||
| Position | ||
| Date |
Questions from your compliance lead?
We will answer information governance questions as readily as product ones, and complete your security questionnaires including the Data Security and Protection Toolkit.
Book a demo