Trust at Dacard

Last updated: April 17, 2026

Dacard, Inc. builds a product operations diagnostic for teams making real decisions about real work. The data you bring into Dacard is how we earn that trust: URLs, integration signals, coaching conversations, billing records. This page explains what we do to protect it, who we rely on, where we are short of a formal attestation, and how to reach us when something looks wrong.

We favor under-claiming. If a control is not in place yet, you will find it on the roadmap below rather than dressed up as more than it is.

1. Security

Encryption in transit. All traffic to dacard.ai and app.dacard.ai is served over HTTPS with TLS 1.3, terminated at the Vercel edge.

Encryption at rest. Production data is stored in Turso and inherits cloud-provider disk encryption. OAuth tokens for integrations are additionally encrypted at the application layer with AES-256-GCM before being written to the database.

Webhook verification. Incoming webhooks from Stripe, Resend, and Linear are verified against an HMAC signature before we act on them. Unverified payloads are rejected.

HTTP security headers. We send Content-Security-Policy (allowlisted for Clerk, Stripe, PostHog, Sentry), Strict-Transport-Security (HSTS, one year), X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and a Permissions-Policy that denies camera, microphone, and geolocation access.

Rate limiting. Anonymous scoring endpoints are capped at 10 requests per 60 seconds per IP. Authenticated API routes have per-plan limits.

Access control. Production access is limited to the founding team, gated by single sign-on through Clerk, and requires multi-factor authentication for administrative actions.

2. Privacy

A full account of what we collect, how we use it, who we share it with, and the rights you have over your data lives in our Privacy Policy. The short version: we minimize what we take, we do not sell personal information, and we honor access, correction, deletion, and portability requests regardless of where you live. Retention windows for scoring inputs, account data, and billing records are spelled out in the Privacy Policy.

3. Compliance

We are not SOC 2 attested today. A SOC 2 Type 2 audit is on our roadmap. We will update this page when the audit is scheduled and again when it completes. Until then, we are candid: our controls are documented and implemented, but they have not been independently attested.

The subprocessors we build on carry their own attestations, listed below. Those attestations do not transfer to us, but they cover the infrastructure tier most commonly asked about in security reviews.

4. Incident response

If you believe you have found a security issue, email hello@dacard.ai with "Security:" at the start of the subject line. A member of the team will acknowledge within one business day and keep you updated as we investigate.

We do not operate a formal bug bounty program at this stage. Responsible disclosure is welcomed and credited.

Historical incidents: none to date.

5. Subprocessors

We rely on the following services to operate Dacard. Each processes data on our behalf under a data processing agreement. This list is maintained; material changes will be reflected on this page.

Attestations are self-reported by each vendor and current as of the Last updated date above. We verify annually and on material change.

6. Contact

For security issues: hello@dacard.ai with "Security:" as the subject prefix.

For privacy requests: privacy@dacard.ai.

For anything else: hello@dacard.ai.

Dacard, Inc., Vancouver, BC, Canada.