Isolation in the database
Multi-tenancy is enforced with row-level security in Postgres: every row is scoped to your organization where it cannot be bypassed. In the database, not the UI.
Your client list is the business. The architecture treats it that way.
A DMC's costing, client relationships and attendee data are the company. Two questions follow from that: who can reach it, and whether it is still there on the morning of a program. Both are answered below, structurally rather than as a checkbox screen.
Every action re-checks
Every server action is treated as a public endpoint and enforces its own permission check. Client-side gating is cosmetic by policy: hiding a button is never the security boundary.
Encryption where it counts
Dietary and allergy fields and passport-adjacent details are encrypted at rest with a dedicated application key, on every write path, with rotation supported. Files are served through signed, expiring links.
Invitation only
There is no open sign-up to attack. An organization is created by us; users are invited by your administrators, on single-use tokens that are stored hashed and expire.
Two-factor, and SSO
Time-based one-time-password 2FA is available to every user on every plan. SAML single sign-on with optional org-wide enforcement is on Enterprise, alongside a scoped, rate-limited, audited API.
Granular permissions
Fourteen permission modules × view/create/edit/delete, plus special powers: manage billing, all programs, external sharing. Program access is membership-scoped: outsiders get a 404.
An audit trail that survives erasure
Activity logs name member, action and time, and label AI-sourced changes. Deleting an account does not empty them: the actor becomes an irreversible pseudonym, because a log you can clear by leaving is not a log.
Signatures that hold up
Every e-signature records signer, timestamp, IP address, device and a SHA-256 hash of the signed document. Countersigned copies attach to the same record.
AI that cannot leak to a trainer
Every model call is routed with data collection denied, so no provider that trains on inputs is used. Requests that could carry health data require zero-retention endpoints and fail rather than fall back.
Retention that is enforced
Seven classes of data expire on a schedule you set within bounds the software enforces on both write and read. Dietary and allergy data has the shortest default of all: 60 days after a program ends.
GDPR tooling built in
Export and erasure live in Settings, no ticket required, and the export includes your own location and device history. Client-facing surfaces practice data minimization: status over surveillance.
An exit that is written down
Export anything, any time, at no charge. On termination we hold your data 60 days so you can take it, and we will not withhold it over a commercial dispute. It is in the Terms, not just on a page.
Continuity
If you run the season on it, it has to still be there.
Security answers who can reach your data. This answers whether it is still there on the morning of a program, and what happens when something outside our control fails. Stated plainly, including what we do not claim yet.
Daily backups, verified as running
Managed Postgres with automated daily backups and seven days of retention. Restores are a platform operation, not a script somebody has to remember to run. We check that they are completing rather than assuming it.
A US region, with EU terms
Production runs in a US region. Data processing terms are available for EU customers, alongside the GDPR export and erasure tooling already built into Settings.
Nothing depends on one machine
The application is served from Vercel's edge network and files from Cloudflare R2 object storage. There is no single server in an office that a program day depends on.
Errors surface to us, not to you
Application errors are monitored with Sentry and alert the team directly. The on-site day is the wrong time for a DMC to be the thing that notices a fault.
Your data leaves whenever you want
Programs, attendees, vendors, financials and documents export on demand. The exit path is built in, because a system of record you cannot leave is a risk, not a feature.
Outages elsewhere stay elsewhere
Flight data, mail and payments are separate providers. When one of them degrades, the record stays readable and the rest of the program keeps running.
What we do not claim
No published uptime SLA. No point-in-time recovery, restores are to a daily snapshot. No completed SOC 2 or ISO 27001 audit, and no independent penetration test. No EU data residency: the platform runs in the United States.
And the one we think matters most: there is no independent off-site backup yet. The daily backups above are real and verified, but they are held by the database platform itself. The job that would write an encrypted copy to immutable storage outside that account is written and configured, and is not yet running. A competent auditor would raise it first, so we raise it first.
The full position on every framework, and the documentation behind it, is on our Trust page.
Privacy posture as a selling point.
Corporate buyers carry a travel-risk obligation to the people they send on incentives. ISO 31030 puts those attendees explicitly in scope. The Client Cockpit, guest advisories and the War Room's timeline give your buyer visibility and evidence, built on the same isolation and audit architecture: with the client seeing only their attendees, and status rather than surveillance.
- Client sees their program and their people: nothing else
- Margin and cost are structurally absent from client surfaces
- Guest advisories carry no internal detail, by construction
- Decisions logged on an audit-ready timeline
Security questions
Where does our data live?
In a Postgres database with row-level security as the tenancy boundary, with files on Cloudflare R2 object storage served through signed links, payments processed by Stripe, and the application running on Vercel. Errors are monitored with Sentry.
Who inside DMC Pilot can see our data?
Access follows least privilege: production data access is restricted, actions are audited, and customer data is processed to operate the service, never sold. Data your organization stores is yours; GDPR export produces it on demand.
Why do external users never get accounts?
Vendors, clients, drivers, photographers and guests interact through scoped token links: password-gated and revocable where it matters. No standing credentials means no standing credential risk for the thousands of outsiders a season touches.
What happens if DMC Pilot goes down mid-program?
The record is the thing that has to survive, so it lives in managed Postgres with automated daily backups and seven days of retention, and the application is served from an edge network rather than a single machine. Guest-facing links, driver dispatch and the day sheet all read from that same record. We do not publish an uptime SLA and will not invent one before we have the operating history to stand behind it.
Can we get our data out?
Yes, on demand and without asking us. Programs, attendees, vendors, financials and documents export from the product, and GDPR export produces a full copy. A system of record you cannot leave is a commercial risk to you, so the exit is built in rather than negotiated.
Do you have formal certifications?
No. No SOC 2 report, no ISO 27001 certificate, no Cyber Essentials assessment. What exists is the set of technical controls those audits test, built while the product was built rather than retrofitted. Our Trust page states the position on each framework, what is outstanding, and what each one would actually require, and every legal document is published in full rather than held back for diligence.
Where does our attendees' dietary and allergy data go?
It is encrypted at rest under a dedicated key on every path that writes it, carries the shortest retention default in the product at 60 days after a program ends, and is excluded from the context routinely given to the AI assistant. It is reachable only through a specific attendee lookup, which records each access to the audit trail, and where a model request could carry it, that request is restricted to zero-data-retention endpoints and fails rather than routing somewhere that would keep it.
Do you train AI on our data?
No, and it is enforced rather than promised. Every model call is routed with data collection denied, which excludes providers that store or train on inputs, the routing default is to permit them, so this is an active setting rather than an omission. The account-level settings with our model gateway independently exclude every training endpoint. There is exactly one file in the codebase that can reach a model, so a new feature cannot bypass this by accident.
What happens to our data if we leave?
You export it yourself, any time, at no charge. On termination we hold it for 60 days so you can complete an export and will provide a complete machine-readable copy on request in that window. We will not withhold your data over a commercial dispute. That is written into the Terms, not just stated here.
The paperwork, published
Our compliance position on SOC 2, ISO 27001, GDPR, CCPA and Cyber Essentials is on the Trust page, stated without badges we have not earned. The Data Processing Addendum is published in full, annexes included, and the subprocessor register is compiled from the source code rather than from memory. The Privacy Policy covers health and location data, transfers and retention in detail.
Found a vulnerability? Email security@dmcpilot.com. We acknowledge within two working days and will not pursue action against research conducted in good faith under our disclosure policy.
Bring your security questionnaire.
We'd rather answer it before you buy than after. Serious evaluations get the documentation and a call with the people who built it.