Trust Center
Whawit ingests telemetry from your production systems — logs, metrics and error tracebacks — and runs AI analysis over it to drive incident response. That data describes exactly how your systems fail, so how we hold it matters as much as what we do with it.
This page states our security posture, our compliance status, and the places where we are not there yet. Where a control is planned rather than in place, it says so.
Due diligence, answered directly
These are the questions a security review asks before a pilot. Each one is answered here in a sentence that stands on its own, including the ones where the answer is no. The sections that follow are the detail behind these answers.
Has WHAWIT completed a SOC 2 audit?
No. WHAWIT has not been audited by an independent third party. A SOC 2 readiness programme is in progress and the plan is deliberately narrow: the Security Trust Services Criteria only, and a Type II report directly rather than a Type I first. Availability, Confidentiality, Privacy and Processing Integrity are out of scope for the first report. The observation period is planned to run from November 2026 to January 2027, which puts a report in the first half of 2027, and no date here is a commitment — audits slip. WHAWIT's infrastructure providers — Google Cloud, MongoDB Atlas, Auth0 and GitHub — each hold their own audited attestations, but those are theirs and are not evidence about WHAWIT.
Will WHAWIT sign a Data Processing Agreement (DPA)?
Not yet. A Data Processing Addendum with EU Standard Contractual Clauses is in preparation and is not available today. If a signed DPA is a precondition for your evaluation, that is a blocker right now rather than a formality WHAWIT can clear during the pilot. What is available to enterprise customers under NDA today is a CSA CAIQ v4 response covering the core control domains and four written policies — Information Security, Access Control, Incident Response and Change Management. WHAWIT also answers VSAQ and SIG Lite questionnaires.
Which sub-processors are in WHAWIT's production data path?
WHAWIT names them on its Trust Center at whawit.ai/security, in two tables: the infrastructure it runs on, and the destinations you connect yourself. The infrastructure is Google Cloud Platform (Cloud Run compute, object storage, Pub/Sub and Secret Manager), Google Cloud Vertex AI (Gemini, and Anthropic Claude served through Vertex AI Model Garden) for analysis and triage, MongoDB Atlas as the primary datastore and telemetry store, Redis Cloud for job queues and caching, Auth0 (Okta) for identity, SendGrid for transactional and notification email, and GitHub for WHAWIT's own source control. ClickHouse Cloud is provisioned in production but no application code writes to it today, and it is listed anyway so that a vendor review sees the whole environment rather than a filtered view. Separately, the destinations you connect yourself — Slack, Microsoft Teams, Discord, Jira, Linear, OpsGenie and GitHub — receive nothing until an admin in your organization links the account.
How is customer data encrypted?
WHAWIT encrypts data with AES-256 at rest across databases, caches and object storage, and TLS 1.2 or higher in transit on every public endpoint, WebSocket connection and internal service call.
How does WHAWIT isolate one customer's data from another's?
Physically, at the database level. Each customer is provisioned on a dedicated instance with its own database and its own deployment, so one customer's data is not in the same database as another's. Inside a tenant, separation between organizations and projects is enforced in the application: every record and telemetry stream carries an explicit organization reference, every query that reads them is scoped to it, and a role check sits above that. WHAWIT also runs a shared instance, but it carries demo and internal data only and no customer is provisioned onto it.
Has WHAWIT had an independent penetration test?
No. No third-party penetration test or independent security assessment has been performed on WHAWIT to date. This is one of the specific gaps WHAWIT names on its Trust Center rather than leaving a reader to infer it from the absence of a report.
Are customer logs used to train AI models?
No. WHAWIT does not train models on customer telemetry, and customer data processed through the platform is not used to train generalized machine learning models. Analysis runs on Google Cloud Vertex AI, using Gemini and Anthropic Claude served through Vertex AI Model Garden.
Who can see sensitive data that WHAWIT has masked, and is that recorded?
Only a user holding the data.reveal_sensitive capability in that organization, and yes, every reveal is recorded. Masked content is not a toggle any viewer can flip: without the capability the request is refused, and a reveal that is served is written to an audit collection capturing who saw it, which resource, which screen served it and which data classes had been hidden. So "who has seen the card numbers in this incident" has an answer after the fact.
How do I report a security vulnerability in WHAWIT?
Email [email protected] with the affected endpoint or component, the steps to reproduce, and what an attacker could reach. WHAWIT acknowledges every report it receives, tells you whether it is being treated as a security incident, and comes back with what was done about it. WHAWIT does not run a staffed 24/7 security rotation and therefore deliberately publishes no response-time SLA for inbound reports.
Security posture
Encryption
AES-256 at rest across databases, caches and object storage. TLS 1.2+ in transit on every public endpoint, WebSocket connection and internal service call.
Identity and access
Authentication runs on Auth0 (Okta): MFA, SSO over SAML and OIDC, and enterprise password policy. Access to telemetry, incidents and administration is scoped by organization and by role.
Tenant isolation
Each customer is provisioned on a dedicated instance with its own database and its own deployment, so separation between customers is at the database level rather than only inside the application. Within a tenant, every record and telemetry stream still carries an explicit organization reference and every query is scoped to it, with a role check above that.
Secrets
No credential is hardcoded in the source tree. Production secrets live in GCP Secret Manager, and automated secret scanning runs against the repository on every pull request as a required check that the change's author cannot bypass.
Compliance posture
Whawit has not been audited by an independent third party yet. Stating that plainly is worth more to a procurement team than a badge we have not earned.
- Trust Services Criteria in scope
- Security (the common criteria), Availability and Confidentiality. Privacy and Processing Integrity are out of scope for the Type I.
- Where the work stands
- The policy framework and the customer-facing security packet are written. Technical control implementation and evidence collection are underway. Selecting an audit firm and the readiness gap assessment come next. A Type II observation period would begin after a Type I report is issued.
- Available to enterprise customers under NDA
- A CSA CAIQ v4 response covering the core control domains, and four written policies — Information Security, Access Control, Incident Response, and Change Management. We also answer VSAQ and SIG Lite questionnaires. A Data Processing Addendum with EU Standard Contractual Clauses is in preparation and is not yet available.
Two things we are careful not to imply: no third-party penetration test or independent security assessment has been performed, and our infrastructure providers' certifications are theirs, not ours. Google Cloud, MongoDB Atlas, Auth0 and GitHub each hold their own audited attestations; that is a reason to trust the layer beneath us, not evidence about Whawit.
Sub-processors
Two lists. The first is the infrastructure Whawit runs on; it is listed in full, including components that are provisioned but not yet carrying data, because a vendor review should see the whole environment rather than a filtered view. The second is the destinations you connect yourself — nothing reaches them until an admin in your organization links the account. Whawit's own compute and storage run in Google Cloud regions in the United States and the European Union; the other providers below are independent and operate in their own regions.
Infrastructure
| Sub-processor | Purpose | What it can receive |
|---|---|---|
| Google Cloud Platform | Compute (Cloud Run), object storage, Pub/Sub and Secret Manager. | Telemetry in transit and at rest, application data, encrypted credentials. |
| Google Cloud Vertex AI | AI analysis and incident triage. Gemini, and Anthropic Claude served through Vertex AI Model Garden. | Excerpts of logs, metrics and error tracebacks submitted for a given analysis. |
| MongoDB Atlas | Primary datastore and telemetry storage. | Organizations, users, incidents, analyses, integration configuration and ingested telemetry. |
| ClickHouse Cloud | Columnar telemetry store provisioned in the production environment. | Nothing today — it is provisioned but no application code writes to it. Listed for completeness. |
| Redis Cloud | Job queues (BullMQ), distributed locks and caching. | Queued job payloads — incident, analysis and notification content in transit between workers. |
| Auth0 (Okta) | Identity provider: authentication, MFA, SSO. | User identity — email address and profile. No telemetry. |
| SendGrid | Transactional and notification email. | Recipient addresses and the contents of invitations, alerts and escalation notices. |
| GitHub | Source control and CI/CD for Whawit's own code. | Whawit's source code. No customer telemetry. |
Destinations you connect
| Destination | Purpose | What it can receive |
|---|---|---|
| Slack | Incident notifications, escalation pages, and answers to questions asked in Slack. | Incident summaries, severity, and analysis text. |
| Microsoft Teams | Incident notifications and escalation pages. | Incident summaries, severity, and analysis text. |
| Discord | Incident notifications posted to a webhook you configure. | Incident summaries, severity, and analysis text. |
| Jira | Issues Whawit opens, comments on and transitions for an incident. | Incident summary and analysis text in the issue body and comments. |
| Linear | Issues Whawit opens and keeps in sync with an incident. | Incident summary and analysis text in the issue body and comments. |
| OpsGenie | Alerts Whawit raises, acknowledges, assigns and closes. | Incident summary, severity and assignment. |
| GitHub | Reading repository context and opening pull requests on your behalf. | Connected repository contents and the pull requests Whawit authors. |
Everything Whawit sends to a connected destination is masked according to your declared compliance frameworks — see below. Vendors that are configured but not yet carrying customer data — SMS and WhatsApp delivery, for instance — are deliberately left off these tables until they go live. Whawit does not train models on your telemetry.
Compliance criteria inside the product
This is a product setting, not a statement about Whawit. It lets your organization declare which rules govern its data, and Whawit masks the corresponding classes of sensitive data in what it shows and what it sends. It does not make Whawit certified under those frameworks, and it says nothing about the audit status in the section above.
An organization admin turns on the frameworks that apply. Whawit maps each one to the classes of sensitive data it masks:
| Framework | Data classes masked |
|---|---|
| HIPAA | Health identifiers, personal data |
| SOC 2 | Credentials, personal data |
| PCI DSS | Card data |
| GDPR | Personal data |
| CCPA | Personal data |
| Aviation / PNR (IATA) | Passenger records, personal data |
- The declaration is organization-wide. One record per organization, not per user and not per project, so there is a single answer to what governs your data.
- It is validated server-side. An unrecognised framework, or a value that is not a boolean, is rejected by the API rather than stored and quietly ignored.
- Every change is attributed. The saved record carries the admin who changed it, so a later question about who declared what has an answer.
How masking works
Turning on a framework changes what Whawit displays and what it sends. Incident analysis, incident logs and query history are masked as they are served; escalation pages, Slack and Teams messages, Jira, Linear and OpsGenie issues, ticket bodies and alert payloads are masked before they leave. This is what the product does with your data — a feature, not a certification.
Deterministic, shape-anchored detectors
One set of detectors per data class, matching on structure rather than guessing: card numbers only when they pass a Luhn check, PEM private-key blocks, Bearer and Basic tokens, key=value secret assignments, credential pairs inside URLs, JWTs, AWS access key ids, email addresses, dashed US social security numbers, phone numbers.
Precision over recall
The classes that have no unambiguous shape — health identifiers and passenger records — fire only behind an explicit label such as MRN, NPI, PNR or record locator. A bare six-character alphanumeric matcher would mask half of every stack trace, and an incident page you cannot read is not a security control.
Masked at the boundary, on a copy
Masking happens as a response or a message is assembled. The stored record is never modified, so nothing is lost and changing your declared frameworks changes what is shown from that moment on.
Reads fail open, outbound fails closed
If the policy lookup itself fails, a read is served unmasked — a policy outage must not brick every incident page, and the stored document is unchanged either way. Outbound does the opposite: a message that has already left for Slack cannot be recalled, so an undecidable policy masks every class and logs loudly.
A masked document says what was taken out
Every removal leaves a stable, greppable placeholder in place of the value, so an engineer reading a masked incident can tell the difference between “there was nothing here” and “there was a card number here” — and a labeled match keeps its label, so MRN: 12345 becomes MRN: ⟦PHI⟧.
⟦PHI⟧Health identifiers⟦PCI⟧Card data⟦PII⟧Personal data⟦PNR⟧Passenger records⟦CRED⟧Credentials
Revealing is a privilege, and it is audited
Masked content is not a toggle any viewer can flip. Asking for the unmasked version requires the data.reveal_sensitive capability in that organization; without it the request is refused. A reveal that is served is recorded to an audit collection: who saw it, which resource, which screen served it, and which data classes had been hidden. So the question “who has seen the card numbers in this incident” has an answer, after the fact.
Reporting a vulnerability
If you have found a security issue in Whawit, tell us directly. Include the affected endpoint or component, the steps to reproduce, and what an attacker could reach. Please do not test against another organization's data.
Report a vulnerability
[email protected]Request the security packet
[email protected]What we commit to: we acknowledge every report we receive, tell you whether we are treating it as a security incident, and come back to you with what we did about it. We do not run a staffed 24/7 security rotation, so we do not publish a response-time SLA for inbound reports — a number we could miss is worth less to you than one we keep.
Internally, our written incident response plan sets severity levels with target response and customer-notification times for incidents we declare, and requires a blameless post-mortem within five business days for the two highest severities, with the action items tracked as high-priority engineering tickets. The plan is part of the security packet above.
Last reviewed August 2026. This page is maintained alongside the compliance documentation in the Whawit monorepo; when a control moves from planned to in place, it is updated here.