Platform architecture

The security posture of the WASViking platform. Tenant isolation, encryption, identity, availability and the commitments behind them.

WASViking^® is a multi-tenant SaaS platform. This page is the security summary the procurement and security teams of prospects ask for. It covers the main components, how your data is protected and kept apart from other customers, and the engineering commitments behind the service. It is written so it can be attached to a vendor diligence response without further editing.

Components

Where your data lives

Customer data is stored in managed cloud services in the United States, encrypted at rest and limited to the organization it belongs to. Scan artifacts, evidence bundles and reports follow the same rules. Regional options and the sub-processor list are covered under Data residency, further down this page.

Encryption

Key rotation is automated for short-lived material (agent client certificates, session keys) and operator-driven for long-lived material (API keys, with a 24-hour overlap window).

Tenant isolation

Each customer is an organization, and everything it owns (targets, findings, reports, agents, users and API keys) belongs to that organization only.

• Your users and API keys only reach the data of your own organization. Data is never shared across customers.
• Sentinel agents are bound to your organization and only receive work from it.
• The audit log you see covers your own organization only.

The Partner Console uses accounts that are separate from the customer realm. Partner operators are not customer users. The two cannot see each other across hosts. More detail in Tenant isolation.

Identity and access

• SAML 2.0 SSO as Service Provider. Standard attribute mapping, optional group-to-role propagation. First sign-in defaults to Read-only by policy; promotion requires an existing Admin or Manager.
• Multi-factor authentication is mandatory for every operator. TOTP-based when SSO is not enforced; IdP-enforced when SSO is on.
• RBAC with four default roles (Admin, Manager, Analyst, Read-only) and a granular capability catalog of 25+ scopes. Roles are editable per organization.
• API keys scoped per organization. Granular scope set per key. Hashed at rest, rotatable with overlap, optionally IP-restricted.
• Emergency local login for SSO-enforced organizations, for when the identity provider is unavailable. It is time-limited and every use is recorded as a high-severity audit event.

Network protection

• The Sentinel agent is outbound-only. It connects to WASViking from inside your network. No inbound ports, no static IP allow-listing, no VPN required. The agent's private key never leaves the host.
• Sensitive content stays out of logs. Cookies, CSRF tokens and the content of your internal targets are never written to logs.
• Public endpoints are protected by DDoS mitigation, bot management and rate limiting.

Hardening

Agent:

• Signed releases, so you can verify the binary before running it.
• Runs as a hardened service with the minimum privileges it needs.

Platform:

• Least privilege for every service and every member of the team.
• Production access requires MFA, is time-bound, and is logged.
• Platform credentials are kept in a dedicated secrets vault, never in code.

Cloud accounts

Cloud Security reads your AWS accounts through a role you create in each account and keep under your control:

• The role is read-only: the AWS managed read-only audit policy plus a small supplement of list and describe actions. It cannot change a resource and it cannot read object contents, secret values, parameter values, function code or database rows.
• The role trusts the WASViking account with an External ID generated for your account only; sessions are temporary and no access key is ever shared or stored.
• Removing an account stops the reads at once, and only you can delete the role.

The exact policies are in the templates the connect wizard generates; see Cloud Security.

Secure software development

WASViking runs its own product against its own code:

• DAST before every release.
• SBOM and SCA with known-exploited vulnerability checks on every change.
• Secrets detection on every change. Changes with a known-exploited component or a live secret do not ship.
• Code review is mandatory, with protected branches and required checks before a change is merged.
• Signed releases of the Sentinel agent, which you can verify before installing.
• Threat modeling for changes that touch identity, access control or data isolation.

This is the same set of gates WASViking ships as a product. The product page set has the full reference: CI/CD with wasviking-sentinel.

Logging and audit

• Customer-facing audit log at /portal/audit-log/, gated by the audit_logs.view RBAC capability. Public REST scope audit_logs:read.
• Mutation events (RBAC change, API key issuance, finding status transition, posture share access, evidence bundle access) are written immutably.
• Platform events are monitored by WASViking.
• Default audit retention is 24 months; configurable up to 7 years on Enterprise plans.
• Signed webhook events mirror audit-relevant transitions for external SIEM ingestion.

Backups and recovery

• Automated backups of all customer data stores, kept on a 7-day rotation with point-in-time recovery.
• Restoration is tested every month, and the result is kept as audit evidence.
• Copies of erased data expire with the rotation and are never restored into production.

Data residency

Production data is hosted in United States regions today. Regional residency options for additional jurisdictions are part of the Enterprise roadmap. Sub-processors and their regions are documented on the Trust Center.

Compliance posture

Two postures, kept strictly separate:

What the product supports. WASViking maps findings to controls across PCI DSS v4.0, LGPD, GDPR, BACEN (CMN 4.893 and BCB 85), and ISO 27001:2022, from a single rule table. Evidence Bundles are designed to be attached directly to an audit binder. See Framework mapping.

What the company is certified for. WASViking LLC is working toward SOC 2 Type I and ISO 27001 Certification. Current status, sub-processor list, DPA, and the security questionnaire (CAIQ / SIG) are available on the Trust Center at wasviking.com/trust-center/.

Vulnerability disclosure

WASViking welcomes coordinated disclosure. The policy, scope, safe harbor, and PGP key are at Reporting vulnerabilities. Acknowledged reporters are named (with permission) when WASViking notifies affected customers about the issue.

What we publish externally

• This documentation.
• The institutional marketing site.
• The Trust Center with DPA, privacy policy, sub-processors, and the SOC 2 roadmap.
• A coordinated disclosure policy and PGP key.

What we do not publish externally

The following are shared only on signed mutual NDA (or not at all):

• Internal IP ranges, network diagrams, and provider-account identifiers.
• Specific framework, database, and runtime versions in use.
• Internal admin routes and operator runbooks.
• Margin and cost models.
• Incident response procedures.
• Customer-specific configurations.

These are deliberately withheld because they are operationally sensitive and provide no security value to a prospect.