Business Continuity, Succession and Service Transition

Last Updated October 4, 2026

1. Purpose and scope

This document describes how Trooth is built to stay available, how incidents are detected and communicated, the arrangements that allow the Service to continue if its operators are unavailable, and the commitments Trooth makes to its users if the Service is ever transferred or discontinued. Trooth builds on managed infrastructure. The resilience described here combines vendor capabilities with Trooth's own documented procedures, and this document does not claim more than that.

2. How the Service is built to stay up

The web application is served from a managed multi-region edge platform. The database is a managed PostgreSQL service with automated backups and vendor-provided point-in-time restore capability. Authentication is delegated to a managed identity provider. Each of these vendors, and what it does, is on the Sub-processor List. In addition to vendor backups, Trooth maintains an offline vault procedure for its own copies of critical data.

3. How problems are detected

The Service exposes a health endpoint that checks its own dependencies, external monitors probe availability from outside Trooth's infrastructure, and application errors are reported to an error-tracking service. A production deployment that fails its required checks reports itself unhealthy rather than pretending otherwise. The current state of the Service is published on the status page.

4. How Trooth communicates during an incident

For availability incidents, Trooth communicates with affected users by email as the situation warrants and on the status page. For security incidents involving personal data, notification obligations and timelines are governed by the Data Processing Addendum for customers with a DPA, and by applicable law for everyone; this document does not restate those timelines, so the two can never disagree. Security reports from outside Trooth are received under the Vulnerability Disclosure Policy at security@trooth.co.

5. Dependencies and their limits

Trooth depends on the vendors on the Sub-processor List, and an outage at one of them can impair the Service. Where that happens, Trooth's responsibility is what the Terms of Service say, including the force majeure provision. Choosing well-operated managed vendors is itself part of the continuity posture: each vendor named runs its own redundancy and its own security program, which Trooth evaluates when it adopts one.

6. Operator continuity

So that the Service, and the data entrusted to it, never depend on the availability of any one person, Trooth maintains the following arrangements.

A designated Continuity Contact. Trooth, LLC has appointed an individual outside Trooth's day-to-day operation who is authorized to act for Trooth under this section. The Continuity Contact does not take part in operating the Service in the ordinary course.
Sealed instructions and emergency access. The Continuity Contact holds written instructions and emergency access to the accounts the Service depends on. That access is not used in the ordinary course and is arranged so that it can be used only when this section applies.
Accounts held for the company. The domain, hosting, database, email and source-code accounts on which the Service depends are held by or for Trooth, LLC, so that authority over them follows the company rather than any individual.
A written operating runbook. The steps needed to keep the Service running, keep its domain and infrastructure in good standing, publish notices, contact users and export data are written down and kept with the sealed instructions.

Two different situations are covered, and they give different powers. The sealed instructions and the runbook follow this section; where they differ, this section governs.

6.1 Immediate response: an incident while Trooth's operators cannot be reached

This applies from the first hours, not after 14 days. If the Continuity Contact learns of a security or availability incident, from a report to security@trooth.co, the status page, a user or a vendor, and cannot reach Trooth's operators within 4 hours, the Continuity Contact may take these containment steps and no others:

1. take the Service, or the affected part of it, offline, or put back the last deployment that was working; 2. revoke or rotate an account credential, access token or key believed to be compromised. A compromised signing key is revoked by marking it compromised, with the time, in the published key list at https://api.trooth.co/public/keys and announcing it on the changelog, as the key policy there requires, so that anyone checking a signature can see it; the key and every statement it signed are kept, not deleted, because the record of what was signed is part of the evidence; 3. withdraw from public view a page or record that is causing harm, without deleting it; and 4. publish a notice on the status page saying what was done and why.

In this mode the Continuity Contact does not edit the content of any published record or reading, delete data, change a policy, or make a commitment on Trooth's behalf. Every step is written down with its time as it is taken and handed to Trooth's operators, who decide what happens next when reachable.

6.2 Succession: Trooth's operators unable to operate the Service for more than 14 days

This applies if Trooth's operators are unable to operate the Service for more than 14 consecutive days. The Continuity Contact will then:

1. keep the Service, its domain and its infrastructure accounts in good standing, and may take any step in 6.1; 2. publish a notice on the status page and email account holders within 7 days of acting, saying that the Continuity Contact is acting and what users can expect; 3. preserve data and records as they are, and change no published record or reading; revoke or rotate a signing key only as 6.1 describes; and 4. carry out requests for data export, account deletion and erasure as the Retention Schedule sets out. Preserving records never overrides a deletion the Retention Schedule or the law requires; the records that the schedule keeps longer than an account are kept only in the minimal form it describes.

If Trooth's operators have not resumed operating the Service within 90 days, the person then authorized to act for Trooth, LLC will either arrange a transfer of the Service under section 8 or begin its discontinuation under section 7. In either case every commitment in those sections applies.

6.3 Recovery targets and their clocks

Three clocks are used in this document and on the security page, and they start at different moments.

The incident clock starts when Trooth first knows of the incident: the first alert from a monitor or from the error-tracking service, or the first report from a user, a vendor or security@trooth.co.
The unavailability clock starts when the Continuity Contact first tries to reach Trooth's operators about that incident. The 4 hours in 6.1 and the 14 days in 6.2 are counted on it.
The recovery clock runs from the start of the incident clock until the Service is available again. The recovery target is 4 hours. The data-loss target is at most 24 hours of data, counted back from the incident to the last nightly backup that was good.

The 4-hour recovery target holds only when Trooth's operators respond. If Trooth's operators cannot be reached, the Continuity Contact may act only after trying for 4 hours, so that wait can use the whole 4-hour target before any step is taken. The steps then permitted are the containment steps in 6.1: putting back the last deployment that was working can restore the Service when a deployment caused the outage, and the other steps contain an incident without restoring the Service. In that case Trooth states no recovery time. What it can say honestly is that containment can begin 4 hours after the Continuity Contact first tries to reach Trooth's operators, and that a recovery beyond those steps waits for Trooth's operators, or for section 6.2 after 14 days. The first exercise described in section 10 will measure the actual times.

7. If the Service is discontinued

Trooth intends to operate the Service for the long term. If Trooth, LLC ever decides to discontinue it, Trooth will do the following.

Notice. Give at least 90 days' notice before the Service stops, by email to every account holder, on the status page and in the changelog.
Service during the notice period. Keep the Service available throughout the notice period. Published Trust Profiles remain visible, and account holders can sign in, export their data and delete their accounts. Trooth may stop accepting new accounts during this period.
Data export. Keep Download my data in account settings, and the GET /me/export endpoint, available until the last day of the Service, and provide the same export on request to support@trooth.co for 30 days after it stops. How export works today is described on the Data Return and Portability page.
Deletion. After that period, delete customer data from production systems, and let it expire from backups on the schedule in the Retention Policy, which is no more than 35 days. Trooth will confirm deletion in writing on request.
Published records. At the end of the notice period, withdraw Trust Profiles and the directory from public view. Published records and customer data are not sold or transferred except under section 8.
Signatures that remain checkable. Before the Service stops, publish Trooth's public signing keys, and the method for checking a signature, in a public location that does not depend on the Service, so that witness statements issued before the end can still be checked independently.
No charges. Introduce no fee during a notice period. The Service is free under the Terms.

Where a shorter period is required by law, by a court or regulator, or by an event outside Trooth's reasonable control, Trooth will give as much notice as it can, and the export and deletion commitments above still apply.

8. If the Service or the company is transferred

If Trooth, LLC or the Service is acquired, merged or transferred to another operator:

account holders will be told by email, at least 30 days before any customer data is transferred, who the new operator is;
anyone who does not want their data transferred can export it and delete their account before the transfer takes place;
Trooth will make it a condition of the transfer that the new operator honors the Terms of Service, the Privacy Policy, any Data Processing Addendum in place and this document for the data transferred, until they are changed under their own procedures and with the notice those procedures require; and
Trooth will also make it a condition that no payment can change what a Trust Profile shows.

9. Data return

While your account is open you can download your data at any time, as a file in JavaScript Object Notation (JSON), from Download my data in account settings or through GET /me/export. If your relationship with Trooth ends, export and return of your data are otherwise governed by the Terms of Service and, where one is in place, the Data Processing Addendum.

10. Testing and review

Trooth tests that its backups can be restored and records the result. The arrangements in section 6 have not yet been exercised with the Continuity Contact. The first exercise, a key compromise and a deletion request while Trooth's operators are treated as unreachable, run through the steps in 6.1 and 6.2 with the Continuity Contact and measured against the clocks and targets in section 6.3, is planned for October 2026, and its result, whatever it is, will be recorded there. Until then the arrangement is appointed, not proven. This document, the Continuity Contact arrangement and the operating runbook are reviewed at least once a year and after any material change to the Service or its infrastructure. The effective date of this document changes when its substance does.

11. Contact

General questions: hello@trooth.co. Availability questions: support@trooth.co. Security incidents: security@trooth.co.

Revision note. Revised September 27, 2026. Sections 6, 7 and 8 were added: the arrangements that let the Service continue if Trooth's operators are unavailable, the commitments that apply if the Service is ever discontinued, and those that apply if it is transferred. Section 9 now states how data can be downloaded, section 10 commits to a yearly review, and the title now names succession and service transition. No right or obligation was narrowed.

Revision note. Revised September 28, 2026. Section 6 now separates immediate incident response from succession. In the first hours of an incident, if Trooth's operators cannot be reached within 4 hours, the Continuity Contact may take the Service offline, revoke or rotate a compromised credential or key, withdraw a harmful page from view and post a status notice, and nothing more; a compromised signing key is marked compromised rather than deleted. Section 6.2 no longer tells the Continuity Contact both to preserve every record and to delete accounts: deletions the Retention Schedule or the law requires are carried out. Section 10 says the arrangement has not yet been exercised and when it will be. No right or obligation of yours was narrowed.

Revision note. Revised October 4, 2026. A new section 6.3 says where each clock starts: the incident clock when Trooth first knows of an incident, the unavailability clock when the Continuity Contact first tries to reach Trooth's operators, and the recovery clock from the start of the incident. It states that the 4-hour wait before the Continuity Contact may act can use the whole 4-hour recovery target, so that target holds only when Trooth's operators respond, and that Trooth states no recovery time when Trooth's operators cannot be reached. Section 10 measures the planned exercise against those clocks; no exercise with the Continuity Contact has been completed yet. The powers in sections 6.1 and 6.2 are unchanged, and no right or obligation of yours was narrowed.