Privacy Policy
Effective July 29, 2026 · last updated July 29, 2026
This policy covers both the DMC Pilot website and the DMC Pilot platform. It is written to be useful to two different readers: a person whose data we hold, and a data protection officer at a destination management company deciding whether to put their attendees' data into our software. The distinction that matters most is set out first.
Our two roles
Digital Envision LLC (“DMC Pilot”, “we”, “us”) handles personal data in two distinct capacities, and which one applies changes who decides what happens to the data.
As a controller, for data about our own prospects, customers and the people who use our software: your account, your name and work email, billing contacts, website inquiries and support correspondence. Here we decide the purposes and means of processing, and this policy governs it directly.
As a processor, for the operational data a customer puts into the platform: their programs, their corporate clients, their attendees and delegates, their vendors and their documents. Here the customer, the destination management company, is the controller. They decide what to collect, why, and for how long. We process it on their documented instructions under our Data Processing Addendum, and we do not use it for our own purposes.
The practical consequence for an attendee: if you attended an event and want to know what is held about you, the organization that invited you is the controller and the right place to ask. We will help them answer, but we cannot lawfully hand their records to a third party on request, and we will not.
Data we hold as controller
Website visitors
The website uses Vercel Web Analytics to count page views and a small number of interactions, such as which call to action was used. It sets no cookies and does not track you across other websites. Visitors are counted using a hash derived from the request, which is discarded within 24 hours, and page views are stored as aggregates rather than against a person or an IP address.
What you type is never sent to analytics. When the contact form is submitted we record only whether it succeeded or failed, never your name, email, company or the content of your message. Those reach us by email and go nowhere else. See our Cookie Notice for the complete position, including the booking calendar.
Inquiries and demonstrations
When you request a demonstration or contact us we collect your name, work email, company and whatever you choose to tell us, and we use it to respond, to hold the meeting and to follow up about the product. If you book a call, the calendar is operated by Cal.com and your booking details go to them as well as to us.
Account holders
Access to the platform is by invitation only; there is no open sign-up. For each user we hold a name, email address, role and permission set, authentication data including two-factor enrollment where enabled, and a record of significant actions taken in the product. We hold billing contact details for the organization, and Stripe holds the payment instrument. We never receive card numbers.
Data we process for customers
On our customers' instructions the platform stores, depending on which features they use: program and itinerary records; attendee and delegate names, contact details, companies and travel details including flight and passport-adjacent information; dietary requirements and allergies; signed waivers and consent records; vendor and supplier contacts; proposals, contracts and e-signature evidence including signer IP address and device; uploaded documents and photographs; internal messages; and staff timesheets.
Each customer's data is isolated at the database level using row-level security, so a record belongs to exactly one organization and that boundary cannot be bypassed by the application. Within an organization, access is governed by a permission model across fourteen product areas, and program access is membership-scoped: a colleague who is not on a program cannot reach it.
We do not sell this data, we do not use it to train artificial intelligence models, and we do not use it to build profiles or advertise to anyone.
Health and other sensitive data
Dietary requirements and allergies are special category data under Article 9 of the GDPR, meaning data concerning health. They are also sensitive personal information under the CPRA. We treat them accordingly, and more strictly than the rest:
- The platform refuses to store them without a recorded lawful basis. Before dietary or allergy data can be saved against a program, a named administrator must record which Article 9(2) condition applies, who collected the attendees' consent and where. An attempt to save health data without that on file is rejected, not warned about.
Two things worth knowing about how this works in practice. It is an attestation by the DMC rather than a tickbox shown to an attendee, because attendees never interact with this platform: the data reaches us from the DMC or from their client, so a checkbox here would record somebody consenting on the attendee's behalf, which is not consent at all. And the requirement applies to every program, not only those touching the EEA or the UK, because health information is a special or sensitive category under almost every modern privacy law, including the CPRA and the US state sensitive-data statutes. The operator is asked the question in plain language rather than in statutory citations; the citations live in this policy and in the Addendum, where they belong. - They are encrypted at rest with a dedicated key, separately from the database's own encryption, on every path that writes them.
- They carry the shortest default retention period of any data class in the product: 60 days after a program ends, and never more than a year.
- They are excluded from the context routinely given to the AI assistant. Until 29 July 2026 they were included in the ambient program context on every assistant request; they are now reachable only through a specific attendee lookup, which records each access to the audit trail.
- Where a model call could carry them, it is restricted to zero-data-retention endpoints, which do not retain the request at all. If no such endpoint is available the request fails rather than being routed somewhere that would retain it.
We are not a covered entity or business associate under HIPAA and this data is not protected health information: it is collected to cater an event, not to provide or pay for healthcare. The GDPR obligations above are in some respects the stricter standard in any case.
Staff location and device data
Where a customer uses time tracking, staff check in and out from their own device and the platform records the location at check-in, together with the resolved address, IP address and browser user agent. This exists so that a DMC can evidence that a member of staff was where the program needed them, and so that hours can be verified.
It is not continuous tracking: a position is recorded at the moment of a check-in or check-out, and at no other time. It is retained for 90 days by default, and an employee's own copy of this data is included in the data export available to them. Because this is monitoring of workers, a DMC deploying it will usually have its own obligations: consultation, notice, and in the EEA very often a Data Protection Impact Assessment. Those sit with the customer as controller.
Lawful bases
| Processing | Basis |
|---|---|
| Operating the platform for a customer | Performance of our contract with the customer (Art 6(1)(b)) |
| Website analytics, cookieless and aggregate | Legitimate interests in understanding whether the site works (Art 6(1)(f)) |
| Responding to your inquiry or holding a demonstration | Legitimate interests, or steps prior to a contract (Art 6(1)(f), (b)) |
| Security, abuse prevention, rate limiting and audit logging | Legitimate interests in keeping the service and its data safe (Art 6(1)(f)) |
| Billing, tax and statutory records | Legal obligation (Art 6(1)(c)) |
| Attendee data, including dietary and allergy fields | Determined by the customer as controller. For Article 9 data the customer must identify a condition under Art 9(2). That is usually explicit consent from the attendee, obtained when they register. The platform now enforces this: see §4. |
Artificial intelligence
The platform includes AI features: an assistant that answers questions about your programs, document and manifest parsing, drafting help, and research on clients and destinations. These are worth being precise about, because “we use AI” tells you nothing about where your data goes.
- Nothing is used for training. Every model request is sent with data collection denied at the routing layer, which excludes providers that store or train on inputs, and the account-level settings with our model gateway independently exclude every endpoint that trains on requests.
- Requests carrying health data use zero-retention endpoints only, as described above, and fail rather than fall back.
- There is exactly one route to a model. The gateway client is imported in a single file, so a new feature cannot accidentally reach a model without these policies applied.
- Research calls send no attendee data, only company and destination names.
- Actions are proposed, not taken. Where the assistant can change data it does so through the same permission checks as a person, and material changes are surfaced for confirmation and labeled in the audit trail as AI-sourced.
Model providers are listed in the subprocessor register below. Note that web-search research is a plugin at the routing layer, and zero-retention guarantees do not extend to a search leg; we therefore do not send attendee data on that path at all.
Sharing and subprocessors
We do not sell personal data and we do not share it for advertising. We disclose it to the service providers below, each engaged under terms requiring confidentiality and security, and only as needed to run the platform. We also disclose data where legally compelled, and would notify the affected customer unless prohibited from doing so.
This register is compiled from the source code rather than from memory, and names where in the platform data actually leaves. The authoritative, always-current copy is at /subprocessors, which is also where changes are announced.
Infrastructure
| Provider | Purpose | Data | Health data |
|---|---|---|---|
| Supabase | Primary database, authentication and object storage | Everything the product stores: accounts, program and attendee records including dietary and allergy fields, waivers, chat, timesheets including location and IP | Yes |
| Vercel | Application hosting, serverless execution and scheduled jobs | All request data in transit; operational logs may contain IP addresses | Only if present |
| Cloudflare R2 | File and document storage, photo albums, database backup target | Uploaded documents and images; encrypted database dumps | Yes |
| Upstash | Distributed rate limiting | IP addresses and user identifiers, held transiently as rate-limit keys | No |
| Sentry | Application error monitoring and session replay | Stack traces, user identifier only, scrubbed request context | Only if present |
Communications and payments
| Provider | Purpose | Data | Health data |
|---|---|---|---|
| Resend | Transactional email, invitations, proposals, digests, alerts | Recipient name and email address, message contents | No |
| Expo (EAS Push) | Mobile push notification relay for the DMC Pilot iOS and Android app | Device push tokens and short notification previews: sender first name and up to 140 characters of message text. Never dietary, allergy or other health information | No |
| Stripe | Subscription billing, add-ons and usage charges | Billing contact details and payment instrument, which Stripe holds and we never receive | No |
| Cal.com | Demonstration booking on the public website only | Name, email address and any answers given when booking a call | No |
Artificial intelligence
| Provider | Purpose | Data | Health data |
|---|---|---|---|
| OpenRouter | Model gateway, the single route by which any model is called | The contents of the prompt for the feature in use | Yes |
| Google (Gemini), via OpenRouter | Assistant answers, document and manifest analysis, safety guards | Program context and attendee names; dietary and allergy fields only when a question requires them | Only if present |
| OpenAI, via OpenRouter | Fallback for assistant answers and guards | As above | Only if present |
| Perplexity, via OpenRouter | Client and destination research requiring web search | Company and destination names only, no attendee data | No |
Operational data sources
| Provider | Purpose | Data | Health data |
|---|---|---|---|
| AviationStack / FlightAware | Flight status tracking | Flight numbers and dates only, no personal data | No |
| Mapbox | Geocoding, maps and place search | Addresses and place queries | No |
International transfers
The platform's database and application run in the United States, in the us-east-2 region, and file storage selects its region automatically. Our subprocessors are predominantly US-based. Personal data of people in the EEA, the UK and Switzerland therefore leaves those territories.
Where that happens, the transfer requires an Article 46 safeguard. Our position, stated plainly. The technical measures that support such a transfer (encryption in transit and at rest, additional field-level encryption for sensitive data, access control and logging) are in place and described in §11. We have also completed a transfer impact assessment covering every subprocessor against US surveillance law, which concludes that transfers may proceed with those measures and that no residual risk is high.
What is not yet done is execution: the Standard Contractual Clauses have not been countersigned with customers, and we will not describe them as in place before they are. Two findings from that assessment are worth knowing regardless. Health data is materially protected against compelled disclosure, because the database and file storage providers do not hold the key that decrypts it. Ordinary attendee details, names, contacts, travel, are not: they are readable by a compelled infrastructure provider, and no measure available to us changes that without breaking the product. A customer for whom EU data residency is a requirement should raise it with us before contracting, because today we cannot offer it.
How long we keep data
The platform enforces retention rather than leaving it to good intentions. Each class of data below has a default period, and a customer can adjust it within bounds that the software enforces on both write and read, a value outside the range is clamped, not honored. Expiry is evaluated daily.
| Data | Default | Customer may set | Why |
|---|---|---|---|
| Dietary requirements and allergies | 60 days after the program ends | 7 days to 1 year | Health data with the shortest useful life of anything here: it exists to brief a caterer, and stops being needed once the event is over. |
| Attendee records | 1 year after the program ends | 30 days to 3 years | Names, contacts and travel details, kept long enough to handle post-event queries and repeat bookings. |
| Staff check-in location and device data | 90 days | 7 days to 1 year | Location, IP and device recorded at clock-in. Kept for the payroll and dispute window, not as a movement history. |
| Notifications | 90 days | 7 days to 1 year | In-product alerts, which have no value once read and acted on. |
| Assistant conversations and memories | 180 days | 30 days to 2 years | Chat history and learned preferences that make the assistant useful across a season. |
| Soft-deleted records | 30 days | 7 days to 1 year | The undo window after something is deleted in the product, after which it is purged for real. |
| Activity and audit logs | 1 year | 90 days to 7 years | Who did what, and when. The floor is higher than the others on purpose, an audit trail a customer can shorten at will is not an audit trail. |
Two honest caveats. First, enforcement is opt-in per organization: until a customer turns it on, the schedule runs in reporting mode and shows what would be deleted without deleting it. Second, database backups are immutable for their retention period, so data erased from the live system can persist in a backup until that copy expires; backups are used only to restore the service, never to answer a query about a person.
Separately, we retain our own business records, contracts, invoices and tax documentation, for as long as the law requires, typically seven years.
Security
The measures we actually operate, and their limits, are set out in detail on our Security page, and our certification position, including what we have not achieved, on our Trust page. In summary: tenancy isolated in the database rather than the interface; every server action enforcing its own authorization check; encryption in transit and at rest, with additional field-level encryption and key rotation for sensitive personal data; invitation-only accounts with granular permissions, optional two-factor authentication and single sign-on on the Enterprise plan; an audit trail that survives account deletion; automated daily database backups; and error monitoring that scrubs personal data before it leaves the application.
Your rights
Where the GDPR or UK GDPR applies you have the right to access your data, to have it corrected, to have it erased, to restrict or object to processing, to receive it in a portable form, and to withdraw consent where consent is the basis. You also have the right not to be subject to a solely automated decision with legal or similarly significant effects, see §16.
Account holders can exercise access and erasure directly in the product, under Settings → Data & Privacy, without asking us. The export includes account data, notifications, assistant conversations and memories, and activity history. For staff whose employer uses time tracking it also includes their own location, address, IP and device records.
Two limits worth stating in advance rather than on refusal. Erasing an account does not erase the audit trail of what that account did: the record is retained with the actor replaced by an irreversible pseudonym, which Article 17(3) permits and which we regard as necessary, an audit log that can be emptied by deleting an account is not an audit log. And the sole remaining super administrator of an organization cannot erase themselves, because access is invitation-only and doing so would strand the organization's data with nobody able to reach it.
California privacy rights
This section is our notice at collection under the CCPA as amended by the CPRA, and applies to California residents.
We do not sell personal information, and we do not share it for cross-context behavioral advertising. We have never done either. There is consequently no “Do Not Sell or Share My Personal Information” mechanism to offer, and any site that presents one while doing what we do is describing a different business.
The categories we collect, and why:
| Category | Collected | Purpose |
|---|---|---|
| Identifiers | Name, work email, account identifier, IP address | Providing and securing the service; responding to inquiries |
| Commercial information | Subscription, plan and billing records | Billing and statutory records |
| Internet activity | Aggregate page views; application error and audit records | Operating, debugging and securing the service |
| Geolocation | Position at staff check-in, where a customer uses time tracking | Verifying attendance and hours worked |
| Professional information | Employer, job role, permissions | Access control within a customer's organization |
| Sensitive personal information | Health data in the form of dietary requirements and allergies; precise geolocation at check-in | Catering and duty of care for an event; verifying attendance. Used only to deliver the service requested, never to infer characteristics, and never for profiling |
You have the right to know what we collect and to receive a copy, to delete it, to correct it, to limit our use of sensitive personal information, and not to be discriminated against for exercising any of these. We do not use sensitive personal information for any purpose beyond providing the service, which is the limit the statute allows you to request in any event. An authorized agent may act for you on proof of authority. Where the data belongs to a customer's organization we will refer the request to them as the business, and support them in answering it.
Making a request
Email privacy@dmcpilot.com. We acknowledge within five working days and respond substantively within one month, which we may extend by two further months for a complex request, telling you why, within the first month, if we do. Requests are free unless manifestly unfounded or excessive.
We will verify your identity in proportion to the sensitivity of what is requested, using the account you are asking about wherever possible rather than asking you for new identity documents. Every request we receive is logged with its outcome and timing, so that our handling of it is itself auditable.
If you are an event attendee rather than a user of the software: the organization that invited you is the controller of your data and is the correct recipient of your request. If you contact us we will tell you so, and where we can identify the customer we will pass the request to them promptly.
Breach notification
Where we act as processor and become aware of a personal data breach we notify the affected customer without undue delay, with the information they need to meet their own 72-hour obligation to a supervisory authority. Where we act as controller we notify the relevant authority within 72 hours where the breach is likely to result in a risk to people, and notify affected people directly where the risk is high.
Automated decision-making
The platform scores vendor reliability, flags margin risk, clusters transfers and suggests actions. None of these produces a decision about a person with legal or similarly significant effect, and none operates without a person able to see and override the output. Vendor scores are explainable by design: the factors behind a score are shown alongside it, because a supplier told their rating dropped is entitled to know which delivery caused it.
Children
The platform is business software and is not directed to children. We do not knowingly collect data from anyone under 16. A customer running an event with minors in attendance is the controller of that data and carries the corresponding obligations, including parental consent where required; if you believe a child's data has reached us in error, contact us and we will work with the customer to remove it.
Changes
We will update this policy as the platform changes. The effective date at the top always reflects the current version. Where a change materially affects how we handle personal data we will notify customers by email or in the product before it takes effect, and for changes to the subprocessor list the notice period in the Data Processing Addendum applies.
Contact and complaints
Privacy inquiries and requests: privacy@dmcpilot.com. Security reports: security@dmcpilot.com, and see our disclosure policy.
Controller: Digital Envision LLC, 16192 Coastal Highway, Lewes, DE 19958, United States of America. No Data Protection Officer has been appointed at the time of writing.
EEA representative under Article 27: [TO BE COMPLETED]. UK representative: [TO BE COMPLETED]. We are established in the United States and have no establishment in the Union, so these appointments are required of us and are outstanding. One consequence worth stating for anyone considering a complaint: because we have no establishment in the Union, the one-stop-shop under Article 56 does not apply to us. There is no single lead authority, and the authority in your own country may act.
You have the right to complain to a supervisory authority. In the EEA that is the authority where you live, work or where the issue arose; in the UK it is the Information Commissioner's Office. We would rather you raised it with us first, but that is your choice and not a precondition.
Questions about this document: legal@dmcpilot.com. Privacy requests: privacy@dmcpilot.com. Security reports: security@dmcpilot.com.