Security at Wysvera

Last Updated: August 1, 2026

You trust us with your customer relationships, which is among the most sensitive data your business holds. This page describes how we protect it — and, just as deliberately, what we have not built yet. We would rather you learn our gaps from us than from your own review.

1. Data protection

1.1 Encryption

• In transit: TLS 1.3. HTTPS is enforced for every connection, with HSTS enabled including subdomains and preload.
• At rest: Customer data is stored in a managed PostgreSQL database encrypted at rest with AES-256. Backups are encrypted.
• Credentials, separately: Values that would be dangerous in isolation — integration access tokens, single sign-on client secrets, and multi-factor authentication secrets — are additionally encrypted by the application with AES-256-GCM before they are stored, so they are unreadable even to someone holding a database dump. A credential that fails to decrypt is treated as absent rather than used.
• Key management: Encryption keys are held in our hosting platform's encrypted environment configuration, with access limited to platform administrators. We do not currently use a dedicated key management service.

1.2 Tenant isolation

Wysvera is multi-tenant. Every request for organization-scoped data passes through a single authorization check that resolves the record and refuses it unless the requesting session belongs to the same organization. Customer portal users are further restricted to their own account's records.

Being precise about where this is enforced: isolation is enforced in our application layer. Row level security is enabled on every table in the database as a defense-in-depth measure against direct database access using other credentials, but it is not itself the tenant boundary. We would rather state that plainly than let the word "database-level" imply a control that is not doing this work.

2. Infrastructure

2.1 Hosting

Wysvera runs on enterprise-grade cloud infrastructure operated by third-party providers, who are responsible for physical security and data-center controls. Data is hosted in the United States.

Wysvera has not completed a SOC 2 audit, and has not had a third-party penetration test. We hold no security certifications of our own. Certifications held by our infrastructure providers apply to their platforms, not to our application, and we do not represent them as covering us. If your procurement process requires either, contact us and we will discuss timelines honestly.

2.2 Network and browser protections

• DDoS mitigation at the network edge, provided by our hosting platform
• HTTPS enforced, with HSTS applied to subdomains and preloaded
• Content Security Policy restricting script, style, frame and connection sources
• MIME-type sniffing disabled, framing restricted to same origin, and a strict referrer policy
• Rate limiting on authentication, sensitive operations, and general API traffic

2.3 Availability and backups

• Cloud-hosted infrastructure with built-in redundancy
• Managed, encrypted database backups
• We have not yet performed a documented restore test, and we have not published formal recovery time or recovery point objectives.

3. Application security

3.1 Authentication

• Passwords: hashed with bcrypt. Never stored or logged in plain text.
• Multi-factor authentication: time-based one-time passwords from any authenticator app, with single-use backup codes. When enabled, a valid code is required before any session is issued.
• Single sign-on: your organization can connect its own OpenID Connect identity provider — Okta, Entra ID, Auth0 or Google Workspace — configured by your administrator. Authorization Code flow with PKCE. Sign-in requires that the email domain is on your allowlist, that the user already exists in Wysvera, and that the user belongs to your organization. An identity provider can assert who someone is; it cannot create accounts, grant roles, or reach another customer's organization.
• Sessions: signed tokens with a 24-hour maximum lifetime, in cookies that browsers will not expose to scripts and will only send over HTTPS.

3.2 Authorization

Role-based access control across administration, customer success, sales, marketing, support and portal roles. Role assignment is ceiling-limited: nobody can grant a role more privileged than their own, which prevents privilege escalation through invitations.

3.3 Secure development

• Static type checking across the entire codebase before release
• An automated test suite covering authentication and isolation controls
• Dependencies updated on a regular cadence to address known vulnerabilities
• Automated checks that fail the release if database security settings drift
• Development practices informed by OWASP guidance

4. Your data and AI

Wysvera uses AI to draft messages, summarise conversations and surface insights. Content you submit to those features is processed by our AI provider under commercial terms that prohibit using it to train models.

We do not train any model on your data, and we do not sell or share personal information for advertising.

Integrations are opt-in per organization. A third-party service you have not connected receives none of your data. A full subprocessor list is available on request.

5. Compliance

5.1 GDPR

• Data Processing Agreement available to all customers
• Rights of access, rectification and deletion supported
• Data export in standard formats
• Data is hosted in the United States; we do not currently offer EU data residency

5.2 CCPA

• Disclosure of data collection and use practices
• Rights to know, delete and opt out
• No sale of personal information

5.3 Not supported

Wysvera is not designed for protected health information and we do not sign Business Associate Agreements. Payment card data is handled entirely by our payment processor through their hosted checkout, so card details never reach Wysvera systems.

6. Monitoring and incident response

6.1 Monitoring

• Application error tracking across server, edge and browser
• Audit records for authentication and administrative changes
• Platform-level infrastructure and uptime monitoring from our host

6.2 If something happens

Our response to a suspected security incident is to investigate and determine scope, contain it, notify affected customers, and restore and verify affected systems. For a confirmed breach of personal data we will notify affected customers within 72 hours, as required by applicable law.

We do not yet have a formally documented incident response plan with defined severity levels and escalation paths. Writing one is on our roadmap, and we will not describe it as complete until it is.

7. Our team

8. Your part

Security is shared. We recommend that you:

• Turn on multi-factor authentication, particularly for administrators
• Connect your own identity provider if you have one, so access follows your directory
• Review user access and permissions regularly, and disable accounts promptly when people leave
• Use strong, unique passwords
• Report anything suspicious to us

9. Reporting a vulnerability

If you find a security issue, please tell us at kristen@wysvera.io. Include steps to reproduce it, and give us reasonable time to fix it before public disclosure. We will acknowledge your report and keep you updated. We do not currently operate a paid bug bounty.

10. Contact

Security questions, questionnaires and due diligence requests: kristen@wysvera.io