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
• Content-Security-Policy headers restricting allowed origins
• Subresource integrity checks on viewer libraries

---

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: security@swyvl.io

---

Responsible disclosure

If you discover a security vulnerability in Swyvl, please report it to security@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. Audit logs are accessible to all workspace members and are retained indefinitely.