Security and Compliance

Keywave is a product of Blocra, Inc. As a voice verification platform, we treat security and privacy as core requirements of the Service.

Keywave is early stage. We use reputable infrastructure providers and implement practical safeguards that are appropriate for our current maturity, while working toward more formal security programs over time. This page describes our current posture at a high level and outlines planned improvements.

This page is informational and does not create contractual obligations. Commitments, if any, are defined in our customer agreements and policies.

1. Security Overview

Our approach is based on three themes:

• Risk reduction: reduce the likelihood and impact of common threats
• Layered controls: apply protections at infrastructure, application, and data layers
• Privacy focused design: minimize sensitive data exposure where possible

2. Data Handling and Privacy Design

2.1 Voice Data

Keywave processes voice samples to produce derived representations used for verification. Our design aims to minimize retention of raw audio in production environments and focus on derived representations and related metadata needed for verification workflows.

2.2 Data Minimization

• We aim to collect and retain only what is necessary to operate and secure the Service
• We separate operational data (account, billing, configuration) from verification artifacts where feasible
• Access to sensitive data is restricted based on need

2.3 Retention and Deletion

Retention depends on data type and operational needs. We describe general retention practices in our Privacy Policy, and we work with Customers on deletion and retention requirements where feasible.

3. Encryption and Protection

3.1 Encryption in Transit

Data is transmitted using HTTPS with modern TLS configurations. The Service does not expose API traffic over unsecured endpoints.

3.2 Encryption at Rest

Our infrastructure providers offer encryption at rest for managed storage systems. Exact encryption controls depend on the specific provider service and configuration.

3.3 Secrets Management

• Secrets are stored using managed secret storage where available
• Access is restricted to systems and personnel that require it
• We support rotation of sensitive keys and credentials

4. Access Controls

4.1 API Access

API requests are authenticated using project scoped API keys. Customers are responsible for securing keys, rotating them when needed, and avoiding client side exposure.

4.2 Internal Access

• Access to production systems is limited
• We aim to apply least privilege principles
• We use multi factor authentication for critical services where supported
• We maintain separation between development and production environments

5. Monitoring and Abuse Prevention

We use logging and monitoring to support reliability and security operations. This may include tracking API usage patterns, rate limiting, and investigating suspicious activity.

6. Incident Response

We maintain incident response procedures appropriate for our current stage and continuously improve them. In the event of a security incident involving Customer data, we aim to:

• Investigate and validate the issue
• Contain and mitigate impact
• Rotate or revoke affected credentials where necessary
• Notify affected Customers without undue delay, consistent with applicable law and contractual commitments
• Perform a review and improve controls based on lessons learned

Some laws require notice within specific timeframes. We work to meet applicable requirements where they apply.

7. Compliance and Regulatory Alignment

7.1 SOC 2

Keywave is not currently SOC 2 certified. Our roadmap includes building toward SOC 2 readiness by maturing policies, controls, and evidence collection. If we complete a formal audit, we plan to share the report with qualified Customers under confidentiality terms.

7.2 GDPR and Similar Frameworks

Customers may use Keywave in contexts where GDPR or similar data protection rules apply. We support Customer needs through privacy focused design, documented policies, and the ability to enter into a Data Processing Agreement where appropriate.

7.3 US State Privacy Laws

We do not sell personal information. We aim to support reasonable requests related to access and deletion for Customer account holders, and we handle End User requests as described in our Privacy Policy.

7.4 Biometric Related Laws

Voice based verification can be regulated under biometric privacy laws in some jurisdictions. Customers are responsible for providing required notices and obtaining required consent from End Users. We aim to design the Service to support consent based workflows and retention controls over time.

8. Third Party Risk

We rely on third party providers for hosting, storage, monitoring, and payments. We select reputable providers and use their security features. Provider level controls vary by service and configuration.

9. Roadmap

As Keywave grows, planned improvements may include:

• Expanded access review and role controls
• Regular third party penetration testing
• More formalized incident response documentation and training
• Security questionnaires and customer facing documentation improvements
• SOC 2 readiness work and potential audit

10. Reporting Security Issues

If you believe you have found a security vulnerability, please email support@keywave.io.

Please do not publicly disclose the issue until we have had a reasonable opportunity to investigate and mitigate it.

11. Contact

Questions about security and compliance can be sent to: