How we protect your data.

Encryption

In transit

TLS 1.2+ on every public endpoint, terminated at Cloudflare and re-established in-network to our origin in Full (Strict) mode. HSTS preload submitted; mixed-content blocked at the edge.

At rest

AES-256 on the Postgres data directory (DigitalOcean Block Storage encryption) and on every object in Spaces (server-side AES-256). Customer database backups carry a second AES-256 layer — encrypted with our own key before upload, so a Spaces credential leak alone cannot decrypt a backup.

OAuth tokens

Integration access tokens are encrypted at the application layer with a versioned key before storage, so the database never sees plaintext provider credentials.

Authentication and access

• Individuals: magic-link only — no passwords, no shared secrets that can leak. 15-minute single-use tokens; 30-day rolling sessions.
• Corporate accounts: mandatory TOTP MFA at signup (with 8 single-use backup codes), per-workspace lockout after 5 attempts in 15 minutes, and password (argon2id, 64 MiB memory cost). Enterprise SSO & SCIM (Okta, Microsoft Entra, Google Workspace, SAML 2.0) is on the roadmap, available on request.
• Database row-level security: `FORCE ROW LEVEL SECURITY` on every customer-data table. Customer A cannot read customer B's rows even if the application layer is bypassed.
• CSRF + clickjacking defense: double-submit CSRF cookies on every state-changing request; `X-Frame-Options: DENY` and a strict CSP on every authenticated response.

File uploads

Every customer file routes through a four-layer pipeline before it ever serves: synchronous validation (size, MIME sniff, polyglot rejection), private storage in DigitalOcean Spaces, asynchronous ClamAV virus scan, asynchronous libvips re-encode + EXIF strip. Infected files are deleted from object storage the moment they're detected, and the row carries the virus signature for forensics. Files do not serve until they have cleared both scan and transform.

The Maria-and-John line

We track scanner engagement to make our marketing relevant and our product better. We do not expose that engagement in identifiable detail to the card owner. When a scanner shares identity (by name, email, exchanging contact), the owner sees the identity. When the scanner views repeatedly, the owner never sees the frequency — that signal reflects the scanner's emotional state, which is the scanner's business.

This is enforced at the database constraint level, not policy alone. The unique-index pattern (card_id, viewer_fingerprint_hash, event_type, occurred_date) means the data simply does not exist for us to surface accidentally.

Sub-processors

We use a small number of industry-standard processors. Each one is scoped to the minimum data needed for its job.

We notify customers at least 30 days before adding a new sub-processor that handles customer data.

Outbound webhook payloads

When a workspace admin subscribes to an outbound webhook, some events carry user-typed business content (comment bodies, announcement text, transfer notes). Delivery is restricted to the admin-configured target URL, HMAC-SHA256 signed with a per-subscription secret, and audit-logged on every attempt. The full per-event disclosure (which events carry content, which carry metadata only) is published with the webhook configuration UI inside each workspace.

Backup and recovery

Daily backups

Encrypted pg_dump to a separate Spaces bucket every night at 03:00 UTC. Tiered retention: 7 daily, 4 weekly, 12 monthly. Backups carry our own GPG layer on top of Spaces' native AES-256.

Tested restore drill

Every quarter, an automated drill restores the latest daily backup to a fresh database, runs a row-count comparison against production, and writes the outcome to the audit log. An untested backup is not a backup.

Snapshot fallback

DigitalOcean droplet snapshots also run nightly, providing a separate restore path if a full VM recovery is needed.

RPO / RTO

Recovery Point Objective: ≤ 24 hours (pre-PITR; ≤ 5 minutes after WAL archiving lands post-launch). Recovery Time Objective: ≤ 10 minutes for the database restore itself.

Compliance posture

• SOC 2 Type I: attestation in progress (target Q4 2026). Pre-attestation: independent security review prior to public launch.
• GDPR: data subject access request (DSAR) export and right-to-be-forgotten endpoints launch with the public gate. EU sub-processor list maintained current; Data Processing Agreement available on request.
• CCPA:California "do not sell" toggle and deletion request endpoints launch with the public gate.
• HIPAA: not currently in scope. Wired but disabled — BAA-eligible customers get isolated infrastructure when revenue justifies the dedicated cluster.
• PCI: Cardholder data never touches our servers. Stripe handles tokenization at the browser.

Continuous monitoring

• Third-party script monitoring: Cloudflare Page Shield catalogs every external script served on Øen pages and alerts on content drift. Compensates for SRI hashes being incompatible with mutable upstream CDN URLs (e.g., Adobe's SDK).
• Bucket access logging: every read, write, and delete against object storage is logged to a separate Spaces bucket with 365-day retention.
• Application audit log: authentication events, admin actions, integration connections, and webhook deliveries write append-only rows to the database audit log. Customer-side exports available to workspace admins at launch.
• System log shipping: nginx, PHP-FPM, and Postgres logs ship daily to off-droplet storage for 90-day retention. Customer database backups ship nightly. Both available for forensics independent of the running droplet.

Incident handling

Suspected security issues are triaged within one business day of report. Confirmed incidents that affect customer data trigger customer notification within the GDPR 72-hour window and a postmortem within seven days. The current incident history is published below — we intend this list to stay short, and to be candid when it cannot.

Incident history: none to disclose as of the last update.

Reporting a vulnerability

Email [email protected]. Include a reproducible proof-of-concept. We acknowledge within one business day and never threaten or pursue legal action against good-faith security research. We do not yet run a paid bounty program; recognition and credit are available to researchers who request them.

For deeper questions

• SOC 2 / customer security questionnaire: [email protected]
• Data Processing Agreement: [email protected]
• Privacy questions and GDPR / CCPA requests: [email protected]
• Service status: oen.cards/status
• Privacy policy: oen.cards/privacy
• Terms of service: oen.cards/terms