SignalHOT reads support and customer data to score churn, escalation, success and growth signals. That means we take on your customers' data, and you are right to ask how it is handled. This page states what is true today.
The short version. Our connectors are read-only, so SignalHOT cannot change anything in your helpdesk or CRM. Credentials are encrypted with a key held separately from our login keys. Every customer organisation is isolated on the server, on every request.
1. We never write to your systems
Our connectors to Zendesk, Salesforce and ServiceNow are read-only by design. There is no code path in SignalHOT that creates, updates or deletes a record in your helpdesk or CRM. The only outbound request our connectors make is the authentication exchange required to obtain a token.
Whatever SignalHOT concludes about a customer, it cannot change a ticket, reassign a case, email your customer, or alter a CRM record on your side. Recommendations are drafted for a human to send.
2. Credentials and encryption
- Connector credentials - API tokens, client secrets and refresh tokens - are encrypted with Fernet (AES with an HMAC integrity check) before they are written to the database. The API never returns a stored secret; it returns only a flag indicating whether one is set.
- The data-encryption key is separate from the key used to sign login tokens. The production API refuses to start if the dedicated encryption key is absent, so a token-signing key can never double as the key protecting your credentials.
- Production secrets are held in Google Secret Manager and referenced by the service at runtime. They are not stored in configuration files or in source control, and access is granted per secret rather than across the project.
- All traffic to the application, the API and the marketing site is served over HTTPS with managed certificates. Data at rest in the database is encrypted by the cloud platform.
3. Authentication and access control
| Control | Implementation |
|---|---|
| Password storage | bcrypt with a unique per-password salt. Plaintext passwords are never stored or logged. |
| Sessions | Signed JSON Web Tokens, HS256, expiring after 8 hours. |
| Password reset | Single-use tokens that expire after 60 minutes. |
| Brute-force protection | Rate limits on sign-in, registration and password-reset endpoints. |
| Roles | Role-based access control. Administrative functions, connector configuration and scoring-model pages are restricted to administrator roles. |
| Account approval | Self-registrations are created inactive and require an administrator to approve them before sign-in. |
| API surface | Every data endpoint requires a valid token. Interactive API documentation is disabled in production. |
4. Tenant isolation
Every customer organisation is a separate tenant, and effectively every record carries its tenant identity. Isolation is enforced on the server for each request - a signed-in user's queries are constrained to their own tenant, and an attempt to reach another tenant's record is refused rather than filtered out silently. Records that have no tenant column of their own, such as contacts and case interactions, inherit it through a required link to a parent record and cannot be detached from it.
5. Infrastructure, backup and recovery
- SignalHOT runs on Google Cloud Platform. The application and API run on Cloud Run; data is held in Cloud SQL for PostgreSQL. Production data currently resides in the United States (us-central1).
- Automated daily database backups are enabled, together with point-in-time recovery.
- We do not currently publish an uptime commitment or a service level agreement. If you need one as a contractual term, raise it during evaluation so we can address it explicitly rather than by implication.
6. AI processing and subprocessors
SignalHOT's scoring models run inside our own infrastructure. Written recommendations produced by the AI Advisors are generated by a third-party language model, which means the relevant customer and case attributes for that recommendation are transmitted to that provider. We think you should know exactly who touches your data:
| Subprocessor | Purpose |
|---|---|
| Google Cloud Platform | Application hosting, database, secret storage, backups |
| Anthropic | Generating the written recommendation and draft email text for AI Advisor output |
| Google Workspace | Transactional email - alerts, notifications, password resets |
A current subprocessor list is provided with our Data Processing Agreement and we will notify you of changes to it. If you prefer that no customer data reaches a language-model provider, the AI Advisors can be left disabled - the signal scoring, dashboards and alerts continue to work without them.
7. Your data stays yours
- We process your data to provide the service to you. We do not sell it, and we do not use one customer's data to train models used for another customer.
- You can export or request deletion of your data at any time. On termination we delete tenant data on request, subject to backup retention cycles.
- Read-only demonstration environments are marked as such in the product and cannot be modified.
8. How we work on security
- We run periodic internal security reviews of the codebase and track findings to closure. A summary of our current posture and any open items can be shared under NDA during evaluation.
- Connector credentials can be rotated or revoked by you at any time; disconnecting a connector removes the stored credentials.
- Changes are deployed from version-controlled source; production configuration and secrets are managed separately from application code.
9. Documents available on request
- Mutual Non-Disclosure Agreement
- Data Processing Agreement, including the subprocessor list
- Security architecture overview
- Completed security questionnaire - we will complete your standard form, or supply CAIQ-Lite responses
10. Security enquiries and responsible disclosure
SignalHOT Inc. regards the security, confidentiality and integrity of the data entrusted to it by its customers as a matter of the highest priority. Security is addressed as a continuing obligation in the design, review and operation of the platform, and the measures described on this page are maintained and reviewed on that basis rather than as a point-in-time exercise.
Security documentation. Requests for security documentation - including the security architecture overview, a completed security questionnaire, a Mutual Non-Disclosure Agreement or a Data Processing Agreement - should be directed to security@signalhot.com. Materials containing non-public information are made available following execution of a non-disclosure agreement.
Reporting a vulnerability. If you believe you have identified a security vulnerability affecting SignalHOT, please report it to security@signalhot.com, including sufficient detail to permit us to reproduce and assess the issue. We will acknowledge receipt within five (5) business days, keep you informed of our assessment and of any remediation undertaken, and notify you when the matter has been resolved.
Coordinated disclosure. In making a report, we ask that you: (a) test only against accounts and data belonging to you; (b) make no attempt to access, modify, retain or disclose the data of any other customer beyond the minimum necessary to demonstrate the issue; (c) refrain from any activity liable to degrade, interrupt or impair the service, including denial-of-service testing, high-volume automated scanning, and social engineering directed at our personnel or customers; and (d) allow a reasonable period for remediation before any public disclosure.
Where a report is made in good faith and in accordance with the above, SignalHOT will treat the activity as authorised examination of the service, and will not initiate or support legal action against the reporter in respect of that research. SignalHOT does not currently operate a paid vulnerability reward programme, and no offer of payment is made or implied by this section.
Contact
All security enquiries, documentation requests and vulnerability reports: security@signalhot.com.
Last updated: September 2026. This page describes the service as it stands today and will be revised as our posture changes.