Security Controls
This page explains the current security posture of the Sales Triage Revenue Engine.
It distinguishes between controls that are currently implemented during beta and controls planned as the platform moves towards wider production use.
Current Beta Hosting
Revenue Engine is currently hosted on a UK virtual server with Fasthosts.
During beta:
- the web application is hosted on the virtual server
- the database is hosted on the same virtual server
- application data is held in the UK
- the setup is intentionally simple while the product is validated
Before wider production use, Sales Triage intends to move towards a more resilient architecture, including separation of application and database services.
Data Location
Data stored directly in the Revenue Engine platform is currently stored in the UK.
Some third-party services, including AI providers and other subprocessors, may process data outside the UK depending on the feature being used. This is explained further in AI and Data Processing and Suppliers and Subprocessors.
Encryption in Transit
All traffic to the platform is protected using HTTPS/TLS.
Encryption at Rest
We are precise about what is and is not encrypted at rest today, because the honest position is mixed.
What is encrypted at rest now:
- 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 encrypted at the field level using AES-256-GCM
What is not yet encrypted at rest:
- the application database is not yet protected by full-database (volume-level) encryption at rest
File and document storage is not currently a major part of the beta platform, with the exception of video messages, which are hosted with a specialist video provider (see Suppliers and Subprocessors). If broader file or document uploads become part of the service, encryption at rest will be included in the production security plan.
Full-database (volume-level) encryption at rest is a planned improvement before wider production use.
Password Security
Passwords are stored as hashes and are not stored in plain text.
Production Access
Production system access is currently limited to the founder.
This reduces the number of people who can access the production environment during beta.
As the platform grows, access control will be formalised further with named administrative roles, stronger authentication and documented access review processes.
Access Control Within an Account
Access control operates at two levels: between organisations, and between users inside one organisation.
Between organisations (tenant isolation): each client organisation is a separate tenant. Every request is bound to the signed-in user's organisation, and every data query is scoped to that organisation. An attempt by one organisation's session to reach another organisation's data is blocked and recorded as a tenant boundary violation, which also sends an operator alert (see Logging and Monitoring). This boundary is enforced in the data layer, not only in the interface.
Within one organisation, there are two roles:
- an organisation administrator can see and manage all records belonging to their organisation
- 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). The deeper detail on a colleague's record - the activity timeline, opportunities, pain analysis, notes and analytics - stays private to the owner and to administrators
Coaching data is more restricted still: a coaching relationship and its notes are visible only to the coach who owns it and to the coachee, and are not exposed to other administrators.
These rules are enforced beneath the interface, in the data and service layer, rather than only by hiding elements on screen. Both reads and writes check the viewer's role and the record's ownership before data is returned or changed. Ownership changes and access grants are recorded in the activity and audit trail.
A manager who needs oversight of a whole team is given the organisation administrator role, which already provides visibility of all records in the organisation. Finer team, territory or group controls (for example a user restricted to only their own pipeline while a manager sees a defined subset of colleagues) are not currently implemented beyond this administrator-sees-all and user-owns-their-own model. They will be considered based on demand.
AI features respect the organisation boundary but currently work at organisation scope inside it. When an AI feature summarises a meeting or drafts a follow-up, it builds its context from the records linked to that meeting within the organisation, so a summary of a meeting you ran can reference a linked opportunity owned by a colleague in the same organisation. AI features never cross the organisation boundary. We do not currently narrow the AI's working context to only the individual user's own records inside their organisation; because contact and company cards are already shared across the organisation, this is intended behaviour for now and is documented here rather than left implied.
Logging and Monitoring
We are precise about what exists today, because logging and active security monitoring are not the same thing.
What exists now:
- operational error logging for diagnostics
- an activity and audit trail of changes inside the platform (for example record changes, contact creation and merges, ownership changes, and access grants)
- a dedicated login and access audit trail: successful sign-ins, sign-outs and failed sign-in attempts are recorded, along with tenant boundary violations (an attempt to reach another organisation's data)
- targeted security alerting: when a tenant boundary violation is recorded, an alert email is sent to the operator so it is seen promptly rather than sitting in a log
- brute-force protection on sign-in (repeated failed attempts are rate-limited and locked out), with the operator alerted to sustained attacks
- logs of external API calls made on a user's behalf
What is not yet in place:
- centralised, automated intrusion detection across the whole environment (a full security monitoring system). Our alerting today is targeted at specific high-signal events rather than a general anomaly-detection system.
Detection today relies on the login/access audit trail and targeted alerting above, the operational logging, and alerts from the providers and infrastructure we use. Broader automated intrusion detection is a planned improvement.
Multi-Factor Authentication
Multi-factor authentication is available to every platform user and is enforced at sign-in, including for administrators.
After entering their password, each user completes a second step using 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 multi-factor authentication on their own account.
The multi-factor system runs on our own infrastructure rather than a separate third-party authentication service, and each user's authenticator secret is stored encrypted at rest.
Email and Calendar Access
Where email or calendar functionality is used, Revenue Engine connects to the user's chosen provider through authorised integration mechanisms.
The platform does not operate as a separate bulk email service.
Email messages are sent through the user's own connected mailbox where that functionality is enabled.
Backups
Revenue Engine currently uses:
- weekly full backups
- daily incremental backups
- backup copies held on the server
- offsite backup copies held in UK-hosted Microsoft OneDrive
Backup retention is being formalised as part of the security improvement plan.
A formal restore test has not yet been completed and documented. This is a priority improvement.
Recovery Objective
If the primary server failed during beta, the realistic recovery target is to restore service within 24 hours.
This is a practical beta-stage recovery target rather than a formal contractual uptime commitment.
Development, Staging and Production
Revenue Engine currently operates without a separate staging environment.
Changes are managed carefully and production can be rolled back quickly when needed.
A separate staging environment is planned before wider production use to reduce deployment risk.
Security Testing
No independent penetration test has been completed yet.
Independent security testing is planned before accepting larger enterprise clients or before wider production use.
Certifications
Sales Triage does not currently hold:
- ISO 27001 certification
- SOC 2 certification
- Cyber Essentials certification
- Cyber Essentials Plus certification
Sales Triage is familiar with these standards and has experience operating businesses with security certification, but the current Sales Triage entity does not currently hold them.
Cyber Essentials will be reviewed as a proportionate next step.
Incident Response
A fair question during supplier review is not only "will you tell us", but "how would you know". We answer both honestly.
Detection today relies on the login and access audit trail and targeted alerting described above (sign-in activity, failed sign-ins, brute-force lockouts, and tenant boundary violations that email the operator), together with the operational and activity logging and alerts from the providers and infrastructure we use. Broader, fully automated intrusion detection across the whole environment is a planned improvement, not something we claim to have in place yet.
If Sales Triage discovers a security incident affecting client data, we will:
- investigate the incident
- take appropriate containment action
- assess the impact
- notify the affected client, who is the controller for their platform data, without undue delay, so they can meet their own obligations
- notify affected individuals or regulators where we are required to
- support clients with any regulatory obligations that arise
As a processor, our role is to detect what we reasonably can, contain it, and inform the controller promptly. Sales Triage will follow UK GDPR breach notification obligations, including notification without undue delay where required.
Current Control Summary
| Area | Current Position |
|---|---|
| UK hosting | Implemented |
| Tenant isolation between organisations | Implemented |
| Role-based access within an organisation (administrator / standard user) | Implemented |
| Team or territory access controls within an organisation | Not currently implemented |
| HTTPS/TLS | Implemented |
| Password hashing | Implemented |
| Encryption of stored API credentials and secrets (AES-256-GCM) | Implemented |
| Founder-only production access | Implemented |
| Weekly full backups | Implemented |
| Daily incremental backups | Implemented |
| Offsite backup copy | Implemented |
| Operational and activity/audit logging | Implemented |
| Full-database encryption at rest | Not yet enabled |
| Encryption of stored OAuth mailbox/calendar tokens | Implemented |
| Login/access audit trail | Implemented |
| Targeted security alerting (tenant boundary violations) | Implemented |
| Brute-force protection on sign-in | Implemented |
| Centralised, fully automated intrusion detection | Not yet enabled |
| Country-restricted (for example UK-only) access | Not yet enabled |
| Multi-factor authentication (all users, enforced at sign-in) | Implemented |
| Separate staging environment | Not currently implemented |
| Independent penetration testing | Not currently completed |
| ISO 27001 | Not currently certified |
| Cyber Essentials | Not currently certified |