Data processing terms.

Last updated: 8 August 2026

1. Definitions
2. Relationship of the parties
3. Description of processing
4. Customer obligations and warranties
5. Processing on instructions
6. Confidentiality of personnel
7. Security of processing
8. Sub-processors
9. International transfers
10. Data subject rights
11. DPIAs and prior consultation
12. Personal data breach notification
13. Audits and information
14. Records of processing
15. Deletion and return of data
16. Liability and indemnity
17. Term and survival
18. Changes to these terms
19. Contact
20. Annex 1, Description of processing by module
21. Annex 2, Technical and organisational measures
22. Annex 3, Sub-processor change procedure
23. Annex 4, Transfer mechanisms and risk assessment
24. Annex 5, Request, breach and deletion timetables
25. Procurement FAQ

In these terms, “UK GDPR”, “Data Protection Act 2018”, “controller”, “processor”, “data subject”, “personal data”, “special category data”, “processing” and “personal data breach” have the meanings given in applicable UK data protection law. “Customer Data” means personal data submitted to, or generated within, the Thornbridge platform by or on behalf of the customer. “Sub-processor” means a third party engaged by us to process Customer Data on our behalf. “Main Agreement” means the order form, subscription agreement or terms of service governing your use of the platform, to which these terms are incorporated by reference wherever we process Customer Data as a processor.

As between the parties, the customer is the controller of Customer Data and Thornbridge is the processor. Thornbridge processes Customer Data solely for the purpose of providing the platform and related support under the Main Agreement, and does not determine the purposes or means of that processing except as expressly agreed. For our own administrative, billing and product-analytics data collected independently of the platform, we act as controller, as described in our privacy policy.

Subject matter

Provision of workforce compliance, care management and sponsorship oversight software, including hosting, storage, support and related processing of Customer Data necessary to operate the platform.

Duration

For the term of the Main Agreement, plus any agreed retention period and the export window described in clause 15.

Nature and purpose

Collection, storage, organisation, retrieval, use, disclosure to authorised users, backup and deletion of Customer Data, carried out by automated means through the platform and, where you raise a support request, by our personnel for the purpose of diagnosing and resolving that request.

Categories of data subjects

• Your employees, workers and contractors
• Job applicants and prospective workers
• Where the relevant module is used, individuals receiving care or support services
• Sponsored workers and their dependants, where sponsorship management features are used
• Your administrators and authorised users of the platform

Categories of personal data

Identity and contact details; employment, right-to-work and sponsorship records; training, qualification and compliance evidence; rota, attendance and case-management notes; and, where the relevant module is enabled, special category data such as health information relevant to safeguarding or care needs, and information about criminal convictions checks undertaken as part of safeguarding or vetting obligations. You are responsible for configuring which modules are used and for ensuring an appropriate Article 9 condition and Schedule 1 basis is in place before any special category data is entered.

You warrant that you have, and will maintain, a lawful basis for collecting and disclosing Customer Data to us, that you have provided all necessary privacy notices to data subjects, and that your instructions to us comply with applicable data protection law. You are solely responsible for the accuracy of Customer Data, for determining which modules and data fields are appropriate for your use case, and for any special category data condition required under Article 9 and Schedule 1 of the Data Protection Act 2018. You must promptly notify us of any change to your instructions and of any restriction, correction or objection notified to you by a data subject that affects our processing.

We will process Customer Data only on your documented instructions, including as set out in the Main Agreement, the platform configuration you control, and any further written instructions you give, unless required to do otherwise by UK law. If we consider that an instruction infringes UK GDPR, the Data Protection Act 2018 or other applicable data protection law, we will inform you without undue delay and may suspend performance of that instruction pending your written confirmation or amendment of it.

We ensure that personnel authorised to process Customer Data are subject to a binding duty of confidentiality, whether contractual or statutory, and receive data protection and information security training appropriate to their role before being granted access, and periodically thereafter. Access is limited to personnel who need it to perform the services.

We implement technical and organisational measures appropriate to the risk, in line with Article 32 UK GDPR, including:

• Encryption, encryption of Customer Data in transit using TLS, and encryption at rest for stored data and backups.
• Access control, role-based access control, least-privilege provisioning, unique credentials, and periodic access reviews.
• Authentication, multi-factor authentication for administrative and privileged access, and support for customer-side MFA enforcement.
• Audit logging, tamper-evident logging of access to and changes made within the platform, retained for a defined period to support investigation.
• Backups and resilience regular automated backups, with periodic restoration testing to confirm recoverability.
• Segregation, logical separation of customer environments and data to prevent cross-tenant access.
• Secure development code review, staged release processes, and security consideration at the design stage of new features.
• Vulnerability management routine scanning, patching of dependencies and infrastructure, and a process for triaging reported issues.
• Monitoring, continuous monitoring for anomalous activity and infrastructure health, with alerting to on-call personnel.
• Business continuity and disaster recovery documented recovery procedures with target recovery point and recovery time objectives, reviewed periodically and tested.

Further detail on our approach to security is set out on our security page.

You provide general authorisation for us to engage sub-processors to support delivery of the platform, subject to imposing data protection obligations on them no less protective than those in these terms. We give at least 30 days’ notice before adding or replacing a sub-processor whose processing materially changes the nature of Customer Data handled, and you may object on reasonable data protection grounds within that notice period, in which case we will work with you in good faith to find an alternative or, failing that, you may terminate the affected service. We remain liable for the acts and omissions of our sub-processors to the same extent we would be liable if performing their services directly. The categories of sub-processor we currently engage are:

Customer Data is hosted primarily in the United Kingdom. Where a sub-processor operates, or Customer Data is otherwise accessed, from outside the UK, we rely on UK adequacy regulations where available or, where not, the International Data Transfer Addendum to the EU Standard Contractual Clauses (or the UK International Data Transfer Agreement) supported by a transfer risk assessment addressing the destination country’s laws and practices. Sub-processors are not permitted to make further onward transfers except on equivalent contractual terms and subject to the same transfer safeguards.

Taking into account the nature of the processing, we provide reasonable technical and organisational assistance to help you respond to requests from data subjects exercising their rights under UK GDPR, including through platform features that allow you to access, export, correct and delete Customer Data directly. If we receive a request directly from a data subject that clearly relates to Customer Data, we will not respond to it substantively, and will instead notify you without undue delay and direct the requester to you, unless we are legally required to respond ourselves.

We provide reasonable assistance, including information about our processing and security measures, to help you carry out data protection impact assessments and, where required, consult with the Information Commissioner’s Office in advance of processing that presents a high risk in the absence of mitigating measures.

We notify you without undue delay, and in any event within 72 hours of becoming aware, of any personal data breach affecting Customer Data. Our notification includes, so far as then known, the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed to address it and mitigate adverse effects, with further information provided as it becomes available. You remain responsible for assessing whether the breach is notifiable to the Information Commissioner’s Office within your own 72-hour statutory deadline and, where required, to affected data subjects.

We make available information reasonably necessary to demonstrate compliance with this clause and Article 28 UK GDPR, and permit and contribute to audits, including inspections, conducted by you or an auditor you mandate. Audits may be carried out no more than once in any 12-month period, save where required following a personal data breach or by a supervisory authority, on reasonable prior written notice, during business hours, at your cost, and subject to reasonable confidentiality restrictions and steps to avoid disruption to our other customers.

We maintain a record of processing activities carried out on your behalf as required by Article 30(2) UK GDPR, and will make a summary available to you on reasonable written request.

On termination or expiry of the Main Agreement, you may export Customer Data for a period specified in the Main Agreement (or, if none is specified, 30 days) following termination. After that export window, we delete Customer Data from live systems within a reasonable period, and it is thereafter removed from backups in the ordinary course of our backup rotation cycle, save where retention is required by law.

Liability arising under these terms forms part of, and is subject to any limitations and exclusions of liability set out in, the Main Agreement and our terms of service. Nothing in these terms limits liability that cannot lawfully be limited under applicable data protection law.

These terms apply for as long as we process Customer Data on your behalf. Clauses relating to confidentiality, security, deletion, audit records and liability survive termination of the Main Agreement to the extent necessary to give them effect.

We may update these terms to reflect changes in the platform, our sub-processors, or applicable data protection law. Material changes affecting your rights will be notified in advance by reasonable means. These terms should be read alongside our privacy policy, security page, terms of service, acceptable use policy and cookie policy.

For data protection enquiries, including requests for a signed counterpart DPA, email dpa@thornbridgesolutions.com.

This annex expands clause 3 and is intended to be reproduced in your own record of processing activities under Article 30. Where a module is not enabled in your tenant, the corresponding processing does not take place. Your administrators control module activation, field configuration and retention settings, and can evidence those settings from the console at any time.

1.1 Enquiries and pipeline module

Personal data comprises the identity and business contact details of individuals who contact you or whom your team records as prospects: name, work email address, telephone number, organisation, job title, the free-text content of their enquiry, correspondence exchanged through the platform, and metadata such as the time of submission and the page from which the enquiry originated. Data subjects are prospective customers and their staff. Processing is continuous for the life of the record and its purpose is contact management, response tracking and service-level measurement. Special category data is not expected in this module and should not be entered into it.

1.2 Workforce compliance module

Personal data comprises employment records for your workers: identity details, dates of birth where required for identity verification, national insurance numbers where you choose to record them, right-to-work documentation and expiry dates, immigration and sponsorship status, training and qualification certificates and their renewal dates, supervision and appraisal records, disciplinary and grievance records, absence records, and the outcome of pre-employment checks. Data subjects are your employees, workers, agency staff, contractors and job applicants. Special category data may be present where a record discloses health information relevant to fitness to work or a reasonable adjustment. Criminal offence data may be present where you record the outcome of a criminal records check undertaken as part of a statutory vetting obligation. Processing is continuous and the purpose is demonstrating regulatory compliance and safe staffing.

1.3 Care records module

Personal data comprises information about individuals receiving care or support: identity and contact details, next of kin and emergency contacts, care and support plans, risk assessments, daily notes, incident and safeguarding records, medication administration records where enabled, and correspondence with professionals involved in a person’s care. Data subjects are people receiving services, their representatives and named professional contacts. This module routinely involves special category data concerning health and may involve data revealing racial or ethnic origin, religious beliefs or sexual orientation where those are recorded as part of a person’s care needs and preferences. Processing is continuous and its purpose is the delivery, coordination and evidencing of care.

1.4 Audit, access and administration

Personal data comprises the identity of authorised users, their assigned roles, authentication events including successful and failed sign-in attempts, multi-factor enrolment status, IP addresses and user-agent strings associated with those events, and an append-only record of the actions each user takes within the platform, including the records viewed, created, amended and deleted. Data subjects are your administrators and authorised users. Processing is continuous, is necessary for the security and integrity of the service, and its purpose is accountability, investigation and the detection of misuse. Retention follows the audit retention period configured by your administrators.

1.5 Support processing

When your team raises a support request, our personnel may access Customer Data to the minimum extent necessary to reproduce and resolve the issue. Such access is time-limited, logged, and performed under the confidentiality obligations described in clause 6. Where a defect can be diagnosed from anonymised or synthetic data, we will use that in preference to production records. Support access is occasional rather than continuous.

The measures below expand clause 7 and are organised under the headings of Article 32 UK GDPR. They describe the measures in place at the date of these terms; we may replace a measure with an equivalent or stronger one, but will not materially reduce the overall level of protection during the term of the Main Agreement.

2.1 Pseudonymisation and encryption

• All traffic between clients and the platform is encrypted using industry-standard TLS, with insecure protocol versions and cipher suites disabled.
• Customer Data at rest, including database volumes, uploaded files and automated backups, is encrypted using industry-standard algorithms with keys managed by the hosting provider’s key management service.
• Authentication secrets are never stored in reversible form; passwords are hashed with a modern memory-hard algorithm and multi-factor recovery codes are stored only as hashes.
• Where operational telemetry is required, identifiers are pseudonymised or truncated so that diagnostic data does not carry more personal data than the diagnosis requires.

2.2 Confidentiality

• Row-level security is applied in the database so that a request can only return records belonging to the requesting tenant and role, independently of application logic.
• Role-based access control maps each named user to a defined permission set, with privileged operations gated behind explicit permissions rather than implicit seniority.
• Destructive administrative actions require a second authorised approver before they take effect, and both identities are recorded.
• Administrative access to production infrastructure is restricted to a small number of named personnel, requires multi-factor authentication, and is reviewed periodically.
• Personnel are subject to written confidentiality obligations that survive the end of their engagement.

2.3 Integrity

• The audit log is append-only and chained, so that each entry incorporates a cryptographic digest of its predecessor and any retrospective alteration or deletion becomes detectable.
• Chain verification runs on a schedule and raises an alert if a discrepancy is found.
• Input is validated on the server as well as in the browser, and database constraints enforce referential integrity.
• Content changes to published material are versioned, with the previous version retained so that a change can be inspected and rolled back.

2.4 Availability and resilience

• The platform runs on managed, redundant infrastructure with automated failover at the hosting layer.
• Automated backups are taken on a continuous or daily basis depending on the data store, and retained for a defined window that supports point-in-time recovery.
• Our recovery point objective is measured in minutes for transactional data and our recovery time objective is measured in hours for a full service restoration; these are internal targets rather than contractual service levels, which are set out in the Main Agreement.
• Restoration is tested periodically against a non-production environment, and the outcome of each test is recorded.

2.5 Regular testing and evaluation

• Automated security checks run against every change before it reaches production, and a change that introduces a known sensitive finding is blocked.
• Dependencies are scanned for published vulnerabilities and patched according to severity.
• Configuration of database policies and privileges is checked automatically, so that a table without an appropriate access policy is surfaced rather than silently deployed.
• The effectiveness of these measures is reviewed at least annually and after any material change to the platform.

2.6 Access governance and the joiner, mover, leaver lifecycle

• Access is granted on a least-privilege basis against a named individual; shared or generic accounts are not permitted.
• Invitations are time-limited, single-use and tied to the intended email address.
• Role changes are recorded in the audit log with the previous and new role, and the identity of the person making the change.
• Access reviews prompt administrators to recertify each account periodically, and unreviewed accounts are highlighted.
• On departure, access is revoked and active sessions can be terminated immediately, including remotely from another session.

2.7 Secure development and change management

• Changes are peer-reviewed and pass automated tests before release.
• Production credentials are never held in source control; secrets are injected at runtime from a managed store.
• Releases are staged, and a change that affects data handling is assessed for data protection impact before it ships.
• Emergency fixes follow the same review path retrospectively and are recorded.

2.8 Logging, monitoring and incident response

• Authentication events, permission changes, record access and administrative actions are logged with an actor, a timestamp and, where relevant, a before-and-after view of the change.
• Anomalous patterns, such as repeated failed sign-ins or unusual bulk export activity, generate alerts to named recipients.
• A documented incident response procedure defines triage, containment, notification and post-incident review, and is exercised periodically.

2.9 Physical security and supplier management

• Physical security of data centres is the responsibility of our hosting sub-processors, whose facilities operate access control, monitoring and environmental protection appropriate to the service.
• Sub-processors are assessed before engagement against their security posture, data location and contractual data protection terms, and reassessed when their role materially changes.
• Personnel with access to Customer Data are subject to identity and right-to-work verification and receive role-appropriate training.
• Media and storage are disposed of by the relevant infrastructure provider using secure deletion or destruction; we do not hold Customer Data on removable media.

The list in clause 8 describes the functional categories of sub-processor we engage. Where you require the named entities, the current list is available on request under the confidentiality terms of the Main Agreement, and we will supply an updated copy whenever it changes.

1. We assess a proposed sub-processor against its security measures, the location of processing, the transfer mechanism required, and whether the engagement can be structured to minimise the personal data disclosed.
2. We notify your nominated data protection contact at least 30 days before the sub-processor begins processing Customer Data, describing the function, the data involved and the safeguards applied.
3. You may object in writing within the notice period on reasonable data protection grounds, setting out the concern.
4. We will work with you in good faith for a further 30 days to address the objection, whether by an alternative supplier, a configuration change that removes the data from scope, or additional contractual safeguards.
5. If the objection cannot be resolved, you may terminate the affected part of the service without penalty and receive a pro-rata refund of prepaid fees for the terminated portion.
6. Where a change is urgent and necessary to maintain security or availability, we may implement it sooner and notify you promptly, explaining why the standard notice period could not be observed.

Customer Data is hosted in the United Kingdom by default. The transfers described here are limited, and are principally driven by email delivery and support tooling rather than by the primary data store.

4.1 Mechanisms relied on

• Where the destination benefits from UK adequacy regulations, we rely on adequacy.
• Otherwise we rely on the UK International Data Transfer Agreement, or the EU Standard Contractual Clauses as supplemented by the UK Addendum, entered into with the importer.
• Each restricted transfer is supported by a transfer risk assessment that we review periodically and after any material change in the destination country’s laws or in the importer’s circumstances.

4.2 Summary of the assessment approach

The assessment considers the categories and volume of personal data transferred, the sensitivity of that data, the format in which it is transferred, the importer’s technical measures including encryption and access control, the legal regime of the destination including any government access powers and available redress, the practical likelihood of such access given the nature of the importer’s business, and any supplementary measures required to bring the transfer to an acceptable level of risk. Where supplementary measures cannot reduce the risk sufficiently, the transfer does not proceed. Copies of the assessments are available to customers on request under confidentiality.

4.3 Onward transfers

Sub-processors are contractually prohibited from making onward transfers except on terms materially equivalent to those in this annex, and must notify us before doing so. Government or law enforcement requests for Customer Data must be referred to us unless legally prohibited, and we will challenge requests that appear unlawful or disproportionate and notify you unless we are prevented from doing so by law.

5.1 Data subject request workflow

1. A request received by us that plainly relates to your Customer Data is acknowledged and forwarded to your nominated contact, normally within two working days, and we do not respond substantively to the data subject.
2. You verify the identity of the requester and determine whether the request is valid, manifestly unfounded or excessive.
3. You use the platform’s search, export and rectification features to locate and compile the data. Where those features are insufficient, you may ask us for assistance and we will provide it without charge for a reasonable volume of requests.
4. You respond within one calendar month of receipt, extendable by two further months for complex or numerous requests, provided you inform the data subject of the extension within the first month.
5. Where erasure or restriction is applied, the platform records the action in the audit log so the decision can be evidenced later.

5.2 Breach notification content

Where we become aware of a personal data breach affecting Customer Data, we notify your nominated contact without undue delay and, so far as the information is available at the time, include: the nature of the breach; the categories and approximate number of data subjects and records concerned; the likely consequences; the measures taken or proposed to address the breach and mitigate its effects; and a named contact for further information. Where the full picture is not yet available, we provide information in phases rather than delaying the initial notification. We do not notify the Information Commissioner or data subjects on your behalf unless you instruct us to do so in writing.

5.3 Illustrative timeline

5.4 Deletion, return and backup expiry

Where data remains in a backup pending expiry, it is not restored to live systems and remains subject to the security measures in Annex 2 until it is overwritten.

Will you sign our own DPA?

Yes. We will review a customer paper and, where its substance matches these terms, sign it. Where a clause conflicts with how the platform actually works, we will say so and propose alternative wording rather than accept an obligation we cannot meet.

Where is our data stored?

Primary storage, including the database and uploaded files, is in the United Kingdom. The exceptions are described in clause 9 and Annex 4.

Can we restrict support access to our tenant?

Yes. Support access can be limited so that it requires an administrator to grant a time-limited window, and every access is recorded in your audit log whether or not that restriction is enabled.

Do you use Customer Data to train AI models?

No. Customer Data is not used to train, fine-tune or improve any general-purpose model, and is not disclosed to a model provider for that purpose.

What happens if we dispute a sub-processor?

The objection procedure in Annex 3 applies, including the right to terminate the affected service without penalty if the objection cannot be resolved.

Can we audit you?

Yes, on the terms in clause 13. In most cases a documented response to your security questionnaire, together with the evidence available from your own console, satisfies the requirement without an on-site visit.