Questions Clients Have Asked
This page answers real due diligence questions clients and prospects have asked about Sales Triage, Revenue Engine, AI, security and data protection.
If one client has asked a useful question, future clients should not have to ask it again.
Where is Revenue Engine hosted?
Revenue Engine is currently hosted on a UK virtual server with Fasthosts.
The web application and database are hosted on the same virtual server. That is a resilience limitation rather than a confidentiality one, and separating them is planned.
Where is client data stored?
Data stored directly in the Revenue Engine platform is currently stored in the UK.
Some third-party services, such as AI providers, may process data outside the UK depending on the feature being used.
Are you a data processor, and do you have an Article 28 agreement?
For client platform data, yes.
Where your organisation stores contacts, prospects, notes, activities, opportunities or emails in the platform, your organisation is the data controller and Sales Triage is the data processor acting on your instructions. Our Data Processing Terms, set out in our Terms and Conditions, are intended to operate as the UK GDPR Article 28 data processing agreement and cover our obligations as processor (security measures, approved subprocessors, assistance with data subject requests, breach notification, and return or deletion of data).
The account-level and usage data we generate to run the service (account administration, billing, security and operational logs) is processed by Sales Triage as a controller. The Privacy Policy explains this split in full.
Is data encrypted in transit?
Yes.
Traffic to the platform is protected using HTTPS/TLS.
Is data encrypted at rest?
Partly, and we are precise about which parts.
Stored API credentials and integration secrets (such as third-party API keys and webhook secrets) are encrypted at rest using AES-256-GCM. Stored OAuth tokens for connected mailboxes and calendars are also encrypted at the field level using AES-256-GCM.
The application database is not yet protected by full-database (volume-level) encryption at rest. That is a planned improvement before wider production use.
If file or document storage becomes a broader part of the service, encryption at rest will be included in the production security plan.
Do you have multi-factor authentication?
Yes. Multi-factor authentication is enabled for every platform user and is required at sign-in, including for administrators.
After their password, each user completes a second step with an authenticator app (for example Authy, Google Authenticator or Microsoft Authenticator) or a one-time code sent to their registered email address. Users cannot disable it on their own account.
Who has access to production systems?
Named individuals only, granted on the basis of what their role requires rather than by default, and protected by multi-factor authentication. Today that is a very small number of people - see "Can Sales Triage staff see our data?" below, which answers the related question of who can see client data. We do not publish the list itself, because it is useful to an attacker and to nobody else.
We are formalising the schedule for reviewing that access, and arranging a defined second pair of hands so continuity does not rest on one person.
Can Sales Triage staff see our data?
Yes, one person can.
As the platform operator, the founder can access client data held in Revenue Engine for support, maintenance and, where your organisation has a coaching relationship with Sales Triage, for coaching. That includes programme submissions and coaching notes. No other Sales Triage staff or contractors have access to the platform or its database.
Client data is not routinely browsed. It is looked at when a client asks for help, when a fault needs investigating, or as part of coaching the client has asked for.
Operator access to client records is not yet separately logged. Clearer administrative audit logging is on the Continuous Improvement page.
Within one account, can different users see each other's data?
Partly, and it depends on the record and the user's role.
Each client organisation is a separate tenant, and no organisation can see another organisation's data. Inside one organisation there are two roles. An organisation administrator can see and manage all of that organisation's records. A standard user has full access to the records they own and a limited card-only view of colleagues' contacts and companies - name, job title, email, phone and who owns the record - while the deeper detail (activity timeline, opportunities, pain analysis, notes and analytics) stays private to the owner and administrators. Coaching relationships, their notes and programme submissions are more restricted again: they are visible only to the owning coach and the coachee.
These rules are enforced in the data layer beneath the interface, not only by hiding things on screen, and both reads and writes are checked against the viewer's role and the record's ownership.
A manager who needs to see everything their team is doing is given the organisation administrator role, which already provides visibility of all records in the organisation. More granular team or territory controls (for example a user restricted to their own pipeline while a manager sees a defined subset of colleagues) are not currently implemented and will be considered based on demand.
Do AI features respect who can see what?
They respect the organisation boundary, and currently work at organisation scope inside it.
AI features never cross between organisations. Inside one organisation, when an AI feature summarises a meeting or drafts a follow-up, it builds its working context from the records linked to that meeting across the organisation. Because contact and company cards are already shared across the organisation, a summary of a meeting you ran can reference a linked opportunity owned by a colleague in the same organisation. We do not currently narrow the AI's working context to only the individual user's own records within their organisation, and we would rather state that plainly than imply a per-user AI boundary that is not in place.
Do you have separate development, staging and production environments?
Yes. There is a separate staging environment, and changes are deployed there before they reach production.
How are backups handled?
Revenue Engine uses weekly full backups and daily incremental backups.
Backups are held on the server and also copied offsite to UK-hosted Microsoft OneDrive.
Restoring from backup has been tested. Backup retention, and how often the restore is re-tested, are being formalised.
Have you tested restoring from backup?
Yes, most recently in September 2026. A working copy of the platform was brought up from backup and confirmed to run, so we know the backups work rather than assuming it.
We repeat that test at least annually, because a restore that worked once is evidence about one moment rather than a standing guarantee.
How quickly could you recover the service if the server failed?
The realistic recovery target is within 24 hours, grounded in a restore we have actually performed.
This is a practical recovery target, not a formal uptime SLA.
Have you assessed the risks of recording meetings and calls?
Yes. We hold a data protection impact assessment covering the four activities where we are the controller and where the risk is highest: recording and transcribing calls, the meeting notetaker on meetings we host, prospecting and enrichment, and email open and click tracking. Each one processes people who are not our users and in most cases did not come to us, which is what makes an assessment necessary rather than optional.
It scores the risks from the individual's point of view rather than ours, maps each measure to the risk it actually reduces, and names the measures that would reduce the remaining risks but are not yet in place. The conclusion is that we can proceed with the residual risks recorded and accepted, and that the position does not require prior consultation with the Information Commissioner.
It is an internal document and we do not publish it, but we will provide it to a client or their auditor on request.
Do you keep a record of your processing activities?
Yes. We maintain a record of processing activities under Article 30 of the UK GDPR, covering both sides of our role: 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.
For each activity it records the purpose, the lawful basis, the categories of people and data involved, who receives the data, where they process it, what safeguards any transfer out of the United Kingdom, and how long we keep it.
The record is maintained 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 and cannot drift apart from them. Where a transfer safeguard has not yet been recorded for a provider, the record says so rather than leaving a gap that looks filled.
It is an internal accountability document rather than a published page, and we provide it to a client's auditor or to a regulator on request.
Are you ISO 27001 certified?
No.
Sales Triage is not currently ISO 27001 certified.
We are familiar with ISO 27001 and have experience operating businesses with security certifications, but the current Sales Triage entity does not hold ISO 27001 certification.
Are you SOC 2 certified?
No.
Sales Triage is not currently SOC 2 certified.
Do you have Cyber Essentials?
No.
Cyber Essentials is under review as a proportionate next step.
Have you completed penetration testing?
No independent penetration test has been completed yet.
Independent testing is planned before accepting larger enterprise clients or before wider production use.
We do run our own automated security tests before releasing any change: checks that the access-control rules hold (including that one organisation cannot reach another's data), that every API endpoint requires authorisation, and that the third-party software libraries we build on have no published vulnerabilities. That is useful, but it tests the rules we already know about. It is not the same as an independent tester trying to find the ones we have not thought of, which is why independent testing remains on the plan.
Is client data used to train AI models?
No.
Client content submitted through Revenue Engine AI features is not used to train AI models under the commercial API services used by Sales Triage.
Which AI providers do you use?
The AI providers currently in use are Anthropic and OpenAI.
The provider used may vary by feature and may change as the service evolves. If we engage a new AI provider, it is added to the supplier and subprocessor list, and we route personal data to it only once it is engaged under an appropriate data processing agreement.
Can AI providers process data outside the UK?
Yes.
AI providers may process data outside the UK, including in the United States.
Where international transfers occur, Sales Triage relies on appropriate contractual safeguards where required.
Where are video messages stored?
Video messages recorded in the platform are hosted and streamed by a specialist video provider rather than on the application server.
The video and audio you record, along with the video title and thumbnail, are processed by that provider to host and play back the message. The provider is listed on the Suppliers and Subprocessors page.
Does the platform record and transcribe meetings?
Where it is enabled, a meeting notetaker can join your online video meetings (for example Zoom, Microsoft Teams, or Google Meet) to capture an audio recording and produce a written transcript. Video is not recorded.
The notetaker joins as a visible participant with a name that shows a notetaker is present (for example "[Name]'s Notetaker (powered by Sales Triage)"), so it is not hidden from attendees. The host chooses whether to record, and can choose not to.
The transcript is stored against the meeting record and is processed by our AI providers (see AI and Data Processing) to produce summaries and follow-up actions. The audio recording is held by our meeting provider (Nylas) behind time-limited links; we do not keep the audio file on our own servers.
A recording and transcript capture what everyone on the call says, including people who are not platform users. Where Sales Triage hosts the meeting, we are the controller and rely on legitimate interests, and attendees can object. Where one of our clients hosts the meeting, that client is the controller and is responsible for informing their own attendees; Sales Triage acts as the processor. The Privacy Policy explains this in full.
Does the platform record and transcribe calls?
Where the Calling and SMS add-on is enabled, calls a user makes or receives through the in-app phone can be recorded, and the recording is transcribed to text so the conversation appears on the relevant contact's timeline. Calls are recorded for training and quality purposes.
The audio recording is held by our telephony provider (Telnyx); we transcribe it through our AI provider (OpenAI, see AI and Data Processing) and store the transcript against the call record. A recording and transcript capture what both people on the call say, including people who are not platform users.
We do not play a separate in-call announcement. There is no legal requirement in the United Kingdom to announce a recording when you are a party to the call, and recording is disclosed in our Privacy Policy and Terms; our people may also mention it at the start of a conversation. Where Sales Triage records its own calls, we are the controller and rely on legitimate interests; our assessment of that balance is available on request, and the other party can object. Where one of our clients records calls, that client is the controller and is responsible for informing the people they call; Sales Triage acts as the processor. The Privacy Policy explains this in full.
Does Revenue Engine read my whole mailbox?
No.
Where email functionality is enabled, Revenue Engine connects to the user's chosen mailbox for the functionality authorised by the user.
The platform does not operate as a separate bulk sending service and does not monitor general mailbox content outside authorised functionality.
How would you know if there was a breach?
A fair question, and we answer it honestly rather than claiming a full monitoring suite we do not have.
The platform keeps a login and access audit trail: successful sign-ins, sign-outs, and failed sign-in attempts are recorded, along with any tenant boundary violation (an attempt by one organisation's session to reach another organisation's data - something that should never happen in normal use). A tenant boundary violation sends an alert email to our operator so it is seen promptly. Sign-in is also protected against brute-force attacks, with repeated failed attempts rate-limited and locked out, and the operator alerted to sustained attacks.
What we do not yet have is a fully automated, centralised intrusion-detection system across the whole environment. Our alerting today is targeted at specific high-signal events rather than general anomaly detection, and broader monitoring is on the Continuous Improvement plan. Alongside our own logging, we also rely on alerts from the providers and infrastructure we use.
What happens if you discover a data breach?
Sales Triage will investigate, contain and assess the incident, following a written runbook rather than working it out at the time. The runbook sets out who decides, what gets contained first, when the notification clock starts, and what our detection would and would not have caught - that last part matters, because "we found no evidence" means less from a system with narrow alerting than from one with full monitoring, and we would rather say so in an assessment than imply otherwise.
Where client data is affected, Sales Triage will notify affected clients where required by law or contract and support clients with any related regulatory obligations.
Sales Triage will follow UK GDPR breach notification requirements.
Can clients export their data?
Yes, with our help today.
Our terms provide for client platform data to be exportable around termination (the Privacy Policy describes a 30-day window) and then deleted. Today this is handled manually on request: we will produce and return a copy of the client's platform data. A self-serve export is a priority improvement and is on the Continuous Improvement plan; we would rather say that plainly than imply a one-click export that is not built yet.
What happens if a client leaves Sales Triage?
Client platform data is handled in line with the applicable terms and data processing terms.
In practice today, on termination we will return a copy of the client's platform data on request and then delete it. We are formalising this into a documented, time-bound process - a self-serve export followed by an automated deletion step - as a priority improvement (see Continuous Improvement).
Someone has asked us to erase their data. What happens?
Send the request to us with the email address it came from and we action it.
Where you are the controller, the request is yours to answer and we assist you, as our Data Processing Agreement sets out. What we do on our side is remove that person from the platform: their contact record is anonymised, their email addresses and phone numbers are removed, notes and call transcripts about them are cleared, and they are removed from the enrichment cache that sits behind our prospecting features. That cache is shared across all clients and keyed to external identifiers, so it needs clearing separately; until recently it did not get cleared at all, and we would rather say that than leave it unsaid.
Activity records themselves are kept but stripped of the person: the row, who did the work and when stays, so your reporting does not change, while the content identifying the individual goes.
Three things we do not do automatically, and tell you about instead. A meeting transcript records what everyone on the call said, so erasing one attendee would destroy the other attendees' data and your own record of the meeting - we review those with you rather than blanking them. Audio held by our meeting and telephony providers has to be removed in their own systems. And anything already sent to an AI provider sits in their limited abuse-monitoring window, normally up to around 30 days, and ages out on its own.
One current limitation worth knowing: nothing yet prevents a future prospecting run finding that person again from a data provider. A suppression list is on our improvement plan.
How is my data deleted if we decide not to proceed?
If you decide not to continue, we will delete your platform data and confirm once it is done.
Today that deletion is carried out manually by the founder on request rather than by an automated, time-bound process. A documented, automated deletion process (with a self-serve export available beforehand) is a priority improvement. Copies held in backups age out on the normal backup rotation rather than being individually removed.
What happens to my data if Sales Triage winds down?
You would be able to obtain a copy of your platform data so you can move it to another system.
This is a fair question for any small supplier, and we would rather answer it directly. The platform data you store is yours; if we wound the service down, we would make your data available for export and then delete it. As above, export is founder-assisted today, with a self-serve export on the improvement plan.
Do you sell personal data?
No.
Sales Triage does not sell personal data.
Do you process special category data?
Revenue Engine is not intended to process special category data.
Users should not submit special category data unless this has been expressly agreed in writing.
What happens if a government or the police ask for our data?
We have a written procedure for this, and it is public: see Government Requests.
The short version. We do not give voluntary access for surveillance or law enforcement purposes, we disclose only where a valid legal instrument compels us and only the minimum it requires, and we challenge a request that is overbroad, defective or served on the wrong party. Where the data is yours rather than ours, we tell the requesting body it belongs to a client and direct them to you.
We tell you when someone asks for your data, unless we are legally prohibited from telling you. Where a non-disclosure restriction applies, we ask for it to be lifted or time-limited, and we review it every year.
We have never received a request of this kind.
Are you subject to laws that could require you to hand data to a government?
Yes, as is every company in every country.
Sales Triage is a United Kingdom company with no overseas entities, so UK law applies: principally the Investigatory Powers Act 2016, the Police and Criminal Evidence Act 1984, the Crime (Overseas Production Orders) Act 2019 and the Data Protection Act 2018. Some of our suppliers are established in the United States and may be subject to US lawful access powers including FISA Section 702 and the CLOUD Act.
Being subject to those laws is not the same as cooperating freely with them. What we actually do when asked is on the Government Requests page.
Do you use our live data in testing?
No, not as a matter of course. Staging and development run on test data created for the purpose, not on copies of the live platform, so building and releasing the platform does not involve client personal data leaving production.
The exception is a fault that only appears with the content that caused it. If you report one and send us the file or record involved, we may need to work with it to find the fault. When that happens we use an isolated test environment rather than staging or production, we anonymise it as far as we can without destroying the thing being tested, we keep it to what the investigation needs, we do not fold it into any test dataset we keep, and we remove it once the investigation is closed.
The honest limit on anonymisation: we can usually replace names and contact details, but not the structure or formatting that triggered the fault, because removing that would remove the fault.
See Security Controls for where this sits in our development process.
Will you make us change our passwords every few months?
No, and that is deliberate rather than an omission.
Forced password expiry and character-composition rules are both advised against by the National Cyber Security Centre and by NIST. Making people change a password every ninety days produces predictable variations of the same password rather than stronger ones, and composition rules push people toward the patterns an attacker already expects.
What we do instead: multi-factor authentication is enforced for every user and cannot be turned off on your own account, repeated failed sign-ins lock the account, and every attempt is recorded. The enforced minimum length is eight characters, applied on the server rather than only in the browser. Raising that minimum is on the improvement plan, and we would rather say so than claim a longer one than we apply. See Security Controls.
What is your uptime?
We do not publish an uptime percentage, because we do not run continuous availability monitoring, and we would rather say that than quote a number we have not measured. External monitoring is on the improvement plan.
No uptime commitment applies unless one is agreed in a Services Schedule. What we do hold is a recovery objective: service restored within 24 hours of a primary server failure, grounded in a restore we have actually performed and repeat at least annually.
What protects the machine you work from?
It is not a privileged machine. It holds no standing access to the live platform, no VPN and no credential that works by virtue of the device itself, so reaching your data from it means signing in with multi-factor authentication exactly as anyone else would. Possession of the machine grants nothing.
Full-disk encryption is on, the operating system blocks unsigned software and runs built-in malware detection with automatically updated signatures, and security patches install automatically. No removable media is used in any part of the service.
We do not run a third-party anti-virus product, device management or remote wipe. For one machine those are not proportionate, and we would put them in place before anyone else was given access to client data. The full position is on Security Controls.
What should happen when a new question is asked?
If a client asks a new security, privacy or AI question:
- answer the client directly
- add the question here if it is useful to future clients
- update the relevant page if the answer changes public documentation
- add an improvement item if the question exposes a gap
- add a changelog entry if public documentation changes