Security

1. Data we collect and why

We collect what a registration and the race need:

• Name, email, phone, and address, used for rosters, emergency contact, and bib production.
• Emergency contact details, captured per registration.
• Waiver acceptance, recorded with a timestamp.
• Event-specific fields, configured by each race director for their event.
• Payment records: amounts, what was bought, and Stripe's reference numbers. We never see or store card numbers.

2. How we protect it

Dead Reckoning Labs is not itself SOC 2 audited. The providers we build on are, and the rest of this list is controls we run ourselves: signed webhooks, scrubbed error reports, rate limits, encrypted off-site backups and separate payments and identity services.

• Hosted on Vercel, a SOC 2 provider.
• Neon Postgres, encrypted at rest, a SOC 2 provider.
• Clerk authentication with MFA and SSO support, a SOC 2 provider.
• Stripe webhook signatures verified server-side before we act on any event.
• Sentry error monitoring with PII scrubbed from reports.
• Upstash Redis used for rate limiting, cache, and uptime history only. It holds no durable PII.
• All traffic is encrypted in transit (HTTPS everywhere, with HSTS).
• Nightly database backups, encrypted before they leave our systems and stored off-site, kept 31 days (monthly copies for a year).
• Payments and athlete identity run as separate services with their own databases. The registration app has no credentials for either database and reaches them only through authenticated service APIs.

3. Payments

Payments run through Stripe (PCI-DSS Level 1). Card details are entered directly with Stripe and never reach our servers. Refunds are issued through our payments service, which keeps a double-entry record of every charge and refund.

4. Access

• Staff and organizers sign in through Clerk. Two-step sign-in (an authenticator app or a passkey) is available on every account and required for the organizer tools.
• Internal access is restricted to the people who need it. An automated review runs every Monday and flags any change in who holds an admin or owner role.
• Database connections require encryption, and credentials are never stored in source code.
• Organizer access is limited to their own organization, and a race director sees only the races they are assigned.

5. Subprocessors

The providers we use to run RaceGoat:

6. Incident response

If we confirm a breach that affects registrant data, we notify affected race directors and registrants without undue delay, and always within the time the law requires.

7. Contact

Security questions and vulnerability reports go to security@deadreckoninglabs.com. We read every report and reply to the reporter. Live uptime for every part of RaceGoat is at status.racegoat.com.

8. Responsible disclosure

If you find a vulnerability, email security@deadreckoninglabs.com with the steps to reproduce it. Our machine-readable contact is at /.well-known/security.txt.

• Safe harbor: we will not pursue legal action against good-faith research that follows this policy, avoids other people's data, and gives us reasonable time to fix the issue before it is disclosed.
• In scope: racegoat.com, status.racegoat.com and the RaceGoat registration, payment and account flows.
• Out of scope: denial of service, load or spam testing, social engineering or phishing of our staff or race directors, physical attacks, and third-party services we use (report those to the provider).
• Use test accounts and your own registrations only. Never access, change or keep another person's data.
• We credit reporters by name on request once the issue is fixed. We do not run a paid bounty.