Legal

Acceptable use policy.

Thornbridge platforms hold records that affect people's safety, employment and care. This policy sets the minimum standards every user must meet, and forms part of our terms of service.

Last updated: 8 August 2026

Contents

1. Purpose and scope

This Acceptable Use Policy (“AUP”) exists to protect the people whose information sits inside Thornbridge platforms, care recipients, employees, contractors and members of the public, and to keep our services available, secure and trustworthy for everyone who relies on them. It sets out the minimum standards of behaviour we require from anyone who accesses or interacts with our software, infrastructure, APIs or support channels.

This policy applies to every environment we operate, including production tenants, staging and sandbox environments, demonstration instances, our public website, our documentation portal, our support ticketing system and any mobile applications we publish. It applies whether access is obtained through a browser, a native application, an API integration, a webhook, a partner connector or any other means.

Nothing in this policy overrides applicable law. Where local law imposes a stricter standard than this policy, the stricter standard applies.

2. Who this policy applies to

This policy binds, without limitation:

  • Customers: the organisation that has entered into a subscription agreement with us, and which is responsible for ensuring its own users comply with this policy.
  • Named users: every individual issued with credentials, including care staff, managers, finance and HR personnel.
  • Administrators: users granted elevated permissions to configure tenants, manage other user accounts, or export bulk data.
  • Contractors and agency staff: individuals engaged by a customer on a temporary basis who are granted access for the duration of an assignment.
  • Integration developers: anyone building against our APIs, webhooks or SDKs, whether employed by a customer, by us, or by a third-party vendor.
  • Security researchers: individuals who investigate our systems under the responsible disclosure programme described in section 17.

Customers are responsible for ensuring that their employees, contractors and integration partners are made aware of, and comply with, this policy. A breach by a customer’s user is treated as a breach by that customer for the purposes of our terms of service.

3. Relationship to the terms of service and DPA

This AUP is incorporated into, and forms part of, our terms of service. Where personal data is processed on a customer’s behalf, the terms of our data processing agreement also apply and take precedence in respect of data processing obligations. Our privacy notice explains how we, as a controller, handle personal data collected about visitors and account holders, and our cookie policy explains our use of cookies and similar technologies. In the event of a conflict between this AUP and the terms of service, the terms of service prevail; in the event of a conflict concerning data processing, the DPA prevails.

4. General principles

Everyone using our platforms must:

  • Use the platform only for its intended purpose: the lawful management of care, workforce and compliance records.
  • Act honestly, and never misrepresent their identity, role or authority.
  • Respect the confidentiality of information belonging to other tenants, organisations or individuals.
  • Comply with all applicable laws, including data protection, employment, safeguarding and equality legislation.
  • Take reasonable steps to keep credentials, devices and connected systems secure.
  • Report suspected misuse, security weaknesses or safeguarding concerns promptly.

5. Prohibited content

You must not use our platforms to create, upload, store, transmit or link to content that is:

  • Unlawful under the law of England and Wales or the jurisdiction in which you operate.
  • Defamatory of any person or organisation.
  • Discriminatory, or that harasses, bullies or intimidates any individual on the basis of a protected characteristic or otherwise.
  • Infringing of another party’s intellectual property, confidentiality or other rights.
  • Obscene, pornographic, or otherwise inappropriate for a professional care or workplace setting.
  • Extremist, or that promotes terrorism, violence or hatred.

This applies to free-text fields, uploaded documents, messages sent through the platform, and any content shared through integrations connected to it.

6. Prohibited data uses

You must not use our platforms to process personal data:

  • Where you have no lawful basis to do so under UK GDPR or equivalent legislation.
  • Involving special category data (such as health, sexual orientation, religion or trade union membership) or criminal offence data, other than for the legitimate purposes for which the platform is designed and in accordance with an appropriate policy document where required.
  • For covert surveillance of staff, including hidden monitoring not disclosed to those affected, save where lawfully authorised and proportionate.
  • By repurposing care records or workforce data for a purpose unrelated to care delivery, employment or compliance without a proper basis for doing so.
  • By collecting more personal data than is necessary for the purpose in question.

Customers remain the controller of personal data entered into the platform and are responsible for establishing and documenting their lawful basis for processing, in accordance with our DPA.

7. Safeguarding and care record integrity

Records relating to safeguarding, disciplinary matters, incidents and care delivery must be accurate and made contemporaneously wherever practicable. Users must not:

  • Deliberately falsify, backdate or otherwise misrepresent an entry in a care or compliance record.
  • Delete or alter a record, or the audit trail relating to it, in order to avoid scrutiny, investigation or regulatory inspection.
  • Discourage, penalise or retaliate against a colleague who raises a genuine concern in good faith (whistleblowing).

Where we identify, or are notified of, conduct that may amount to a safeguarding concern or a serious integrity breach affecting care records, we reserve the right to preserve the relevant data and, where we are legally required or it is otherwise appropriate, to notify the relevant regulator, including the Care Quality Commission (CQC) or the Information Commissioner’s Office (ICO), or law enforcement.

8. Account and credential rules

  • Accounts must be issued to, and used by, one named individual only. Shared or generic logins are not permitted, save for approved service accounts.
  • Credentials must not be shared, written down insecurely, or disclosed to any other person, including colleagues.
  • Multi-factor authentication (MFA) must be enabled wherever it is offered for an account, and must not be deliberately disabled or circumvented.
  • Administrators must offboard leavers promptly, revoking access and credentials on or before the individual’s last working day.
  • Privileged or administrative access must be limited to those who need it, reviewed periodically, and never used to access records outside the legitimate scope of the administrator’s role.
  • Service accounts and API keys must be held securely, rotated periodically, scoped to the minimum necessary permissions, and never embedded in client-side code or shared publicly.

9. System integrity and security

You must not:

  • Attempt to access another tenant’s data, or any system, account or data you are not authorised to access.
  • Attempt to escalate privileges beyond those granted to you.
  • Disable, bypass or tamper with audit logging or other security controls.
  • Introduce malware, ransomware or other malicious code.
  • Carry out or facilitate a denial-of-service attack against our infrastructure.
  • Carry out load testing or penetration testing without our prior written authorisation.
  • Scrape, crawl or carry out automated bulk extraction of data from the platform other than through supported export or API functionality within agreed limits.
  • Reverse engineer, decompile or attempt to derive source code, save to the extent permitted by law.

10. Fair use, rate limits and API usage

Our services are provided subject to fair use. We may apply reasonable rate limits to API calls, exports and bulk operations to protect the stability and performance of the platform for all customers. Automated integrations must respect published rate limits, back off appropriately on receiving throttling responses, and must not attempt to circumvent limits by distributing requests across multiple keys or accounts. Sustained or excessive usage that materially affects service performance for other customers may be throttled or suspended.

11. Email and communications

Where the platform is used to send email, SMS or other messages, you must not:

  • Send unsolicited bulk communications (spam) or use the platform for marketing without a proper lawful basis and consent where required.
  • Spoof sender identities, headers or domains.
  • Ignore unsubscribe requests or supported suppression lists, or otherwise contact individuals who have opted out.

12. Integrations and webhooks

Where you connect a third-party system to our platform via an integration, webhook or connector, you are responsible for ensuring that the receiving system is secure, that data is only shared with parties who have a legitimate need for it, and that the third-party service’s own terms and privacy practices are compatible with your obligations under data protection law. Webhook endpoints must validate signatures where we provide them, and must not be configured to forward data to parties outside your organisation without appropriate authorisation.

13. Export and offboarding of data

Customers may export their data using supported export functionality at any time during the subscription term, and for a reasonable period following termination as described in our terms of service. Bulk exports must be handled securely once downloaded, and must not be retained for longer than necessary or shared beyond those with a legitimate need. Automated or scripted bulk export activity outside supported tooling is not permitted without prior agreement.

14. Use of AI features

Where our platform offers AI-assisted features, such as drafting or summarisation tools, you must not enter personal data, confidential information or any other data that you do not have the right to process into those features. Output from AI features should be reviewed by a competent human before being relied upon, particularly where it relates to safeguarding, care planning or compliance decisions. You must not use AI features to generate content that would otherwise breach section 5 or section 6 of this policy.

15. Monitoring

We monitor and log system activity, including authentication events, administrative actions, API usage, error rates and security events, in order to protect the platform, investigate suspected misuse, and meet our audit and security obligations. We do not monitor the content of records for day-to-day operational purposes beyond what is necessary to provide the service, and access to logs by our personnel is restricted and itself subject to audit. Monitoring is carried out in accordance with our privacy notice and is proportionate to the purposes described above; it is not used to surveil individual users beyond what is necessary for security and service integrity.

16. Reporting a suspected breach

If you become aware of a suspected breach of this policy, whether relating to content, data use, safeguarding, or system security, you should report it to your organisation’s administrator and, where appropriate, to us directly at security@thornbridgesolutions.com. We will treat reports made in good faith seriously and will not penalise anyone for raising a genuine concern.

17. Responsible disclosure programme

We welcome reports from security researchers who identify genuine vulnerabilities in our platform. If you believe you have found a security issue, please contact security@thornbridgesolutions.com with sufficient detail to reproduce the issue, before disclosing it to any third party.

Safe harbour

We will not pursue legal action against a researcher who makes a good-faith effort to comply with this programme, provided that the researcher acts within its scope, avoids privacy violations and service disruption, gives us a reasonable opportunity to investigate and remediate before any public disclosure, and does not access, modify or exfiltrate data belonging to other tenants.

Scope

In scope are our production web applications, public APIs, and infrastructure that we own and operate. Out of scope are social engineering of our staff or customers, physical security testing, denial-of-service testing, testing against another customer’s tenant without that customer’s written consent, and any testing carried out against third-party services we integrate with but do not control. Automated scanning that generates excessive traffic should not be carried out without prior agreement. Further detail on our security programme is available on our security page.

18. Enforcement

Where we identify or are notified of a suspected breach of this policy, we will generally take a proportionate, graduated approach, which may include:

  • Contacting the relevant account administrator to raise the concern.
  • Issuing a formal warning setting out the breach and required remediation.
  • Throttling or restricting access to affected features or accounts.
  • Suspending the account or accounts involved pending investigation.
  • Terminating the account or agreement under the terms of service for serious or repeated breaches.
  • Notifying the relevant regulator or law enforcement authority where required or appropriate.

We may act more swiftly, including immediate suspension without prior warning, where we reasonably believe there is an immediate risk to safety, security or the integrity of care records.

19. Appeals

If you believe an enforcement action has been taken in error, you or your administrator may appeal by contacting us in writing, setting out the grounds for appeal. We will review the matter promptly and confirm the outcome, though enforcement action taken to protect safety, security or the integrity of care records may remain in place while an appeal is considered.

20. Indemnity

Where a customer or user’s breach of this policy causes us loss, liability or regulatory exposure, the customer agrees to indemnify us in accordance with the indemnity provisions of our terms of service.

21. Changes to this policy

We may update this policy from time to time to reflect changes in our services, technology, or legal and regulatory requirements. Material changes will be notified through the platform or by email to account administrators. Continued use of our services after a change takes effect constitutes acceptance of the updated policy.

22. Contact

Questions about this policy, or reports of suspected breaches, should be sent to security@thornbridgesolutions.com. For questions about our wider legal terms, see our terms of service, privacy notice, DPA and cookie policy.

23. Roles and responsibilities

This policy applies to everyone with access, but the standard expected of a person rises with the power their role carries. The following describes what each role is accountable for.

  • Owner, accountable for the tenant as a whole: who holds administrative rights, whether multi-factor authentication is enforced, what the retention settings are, and whether access reviews are completed on time. An owner should not be the only person able to administer the account; leaving a single point of failure is itself a breach of the spirit of this policy.
  • Admin, responsible for day-to-day user management, configuration and approvals. Admins must not grant themselves or others access beyond what a role genuinely requires, and must not use an administrative account for routine work that a lesser role would allow.
  • Privacy officer, responsible for data subject requests, the breach register, consent records and retention decisions. A privacy officer may view records for the purpose of responding to a request or investigating an incident, and for no other purpose.
  • Sales agent, responsible for enquiry and pipeline records only. Accessing workforce or care records from a sales role, where the platform permits it in error, must be reported rather than exploited.
  • Auditor, read-only access for assurance purposes. An auditor must not export records beyond the scope of the review being carried out, and must handle any extract under the same confidentiality terms that bind your own staff.

What good looks like: a care coordinator holds a role that can open the care records they are assigned to, and nothing else. What breaches this policy: giving every member of staff an admin role because it is quicker than configuring permissions properly.

24. Onboarding and leaver checklist

Most access incidents are not sophisticated attacks. They are accounts that stayed open after someone left. Administrators should work through the following whenever a person joins, changes role or departs.

When someone joins

  • Invite the individual to their own named account using their work email address; never create an account on their behalf using a shared mailbox.
  • Assign the narrowest role that lets them do the job, and record why if a broader role is genuinely needed.
  • Confirm they have enrolled a second factor before they access live records.
  • Give them this policy to read, and record that they have read it.

When someone changes role

  • Remove the permissions attached to the old role at the same time as adding the new ones. Accumulated access is the most common cause of over-privilege.
  • Review any saved filters, scheduled reports or webhook subscriptions the person owns and reassign them.

When someone leaves

  • Revoke access on the last working day, not at the end of the month.
  • Terminate their active sessions rather than relying on session expiry.
  • Rotate any API key, webhook secret or service credential they had sight of.
  • Reassign their open records so nothing falls out of view.
  • Keep their audit history intact, deleting a user must never delete the record of what that user did.

25. Password and credential hygiene

  • Use a unique passphrase for the platform that you do not use anywhere else, generated and stored in a password manager.
  • Do not send credentials by email, chat, ticket or SMS, and do not write them in a shared document, a spreadsheet or a note attached to a record.
  • Enrol a second factor and store recovery codes offline, in a place separate from your password manager if that manager also holds the password.
  • Rotate a credential immediately if it has been shared, seen over a shoulder, entered on a suspicious page, or held by someone who has left.
  • Treat API keys and webhook secrets with the same care as passwords: scope them narrowly, store them in a secrets manager rather than source code, and rotate them on a schedule.
  • Never approve a multi-factor prompt you did not initiate; report it instead.

26. Devices, BYOD and working locations

Care and workforce records are frequently accessed away from a desk. That is legitimate, provided the surroundings are controlled.

  • Use a device with full-disk encryption, an up-to-date operating system, a screen lock with a short timeout, and current security updates.
  • Personal devices may be used only where your organisation permits it and the device meets the same standard. Do not sign in on a device that other people also use for their own purposes without a separate user profile.
  • Do not use shared, public or hotel computers, and do not save credentials in a browser on a device you do not exclusively control.
  • Public Wi-Fi is acceptable because all traffic is encrypted in transit, but the screen is not: assume anyone behind you can read it.
  • Report a lost or stolen device to your administrator immediately so sessions can be revoked.
  • In shared workspaces and vehicles, position the screen so records are not visible to people who have no reason to see them, and lock the device whenever you step away.

27. Printing, screenshots and exports

Once a record leaves the platform it also leaves the audit log, the retention schedule and the access controls that protect it. Exports are therefore permitted but must be deliberate.

  • Export only the fields and rows needed for the specific purpose, and delete the extract when that purpose has been served.
  • Do not email an export of care or workforce records to a personal address, or upload it to a file-sharing service that your organisation has not approved.
  • Screenshots of records must not be shared in group chats, support tickets or training material unless the personal data has been removed or replaced.
  • Printed records must be collected immediately, stored securely and destroyed by confidential waste, never left in a communal printer tray.
  • Bulk export by an account that has no operational reason to perform it will trigger an alert and may result in immediate suspension pending explanation.

28. Retention and minimisation duties

You decide what is recorded and for how long. In doing so you must not use the platform to hold more personal data, for longer, than your own lawful basis supports.

  • Do not paste unrelated documents, whole email chains or clinical correspondence into a free-text field because it is convenient.
  • Do not record opinions about an individual that you would be unwilling to justify to that individual, a regulator or a court; assume every note will one day be read by its subject.
  • Keep retention settings enabled. Turning off an automatic purge is a reason-coded action and will be recorded against your account.
  • Where a record must be preserved beyond its normal retention period, for example because it is relevant to an ongoing investigation or claim, apply a documented hold rather than disabling retention for the whole tenant.

29. Training, contractors and regulator cooperation

Training

Every user should complete your own data protection and safeguarding training before being given access to live records, and refresh it at least annually. Administrators and privacy officers should additionally understand the platform’s audit, retention and request-handling features well enough to evidence a decision months after it was made.

Contractors and agency staff

Contractors, agency workers and consultants may be given named accounts provided they are bound by written confidentiality terms, their access is time-limited to the engagement, and their role is scoped to the work in hand. Access must be revoked on the final day of the engagement rather than left open in case they return.

Regulator cooperation

Where a regulator, commissioner or safeguarding body requests evidence relating to your use of the platform, you must not alter or delete records to change what that evidence shows. The audit log is tamper-evident: an attempt to rewrite history will be detectable and will be treated as a serious breach of this policy.

30. Test and sandbox data

  • Never copy real service-user, worker or applicant data into a demonstration, training or sandbox environment. Use the synthetic records provided.
  • Do not use a live tenant to trial an integration; request a sandbox instead.
  • Anything entered into a demonstration environment must be treated as non-confidential and may be reset without notice.
  • If real data reaches a test environment by mistake, report it as an incident so it can be removed and the exposure assessed.

31. Breaches and typical enforcement

The table below indicates how we normally respond. It is illustrative: we take the circumstances, the intent and the risk to individuals into account in every case.

ActivityTypical response
Sharing a named account or credentialsImmediate credential reset, notice to your administrator, repeat instances escalate to suspension
Accessing records with no operational reasonAccess review of the account, role reduction, referral to your organisation for disciplinary action
Falsifying or back-dating a care or compliance recordSuspension pending investigation and, where legally required, notification of the relevant regulator
Deleting records to avoid scrutinyImmediate suspension, preservation of the audit chain, regulator and, where appropriate, law enforcement notification
Unauthorised scanning, load testing or penetration testingRate limiting or IP blocking, written warning, termination for repeat conduct
Attempting to reach another tenant's dataImmediate suspension and full investigation; deliberate attempts are reported to law enforcement
Excessive automated querying or bulk exportThrottling and a request for justification; sustained abuse leads to API key revocation
Sending unsolicited bulk email through the platformSending suspended for the tenant until controls are demonstrated
Uploading unlawful or infringing contentContent removal, notice to your administrator, termination for serious cases
Failing to remove leavers' access after noticeWritten warning and a required access review before further users can be added

32. Frequently asked questions

Can two people share one licence if they never use it at the same time?

No. Every action is attributed to an account, and a shared account makes the audit trail meaningless. If two people need access, they need two accounts.

May I look up a record about someone I know personally?

Only if you have an operational reason to do so. Curiosity is not a lawful basis, and every record view is logged.

Can I use a personal phone to complete notes on a visit?

Yes, provided your organisation permits it and the device meets the standard in section 26, encrypted, patched, screen-locked and not shared with anyone else.

What if I discover a security flaw by accident?

Stop, do not explore further, and email security@thornbridgesolutions.com. Reporting in good faith is protected; continuing to probe is not.

Will you tell me if my account is investigated?

We normally contact your administrator first. Where doing so would prejudice an investigation into that administrator, we contact the account owner or another appropriate contact instead.

Does this policy apply to our integration developers?

Yes. Anyone using an API key issued for your tenant is bound by this policy, and you remain responsible for their conduct.