Security Controls
This page explains the current security posture of the Sales Triage Revenue Engine.
It distinguishes between controls that are in place today and controls that are planned, and says which is which rather than blurring them.
Hosting
Revenue Engine is currently hosted on a UK virtual server with Fasthosts.
Today:
- 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
The key for both is held in the server's filesystem, deliberately apart from the database holding the encrypted values, so a copy of the database alone does not reveal a credential. That key is now a dedicated secret used for nothing else. It was previously derived from the platform's own authentication keys, which are a value that hosting control panels regenerate as part of routine security hardening - so a maintenance action taken for good reasons could leave us unable to read our own stored credentials. Separating the two removes that coupling. The encryption itself is unchanged; what changed is which key it uses and who can disturb it.
A client protection list is handled differently again, and not by encryption. When an organisation tells us which companies are its existing clients so that nobody in it can prospect them, we keep only a one-way fingerprint (HMAC-SHA256 under a secret key held outside the database) and discard the address. Encryption can be reversed by whoever holds the key; this cannot be reversed by anyone, including us. The trade-off is deliberate: we can check whether a company is on the list, and we cannot produce the list.
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 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 never kept in plain text or in any recoverable form.
The enforced minimum is eight characters, applied on the server rather than only in the browser, so it cannot be stepped around by submitting the form directly. Credentials we generate ourselves, for invited users and provisioned accounts, are twenty-four characters including symbols.
We do not force password expiry and we do not impose character-composition rules. That is a decision rather than an oversight. Both are advised against by the National Cyber Security Centre and by NIST, because 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. The controls that do the real work are multi-factor authentication, which we enforce for everyone, and protection against repeated guessing, which we apply at sign-in. Failed attempts are recorded in the login and access audit trail and repeated failures lock the account.
Raising the enforced minimum above eight characters is on the improvement plan. We would rather say that than describe a longer minimum than the one actually applied.
Endpoint and Device Security
The machine used to operate the platform is not a privileged one. It holds no standing access to the live environment: no VPN, no persistent session, no credential that grants access by virtue of the device itself. Reaching client data means signing in over HTTPS with multi-factor authentication, exactly as it does for anyone else. Possession of the machine grants nothing.
Client data lives on the server. The platform runs in a browser, and there is no desktop or mobile application keeping a local copy in step with it. Where a file is on the machine at all it is a deliberate artefact, an exported report or a document a client has sent, rather than a copy of the platform.
On the device itself:
- full-disk encryption is enabled, so anything held locally is encrypted at rest
- the operating system enforces code signing, so unsigned software is blocked from running by default
- built-in malware detection is active, with signatures updated automatically by the vendor and independently of operating system releases
- security patches install automatically, while major operating system upgrades are applied manually after review
No removable media is used in any part of the service. Nothing is written to a USB drive, an external disk, optical media or tape at any point, and removable media forms no part of our backup, transfer or recovery process.
What is not in place, said plainly: no third-party anti-virus or endpoint detection product, no mobile device management, no remote wipe, no data loss prevention tooling, and no technical block on removable media. For a single machine those are not proportionate, and a management agent carries its own privilege and its own attack surface. They become the right controls once there is a fleet rather than a device, and they would be in place before anyone else was given access to client data.
Production Access
Access to production systems is restricted to named individuals, granted on the basis of what a role actually requires rather than by default. Today that is a very small number of people. We do not publish who they are, because that list is useful to an attacker and to nobody else.
Access is protected by multi-factor authentication, and every sign-in to the platform is recorded in the login and access audit trail described under Logging and Monitoring.
Two things we are formalising rather than claiming: a documented schedule for reviewing who holds access and removing what is no longer needed, and a defined second pair of hands, so that continuity does not depend on one person being available. Both are on the improvement plan.
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, its notes and the coachee's programme submissions 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 person's role is read from the database on every request rather than cached into their session. An administrator who removes someone's access, or drops them from administrator to standard user, has that take effect on the person's next request, not at their next sign-in and not when a cache expires. This matters on the day someone leaves.
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 full restore has been carried out and documented, most recently in September 2026: a working copy of the platform was brought up from backup and confirmed to run, so the backups are known to work rather than assumed to. The restore is re-tested at least annually, because a restore that worked once is evidence about one moment rather than a standing guarantee. Backup retention is still being formalised.
Recovery Objective
If the primary server failed, the realistic recovery target is to restore service within 24 hours. That figure is grounded in a restore we have actually performed rather than estimated.
It is a practical recovery target rather than a contractual uptime commitment, and we would rather state one we can meet than one that sounds better.
Availability and Performance
We do not measure uptime as a percentage, because we do not run continuous availability monitoring. We would rather say so than publish a figure we have not measured. External uptime monitoring is on the improvement plan.
No uptime commitment applies unless one is expressly agreed in a Services Schedule. The platform is provided on an "as is" and "as available" basis under our Terms, and the recovery objective above is a practical target grounded in a restore we have performed rather than a contractual service level.
The platform runs on a single virtual server rather than a fleet that grows and shrinks with load, and capacity is increased by resizing that server. We have not load tested it to a published concurrency figure.
Response time for AI features is governed by the AI provider rather than by our own infrastructure, and is measured in seconds rather than milliseconds. That is inherent to asking a model to write something, not a sign of a slow system.
Development, Staging and Production
Revenue Engine has a separate staging environment, and changes are deployed there before they reach production.
An automated test suite also runs before a change is released, including the access-control and library vulnerability checks described under Security Testing below, and production can be rolled back quickly if something does get through.
Data Used Outside Production
Staging and development are not populated with copies of live client data. They run on test data created for the purpose, so the ordinary work of building and releasing the platform is done without client personal data leaving production.
There is one exception, and we would rather state it than leave it implied. Some faults only appear with the content that caused them, and a client who reports one may send us the file, message 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, and we anonymise it as far as we can without destroying the thing being tested. Names, addresses and contact details can usually be replaced; the structure or formatting that triggered the fault usually cannot, because changing it would remove the fault.
Where that happens, the data is limited to what the investigation needs, it is not merged into any test dataset we keep, and it is removed once the investigation is closed. We are acting as processor on the client's behalf when we do this, so it is covered by the Data Processing Agreement in our Terms in the same way as the rest of the service.
Security Testing
Two kinds of automated security testing run before any change is released:
- Access-control tests. These check the visibility rules against a real database: that one organisation cannot reach another's records, that a standard user sees only the card-level view of a colleague's records, that an administrator's access stops at their own organisation, and that coaching records stay private to the coach and coachee. Every API endpoint is also checked to confirm it requires authorisation, and the small number that are deliberately public is held to a reviewed list so none can be added by accident.
- Library vulnerability scanning. The third-party software libraries the platform is built on are checked against published vulnerability advisories.
These are our own automated checks. They catch mistakes in rules we already know about; they are not a substitute for someone independent trying to break in.
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.
This is now a written runbook rather than an intention: who decides, what gets contained first, when the clock starts, who must be told and by when, and what our detection would and would not catch. It is reviewed after any incident. We do not publish it, because a document describing how we would respond and where our blind spots are is more useful to an attacker than to you, but we will walk a client through it on request.
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 |
| Enforced minimum password length | Implemented |
| Forced password expiry | Not used, by design |
| Full-disk encryption on the operating machine | Implemented |
| Removable media in any of our processes | Not used |
| Third-party endpoint protection product | Not in use |
| Continuous uptime monitoring | Not yet enabled |
| Encryption of stored API credentials and secrets (AES-256-GCM) | Implemented |
| Credential encryption key held separately from platform authentication keys | Implemented |
| Restricted, named production access | Implemented |
| Documented access review schedule | Being formalised |
| 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 |
| Automated authorisation and tenant-boundary testing before release | In place |
| Automated scanning of software libraries for known vulnerabilities | In place |
| Written incident response runbook | 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 | Implemented |
| Test data rather than live data outside production | Implemented |
| Documented restore from backup | Implemented |
| Independent penetration testing | Not currently completed |
| ISO 27001 | Not currently certified |
| Cyber Essentials | Not currently certified |