ECHO / SECURITY STANDARDS
Protect access. Limit authority. Be clear about what is verified.
ECHO’s approach to security connects technical controls with a simple operating rule: understanding a request does not, by itself, grant permission to act.
Explore the standards01 / IMPLEMENTED CONTROLS
These controls describe the current hosted implementation. Their scope matters: a control protecting one type of information is not a guarantee about every system or deployment.
The Voice Readiness Lab requires a signed-in account. Administrative operations check the account’s current role and active status on the server before allowing access.
Authentication and authorization are separate checks.
Passwords are salted and hashed. Session tokens are cryptographically random and stored as hashes. Session cookies use HttpOnly and SameSite settings, with Secure enabled in production. Repeated sign-in and verification attempts are rate limited.
Sessions expire after 30 minutes without authenticated activity or 12 hours overall. Role changes revoke existing sessions.
Administrator accounts must confirm each sign-in with a time-based code from an authenticator app before any administrative access is granted. Any account can turn on the same protection, and customer workspace administrators need it to make workspace changes. Single-use recovery codes are stored only as hashes.
Authenticator secrets are encrypted at rest; codes cannot be reused.
Credentials saved through ECHO’s managed integration vault are encrypted with AES-GCM, using a random initialization vector and a separately configured vault key. Customer content stored in the workspace is also encrypted, with a separate data key for each organization.
Not every operational record is encrypted this way; ask about a specific record type before relying on it.
Administrative changes enforce same-origin checks. Database queries use bound parameters, and supported service connections validate their authorization callbacks or signed requests. Pages are served with a strict Content Security Policy and cannot be framed by other sites.
Each integration has its own permissions and verification requirements.
The production database is backed up nightly. Backups are encrypted before they are stored and are deleted after 90 days. A daily job removes workspace transcripts once they pass the retention period each workspace chooses.
Deleted data can remain in backups until those backups expire.
02 / AI & ACTION BOUNDARIES
ECHO’s governed design separates what a model suggests, what an integration can do, what is permitted, and what actually happened.
03 / DATA HANDLING
Depending on the feature, ECHO can process transcripts, conversation context, test feedback, and review records. Lab history may also be held in the browser. Consider shared-device access and use fictional or redacted information for formative testing.
Enabled model, speech, hosting, and business-service providers may process information needed for the requested functionality. Their terms, settings, and retention practices form part of the deployment’s data handling.
Optional and off by default for every organization. Only the customer’s own administrator can turn it on, with a recorded attestation; ECHO staff cannot. ECHO masks identifiers before storing shared material, limits client learning to patterns across several conversations, and uses nothing until the customer’s administrators approve it. The approved understanding is context only and never grants authority. Customers choose retention, can turn the feature off, and can delete everything at any time. It is never used to train AI models or shared with another organization. See the Privacy Policy.
Before using sensitive or regulated data, confirm the permitted data types, integration scopes, retention and deletion arrangements, and applicable agreements for that deployment. This page does not set a universal retention period or promise zero retention by every provider.
04 / ASSURANCE & SCOPE
This page is an implementation overview and a statement of ECHO’s governing standards. It is not an independent audit, penetration-test report, or certification.
No SOC 2, ISO 27001, HIPAA, or other compliance or certification claim is made here. A provider’s assurance does not automatically extend to ECHO or a customer’s deployment.
Security hardening and validation remain ongoing. Production readiness also depends on the configured infrastructure, account protections, monitoring, recovery procedures, and the specific use case. Review these requirements with ECHO before a production rollout.
05 / SECURITY INQUIRIES
For a security question, deployment review, or suspected vulnerability, use ECHO’s contact page. Share a brief description and a way to reach you; ask to arrange an appropriate channel before sending sensitive details.
Contact ECHO about securityKeep passwords, access tokens, customer records, and sensitive exploit details out of the initial message.