Tenant isolation and data handling

How WASViking keeps organizations apart, what we encrypt, what we keep, and what never leaves your environment.

WASViking^® is multi-tenant by design. Isolation is enforced at the view layer, the ORM layer, the audit layer, and the billing layer.

Organization scope

Every customer artifact carries an organization_id. Every ORM query that touches a customer artifact filters on the requesting user's organization. This is enforced through:

• Base view mixins that refuse a request without an organization context.
• ORM querysets scoped via .filter(organization=request.user.organization) patterns.
• Audit log writes that record the operator's organization.
• Billing rows linked to organization, not to users.

Cross-tenant data fetch is impossible through the supported API surfaces. We treat any cross-tenant query attempt as a bug.

API key scoping

API keys (wv_live_*) carry the organization they were issued in. The auth middleware sets request.organization from the key. Any attempt to use the key against a different org's resource returns 404 (not 403) to avoid leaking existence.

Partner / customer boundary

The partner host (partners.wasviking.com) and the customer portal host live on the same Django application but on separate URL configs and separate identity tables. Partner operators (PartnerUser) are not Django users; customer users are not partners.

• Partner operators cannot see customer users.
• Customer users cannot see partners.
• Operating model (see Operating models) gates whether a partner sees posture data on a managed customer.

Sentinel agent isolation

• The agent's client certificate binds to one organization.
• Cross-tenant gRPC method calls are refused at the service layer.
• Internal scan jobs are dispatched only to agents bound to the same organization.
• The gRPC server never logs full proto, job, or response payloads.

Encryption

• In transit. TLS 1.2+ on every public endpoint. mTLS on the Sentinel tunnel.
• At rest. AWS-managed encryption on RDS (MySQL) and DocumentDB (MongoDB) where applicable. Tenant-scoped Fernet key for per-tenant sensitive fields.
• API keys are stored hashed, not in cleartext.
• Authentication credentials for authenticated scanning are encrypted with the tenant-scoped key.
• Secrets detected (sentinel secrets) submit only the SHA-256 hash and a masked preview; the raw secret never reaches WASViking.

What never leaves the customer environment

• Raw secrets detected by sentinel secrets. Only hash and masked preview cross the boundary.
• Internal target HTTP bodies in operator logs. The gRPC service redacts proto, job, and response.
• SBOM source files. Only the parsed CycloneDX is submitted.

Retention

When an organization is deleted, all customer artifacts cascade-delete. Audit log rows that name external parties (auditors who accessed a share, for example) are preserved with the customer organization redacted but the third-party access trail intact.

Backups

• Daily automated backups of MySQL and MongoDB.
• 30-day backup retention.
• Restoration is operator-initiated and audited.
• Cross-region backup for disaster recovery on Enterprise plans.

Sub-processors

WASViking uses a short list of sub-processors:

• AWS for compute, storage, network.
• OpenAI for the AI recommendation surfaces.
• Stripe for billing.
• SendGrid for transactional email.
• Cloudflare for edge, WAF, and CDN.

The current list is on the Trust Center (portal.wasviking.com/trust-center). We notify customers under DPA when the sub-processor list changes.

Where to ask deeper questions

• DPA: provided under request from the Trust Center.
• Security questionnaire (CAIQ / SIG): provided under NDA.
• SOC 2 roadmap: posted on the Trust Center.