Changelog

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

November 2026

LinkedIn Outreach Can Read Your Connections for Mine My Network

We are testing a change so that Mine my network can read a person's LinkedIn connections straight from their account, instead of asking them to download their data from LinkedIn and upload the Connections.csv file. Unipile returns each connection's name, profile link, headline and the date they connected, and we match the headlines against that person's Commercial Blueprint. The list is held only while they choose who to bring in, and is gone 30 minutes after the run last moved on; only the people they pick are kept, as contacts in their CRM, along with the date of their newest connection so that next time we show only people they have connected with since. Like the rest of LinkedIn Outreach, only WP administrators can reach it at the moment, and it still only reads: it never posts, comments, connects or sends messages. The subprocessor list now says this.

LinkedIn Outreach Can Tick Off a Playbook's LinkedIn Steps

We are testing a change so that a LinkedIn connect or message step in a playbook ticks itself off once it has been sent. The person still sends it on LinkedIn themselves: My Day copies their wording and opens the contact's profile, and they paste it in. Afterwards, for that one step, Unipile reads their pending invitations, searches their connections for that contact's name, or reads their LinkedIn messages with that contact. We keep only what they sent, as an activity on the contact's timeline, and nothing else from those reads. Like the rest of LinkedIn Outreach, only WP administrators can reach it at the moment, and it still only reads: it never posts, comments, connects or sends messages. The subprocessor list now says this.

LinkedIn Outreach No Longer Runs People Searches

We are testing a narrower version of LinkedIn Outreach. Its own page, with saved people searches checked every day and a list of posts matching keyword searches, has gone, and the people those searches found have been deleted. What it does now happens inside the deal and contact pages: it finds which of your LinkedIn connections also know the contacts on a deal, so you can ask for an introduction, and it can fill in a new contact from their LinkedIn profile link. You connect your account in your Settings, on the Outreach tab. Neither of those keeps anything unless you save the person as a contact. Like the rest of LinkedIn Outreach, only WP administrators can reach it at the moment, and it still only reads: it never posts, comments, connects or sends messages. The subprocessor list now says this.

LinkedIn Outreach Can Read the Posts of Your Own Contacts

We are testing a change to LinkedIn Outreach so that it can tell a person when someone on their pipeline, or someone they have chosen to watch, posts on LinkedIn. To do that, Unipile now also receives the LinkedIn profile links of those contacts and returns their recent posts. Like the rest of LinkedIn Outreach, only WP administrators can reach it at the moment. It still only reads: it never posts, comments or sends messages. We keep a post for 30 days, as before, and a post and the record of when we last read someone are deleted with that contact if they ask to be erased. The subprocessor list now says this.

Video Replies on Help Requests Are Kept in a Locked Library

We are testing video replies on help requests, so that someone can answer a question by recording a short video instead of typing. At the moment only WP administrators can record one. These videos are held by Bunny.net, the same supplier and the same London and Frankfurt storage as video messages, but in a separate library that only plays a video through a link we sign for one of the two people on the request, and that link expires after a few hours. Video messages you send to contacts are unchanged. A video reply is deleted 90 days after it is sent, and a recording that is never sent is deleted the next day.

We No Longer Describe Sales Triage as Being in Beta

Several of these pages said improvements were planned "before wider production use". Now that the product is out of beta, that wording no longer means anything, so we have removed it rather than leave a condition you could not hold us to.

This does not change what is in place. Full-database encryption at rest and an independent penetration test are still planned and still not done, and these pages continue to say so. Independent testing remains planned before we accept larger enterprise clients.

The Last Supplier Agreement Is Signed, and Our Transfer Wording Is Now Specific

Tavily, which searches the web for company news when you research a prospect, has signed our data processing agreement, dated 5 November 2026. That was the last supplier on our list without one, so every provider that handles personal data for us is now covered by a written agreement. Only company names and search terms are ever sent to Tavily, never your contacts' details.

With that in place, we carried out a transfer risk assessment for the providers that process data outside the UK (in practice, the United States), and we made our wording on international transfers more specific. Our Privacy Policy and our Data Processing Terms now say that we hold a named transfer mechanism for each provider - recorded against that provider in the subprocessor list - rather than describing the safeguards in general terms. For Tavily, that mechanism is the UK International Data Transfer Addendum.

Because this sharpens a clause in the Data Processing Terms (now v5.1.1), you may be asked to re-accept the Terms next time you sign in. Nothing about your obligations or the service has changed; the wording is simply more precise about safeguards that were already in place.

Unipile Added as a Supplier for an Optional LinkedIn Feature

We have added Unipile to our supplier list. It connects a person's LinkedIn account for LinkedIn Outreach, an optional feature in testing that only WP administrators can reach at the moment, so no client data goes to Unipile today. Before anyone can use it they accept a risk statement for their own account, because Unipile works through LinkedIn's private interface and LinkedIn has not approved it. The feature only reads: it never posts, comments or sends messages. We hold what a search finds for 90 days and posts for 30, and that data stays private to the workspace. We have not yet requested Unipile's data processing agreement, and will before the feature is released.

Our Email and Calendar Provider's Data Is in London, Not the EU

A correction to the October entry about Nylas, who connect your inbox and calendar and power the meeting notetaker. We said our account is set to their Europe region and that your data sits in a European data centre. Nylas have since confirmed that their EU region is hosted in London. So the data is stored in the United Kingdom, not the European Union. That is better news than we gave, because storage in the UK is not a transfer out of the country at all, but what we wrote was wrong and the supplier page now says London.

They also answered the questions we listed as outstanding:

The region cannot be changed quietly. In October we said the region setting was doing the protective work, and we asked whether it could be changed without us being told. It cannot be changed at all. Moving region means setting up a new account with them and every user connecting their inbox again, which nobody could miss.

How long they keep things. Meeting recordings and transcripts are deleted by Nylas after 14 days. We copy the transcript into the platform as soon as it is ready, so this does not affect what you see. For a mailbox connected by IMAP rather than Google or Microsoft, they keep a rolling copy of the most recent 90 days of messages. Their database backups run every four hours and are kept for 7 days. The Privacy Policy's retention table now says all of this.

What the agreement covers. They confirmed that the signed agreement applies to our self-serve account, and that it covers email content, calendar data, and notetaker audio and transcripts, not only the example categories it lists.

Their SOC 2 Type 2 report is available through their Trust Center rather than sent on request. Our checks on suppliers rest on the signed agreement rather than on certificates, so we have not downloaded it, but the agreement gives us the right to it and we will obtain it if a client review needs it.

October 2026

First-Year Value Now Has a Definition, and It Is Recurring Fees Only

Terms v5.1.0. The success fee has always been charged on the first-year value of a qualifying deal, and the Terms never said what first-year value meant. They now do, and the definition is narrower than the phrase on its own might have been read.

It is the recurring fees payable to you in the twelve months after you sign, whether you bill them monthly, quarterly or annually in advance. Setup, implementation, onboarding, migration, configuration and training fees are not counted, and neither is a one-off piece of project or professional services work, nor expenses, disbursements or VAT. Where a deal has no recurring element at all, no success fee is payable on it.

This narrows what is payable rather than widening it, and it settles in advance an argument that would otherwise have to be had one deal at a time. Nothing else about the success fee changed: the rate and the period are still the figures stated in your Schedule, the test for a qualifying organisation is the same, and it is still paid in twelve monthly instalments.

Billing Moves in Front of the Service Period, and Three Standing Arrangements Move into the Terms

Terms v5.0.0. Most of this change moves wording out of individual contracts and into the Terms, so that an arrangement every client shares is written down once instead of being retyped into each Schedule. Where the two documents said the same thing in different words, they could drift apart and disagree. Now the Terms say what something means and a Schedule states only the figures that differ between clients.

Invoices now arrive before the period they pay for. A recurring invoice is issued ahead of its service period by the length of your payment terms, so it falls due on or before the first day of that period. Alongside it, two things tightened, and both are worth saying plainly rather than leaving to be discovered. Invoices are now due fourteen days from the date of the invoice rather than fourteen days from receipt, because a due date both sides can work out from the document is the only kind that can be billed against in advance. And where an invoice is unpaid at its due date we may suspend the service it relates to, where previously there was a further fourteen days of grace. For anyone who pays on time the only visible effect is one invoice arriving about two weeks earlier than usual, once, as the change takes effect.

One billing date for each client. It is the day of the month you first had access, and everything you hold is billed on it, on one invoice. A schedule, seat or plan that starts mid-month is charged pro-rata for the remainder of that month rather than starting a second billing cycle of its own. A seat added mid-month is invoiced at the point it is added and may be held until that invoice is paid. A seat removed mid-month stops at the next billing date and the rest of the paid month is not refunded.

Three arrangements are now described in the Terms: platform seats and calling plans, outreach programmes, and the success fee. How they work has not changed. Where they are written down has. Your Schedule now carries the numbers that are yours, such as the rate, the minimum term or the capacity, and the Terms explain what each of those numbers means.

Two smaller changes. VAT is now dealt with in the Terms rather than restated at the foot of every Schedule, and it covers prices published on the platform as well, which a Schedule could never reach. And where these Terms are accepted on behalf of an organisation, the person accepting now warrants that they can bind it. That second one is not a change of position so much as writing down what was already assumed: a Terms update binds by being published and the service going on being used, and it cannot vary the fees or scope of a Schedule already in force, so what one individual clicks has never been what moves your commercial agreement.

The list of what an outreach programme needs from you moved the same way, from the back page of a Schedule into the Terms. It has not changed: a mailbox on your own domain for the SDR, your blueprint signed off, the playbooks agreed, two named contacts with their calendars connected, and answers on objections within two working days.

Two rules inside them are genuinely new. Where an outreach programme has not started within six months of your access date, it is treated as having started then, because the minimum term runs from the outreach start date and a term measured from a date that never arrives has no end. And where a qualifying deal is not notified to us within the period stated, or a quarterly confirmation says there was none when there was, we may invoice the whole success fee at once instead of across twelve months. Paying in instalments is a concession offered on the basis of being told, so it is the concession that falls away rather than a penalty being added.

Our Stored Credentials No Longer Depend on a Key the Hosting Panel Can Change

On the morning of Saturday 10 October, an automated security-hardening action on our hosting control panel regenerated the platform's authentication keys. That is normally a sensible thing for such a tool to do. In our case it also changed the key our stored API credentials were encrypted under, and every one of them became unreadable in the same instant. Integrations that depend on them stopped working until the credentials were re-entered.

No personal data was exposed, and none was lost. This was an availability failure, not a confidentiality one. The encrypted values stayed exactly where they were and stayed encrypted; what was lost was our own ability to decrypt them. No client data was disclosed to anyone, and no client record was deleted or altered.

Two things were wrong, and both are fixed. The first is that credential encryption was keyed to a value that exists for a different purpose and that platform tooling treats as safe to rotate. Credentials are now encrypted under a dedicated key used for nothing else, which no maintenance action touches. The second is that nothing told us. The failure was recorded in an internal log and nowhere else, so it was found by noticing that features had stopped working rather than by being informed. An unreadable credential now raises an alert in the administration area and sends an email, and the setup checklist distinguishes "saved but unreadable" from "not yet configured" instead of quietly reporting a broken credential as an unfinished task.

The wider lesson is the one worth recording: a system that fails silently will be found late, and the time to decide how you will hear about a failure is before it happens rather than after.

Our Email and Calendar Provider Now Has a Signed Data Processing Agreement, and Your Data Sits in Europe

Two changes to the supplier entry for Nylas, who connect your inbox and calendar and power the meeting notetaker. They are the provider holding the most sensitive data in our supply chain, so this is the one worth reading.

There is now a signed Article 28 agreement, executed on 8 October 2026. There was not one before. Their standard terms apply by default to self-serve accounts and reference no processing agreement at all, which meant the provider handling email content, calendar data and meeting transcripts was the one we had the least contractual cover with. We said so on the supplier page by leaving the agreement field empty rather than quietly filling it. It is now signed, and it carries a 72-hour breach notification to us, an annual SOC 2 Type 2 audit report on request, deletion at termination, and security measures including AES-256 encryption at rest and annual independent penetration testing.

The transfer position has changed, and improved. We previously relied on their certification under the UK Extension to the EU-U.S. Data Privacy Framework. The signed agreement incorporates the UK Addendum to the EU Standard Contractual Clauses, signed for both Module Two and Module Three, so it covers data we control and data we process on behalf of a client. More significantly, our account is configured to their Europe region: application data, connector data and grant information are stored in their European data centre, the EU and US regions are isolated, and the only routine transfer out of the region is a support engineer reading error logs on a support ticket.

So the honest description of where this data lives has moved from "United States and European Union" to European storage with narrow, purpose-limited access from outside. The supplier page now says that.

One thing we are watching. The region setting is doing the work here, not a clause. Moving the account out of the Europe region would widen what crosses the border without anyone touching a contract. We have recorded it as a control rather than a preference, and asked the provider to confirm who can change it and whether we would be told. It is the same lesson our video provider taught us in September.

Five Things a Supplier Review Asked That These Pages Could Not Answer

Working through an enterprise supplier review surfaced questions these pages had no answer to, or only a one-line one. Rather than answer them privately and move on, they are now here.

Endpoint and device security, which was missing entirely. What the machine used to operate the platform actually is, and what it is not: not a privileged machine, holding no standing access to the live environment, with full-disk encryption, enforced code signing, automatically updated malware detection and automatic security patching. No removable media is used anywhere in the service. The absences are stated too: no third-party anti-virus product, no device management, no remote wipe, no data loss prevention.

Password policy, which previously said only that passwords are hashed. It now gives the enforced minimum, where that minimum is applied, the length of credentials we generate, and why we do not force password expiry or impose composition rules, which is a decision with reasoning behind it rather than something we forgot.

Availability, which was implied by the recovery objective but never stated. We do not measure uptime as a percentage because we do not run continuous monitoring, no uptime commitment applies unless one is agreed, and AI response time is governed by the AI provider rather than our infrastructure.

How we assure our suppliers, which was the half of the supplier page nobody could see. Every supplier must declare five things, an entry missing any of them is flagged to us rather than rendering as a blank line, gaps are worked in order of how much personal data each supplier handles, and a new supplier gets its terms before client data is routed to it.

One detail worth stating: a person's role is read fresh on every request rather than cached into their session, so removing someone's access takes effect on their next request rather than at their next sign-in. That matters on the day someone leaves.

What Data We Use Outside Production, Including the Exception

Security Controls now says what staging and development run on, and Questions Clients Have Asked carries the same answer.

The position: staging and development are not populated with copies of live client data. They run on test data created for the purpose.

The exception, which we would rather state than leave implied: some faults only appear with the content that caused them, and a client who reports one may send us the file or record involved. Where reproducing it is the only way to find the fault, we work with it in an isolated test environment rather than in staging or production, anonymised as far as we can without destroying the thing being tested. We can usually replace names and contact details. We usually cannot replace the structure or formatting that triggered the fault, because removing that would remove the fault.

Where it happens, the data is limited to what the investigation needs, it is not folded into any test dataset we keep, and it is removed once the investigation closes.

This was written down because a supplier review asked whether production data can be refreshed into non-production environments. The accurate answer was no, with one narrow exception, and an exception nobody has written down is not one a client can hold us to.

A Written Procedure for Government and Third-Party Requests for Data

There is a new section on these pages, Government Requests, setting out what we do when a government body, law enforcement agency, regulator or court asks us for data.

It says that we give no voluntary access for surveillance or law enforcement purposes, that we disclose only where a valid legal instrument compels us and only the minimum it requires, and that we challenge a request that is overbroad, defective or served on the wrong party. It sets out the five checks we run on any request, in order, and what we do when one of them fails.

The part that matters most to a client is the distinction between data we hold for you and data we hold about you. Records you store in the platform are yours, and a request for them should be served on you rather than on us. Where that happens we decline and direct the requesting body to you. We also tell you when someone asks for your data, unless we are legally prohibited, and where a non-disclosure restriction applies we ask for it to be lifted or time-limited and review it every year.

The page also names the UK laws we are subject to, rather than leaving a reviewer to assume. Being subject to lawful access powers is not the same as cooperating freely with them, and the distinction is worth writing down.

We wrote this because a client asked, during a supplier review, whether we maintained such a procedure. We did not. The honest answer to "what would you do if the police asked for our data?" should not be invented on the day it happens. We have never received a request of this kind, and if that changes the page changes.

Two questions covering the same ground have been added to Questions Clients Have Asked.

Terms Updated: What a Service Schedule Can Say, and Notice of Fee Changes

We have published a new version of our Terms, so you will be asked to accept them again. There are four changes and one smaller one.

A Service Schedule can now carry more, but it can never override the Terms. A Schedule used to be limited to scope and pricing, with anything else in it having no effect unless both parties signed it separately. That carve-out meant a signature could in principle make anything in a Schedule binding, which is not how we want to do business. It is gone. A Schedule may now set out the scope of work, the fees and how they are invoiced, dates and timelines, a minimum term and notice period, and what we need from you in order to deliver. Anything beyond that is void, whether or not both sides have signed it. The Terms always win.

A Schedule can state a minimum term. Where it does, notice to end that Schedule can be given at any time but takes effect at the end of the minimum term rather than before it, and afterwards the usual 30 days applies. Fees paid in respect of a minimum term are not refundable. Where a Schedule states no minimum term, nothing changes for you.

We can change the fees in a Schedule on 30 days' written notice. If you do not want to accept a new fee, you can end that Schedule by giving notice before the new fee takes effect, and the existing fee continues to apply until that happens. Apart from a change you and we agree together, this is the only way a fee in a Schedule can move.

Updating these Terms no longer affects a price you have already agreed. The fees and scope set out in a Schedule that is already in force are not varied by a later update to these Terms.

The smaller change: where work under a Schedule has not started and the first invoice is still unpaid 30 days after it was issued, we can withdraw that Schedule, and nothing is payable under it.

Download These Pages as a PDF or as Markdown

You can now take a copy of this whole area away with you. There is a Download as PDF link on the page, which produces every section as one branded document, and a Download as Markdown link beside it, which produces the same content as a plain text file.

Both carry a version number, and the version is worked out from the content itself rather than being something we remember to update. That means it changes when, and only when, something on these pages changes. If you file a copy during a supplier review and come back in six months, you can compare the version on your copy with the one shown here and know immediately whether anything has moved.

The markdown version exists because a growing number of people review a supplier's security posture by giving it to an AI model rather than reading it themselves. We would rather hand you something a model reads cleanly than have the structure mangled by extracting it from a PDF. We would also rather you reviewed us properly, by whatever means suits you.

Terms Updated: Honest Wording on Sensitive Data in Transcripts

We have published a new version of our Terms, so you will be asked to accept them again. Two changes, and this is what they are.

Annex B previously said we process no special category data. Special category data is the sensitive kind: health, religion, trade union membership and so on. That statement was not true for any account using the meeting notetaker or call recording. People mention a health problem, a religious holiday or a family matter in ordinary conversation, and a transcript keeps it. Nobody chose to store it, which is exactly why telling clients not to submit it did not solve the problem.

The replacement says what is actually the case: it is not sought and not required, clients are still instructed not to submit it deliberately, but incidental capture in a transcript is possible where recording is on. Such content is never used to profile anyone or make decisions about them, and it carries the same protections and deletion rights as everything else.

Annex C, which summarises our security measures, has been brought up to date. It now includes the staging environment, the tested restore, the written incident response runbook and restricted named production access. It also states plainly what is not in place: full-database encryption at rest, independent penetration testing, centralised intrusion detection, separation of the database from the application server, and self-serve export and deletion. It previously described itself as a beta-stage posture; it now simply describes the position.

We held the Annex B wording back until there was a second reason to publish, so that you are asked to re-accept once rather than twice in quick succession.

These Pages No Longer Lean on the Word "Beta"

Our security pages used to explain several things by saying they were a beta-stage position: the simple architecture, the single server, the absence of penetration testing, the recovery target. That framing was doing too much work. It let a limitation read as a temporary choice rather than as something you should weigh before deciding, and it would have quietly become untrue the moment we stopped using the word.

So every one of those now stands on its own. Where we have since built the control, it says so. Where we have not, it says that plainly, with the reason and what we intend to do, and without a stage label softening it. The clearest example is the overview page, which now lists what is in place and then, just as prominently, what is not: no independent penetration test, no full-database encryption at rest, the application and database still on one server, no centralised intrusion detection, no certifications.

Nothing about our actual security changed in this update. What changed is that you can now read any one of these statements without needing to know what stage we consider ourselves to be at.

Earlier entries on this page still refer to beta. Those are a record of what we said at the time and we have deliberately left them alone.

Staging, a Tested Restore, and Clearer Wording on Access

Three updates, two of them things we had listed as planned and have now done.

There is a separate staging environment. Changes are deployed there before they reach production, alongside the automated tests that already ran before release.

Restoring from backup has been tested and documented. We previously said plainly that it had not been, because an untested backup is a hope rather than a control. It has now been carried out, so we know the backups work. How often that test is repeated is being formalised, since a restore that worked once tells you about one moment rather than every moment.

Clearer wording on production access. We previously said access was limited to the founder. That was true and remains close to true, but the honest shape of it is better described as: access is restricted to named individuals, granted on what a role actually requires, protected by multi-factor authentication, and recorded in the sign-in audit trail. We do not publish who holds it, because that list is useful to an attacker and to nobody else. Two things we are formalising rather than claiming: a documented schedule for reviewing that access, and a defined second pair of hands so continuity does not depend on one person. The separate question of who can see client data is answered unchanged on the Questions page.

You Can Stop Your Clients Being Prospected Without Giving Us the List

If your organisation sells to companies it already serves, that is an awkward conversation nobody wants to have. You can now upload the website addresses of your existing clients, and from that point nobody in your organisation can add them as a prospect and our prospecting tools never put them forward.

The part worth explaining is what we keep. We do not store the addresses you upload. Each one is turned into a one-way fingerprint and only the fingerprint is kept, so there is no client list on our systems to be read, leaked, or handed over. A simple hash would not have been good enough - there are only a few hundred million registered domains in the world, so anyone who obtained our database could work through them and recover the list. The fingerprint is computed under a secret key held outside the database, which is what makes it genuinely one-way rather than merely inconvenient.

The honest cost of that choice is that we cannot show the list back to you. There is no screen listing your protected clients, no export, and no edit. To remove a company you type its address again and we remove the matching fingerprint. We would rather accept that than hold something we have told you we do not hold.

A match does not stop the company being in your CRM. It stops them being a prospect. Someone adding a protected company gets them as an existing client instead, and all the ordinary work - contacts, meetings, opportunities, renewals - carries on as normal. Blocking the record outright would have left a client you genuinely need to work with no way in at all.

Using a Client as an Example Is Now Something You Choose

Our "find companies like our best clients" feature learns from your existing clients, and to do that it sends a client's website address to a discovery provider. Until now, any company marked as an existing client in the CRM was eligible, which meant a field nobody associated with disclosure quietly decided what we shared.

That is now opt-in per company and off by default. A company is only used as an example if someone ticks it, either while uploading a client list or on that company's own page, and the tick says plainly what it means: we keep the name and address as they are, and may share the address with a provider to look for similar companies.

If you were already using this feature, it will ask you to tick your examples once before it works again. We decided against switching existing clients on automatically, because that would have been us assuming a consent nobody had actually given.

September 2026

A Word of Caution Where Recording Is Switched On

Recording a meeting or a call captures everything said, by everyone present, and a transcript keeps whatever people mention in passing. That can include things they would not have chosen to write down: a health problem, a religious holiday, something personal about their family.

We now say so at the point where recording is switched on, rather than only in our legal documents. Choosing to send the AI Notetaker to a meeting carries a note that it records everyone on the call and that it may not be appropriate for every conversation. The Calling and SMS setup screen carries a stronger one, because calls are recorded without an announcement at the start, which makes the organisation using those lines responsible for telling the people it rings.

We are not changing what is captured, and we do not use any of it to profile anyone or make decisions about them. The change is that the caution appears where the decision is made.

Our Terms still describe special category data as not occurring, which is not quite right for accounts using recording, and we are correcting that wording. We have held the change back so that it goes out with the next Terms update rather than asking everyone to re-accept twice in a fortnight.

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 was stated plainly when this was first published: nothing then stopped a later prospecting run finding that person again from a data provider. That has since been addressed. Erasing someone now records a suppression first, so their details are not added back if a provider returns them later, and asking a sender to stop contacting you is honoured for that sender in the same durable way.

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