Your data is yours. We just process it for you.
This is a plain-English explanation of what data YourKith handles, who controls it, where it lives, who else touches it, and how to exercise your rights. We've kept the legalese to a minimum.
Effective date: August 8, 2026
Who controls your data
When your firm uses YourKith, you are the data controller, it's your CRM and advisory data, and you decide what goes into the platform and why. Triarch acts as a processor, running the software and infrastructure on your behalf. We process the data to provide the service to you; we don't sell it, and we don't repurpose it for our own ends. One flow does leave your instance and you should know about it: once a day your deployment reports account-administration figures back to Triarch so we can run your subscription and support, and that report includes each authorised user's email address, when they last signed in, and how often. It carries no CRM, engagement or finance content. It is the only scheduled path out of your environment.
What data the platform processes
YourKith processes the operational data your firm puts into it and the signals you connect to it, including:
- CRM and advisory records you create, companies, contacts, deals, engagements, contracts, finance and billing data.
- Content from connected sources you choose to link, for example email, calendar, messaging, banking, and CRM integrations.
- Contact details that may include personal data such as names, email addresses, and phone numbers.
- Account and usage information needed to operate, secure, and audit your instance, including the audit log of access and actions.
You decide which sources to connect and what to load. The intelligence features of the platform derive insights from this data to help you run your operation.
We practice data minimization on connected sources, and it is worth being precise about what that does and does not mean. For email bodies, Slack message text and calendar descriptions, the raw content is held only until the platform has extracted what it needs from it, and is then erased on a nightly job. It is not kept indefinitely so that it can be re-read later. On top of that, any of those bodies the platform never manages to analyse is erased anyway after 30 days by default, so nothing lingers merely because it was never looked at. Both windows are set per deployment, and we should be accurate about what that means: they are defaults rather than caps, a deployment can be configured to hold content for longer, and a misconfigured value falls back to the 30-day default rather than to the shortest window. Meeting transcripts are outside this automatic sweep entirely and are erased on request rather than on a timer, as is the short preview line we keep with each email thread.
What we do not claim is that nothing personal is ever stored. Contact details you keep in the platform are stored because the product would not work otherwise. Email addresses and phone numbers are encrypted at rest under a key we manage for your deployment, as described on our security page. Names are not. A person's name is stored as ordinary text, and appears again in the index that makes them searchable, so it is protected by isolation, access control and the provider's disk encryption rather than by our own field encryption. And during the window between ingest and extraction, the raw source content genuinely is present in your database. It is encrypted in transit and at rest, and it lives in your own isolated instance, but we would rather tell you it exists than describe it as stripped.
Data isolation & retention
Each customer runs on a dedicated, single-tenant deployment, its own cloud project, its own database, and its own domain. Your data is never commingled with another customer's, and there is no shared multi-tenant database. For the technical detail of how this works, see our security page.
Retention follows your account. The records your firm creates, companies, contacts, deals, engagements, finance, persist for as long as your subscription is active. On account termination, your data is exported to you and your dedicated environment is decommissioned. We should be honest about the state of this rather than quote a number we cannot yet stand behind: offboarding today is a procedure we carry out by hand, not an automated teardown, and we do not currently publish a backup-retention window for the new database platform. The deletion timetable and the backup terms that apply to you are set in the agreement between us, and we would rather agree them with you in writing than imply a default here.
Raw content pulled from connected sources is treated differently and more aggressively, as described above: erased once it has been analysed, and erased after 30 days regardless if it never was. One deliberate exception is worth naming. A calendar event's agenda is now kept until the platform has actually read it, rather than being erased the moment the meeting ends. That is a change we made on 8 August 2026, and it was a correction: the previous behaviour destroyed agendas before anything had a chance to use them, which lost you information you had every reason to expect the product to have. The same 30-day ceiling still applies.
Sub-processors
To deliver YourKith, data may be processed on our behalf by the providers below. This list covers infrastructure that stores your data and every outside service the platform sends your data to in the course of doing its job, including enrichment and web lookup. Which of them are reached at all depends on the modules and connectors you enable.
Hosting, application runtime, identity provider, and key management (KMS).
The managed Postgres database that stores your instance's data.
The infrastructure Neon runs on, so your database resides in AWS (us-east-2) even though the application runs on Google Cloud.
For AI features, e.g. Anthropic, OpenAI, or Google. Under your own key when you supply one; under Triarch's managed key if you do not.
Contact enrichment. When you enrich a contact or company, we send that person's name, email address, employer and public profile URLs to PDL, and store the employment history it returns. This is a data-broker lookup and is the one sub-processor we would most want you to notice.
Web lookup for the AI ops brain. The search text it composes, which routinely contains a company or person's name, goes to the search provider. DuckDuckGo is the default when no Exa key is configured.
Delivery of briefings and deliverables you send by email: the recipient address, the subject, and the full message body.
Text to speech, only when you play an answer aloud. The text of that answer is sent to the provider.
Embeddings for semantic search, generated over your indexed records. Under your own key when you supply one, and under a Triarch-held key if you do not.
A separate Triarch product, used only if you enable the competitive intelligence module. Receives the company name, domain and market notes for the accounts you track.
Public company-signal sources. These receive the names of companies you track, which reveals who is in your pipeline, but no contact data.
A note on the AI keys, because the distinction matters and is easy to gloss over. When your firm supplies its own provider key, your firm chooses the provider and the calls run under your account, and we require an attested no-training / zero-data-retention configuration on reasoning calls, which is enforced in code rather than merely promised, and which refuses our own managed key just as readily. The embedding step behind semantic search does not yet pass through that same check, and we are closing that. If you do not supply a key, the platform falls back to Triarch's managed provider keys so the features work without setup, and on that path the calls run under Triarch's provider account rather than yours. Either way your data stays inside your own isolated instance, but if you need the provider relationship to be yours, supply your own key.
Security measures
We protect your data with isolation by architecture, KMS-backed encryption of sensitive PII fields at rest, TLS in transit, hardened authentication with short-lived server-signed sessions in httpOnly cookies, role-based access control, and an audit log. The full description lives on our security page.
Data subject requests
If an individual whose personal data appears in your instance wishes to access, correct, or delete that data, those requests are generally directed to your firm as the data controller. As your processor, Triarch will support you in responding to such requests in line with our agreement and applicable law.
Contact
Questions about this statement, how we handle data, or any security matter? Reach us at mike@triarchsecurity.com.
This statement describes current practices and may be updated. Material changes will be reflected here with a revised effective date.
Want the technical detail?
See exactly how isolation, encryption, and access control are engineered into the platform.