Security & architecture
Your own database. At every tier.
A separate PostgreSQL database for every customer, on every band. Not an enterprise upgrade, and not a column with your name in it. Backup and restore are per customer, and so is every query.
Isolation
Another customer’s data is not in your database.
The most common multi-tenant breach is a query that forgets its tenant filter. That query has nothing to leak here. Another customer’s rows are not in the database it runs against.
Isolation tested on real PostgreSQL
Every scoped model carries an isolation test, run against a real database through the same routing the application uses. No mocks, no simulated tenant context.
Restore your data on its own
Point-in-time restore runs against your database alone. No other customer is touched, and no other customer’s restore touches you.
Take the whole database with you
Your data is a database that can be handed over intact, not a report we generate for you on the way out.
Your neighbours cannot slow you down
A ten-thousand-person show in another tenancy is a different database on different connections. Nobody else’s registration day lands on your registration day.
The security review
The five questions your security review will ask.
Answered here so you can check them before you send the questionnaire.
“Where does our data live?”
In a database that holds your tenancy and nothing else. Attendee records, registrations, sessions, leads and the attendance log are all inside it.
“Who at your company can read it?”
Nobody, by default. Access during an incident requires a written reason, approval by a second person, and an expiry, and it is read-only unless explicitly granted otherwise. You are notified every time.
“Where do the card numbers go?”
Not to our servers. Tokenisation happens in the browser on the processor’s own hosted field, which is also the only way a 3-D Secure challenge can complete.
“What happens if your platform is down on our show day?”
The door keeps scanning. Rosters and admission rules are cached on the device, the decision is made on the device, and scans reconcile when the network returns — and a scan replayed twice is still one record.
“Can we get everything out?”
Yes. Every action the interface takes is an API endpoint you also have, and your data sits in a database that can be handed over whole.
Privacy, operationally
Erasure, retention and consent are built in.
Each of these is a working feature you can demonstrate to a reviewer, not a paragraph in a policy document.
Erasure that propagates
A deletion request reaches the registration, the attendance record and the lead — not just the row somebody remembered.
Retention classes, enforced
Each class of data has a retention period the system applies, with legal holds that suspend it where a case requires.
Consent is versioned
Terms and notices are versioned documents, so you can show which text a given attendee accepted and re-request when it changes.
Subject requests are routed
Access, correction and withdrawal requests land somewhere with an owner and a clock, rather than in a shared inbox.
Subprocessors and residency, on record
Who processes what, and where it sits. The question your DPA review opens with, answered from the product rather than from memory.
Sensitive fields stay sensitive
Dietary and accessibility answers are gated per field — not exposed to everyone who can open a registration.
Send us your security questionnaire.
It comes back completed, usually the same week, from the engineer who designed the architecture it asks about.
hello@fieravents.com