Security & compliance

Overview

Swyvl is built with security as a core requirement, not an afterthought. Spatial data often contains sensitive asset information, infrastructure locations, and proprietary survey data. Here’s how we protect it.

---

Authentication

• Swyvl is passwordless — sign in via a magic link emailed to you, or with Google
• Sessions expire and are automatically refreshed
• Optional two-factor authentication (2FA) via TOTP (Google Authenticator, 1Password, Authy, etc.) — enable in Settings → Account → Security

---

Data access control

Row-level security (RLS)

Every database table has Row-Level Security policies enforced at the database level by PostgreSQL. Even if application code has a bug, the database will not return data you don’t have permission to see.

Access is scoped by:

• Organisation membership — you can only see data in organisations you belong to
• Workspace membership — you can only see data in workspaces you’re a member of

Share links

Share links are public by design — they’re intended for clients who don’t have Swyvl accounts. Share link security is controlled by:

• Access mode — view-only prevents downloads
• Unpublish — revokes access immediately
• Password protection — clients enter a password before viewing
• Invite-only — only specific email addresses can access
• Link expiry — coming soon

File access

Files are stored in private object storage. Access is granted only via short-lived presigned URLs (1-hour expiry) generated by the Swyvl server. URLs are never cached with credentials.

---

Data storage

• Files are stored in Wasabi object storage — SOC 2 Type II, ISO 27001 certified
• Storage is region-locked — files in your chosen region never leave it
• All data is encrypted at rest (AES-256) and in transit (TLS 1.2+)
• File data is never used for AI training

---

Viewer security

Swyvl’s file viewers run inside sandboxed iframes. Viewer code cannot:

• Access your Swyvl session or cookies
• Make requests outside the viewer sandbox
• Read or write to the parent page’s DOM

This is enforced via:

• sandbox attribute on the iframe element
• A separate browser origin (embed.swyvl.io) that cannot reach hub/share cookies
• Content-Security-Policy headers restricting allowed origins

---

Infrastructure

• Database: Supabase (managed PostgreSQL) — automated backups, point-in-time recovery
• Processing: Google Cloud Run — isolated containers per job, no persistent state
• File storage: Wasabi S3-compatible — zero egress costs, no data transfer to third parties
• Hosting: Firebase Hosting (Google CDN) — global edge network, DDoS protection

---

Compliance

Standard	Status
SOC 2 Type II (via Wasabi)	✓ Storage layer
ISO 27001 (via Wasabi)	✓ Storage layer
GDPR	✓ EU region available, DPA on request
Australian Privacy Act	✓ AU region, APP compliant
CCPA	In progress

For compliance documentation, DPA requests, or security questions: support@swyvl.io

---

Responsible disclosure

If you discover a security vulnerability in Swyvl, please report it to support@swyvl.io. We aim to acknowledge reports within 24 hours and resolve critical issues within 72 hours.

Please do not publicly disclose vulnerabilities before we’ve had a chance to address them.

---

Audit logging

Every significant action in Swyvl is recorded in an audit log, visible in the Activity tab of each site:

• File uploads, downloads, and deletions
• Share link creation, viewing, and unpublishing
• Client feedback (approvals, change requests)
• Account changes (login, member added/removed)

Each event captures the IP address and approximate geolocation (city, country) of the actor. Site activity is accessible to all workspace members and is retained for up to two years. The separate immutable compliance audit trail (administrative and security events) is retained as our chain-of-custody record.