SECURITY MODEL
How TideWater handles your material.
This page is the implementation, not a summary of it, and it is written to be handed to whoever runs your security review. Where a control is partial, it is stated here rather than left for you to discover. Ask if you need any of it evidenced in more depth.
LAST REVIEWED: 2026 - CONTROLS BUILT TO SOC 2 PRINCIPLES - NO ATTESTATION HELD
01 / ENCRYPTION IN TRANSIT AND AT REST
Encryption
- IN TRANSIT
- TLS on every connection, between your browser and the platform and between the platform and every source or delivery endpoint.
- AT REST
- AES-256-GCM for TOTP secrets, backup codes, API keys, proxy credentials, webhook secrets, and Telegram session data. Other database contents are not separately encrypted at the storage layer; records for users with registered keys are covered by end-to-end encryption below.
- KEY ROTATION
- Rotation runs client-side in batches, with a twenty-four hour server-side backup so a rotation cannot strand an account mid-way.
02 / END-TO-END ENCRYPTION
End-to-end encryption, and exactly what it covers
Key pairs are RSA-4096, generated in your browser with Web Crypto. The private key is held in browser storage on that device and is never transmitted to the server. Content is encrypted with AES-256-GCM under a content key, which is wrapped for both the user and an organization master key, so an organization retains access when a member leaves.
- COVERED
- Alerts, investigations, and generated reports, for users who have registered keys.
- NOT COVERED
- Users who have not registered keys. Their content is stored unencrypted.
- IN THE CLEAR
- Content passes through server memory during ingest, during matching against your rules, and while a report is generated. "We cannot read it" is true of sealed data at rest and we do not stretch the claim further than that.
- ENFORCEMENT
- An organization administrator can require end-to-end encryption from a set date, with a grace period for existing members.
03 / BLIND INDEXING
Matching without decrypting
Keyword detection over encrypted content runs against an HMAC-SHA256 blind index with a per-user salt. Matches are found without decrypting the underlying material, so detection does not require handing the plaintext back to the server.
04 / AUTHENTICATION AND ACCESS
Who gets in
- SSO
- Enterprise single sign-on over OIDC or SAML. Users reach their organization by company name or work email.
- OAUTH
- OAuth sign-in for organizations that do not run their own identity provider.
- MULTI-FACTOR
- TOTP or WebAuthn passkeys. An organization can require MFA from a set date, with a grace period.
- LOCKOUT
- Accounts lock after repeated failed attempts.
- SESSIONS
- Global session revocation per user, and a platform-wide forced logout when circumstances require it.
- CUSTOM LOGIN
- An organization can have its own branded login page.
05 / ROLES AND PERMISSIONS
Who can do what
- AUDIT
- Read and review. Cannot change configuration or data.
- MEMBER
- Day-to-day analyst work: keywords, alerts, dashboards, investigations.
- ADMIN
- Organization configuration, members, security settings, and enforcement policy.
- OWNER
- Everything an admin can do, plus ownership of the organization itself.
Authorization is checked on every request against the acting user's role and the resource's owning organization. A resource that is not yours returns not-found, not forbidden.
06 / AUDIT AND MONITORING
The record of what happened
- ACTIVITY LOGS
- Every consequential user action is recorded with actor, timestamp, and target.
- SECURITY EVENTS
- Authentication, permission changes, key events, and administrative actions are logged separately from general activity.
- SIEM
- Organization security events can be forwarded into your existing monitoring stack.
- TAMPER EVIDENCE
- Saved messages carry an HMAC-SHA256 hash over canonical content. If the upstream post is edited, the earlier version is archived rather than overwritten, and any saved item can be verified independently against its hash.
07 / DELIVERY AND EGRESS
What leaves the platform
- WEBHOOKS
- Signed with HMAC-SHA256 and scoped to a five-minute replay window, so a recipient can verify the payload came from us and has not been replayed.
- DESTINATION CHECKS
- Webhook and feed URLs are validated against private address ranges and unsafe redirects before a request is made.
- OPT-IN
- Every outbound destination, including Signal, SMS, Telegram, and email, is configured by your own administrators. Nothing is enabled by default.
08 / TRANSLATION AND AI
Where the models run
- TRANSLATION
- Runs on infrastructure we control. There is no third-party translation API in the path, so no translation vendor sees your traffic.
- BRIEFINGS AND REPORTS
- Catch-up briefings and recurring reports are generated by an external model provider, disclosed to customers under our data processing terms.
- CITATIONS
- Every claim in a generated report links back to the alert or source message behind it, so the output can be checked rather than trusted.
09 / SUPPORT ACCESS
When we need to look
Our support access to your workspace requires your organization's consent, is read-only by default, and is logged from request to close. Every session is time-bounded and visible to your administrators while it is open.
10 / PRIVACY AND DATA PROTECTION
GDPR posture
- CONSENT
- Consent is gated per processing type and checked before any consent-bound operation runs.
- EXPORT
- Full data export on request, in a machine-readable format.
- ERASURE
- Right to erasure, with anonymization applied before deletion so audit records remain valid without carrying personal data.
- MASKING
- Personal data is masked in logs and in system reports.
- RETENTION
- Retention jobs run on a defined schedule, not on request.
- SUB-PROCESSORS
- The categories of external services we rely on are disclosed in the privacy policy. Customers receive the named sub-processor register under our data processing terms, on request.
11 / COMPLIANCE POSTURE
What we claim, and what we do not
TideWater's controls are built to SOC 2 principles: security event logging, immutable audit records, access review, and least-privilege authorization. TideWater does not hold a SOC 2 attestation and does not claim one. If your review requires evidence rather than a badge, we will walk you through the controls individually.
The platform is in active alpha and ships frequently. We will tell you what is shipped, what is partial, and what is not built.
Questions your review will ask
If your security team needs something this page does not answer, write to us. We would rather answer it before a deployment than after one.