What this page is
This is the operational half of our security documentation. It covers how we grant access, how changes reach production, what we log, and what we do when something goes wrong.
The other half lives on /trust: our compliance posture, the full subprocessor list with regions, data residency options, and our AI training stance. We deliberately do not repeat that here. Where the two pages touch the same control, /trust states where we stand and this page states how it works.
It applies to wysera.ai, postwyse.com, opswyse.com, and the Wyse AI inside those products.
Identity and access
Access to production is the control we treat as most important, because almost every serious breach is an access failure rather than a cryptographic one.
Single sign-on
Access to production systems is gated by SSO. There are no shared logins and no local accounts on production infrastructure.
Hardware-key MFA
Multi-factor authentication uses hardware security keys, not SMS or TOTP, so production access is resistant to phishing and SIM-swap.
Least privilege
Roles are assigned per person and scoped to the narrowest set of permissions that lets them do the job. Broad admin is not the default.
Privileged actions logged
Every privileged action against production is written to an audit log, including who performed it and when.
Customer-side authentication is separate from the above. Account passwords are stored as Argon2 hashes, never in recoverable form, and we cannot read a customer password.
Infrastructure
Wysera runs on AWS. Primary infrastructure is in us-east-1 (Virginia) with multi-AZ failover, and backups replicate to us-west-2 (Oregon).
EU residency in eu-central-1 (Frankfurt), also multi-AZ, with backups in eu-west-1 (Ireland), is available on Pro Bundle and Enterprise. Dedicated single-tenant deployments for Australia, UK and Canada are available to Enterprise customers with a typical lead time of 30 to 60 days. The residency table on /trust is the authoritative version.
Cloudflare sits in front of the platform for CDN and DDoS protection. Customer workspaces are logically isolated from one another; one customer's data does not cross into another's.
Encryption and keys
| Control | How it works |
|---|---|
| At rest | AES-256 for all customer data. Keys are managed by AWS KMS. Database backups are encrypted with separate keys held in a different region, so a single key compromise does not reach both. |
| In transit | TLS 1.3 on all customer-facing endpoints, with HSTS enforced. Internal service-to-service traffic uses mutual TLS where appropriate. |
| Key rotation | KMS master keys rotate annually. Application-level encryption keys rotate every 90 days. Pro Bundle and Enterprise tenants get customer-specific keys generated per tenant. |
| Field-level redaction | Fields holding PHI or PII can be flagged for redaction before the AI agent processes them. Redacted data never leaves the storage layer. |
How code ships
Changes reach production through version control and code review. Nobody edits production by hand.
- Every change is a pull request against the main branch. Direct pushes to production branches are not part of the workflow.
- Automated static analysis runs on every pull request, including CodeQL for JavaScript and TypeScript. A failing security check blocks the merge.
- Dependencies are tracked and updated. Advisories against packages we ship are treated as defects, not as chores.
- Secrets are held in environment configuration and secret storage, never committed to the repository. Keys found in a commit are rolled, not just removed.
Logging and monitoring
We log privileged actions against production, authentication events, and application errors. Error tracking runs through Sentry with personally identifying information scrubbed before it leaves our systems, so a stack trace does not become a data export.
Every Wyse AI output is logged with its prompt, the model used, and the result. Those logs are searchable and exportable by the customer for the lifetime of the account plus the retention period, which is what makes an AI decision auditable after the fact rather than merely explainable in principle.
Incident response
If customer data is exposed, the obligation we care about is telling you quickly and accurately, including when the honest answer is that we are still establishing scope.
| Stage | What happens |
|---|---|
| Detect | An incident can start from monitoring, a customer report, or an external disclosure. All three enter the same process. |
| Contain | First priority is stopping ongoing exposure: revoking credentials, disabling the affected path, or taking a component offline. |
| Notify | Where we process data on your behalf, we notify affected customers without undue delay and, per the DPA, within 48 hours of becoming aware. Notice goes to account admins. |
| Resolve and review | We fix the cause, not only the symptom, and write up what happened. Customers materially affected can request that write-up. |
Backups and recovery
Backups are encrypted and retained for 30 days, then purged automatically. They replicate to a second region, so losing a region does not mean losing the backups with it.
Deleted accounts are hard-deleted within 30 days, except where retention is legally required, such as tax invoices kept for seven years. That is a deletion guarantee, not a backup schedule: the purpose is that deleted means deleted, including from the copies.
People and devices
Wysera is a small team, which cuts both ways. Fewer people hold production access than at a larger company, and the ones who do hold more of it. We manage that with the least-privilege and audit-log controls above rather than by pretending the team is bigger than it is.
- Production access is granted per person, tied to SSO, and removed when someone no longer needs it.
- Access to customer workspace content is not part of normal operations. Where support requires it, it is logged.
- Compliance monitoring runs through Vanta, which is also the control-monitoring layer for the SOC 2 Type II audit currently underway.
Controls around Wyse
Wyse is the AI agent inside PostWyse and OpsWyse, and it is the part of the platform customers ask about most. The full policy is on /trust; the security-relevant shape of it is:
- Customer data never trains public models, and is never included in fine-tuning datasets for public release.
- What Wyse learns from your team's edits stays scoped to your tenant. Other customers do not benefit from your data.
- Upstream providers (Anthropic, OpenAI) receive only the prompt content needed for the task, under zero-data-retention contracts, so prompts are not retained beyond the inference request.
- Prompt and output logs are retained 90 days by default, and can be configured down to 7 days on Pro Bundle and Enterprise.
Vendors
We use a deliberately short list of subprocessors, each with a defined purpose and region. The current list is maintained on /trust and is the version we keep up to date.
We give notice before adding a new subprocessor. Enterprise customers can object in writing, and the mechanics of that objection are set out in the DPA.
Reporting a vulnerability
Email hi@wysera.ai with the subject line Security disclosure. Please give us a chance to fix it before disclosing publicly.
| Commitment | Target |
|---|---|
| Acknowledge your report | Within 24 hours |
| Triage and confirm severity | Within 72 hours |
| Patch critical vulnerabilities | Within 7 days |
| Credit you | On request, once the fix has shipped and it is safe to describe |
There is no paid bug bounty in 2026. We can offer a genuine thank you, credit on this page with your permission, and Wysera Pro credits. We would rather say that plainly than imply a payout that is not coming.
Where we are not yet
The reason to trust a security page is usually the things it admits. These are ours, as of the date at the top.
| Gap | Status |
|---|---|
| SOC 2 Type II | Audit underway with Vanta-led control monitoring. We do not have a report yet. Letter of engagement available on request. |
| ISO 27001 | Not started. Planned for Q2 2027, after the SOC 2 Type II report is issued. |
| Bug bounty | No paid programme in 2026. Disclosure is handled directly, on the timelines above. |
| PCI DSS | Not applicable rather than achieved. We never see or store card numbers; card data lives in Stripe. |
| Penetration testing | We do not publish a third-party penetration test report. Enterprise customers evaluating us should ask, and we will tell them exactly where that stands rather than point at this page. |
Contact
Security questions, customer security reviews, and vulnerability reports all go to hi@wysera.ai. For a security questionnaire or a review call, say so in the subject line and we will route it to someone who can answer rather than to support.
For the contractual version of the commitments on this page, see the Data Processing Addendum. For what data we collect and why, see the Privacy Policy.