Security at Voxen

1. Our approach

Voxen aims to use administrative, technical, and organisational safeguards appropriate to the nature of the service and the information being processed. Security considerations should be included in service design, access decisions, vendor selection, operational processes, and incident response.

Specific controls may vary by product, plan, infrastructure, location, and customer agreement. Customers evaluating Voxen for regulated or sensitive use should request the current security documentation applicable to their service rather than rely only on this public overview.

2. Data protection

Our security approach is intended to address areas such as:

• protecting information while it is transmitted and stored, where appropriate;
• limiting collection and retention to information needed for a defined purpose;
• separating customer information and service access where the architecture requires it;
• maintaining backup and recovery processes appropriate to the service;
• disposing of information according to applicable retention requirements; and
• protecting logs, recordings, transcripts, and integration data based on their sensitivity.

The exact handling of call audio, transcripts, messages, and connected-system data depends on service configuration and the applicable agreement. Customers should confirm storage, retention, location, export, and deletion requirements before using Voxen with sensitive information.

3. Access and accounts

Access should be limited to authorised people and systems with a legitimate operational need. Depending on the service, controls may include account authentication, role or permission management, credential protection, logging, and periodic access review.

Voxen personnel and service providers should receive only the access needed to perform their responsibilities. Access should be changed or removed when responsibilities end. Customers remain responsible for their own users, transfer destinations, integration permissions, and account credentials.

4. Service development

Reasonable secure-development practices may include:

• reviewing changes before they are released;
• using automated checks for code quality and known dependency issues;
• keeping supported software and dependencies reasonably current;
• separating development and production access where appropriate;
• protecting secrets and configuration values from public source code; and
• testing important workflows, permissions, and failure paths.

No development process eliminates all defects or vulnerabilities. Findings should be assessed according to risk and addressed within a reasonable period based on severity, exploitability, and potential impact.

5. Monitoring and response

Voxen aims to monitor service health and security signals appropriate to its systems. When a potential incident is identified, the response process should support investigation, containment, recovery, documentation, and measures intended to reduce recurrence.

If an incident affects customer information, notification will be handled according to applicable law and contractual obligations. Customers should keep their administrative and security contact information current so important notices can reach the right people.

6. Service providers

Voxen may rely on hosting, telecommunications, communications, payment, analytics, support, or other service providers. Providers should be evaluated based on the role they perform and the information they process, and should be subject to appropriate contractual and confidentiality obligations.

Third-party integrations selected by a customer have their own security practices, terms, and availability. Customers should review those providers and remove permissions that are no longer required.

7. Customer responsibilities

Customers can reduce risk by:

• using unique credentials and protecting account recovery methods;
• granting access only to current, authorised users;
• reviewing forwarding numbers, transfer destinations, and integration permissions;
• providing accurate call-handling and escalation instructions;
• avoiding unnecessary sensitive information in scripts, prompts, and test calls;
• testing fallbacks before relying on an automated workflow;
• following laws concerning recordings, transcripts, consent, and customer notices; and
• reporting suspected compromise or unexpected service behaviour promptly.

Voxen should not be the sole mechanism for emergency communication or any process where an unavailable or incorrect automated response could create serious harm.

8. Reporting security issues

If you believe you have found a security vulnerability or suspect unauthorised access, report it to hello@voxen.tech, through your account, or through the method in your service agreement.

Include a clear description, affected location or feature, steps to reproduce, and the potential impact. Do not access, alter, download, or disclose information belonging to other people; disrupt the service; use destructive testing; or publish a finding before Voxen has had a reasonable opportunity to investigate and respond.

9. Important limitations

This page is a general overview, not a certification, audit report, warranty, or contractual commitment. It does not claim compliance with a particular standard or regulation. Any required certifications, audit reports, service levels, data locations, recovery targets, or specific technical controls must be verified and documented separately.

Security practices evolve as technology, threats, services, and legal requirements change. We may update this page to reflect material changes in our approach. For information about personal data handling, review the Privacy Policy.