Security and data residency

*Last updated: 2026-07-13.*

Reporting a vulnerability

Email security@campsite-os.com. Machine-readable version: [`/.well-known/security.txt`](/.well-known/security.txt) (RFC 9116).

We will acknowledge within 3 working days and tell you what we intend to do. We will not take legal action against good-faith research that respects the rules below, and we are happy to credit you when it is fixed.

In scope: `campsite-os.com` and its subdomains. Out of scope: our customers' own websites; and our payment providers (Stripe, Mollie) — please report those to them directly.

Please do not: run automated scans that degrade service for real campsites; access, modify or exfiltrate other people's booking or guest data; or attempt social engineering. Ask us for a test campground — we will give you one.

Where the data lives

We would rather be plainly accurate here than comfortably vague.

Application (Vercel)Production function region not yet evidenced in this draft
Database (Neon Postgres)United States (`aws-us-east-1`) — today
Email (Resend)US-based provider; configured processing/sending region requires production evidence
Payments (Stripe, Mollie)The park's own PSP account. Card data never reaches us.

The database is not yet in the EU. Transfers to the US are covered by the EU Standard Contractual Clauses in the applicable subprocessor agreements, which is not the same thing as EU residency. The exact production database, application and email regions must be recorded and reviewed before live guest processing; this page does not promise a future migration as a present fact.

If EU residency is a hard requirement for you, ask us where the migration stands before you sign anything.

What we do not hold

  • Card numbers. Checkout is hosted by the park's PSP; no card field exists anywhere in our code.
  • Passport images. Guest registration captures the *fields* an authority requires, never a scan or a photo of the document.

How the money records are protected

  • Invoices and ledger events are immutable at the database level — UPDATE and DELETE are rejected by triggers, not by convention. Corrections are credit notes.
  • Invoice numbers are gapless per property.
  • Authority credentials are encrypted at rest (AES-256-GCM).
  • Per-property access control, so a chain can fence a member to their own site.

Sub-processors

The full list, with what each one does and where it runs, is at /legal/subprocessors. The applicable notice period and objection process are the ones stated in the executed DPA; this draft does not invent a 30-day promise.