Security Policy
How we protect your data and your customers' data
Updated October 8, 2026 · Contact: security@wubba.ai
This page lists only what is in place today. What we are still building is listed at the end, so you can see the difference.
Encryption
Data in Transit
Traffic to app.wubba.ai is encrypted with TLS 1.2 or 1.3. Older TLS 1.0 and 1.1 connections are refused, plain HTTP redirects to HTTPS, and HSTS tells browsers to use HTTPS only. The app also sends Content-Security-Policy, X-Frame-Options, X-Content-Type-Options and Referrer-Policy headers.
Data at Rest
The WUBBA database runs on Amazon RDS and is encrypted at rest with AWS KMS keys, as are its backups. The application servers' own disks are not yet encrypted, and they hold the database behind calls, texts and chat (messages and contact details). Moving them to encrypted disks is in progress (see below).
Patient Health Information
In a practice's patient records, names, phone numbers, email addresses, dates of birth, notes, hearing-device serial numbers, and hearing-test results and their summaries are encrypted by the application (AES-256-GCM) before they are stored, each practice under a data key of its own that AWS KMS protects. A medical, audiology or counseling business's outbound messages and letters are encrypted the same way. In the communications service, customers' dates of birth, notes and insurance details, intake answers, call and voicemail transcripts and fax text are encrypted per business too, and so are a health practice's messages. Without a usable key the app refuses to save rather than store plain text. Records written before this was switched on are converted by a one-time job, and keep their earlier protection until it has run. Names and phone numbers in bookings, contacts and the communications service are not encrypted by the application. WUBBA does not yet sign Business Associate Agreements (see below).
Passwords
User passwords are hashed with bcrypt (cost factor 12). Raw passwords are never stored.
Payment Data
Cards are entered only on Stripe-hosted Checkout pages (Stripe is PCI DSS Level 1), so card numbers, expiry dates and security codes never touch our servers. A saved card is a Stripe token plus a record of the customer's consent: the exact wording they agreed to, when, and from where. A single, guarded code path can charge a saved card, and only within that consent. Payment notifications from Stripe are accepted only with a valid signature.
Financial Data
Bank account connections are powered by Plaid (SOC 2 Type II). Bank credentials go to Plaid and are never shared with or stored by WUBBA.
Access Controls
Authentication
Sign-in uses email and password. An account that has set up two-step verification (authenticator app, SMS or email code) must enter a code after its password at every sign-in, and no session exists until the code checks out. Code attempts are limited per account, and each account gets one-time recovery codes for a lost device. Accounts that have not set it up are not yet required to; that is on the list below.
Role-Based Access
An account has a role in each business it belongs to: Agency, Client, or Genesis (confined to the Genesis app builder), and the session carries the role for the business being worked in, re-read on every request. Admin is reserved for platform staff and applies in every business. Changes to billing, saved cards, mailings and phone setup are limited to a business's staff, and the server checks the role on each of those changes.
Clinical Access
In a medical, audiology or counseling business, patients' clinical records (intake answers and screener scores, dates of birth, notes, hearing tests, and call transcripts and recordings) are shown only to members given Clinical access by the business's owner, or by staff the owner has allowed to grant it, and to platform staff. Other members see scheduling and contact details. The server checks this on every request, and the communications service checks it again from a signed token that names the person. A member without it can open one record by typing a reason; that is logged and flagged for the owner. Client portal logins never see other clients' records.
Tenant Isolation
Data requests from a signed-in user are filtered on the server by the business they are working in. A second, database-enforced layer is being switched on (see below).
Session Management
Sessions expire after 24 hours without activity, and end 12 hours after sign-in however active they are. In a medical, audiology or counseling business, anyone who can see patients' clinical records is signed out after 15 minutes without activity. Signing out ends every session the account has, on every device, on the server and not just in the browser; so does a password reset. A deactivated account's sessions end at once. Session cookies are HttpOnly, Secure and SameSite.
Rate Limiting
Sign-in, registration, password reset and email verification are rate limited, as are the public contact, lead, order and civic-message forms, the public invoice, bill-payment and intake pages, and the links that open a patient's or customer's forms. Keys for the WUBBA API carry their own per-key limit.
Infrastructure
Cloud Provider
Hosted on Amazon Web Services (AWS) in us-west-2, with backup copies in us-east-1. AWS holds SOC 2 and ISO 27001 certifications for its infrastructure.
Network Security
The database is not reachable from the internet. It accepts connections only from our application servers.
Server Hardening
SSH access requires a key; password login is disabled. Servers require IMDSv2 for instance metadata. The web application runs as a non-root user inside its container.
AWS Account Security
The AWS root account is protected with MFA. AWS CloudTrail records account activity in every region, with log file integrity validation.
Email Security
SPF, DKIM and DMARC (quarantine) are published for wubba.ai, so mail forged from our domain is flagged or rejected. Transactional email is sent through Amazon SES from a verified domain.
Data Privacy & Retention
Privacy Policy
Published at /privacy. Covers data collection, usage, third-party services, and your rights including access, deletion, and portability.
Consent
Consent to receive text messages is recorded with a fingerprint of the exact wording shown, the time, the page and, where available, the IP address. Replying STOP stops further texts.
Backups
The WUBBA database has automated backups kept for 30 days, daily copies kept for 60 days in a locked backup vault, and a copy in a second AWS region. The communications database is backed up twice a day to versioned storage that is replicated to a second location.
Data Retention
Account data is kept while the account is active. A daily job is in place that empties the content of messages, call recordings and transcripts, and intake answers once they pass each business's retention window (two years for messages, one year for recordings and transcripts, and seven years for intake answers, unless the business sets its own; a financial advisor's content is kept at least six years and a government office's is never removed, because records rules set those), keeping the record that a message was sent. For now it only reports what it would remove: we do not yet delete data automatically on a schedule.
Expiring Links
A link that opens an invoice or a form works without signing in, so it does not work forever: an invoice's payment link stops 60 days after the business last sent it (30 days after it is paid), and a form link 14 days after it was last sent. Links sent before this was introduced keep working until the end of 2026. Our web server's access log records pages without their query strings and with those links' codes removed.
Discreet Messages
Texts, emails and letters from a medical, audiology or counseling business never name the service booked, a device or a condition, so a lock screen or a letter on the table does not say why someone is a patient. Alerts texted to the business's own staff about a conversation say only that someone needs them, not what was said.
Logs
The communications service logs message bodies, transcripts, email subjects and the details passed to the AI's tools only as a length, never their words. In both services, phone numbers and email addresses that reach a log line are masked, and a database error no longer prints the record it failed on.
Data Export & Deletion
To export or delete your account's data, email privacy@eyentelligence.com. Our team handles these requests directly today; self-service export and deletion are being built.
Audit Logging
Sign-ins and sensitive account changes (invitations, role changes, password resets, subscription changes and deletions) are recorded in an audit log with the time, the user and the record affected. Separately, each time someone opens a patient's clinical record, and each change to who has Clinical access, is written to an access log with the person, the time, their IP address and any reason they gave. The database refuses edits and deletions to it, it is kept when a business is deleted, and each entry is chained to the one before by a hash, so a change can be detected. The business's owner can see who opened which record.
Vulnerability Management & Incident Response
Automated Checks
Every proposed code change runs automated checks. The run fails if the type check, the test suite, the production build or secret scanning fails; a dependency audit for high-severity vulnerabilities also runs and reports what it finds. Updates to the app's dependencies are proposed automatically every week.
Secure Development
Database access goes through the Prisma ORM, which parameterizes queries. The public WUBBA API validates its input against schemas.
Incident Response
If we confirm a breach affecting your data, we notify you within 72 hours. Our Information Security Policy sets out the steps: detect, contain, investigate, remediate, notify, review.
Responsible Disclosure
Security researchers can report vulnerabilities to security@wubba.ai. We commit to acknowledging reports within 48 hours.
What We Are Still Building
As of October 8, 2026. None of these is claimed above.
Business Associate Agreements (HIPAA)
WUBBA does not yet sign Business Associate Agreements (BAAs). Until it does, don't store patients' health information in WUBBA. The vendors that would handle that information are not all under a BAA with us yet either.
Server disk encryption
The database is encrypted today. The disks of the application servers are being moved to encrypted volumes.
Two-step verification for every account
Accounts that have set up two-step verification must use it at every sign-in. Next, every account will have to set it up before it can use the dashboard.
A separate signing key for service tokens
The tokens our servers use to talk to each other are moving to a key of their own, separate from the one that signs your session.
Database-enforced separation between businesses
Row-level security in the database, as a second layer behind the application's own checks.
Donation ledger and receipts
A record of every gift, with a numbered receipt sent to the donor.
Self-service data export and deletion
Export and delete a person's data from the dashboard, instead of by email request.
Independent penetration test
An outside firm testing sign-in, donations and the public forms.
Questions about our security practices?
Contact our security team at security@wubba.ai