Continuous Improvement
This page explains the security and operational improvements Sales Triage intends to make as the platform matures.
The purpose of publishing this page is not to pretend everything is already complete. It is to show clients what exists today, what is planned next and why those improvements matter.
Priorities may change as the platform, client requirements and risk profile evolve.
Already in Place
| Outcome | Control or Practice | Status |
|---|---|---|
| Keep platform data in the UK | UK hosting on Fasthosts virtual server | Implemented |
| Protect data in transit | HTTPS/TLS enforced | Implemented |
| Protect stored credentials | API keys and integration secrets encrypted at rest (AES-256-GCM) | Implemented |
| Reduce password exposure | Passwords stored as hashes | Implemented |
| Limit privileged access | Production access restricted to a small number of named individuals, under multi-factor authentication | Implemented |
| Support recovery | Weekly full backups | Implemented |
| Reduce data loss risk | Daily incremental backups | Implemented |
| Reduce local backup dependency | Offsite backup copy held in UK-hosted Microsoft OneDrive | Implemented |
| Provide legal privacy transparency | Published Privacy Policy | Implemented |
| Reduce deployment risk | Separate staging environment, with changes deployed there before production | Implemented |
| Know the backups work | Full restore to a working system, carried out and documented (most recently September 2026), repeated at least annually | Implemented |
| Respond consistently to an incident | Written incident response runbook, reviewed after any incident | Implemented |
| Evidence what we process and why | Article 30 record of processing activities, maintained in code so it cannot drift from the supplier list | Implemented |
| Assess the risk of our most intrusive processing | Data protection impact assessment covering call recording, the notetaker, prospecting and engagement tracking | Implemented |
| Respond properly to a request for data from a public authority | Written procedure for validating, challenging and minimising government and third-party requests, including when and how we tell the affected client | Implemented |
| Clarify controller and processor roles | Privacy Policy explains data protection roles | Implemented |
| Improve supplier transparency | Published supplier and subprocessor page | Implemented |
| Catch authorisation mistakes before release | Automated test suite covering every API endpoint's authorisation requirement and the access-control matrix | Implemented |
High Priority Improvements
These are the highest priority items because they are likely to reduce real client risk and answer common supplier review questions.
| Outcome | Improvement | Current Status |
|---|---|---|
| Protect stored client data | Enable full-database encryption at rest for database storage | Planned |
| Protect connected accounts | Encrypt stored OAuth mailbox and calendar tokens at the field level (AES-256-GCM) | Implemented |
| Reduce attack surface | Offer restriction of platform access to approved countries (for example UK-only) | Planned |
| Protect future file uploads | Ensure file and document storage is encrypted at rest before wider use | Planned |
| Reduce account compromise risk | Enforce multi-factor authentication for all users, including administrators | Implemented |
| Improve recovery clarity | Document backup retention, RPO and RTO | Planned | | Measure availability | External uptime monitoring, so availability can be stated as a measured figure rather than not stated at all | Planned | | Strengthen password requirements | Raise the enforced minimum password length above its current eight characters | Planned |
| Improve breach detection | Add a login/access audit trail and targeted security alerting (tenant boundary violations) | Implemented | | Reduce account-attack risk | Brute-force protection on sign-in (rate-limiting and lockout of repeated failed attempts) | Implemented | | Improve breach detection | Add centralised, fully automated intrusion detection across the environment | Planned | | Improve infrastructure resilience | Separate database from application server | Planned |
Medium Priority Improvements
| Outcome | Improvement | Current Status |
|---|---|---|
| Validate security posture | Commission independent penetration testing | Planned before larger enterprise use |
| Verify access-control enforcement automatically | Automated tenant-boundary and access-mode regression tests (cross-organisation access denied, standard user limited to a card-only view of colleagues' records, coachee data hidden from other administrators), run against a real database before every change is released | Implemented |
| Improve vulnerability management | Automated scanning of third-party software libraries for known vulnerabilities, run with every change | Implemented |
| Improve vulnerability management | Extend vulnerability scanning to the server and wider environment, not only software libraries | Under review |
| Improve supplier confidence | Evaluate Cyber Essentials certification | Under review |
| Improve governance maturity | Review ISO 27001 suitability as the business scales | Future consideration |
| Improve auditability | Add clearer administrative and client audit logging | Under review |
| Improve access governance | Introduce documented access review process | Planned as team grows |
| Support data portability | Provide a self-serve export of a client's full platform data (a manual export is available on request today) | Planned |
| Support clean offboarding | Automate a time-bound account deletion process on termination (handled manually on request today) | Planned |
| Action an erasure request completely | Tool that finds and removes an individual's data across every organisation and the shared enrichment cache, and lists what still needs doing by hand | Implemented |
| Keep an erasure permanent | Suppression so a later prospecting run cannot rediscover someone who asked to be removed | Implemented |
Not Currently Planned
| Item | Reason |
|---|---|
| ISO 27001 certification | Not proportionate to our current size, and we would rather spend the same effort on controls that reduce real risk. To be reviewed as the client base grows |
| SOC 2 | Not currently asked for by our UK-focused client base. To be reviewed if that changes |
| Enterprise SSO | To be reviewed if clients require it |
| Formal uptime SLA | To be reviewed after production architecture matures |
How This Page Should Be Maintained
When an item is completed:
- move it into the implemented section
- update the relevant security page
- add a changelog entry
- add or update any relevant question in Questions Clients Have Asked
When a client asks about a risk not covered here:
- answer the client directly
- add a question and answer if useful to future clients
- add an improvement item if the question exposes a gap