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
What is not yet encrypted at rest:
- the application database is not yet protected by full-database (volume-level) encryption at rest
- stored OAuth tokens for connected mailboxes and calendars are not yet encrypted at the field level
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 encryption at rest and field-level encryption of stored OAuth tokens are planned improvements 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.
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)
- logs of external API calls made on a user's behalf
What is not yet in place:
- a dedicated login and access audit trail
- centralised security alerting or automated intrusion detection
Centralised security alerting and a login/access audit trail are planned improvements. Until they are in place, detection relies on the operational logging above and on alerts from the providers and infrastructure we use.
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 operational and activity logging described above and on alerts from the providers and infrastructure we use. Automated intrusion detection and centralised security alerting are planned improvements, 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 |
| 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 | Not yet enabled |
| Login/access audit trail and security alerting | 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 |