Changelog

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

August 2026

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