Security & data protection

Last reviewed 9 August 2026

RSVPPlus holds the names, contact details and attendance of people invited to official government functions. That is sensitive by nature: a guest list can reveal who met whom and when. The controls below describe how that data is protected.

Personal data is encrypted by the application, not just the database

Guest email addresses and telephone numbers are encrypted with AES-256-GCM before they reach the database, using a key held only in the environment. A database dump, a leaked backup or an over-privileged query returns ciphertext that the database itself cannot decrypt. Equality lookups (finding a person by email) run against a keyed HMAC blind index, so searching never requires storing or querying plaintext.

Each department sends from its own authenticated domain

Invitations are delivered from the department's own sending domain with DKIM signatures aligned to it, and replies route to the department's existing mailbox. Guests see an address they recognise, and receiving mail servers can verify it. No inbound mail plumbing is required: MX records are untouched.

Departments are isolated from one another

Every guest, event and message is scoped to a single department. Row-level security is enabled on all tables holding personal data and the anonymous role is revoked from them. Public API keys are bound to one department and cannot be pointed at another.

Public surfaces are opt-in, never inherited

Self-registration links, public event pages and ticket sales each default to OFF and must be switched on deliberately per department and per event. A feature that opens a public write endpoint is never enabled by a default.

Every administrative action is recorded

Creating, editing, approving, publishing, exporting, suppressing and sending are all written to an append-only change log with the acting user, the department, the affected record and a timestamp. The log is exportable for audit.

Guest-facing endpoints are rate limited

RSVP pages, RSVP submissions, self-registration and check-in each carry their own rate limit, keyed by network address, to resist token enumeration and automated abuse. Limits fail open so that an infrastructure fault can never lock staff out of check-in at a live event.

Payments never touch our servers

Card details are entered on Stripe-hosted checkout. The platform stores an order record, the amounts as sold and a payment reference. Webhook payloads are verified by HMAC signature with a replay window before they are trusted, and ticket issuance is idempotent by database constraint.

Outbound integrations are signed and encrypted in transit

Webhook receivers must be https. Each payload is signed with a per-endpoint secret over a timestamped body so a receiver can reject both tampering and replay. API keys are stored only as SHA-256 hashes — the platform cannot reveal an existing key, only issue a new one.

Reporting a vulnerability

If you believe you have found a security issue, report it to your department's platform administrator rather than disclosing it publicly. Reports are triaged ahead of feature work.