1. Purpose
This policy explains how a customer can leave Subcontext in an orderly way: how they get their data back, how we support the move to another provider, and how their data is deleted afterwards. It is written to help customers meet their own outsourcing obligations, including the FCA's requirements in SYSC 8 and, for PRA-regulated firms, Supervisory Statement SS2/21.
Regulated firms are expected to have documented, workable exit strategies for material outsourcing arrangements, covering both a planned exit and a stressed exit, so that the end of the arrangement does not disrupt their regulated activities or harm their customers. This document sets out Subcontext's side of that plan. Customers can use it as an input to their own exit plans and testing.
2. Scope
This policy covers all data that Subcontext holds for a customer as processor, including leads and contacts, conversation transcripts and recordings, insurance applications, quotes, policies and claims, configuration of agents, journeys and integrations, knowledge content, and the records the platform keeps about that data (such as compliance decision records). It covers every Subcontext service: the dashboard, the REST API, the MCP server, embedded widgets, and the iOS, Android and Mac apps.
It does not cover data that a customer holds directly with a third party under its own account, such as its own Stripe account or its own systems connected through an integration. Those remain with the customer and its provider throughout.
3. Definitions
| Term | Meaning |
|---|---|
| Notice period | The period between notice of termination being given and the effective termination date, as set out in the customer's agreement |
| Effective termination date | The date the agreement ends and the service stops |
| Planned exit | An exit the customer or Subcontext chooses, with notice given under the agreement |
| Stressed exit | An exit forced by Subcontext being unable to continue providing the service, for example insolvency or a severe, prolonged loss of service |
| Assisted export | A complete export of the customer's organisation data, prepared by Subcontext on request |
4. Exit Triggers
This plan applies whenever the service ends, including:
- The customer ending their subscription or agreement, for any reason
- Subcontext ending the agreement in accordance with the Terms of Service
- A regulatory instruction or change requiring the customer to move the service
- A stressed exit, where Subcontext is unable to continue providing the service
5. Roles and Responsibilities
| Party | Responsibility |
|---|---|
| Customer | Decides to exit and gives notice, owns its own exit plan, chooses the replacement provider, takes the exports it needs, and confirms when it has everything it requires |
| Subcontext account contact (a member of the founding team) | Acts as the single point of contact for the exit, agrees the exit timetable with the customer, and tracks it to completion |
| Subcontext engineering | Prepares the assisted export, answers questions about the data, and carries out release, transfer and deletion |
| Directors | Approve any departure from this policy and sign written confirmation of deletion |
6. Getting Your Data Out
6.1 Self-service, at any time
Customers can export their data themselves from the dashboard throughout the agreement, without asking us:
| Data | Format |
|---|---|
| Leads and contacts | CSV, and a full JSON record per lead |
| Conversation transcripts | Transcript export per conversation |
| Conversation compliance audits | Audit report |
| Insurance book (applications, quotes and policies) | CSV |
| Analytics | Daily CSV |
| Messaging usage and billing statements | CSV and statement exports |
| Compliance check questions and run reports | Report exports |
| Custom integration definitions | JSON configuration files, re-importable |
Data can also be read programmatically through the Subcontext REST API and MCP server, using OAuth credentials the customer controls.
Exports generated in the dashboard are available to download for 7 days, after which they are deleted automatically. A customer can generate a new export at any time.
6.2 Assisted export on exit
On request, we provide a complete export of the customer's organisation data in machine-readable formats (JSON and CSV) within 30 days. This includes data not covered by the self-service exports, such as agent configurations and knowledge content.
The assisted export is delivered securely to a contact the customer nominates, and comes with a description of the files and fields so the customer or its new provider can understand and load it.
6.3 Data held under retention periods
Some data is kept for a limited time and deleted automatically during the agreement, as set out in the Data Retention & Deletion Policy (for example voice recordings, which are kept for 365 days by default). Customers who need a long-term copy of such data should export it during the agreement, or change the retention setting where one is available. An exit export can only include data that still exists on the date it is produced.
7. Exit Procedure
| Step | What happens | Who |
|---|---|---|
| 1. Notice | The customer gives notice under its agreement, or Subcontext gives notice under the Terms of Service | Customer or Subcontext |
| 2. Exit meeting | We agree an exit timetable, the data to be returned, any items to be transferred (such as phone numbers), and the target date for deletion | Customer and Subcontext |
| 3. Parallel running | The service continues as normal while the customer builds and tests its replacement | Customer |
| 4. Export | The customer takes self-service exports, and requests the assisted export where needed | Customer and Subcontext |
| 5. Verification | The customer checks the exports are complete and readable, and tells us of any gaps, which we address | Customer and Subcontext |
| 6. Release and transfer | Phone numbers, messaging sender identities and integrations are released or transferred where possible, and the customer's connected credentials are disconnected | Subcontext |
| 7. Termination | The service stops on the effective termination date | Subcontext |
| 8. Deletion | Customer data is deleted as set out in section 9, and confirmed in writing on request | Subcontext |
Worked example
An insurer gives three months' notice. In the first week we hold an exit meeting and agree the timetable. Over the next two months the insurer runs its new provider alongside Subcontext, routing a growing share of traffic away, and uses the self-service exports to load leads and its insurance book into the new system. It requests the assisted export six weeks before the end date and receives it within 30 days, leaving time to check it. Its phone numbers are ported to the new provider before switch-off. After the effective termination date, its data is deleted and we send written confirmation.
8. Transition Support
- The service continues to operate as normal during the notice period
- Customers can run Subcontext alongside a replacement provider while they migrate
- We provide reasonable assistance to help the customer or their new provider understand the exported data
- Customers' own integrations, phone numbers and messaging sender identities can be released or transferred where the underlying provider allows it
Our security and support commitments continue to apply in full until the effective termination date. We do not reduce service, withhold data or delay an export because a customer is leaving, and the return of data is not conditional on any dispute about fees.
9. Deletion After Exit
- Customer data is deleted within 90 days of the effective termination date, in line with the Data Retention & Deletion Policy
- Automated database backups expire within 7 days of deletion
- Data held by sub-processors is deleted in accordance with their contractual obligations
- On request, we confirm deletion in writing
- We keep only what the law requires us to keep, such as billing records, and anything the customer instructs us in writing to retain
Deleting a whole customer organisation is a deliberate, recorded action that we carry out on request or at the end of the agreement. It is not triggered automatically, so data is not lost by accident while an exit is still under way.
10. Stressed Exit
If Subcontext were unable to continue providing the service, we would:
- Give customers as much notice as possible, aiming for at least 90 days
- Keep data exports available for the whole of that period
- Provide the assisted export in section 6.2 to every customer who asks
Several features of the platform make a stressed exit more manageable:
- Customers can take self-service exports and use the API at any time, so they can hold their own current copy of their data without depending on us
- Customers' integration definitions export as re-importable JSON configuration
- The platform's infrastructure is defined as code and the platform is documented, so others can operate it for a period if needed
- Payments are taken through Stripe, so card details are never stored by Subcontext
We recommend that customers who rely on Subcontext for an important business service take regular exports of their key data as part of their own resilience planning.
11. Testing and Customer Exit Planning
On request, we will help customers test their exit plans, for example by providing a sample assisted export, so they can confirm that the format meets the needs of a replacement provider. We also provide the information customers need for their own exit plans, such as the data categories we hold and how each is exported.
12. Exceptions
Any departure from this policy, for example a different export format or a longer retention period requested by the customer, is agreed in writing with the customer and approved by a director.
13. Review
This plan is reviewed at least annually, and whenever the services or data covered by it change significantly.
14. Related Documents
- Data Retention & Deletion Policy
- Operational Resilience Statement
- Business Continuity & Disaster Recovery Policy
- Sub-Processor List
- Service Levels & Support Policy
- Supplier Risk Management Policy
15. Document Control
| Item | Detail |
|---|---|
| Owner | A director of Subcontext Ltd |
| Approved by | The directors of Subcontext Ltd |
| Review | At least annually, and whenever the services or data covered by it change significantly |
| Effective | October 2026 |