Security & Compliance
How we protect information: architecture, encryption, access control, monitoring, our development lifecycle, incident response, subprocessors, and responsible disclosure.
Last reviewed July 20, 2026 · Last updated: July 20, 2026
1. Our security program
Security is foundational to QuezBridge, not an add-on. Our program is designed around the principles of least privilege, defense in depth, and keeping health information inside a strictly controlled boundary. This page describes the safeguards in place and the ones we are building as we scale.
We describe our controls honestly. Where we are working toward a formal third-party attestation (such as SOC 2) rather than holding one today, we say so rather than imply a certification we do not yet have.
2. Architecture and data isolation
- A two-plane design separates the public, non-PHI website from the clinical PHI environment. The marketing site is designed never to receive health information.
- PHI will be processed only within a boundary covered by a provider Business Associate Agreement, isolated from general-purpose and external systems; production PHI handling stays disabled until that BAA is in place.
- Health information is never sent to advertising platforms and is never used to train third-party models.
3. Encryption and key management
- Data is encrypted in transit using current TLS, and at rest using strong, industry-standard encryption.
- Encryption keys are managed through a dedicated key-management service with restricted access.
4. Access control and monitoring
- Role-based access on a least-privilege, need-to-know basis, with strong authentication.
- Access to sensitive systems and to PHI is logged and auditable.
- Systems are monitored for anomalous activity, and access is reviewed periodically.
5. Secure development and vulnerability management
- Changes go through review and automated testing before release.
- Dependencies are monitored for known vulnerabilities and updated promptly.
- We validate that safeguards work as intended before shipping features that touch sensitive data.
6. Responsible AI and clinical safety
- AI features are designed to keep the clinician in control; they inform, and do not make, clinical decisions.
- A deterministic safety layer is designed to detect crisis or self-harm indicators and route to human support and emergency resources rather than have AI improvise a response. See the Medical & Safety Disclaimer.
- We evaluate AI features for safety and quality and constrain their scope to appropriate, low-risk tasks.
7. Incident response
We maintain an incident-response process to detect, contain, investigate, and remediate security events, and to notify affected customers consistent with our contracts, the Business Associate Agreement, and applicable law, including the HIPAA Breach Notification Rule and the FTC Health Breach Notification Rule where they apply.
8. Subprocessors
We use a limited set of vetted subprocessors, each under a contract requiring appropriate protections, and — where they may handle PHI — a Business Associate Agreement. A current list is available to customers, who are notified of material changes as their agreement provides.
9. Responsible disclosure
We welcome reports from security researchers. If you believe you have found a vulnerability, please email security@quezbridge.com with details and steps to reproduce, and give us a reasonable opportunity to remediate before public disclosure. We will not pursue good-faith research that respects user privacy and avoids service disruption.