Changelog

This page records material changes to Sales Triage Security and Transparency documentation and related security controls.

September 2026

People Data Labs Is No Longer a Supplier

People Data Labs was one of the providers our prospecting features could be configured to use for company and contact enrichment. It has been removed from the platform entirely: the integration, the stored credentials, the identifiers we held against it, and its entry on our Suppliers and Sub-Processors list.

Nothing is shared with People Data Labs any more. The other enrichment providers already on the list are unchanged, and nothing new was shared with anyone to replace it. The supplier list, the same list published in our Privacy Policy and in Annex A of the Data Processing Agreement in our Terms, is updated automatically.

Enrichment records themselves are kept, minus the identifiers that pointed at People Data Labs.

Clearer Wording on How Long We Keep Your Platform Data

Our Privacy Policy said that data you store in the platform is kept "per client instructions". That implied a retention setting you could use, and there isn't one, so we have replaced it with what actually happens.

Your data is kept for as long as your account is open. Nothing expires automatically, and there is no setting in the platform that applies an expiry. You decide what to keep, because it is your data and you are the controller of it. If you want something removed, whether that is a particular record, everything about one individual, or a date range, ask us and we will do it. If you give us a retention instruction, we will apply it. When your account ends, your data is available for export or return for 30 days and is then deleted.

We considered building automatic expiry and decided against it for now. Deciding how long to keep your own records is your call rather than ours, and a system that quietly deleted them on a timer would be more likely to lose something you wanted than to help. If you would like a retention policy applied to your account, tell us and we will apply it.

Data Processing Agreement Signed With Our Video Hosting Provider

We have signed an Article 28 data processing agreement with bunny.net, who host the video messages recorded in the platform. It is held on file rather than published, because they issue a document to sign rather than standing public terms, and our supplier list now records agreements of that kind as well as linked ones.

Two things about it are worth stating plainly. Their agreement does not name a standard transfer mechanism. Instead, the regions we choose count as our instruction about where data goes, and ours are set to London and Frankfurt: the London copy stays in the United Kingdom, and the Frankfurt copy goes to the European Economic Area, which United Kingdom adequacy rules already cover. That is what makes the arrangement work, so we treat the region setting as a control rather than a preference. And while they publish a list of the companies they use, they decline to name their server and network providers, describing that as commercially confidential. We would rather tell you that than leave it out.

Separately, our email and calendar provider is certified under the UK Extension to the EU-U.S. Data Privacy Framework, which has been a recognised route for transfers from the UK to the United States since October 2023. That covers the transfer itself. It does not replace a processing agreement, and we are still pursuing one with them.

Correction: Stripe Is Still Involved in Card Payments

An earlier entry on this page said that Stripe had been removed entirely and that nothing is shared with Stripe any more. The first half was true of our platform; the second half was not, and we are correcting it rather than leaving it.

What is accurate: Stripe no longer has any integration with the Revenue Engine platform, and we no longer hold Stripe credentials in it. However, our Stripe account is connected to Xero, so when you pay an invoice by card the payment is processed by Stripe. Your name, email address, billing address, the invoice reference and the card details you enter reach Stripe in order to take the payment. We never see or hold the full card number.

Stripe has therefore been restored to our Suppliers and Sub-Processors list, which also means it reappears in our Privacy Policy and in Annex A of the Data Processing Agreement in our Terms. Its entry records what it does now, which is narrower than before: taking card payment against an invoice, rather than running checkouts inside the platform.

Its role is recorded as both controller and processor, because a card payment provider decides some things for itself, such as how to screen a payment for fraud, while acting on instructions for the rest. Stripe's own data processing addendum says the same.

The Privacy Policy sections on billing data and on who we share data with have been corrected to name Stripe again.

Supplier Register Worked Through, and Each Supplier's Role Recorded

We went through every supplier on our list one at a time and read each one's own data processing agreement, rather than assuming what it said.

Nine now carry a named safeguard for transfers of personal data out of the United Kingdom, each taken from that provider's own agreement: Anthropic, OpenAI, Telnyx, Apollo, Lusha, Exa, Xero, Microsoft and our host Fasthosts.

Two turned out not to be processors at all, which is a more accurate answer than finding an agreement. GoCardless states that it acts as an independent controller because of its regulated role in payments, so a processing agreement with us is not the applicable instrument. Companies House is a public register we read, and processes nothing on our behalf. Every entry now states its role, so where no agreement is listed against one of those two you can see why rather than wondering.

Four are still outstanding and we would rather name them than let the list look finished: our email and calendar provider, our video hosting provider, one search provider and one data provider. Each is being addressed. Our Privacy Policy wording on international transfers will be made more specific once all four are closed, rather than before.

Stripe Is No Longer a Supplier

Payments and subscriptions are billed through Xero, and the last things that still used Stripe - top-up packs for AI tokens and images, and coaching sessions paid up front - now raise a Xero invoice like everything else. Stripe has been removed from the platform entirely: the integration, the stored credentials, and the entry on our Suppliers and Sub-Processors list.

Correction, made shortly after this entry was first published: the original wording said nothing is shared with Stripe any more. That was wrong. Stripe no longer has an integration with our platform, but our Stripe account is connected to Xero, so a card payment against an invoice is still processed by Stripe. Stripe is therefore still a recipient of payer data and remains on the supplier list. See the correction entry above.

Card payment against an invoice is handled by the payment provider attached to it in Xero, as it already was for subscriptions. We do not store full card numbers, and did not before.

Erasure Requests Can Now Be Actioned Properly

We have built a tool that carries out an erasure request for one person across everything we hold, rather than doing it by hand a table at a time.

It anonymises rather than deletes: the contact record, its activities and their dates stay, so your reporting and the credit your reps get do not change, while the name, contact details, notes and call transcripts identifying the individual are removed. Email addresses and phone numbers are removed outright. It also clears that person from the enrichment cache behind our prospecting features, which is shared across all clients and keyed to external identifiers, and so needed clearing separately from any one client's records.

It deliberately stops short of three things and reports them instead. A meeting transcript records what every attendee said, so erasing one person would destroy the others' data and your own record of the meeting; those are reviewed rather than blanked. Audio held by our meeting and telephony providers is removed in their systems. And content already sent to an AI provider sits in that provider's limited abuse-monitoring window and ages out on its own.

One limitation stated plainly: nothing yet stops a later prospecting run finding that person again from a data provider. A suppression list to prevent that is on the improvement plan.

Before this, an erasure request was fulfilled by us directly in the database, and the shared enrichment cache was not reached at all.

Correction: How AI Content Is Stored, Stated Accurately

Our Privacy Policy and AI pages said that content submitted to an AI feature might be indexed into a vector store associated with your account, and that such indexed content persists until deleted. Checking this against what the software actually does, that was not right, and it overstated what we do with your content.

What is accurate: content you submit is not automatically added to a searchable index. Separately, we can set up an assistant with reference material indexed at the provider so it can search that material - that upload is done by us rather than by you, and where an assistant is set up for a particular client it may hold that client's own material and be available only to them. Material indexed that way stays at the provider until we remove it. A conversation continues from the provider's record of the previous turn, so that record exists at the provider for the same limited abuse-monitoring period as the rest of the conversation, normally up to around 30 days.

One thing we found that does persist, and that we had not disclosed: a file you attach to a message is uploaded to the AI provider for that request and stays in the provider's file storage afterwards, because we do not currently delete it. It is now on the improvement plan and stated in the Privacy Policy.

The affected wording has been corrected in the Privacy Policy and on the AI and Data Processing page.

Record of Processing Activities Introduced

We now maintain a record of processing activities under Article 30 of the UK GDPR. It covers the processing we carry out for our own purposes as a controller, and the categories of processing we carry out on behalf of each client organisation as a processor, setting out for each one the purpose, lawful basis, categories of people and data, recipients, transfer safeguards and retention period.

It is kept in code alongside our supplier list, so the recipients and transfer safeguards in it are the same facts published on the Suppliers and Subprocessors page. It is an internal accountability document, provided to a client's auditor or a regulator on request.

Writing it surfaced two things we have chosen to record honestly rather than smooth over, both on our improvement plan: there is no mechanism yet for a client to give us a retention instruction for their platform records; and the platform has no delete function for a contact, company, opportunity or meeting, so erasing one of those records is something we do for you on request rather than something you can do yourself. The record names both rather than describing a policy we do not yet operate.

No change to what data we hold, who we share it with, or how long we keep it.

Supplier List Now Shows Transfer Safeguards and Agreements

The Suppliers and Sub-Processors list, which also appears in our Privacy Policy and in Annex A of the Data Processing Agreement in our Terms, now records two further things for each provider: how a transfer of personal data out of the United Kingdom is safeguarded, and a link to that provider's data processing agreement.

Five entries are recorded so far, each checked against the provider's own agreement: Anthropic, OpenAI and Telnyx rely on the UK International Data Transfer Addendum to the EU Standard Contractual Clauses, and Companies House and Fasthosts process in the United Kingdom only, so no restricted transfer arises.

Where we have not yet recorded a safeguard for a provider, the list says nothing rather than implying one. We would rather show you an incomplete register than a complete-looking one, and the remaining providers are being worked through. Our Privacy Policy wording on international transfers will be made more specific once that work is finished.

No change to which suppliers we use, what we share with them, or where they process it.

Our Own Staff Can Keep Their Browsing Out of the Website Visit Log

The short-lived website visit log records page views by people who are not signed in. Our own staff were already left out of it whenever they were signed in, but a browser they used signed out still appeared in the list alongside genuine visitors. They can now mark such a browser as theirs, from inside our admin area, and it stops being recorded.

This sets a single cookie on that staff browser. It carries no identifier, it is set only by the person using that browser, and it is never set on a visitor's device. Section 12 of the Privacy Policy has been updated to say so rather than state flatly that no cookie is involved. No change to what we record about visitors, how long we keep it, or who can see it.

Automated Authorisation and Vulnerability Testing Introduced

Added an automated test suite that runs before any change is released, and moved two items from the improvement plan to implemented:

Access-control enforcement is now verified automatically. Tests run against a real database and check the full visibility matrix: a person in one organisation cannot reach another organisation's records at all, a standard user sees only the card-level view of a colleague's records, an administrator has full access within their own organisation but none outside it, and coaching records stay visible only to the coach and coachee - including from administrators. Every API endpoint is also checked to confirm it requires authorisation, and the small number of endpoints that are deliberately public (payment and calendar callbacks, email tracking links, opt-out pages) are held to a reviewed list so none can be added by accident.
Third-party software libraries are now scanned automatically for known vulnerabilities with every change. The first run found six published vulnerabilities in the library used to generate PDFs; that library was upgraded and the issues are resolved. Scanning of the wider server environment remains a planned improvement, and is listed as such.

No change to what data we hold, who we share it with, or how long we keep it.

GoCardless Added as a Data Sub-Processor

Invoices raised in Xero are collected by Direct Debit through GoCardless. Your name, email address, billing address and bank account details are shared with them for that purpose. GoCardless now appears on the Suppliers and Sub-Processors page, in the Privacy Policy, and in Annex A of the Data Processing Agreement in our Terms. It was in use before it was listed; listing it corrects that.

AI Provider Keys Encrypted at Rest

The API keys we hold for the AI providers (OpenAI and Anthropic) are now encrypted at rest with AES-256-GCM, the same protection already applied to our other stored credentials and to mailbox and calendar tokens.

These keys are ours rather than any client's, and they were stored unencrypted while the rest of our credentials were not. No client data was exposed by this and we have no indication the keys were accessed, but a credential held in the clear alongside encrypted ones is an inconsistency worth naming rather than quietly closing. The key is also no longer displayed anywhere in the administration screens.

Xero Added as a Data Sub-Processor

We now raise and hold your invoices in Xero, our accounting provider. Your organisation name, billing contact email, billing address, VAT number where you have given one, and the invoices raised against your account are shared with them. Xero is listed on the Suppliers and Sub-Processors page and in the Privacy Policy, and appears in Annex A of the Data Processing Agreement in our Terms. Card payments are taken by the payment provider attached to the Xero invoice; we do not store full card numbers.

Website Visit Log Disclosed

Added a short-lived server-side visit log behind the platform operator's admin dashboard, and documented it in the Privacy Policy (Sections 4.2, 12 and 13):

for each page view by a visitor who is not signed in, the server stores a keyed hash of the IP address (never the raw address), the page path without its query string, the browser user-agent string and the time; no cookie is set
the log shows the operator how many visitors are on the site, which pages are busy, whether a visitor has been here in an earlier session, and where a hash matches an earlier tracked-email click or booking, that the visit could be from that business contact - presented as a possibility, and never for a contact who has opted out of tracking
the lawful basis is legitimate interests; rows are deleted after 30 days

Operator Access and Programme Data Clarified

Following a client vendor assessment, made explicit what was previously only implied:

added a "can Sales Triage staff see our data?" answer: the founder, as platform operator, can access client data for support, maintenance and coaching; nobody else at Sales Triage can; client data is not routinely browsed; operator access is not yet separately logged (already tracked under administrative audit logging on the improvement plan)
named coaching programme submissions, module outputs and reflections among the content sent to AI providers where AI feedback is part of a programme
stated that a coachee's programme submissions sit inside the coach-and-coachee-only visibility rule, alongside coaching notes
corrected the overview page, which still said stored mailbox/calendar tokens were not yet encrypted at rest; they have been field-encrypted (AES-256-GCM) since that control was implemented, as the Security Controls and Continuous Improvement pages already stated

August 2026

Call Recording and Transcription Disclosed

Documented call recording and transcription across the public documentation as the Calling and SMS add-on gained the ability to transcribe recorded calls onto the contact timeline:

added a "does the platform record and transcribe calls?" answer covering what is captured, that calls are recorded for training and quality, where the audio and transcript are held, that there is no in-call announcement, and how the other party can object
added a "Call Recording and Transcription" section to the Privacy Policy setting out legitimate interests as the lawful basis (with reference to the Lawful Business Practice Regulations 2000), the client-as-controller position, retention, and the right to object
noted that call recordings and their transcripts are among the content sent to AI providers, and that OpenAI transcribes recorded calls
added Telnyx as a subprocessor (in-browser calling, call recording, and text messaging), which flows into the Privacy Policy and the Suppliers and Subprocessors page
the recording and transcription permission in the Terms already covered call content (from the earlier meeting-recording change), so no re-acceptance was required

Access Control Within an Account Documented

Documented how access control works between and within organisations, including the scope of AI features, in response to a client due-diligence question about user-level permissions:

added an "Access Control Within an Account" section to the Security Controls page covering tenant isolation between organisations, the organisation-administrator and standard-user roles, the card-only view a standard user has of colleagues' contacts and companies, coachee privacy, and enforcement in the data layer rather than only in the interface
stated plainly that AI features respect the organisation boundary but currently work at organisation scope inside it, so a meeting summary can reference a colleague's linked opportunity within the same organisation
added "within one account, can different users see each other's data?" and "do AI features respect who can see what?" answers to the questions page
added tenant isolation, role-based access, and team/territory rows to the Security Controls summary table
added a continuous improvement item to introduce automated tenant-boundary and access-mode regression tests, since tenant isolation is enforced and runtime-logged today but not yet covered by an automated test

July 2026

Meeting Recording and Transcription Disclosed

Documented the meeting notetaker (which records audio and produces a transcript of online video meetings) across the public documentation, so the processing is disclosed rather than only authorised in the Terms:

added a "does the platform record and transcribe meetings?" answer covering what is captured, that the notetaker joins as a named, visible participant, where the audio and transcript are held, and how attendees can object
added a dedicated "Meeting recording and transcription" section to the Privacy Policy, setting out legitimate interests as the lawful basis where Sales Triage hosts the meeting, the client-as-controller position where a client hosts, retention, and the right to object
noted that meeting transcripts (including those captured by the notetaker) are among the content sent to AI providers
broadened the Nylas subprocessor entry to state it hosts meeting audio recordings and transcripts, not only email and calendar data
clarified in the Terms that the recording and transcription permission covers meeting and call content, and added the client's obligation to inform their own attendees where they host a recorded meeting (Terms v3.4.0)

Login and Access Audit Trail with Security Alerting

The platform now keeps a dedicated login and access audit trail, and alerts the operator to high-signal security events:

successful sign-ins, sign-outs and failed sign-in attempts are recorded, along with tenant boundary violations (an attempt by one organisation's session to reach another organisation's data)
a tenant boundary violation sends an alert email to the operator so it is seen promptly, not left sitting in a log
sign-in is protected against brute-force attacks, with repeated failed attempts rate-limited and locked out, and the operator alerted to sustained attacks
the audit trail has a configurable retention period and a daily prune, and there is an operator-only admin view of the events
moved the login/access audit trail and alerting from Planned to Implemented on the continuous improvement plan, updated the Security Controls Logging, Incident Response and control summary sections, and added a "how would you know if there was a breach?" answer
updated the Terms Annex C measures summary to list the login/access audit trail, targeted alerting and brute-force protection as in place (Terms v3.3.3)
we remain precise that a fully automated, centralised intrusion-detection system across the whole environment is not yet in place; today's alerting is targeted at specific high-signal events

OAuth Mailbox and Calendar Tokens Encrypted at Rest

Stored OAuth tokens for connected mailboxes and calendars are now field-encrypted at rest using AES-256-GCM, the same scheme already used for stored API credentials and integration secrets:

access and refresh tokens for connected email and calendar accounts are encrypted before they are written to the database and decrypted only in memory when a connected action runs
existing tokens were encrypted in place during the upgrade
moved this item from Planned to Implemented on the continuous improvement plan, updated the Security Controls encryption section and control summary, and answered the related due-diligence question
updated the Terms Annex C measures summary to list encryption of stored OAuth mailbox/calendar tokens as in place (Terms v3.3.2)
full-database (volume-level) encryption at rest remains a planned improvement; we continue to be precise that it is not yet enabled

June 2026

Multi-Factor Authentication Implemented

Multi-factor authentication is now enabled for every platform user and enforced at sign-in, including for administrators:

each user completes a second step with an authenticator app (Authy, Google or Microsoft Authenticator) or a one-time code sent to their registered email
users cannot disable multi-factor authentication on their own account
the multi-factor system runs on our own infrastructure, not a separate third-party authentication service, and each user's authenticator secret is stored encrypted at rest
moved multi-factor authentication from Planned to Implemented on the continuous improvement plan, updated the Security Controls page and control summary, and answered the related due-diligence question
updated the Terms Annex C measures summary to list multi-factor authentication as in place (Terms v3.3.1)

Discontinued Chrome Extension Removed from Documentation

The Sales Triage Chrome extension has been discontinued and is no longer offered. Removed all references to it so the documentation reflects what we actually provide:

removed the Chrome extension question from Questions Clients Have Asked
removed the Chrome extension section from the Privacy Policy (and its mention in the scope and the Terms "Platform Services" definition), renumbering the remaining policy sections

Honesty Corrections After a Client Security Review

Following a client due diligence review, corrected and added content so the pages match what is actually built:

export and deletion: replaced an implied automated "export for 30 days then delete" with the honest position (founder-assisted on request today; self-serve export and automated deletion are on the improvement plan), and added a direct "how is my data deleted" answer
added an Article 28 / data processor answer pointing to the Data Processing Terms
added a Logging and Monitoring section distinguishing the operational/activity logging that exists from the security alerting and login audit trail that do not yet
strengthened Incident Response to address breach detection, not only notification, and the processor-to-controller notification duty
added planned improvements for self-serve export, automated account deletion, country-restricted (for example UK-only) access, and a login/access audit trail with security alerting

Suppliers and Infrastructure Updated

added Bunny.net as a subprocessor for hosting and streaming video messages
added Exa as a subprocessor for company discovery and news research
moved offsite backups from Dropbox to UK-hosted Microsoft OneDrive, so backup copies are now held in the United Kingdom
added Fasthosts (UK hosting) and Microsoft OneDrive (UK offsite backup) to the subprocessor list, so the providers that hold platform data are disclosed alongside the other subprocessors rather than in a separate table

Encryption Position Clarified

clarified that stored API credentials and integration secrets are encrypted at rest using AES-256-GCM
documented that full-database encryption at rest is not yet enabled
documented that stored OAuth mailbox and calendar tokens are not yet encrypted at the field level, and added both items to the improvement plan

Initial Security and Transparency Pages Created

Created the initial public Security and Transparency content covering:

current beta hosting position
UK hosting on Fasthosts virtual server
current application and database architecture
HTTPS/TLS
backup approach
production access
AI processing
supplier and subprocessor list
current limitations
continuous improvement plan
client due diligence questions

Current Beta Limitations Documented

Publicly documented current beta limitations including:

no full-database encryption at rest yet
no encryption of stored OAuth tokens yet
no MFA yet
no separate staging environment yet
no independent penetration testing yet
no ISO 27001, SOC 2 or Cyber Essentials certification yet

Continuous Improvement Plan Added

Added a public improvement plan covering priority items including:

full-database encryption at rest
encryption of stored OAuth tokens
MFA
staging environment
backup restore testing
documented RPO/RTO
incident response documentation
infrastructure resilience
independent penetration testing