Data processing agreement

You, the host, hold the account and bring guest lists into Vientic. You decide which guests to bring in, what to ask of them, how to score them, what to decide and when to delete them. For your guests’ personal data you are the controller.

We are Vientic, a sole proprietorship based in Seattle, Washington, at 2801 Alaskan Way, Seattle, WA 98121. We process your guests’ data to provide the service and on your instructions. For that data we are your processor.

Two things are outside this agreement, because for them we are the controller and our privacy policy governs:

• Your own account data: your email address, name, workspace, connected keys and what you do in the product.
• The look-up cache: a public LinkedIn profile we have fetched is keyed by its LinkedIn slug, used for 90 days and then treated as stale, and shared across hosts so the same profile is not bought twice. It holds only what the vendor returned, never your notes, scores, decisions or guest lists. A stale copy is not deleted on a schedule; a profile is deleted when the guest is erased. The privacy policy describes it.

Subject matter. The personal data about guests that you bring into Vientic by connecting Luma, turning on Luma webhooks or uploading a CSV, and the data we derive from it to provide the service.

Duration. For as long as you have an account, and then for the deletion window described under Return and deletion. Erasing a single guest ends the processing of that guest’s data once the erasure is carried out, within the 30 days described under Requests from guests.

We store, display, match, score, enrich, summarize, aggregate and delete guest data, and we transmit it to the subprocessors listed below, in order to:

• show you your guest list and let you decide on it;
• recognize a returning guest across your own events and show you that history (never another host’s);
• score registrations against criteria you write, and explain the score;
• look up a guest’s public professional profile, when your plan allows it, you have turned look-ups on, and the guest gave a LinkedIn URL;
• build an event report, including a short narrative, which you may share;
• push your decisions back to Luma when you ask;
• keep a record of what each AI model was asked and what it answered, so we can measure and improve the quality of scoring and summaries;
• run the service: authentication, plan limits, error detection, and backups.

The privacy policy’s sections on AI processing and LinkedIn profile look-ups say exactly what each of those steps sends and to whom. They are part of your instructions to us.

Data subjects

Your guests: the people on the guest lists you bring in, whether they registered through Luma or appear in a CSV you uploaded. Guests never sign up for Vientic and never interact with it directly.

Categories of personal data

• From the registration: name, email address, LinkedIn profile URL, company, job title, the guest’s answers to your registration questions, ticket name, amount paid and currency, registration status and its timestamps, seats, check-in, Luma’s identifiers for the guest and the registration, and the raw record as the source sent it.
• Derived by Vientic: one person record per guest within your account, linking them across your events, with counts of how often they applied, were admitted, attended, missed or cancelled late; a fit score, bucket and reasons per registration, if you run scoring; a looked-up professional profile (headline, occupation, summary, location, work history, education, skills, industry, follower and connection counts, and the vendor’s response verbatim) and an AI-written two-line summary of it, if you run look-ups.
• Written by you: notes about a guest, and your admit and decline decisions.

Special categories

The service needs none, and asks for none. A guest’s free-text answer to a question you wrote may contain whatever the guest typed, so if your registration form invites information about health, religion, politics, sexuality or similar, you are responsible for having a lawful basis to collect it, and you must not write scoring criteria that use it. The same holds for everything you bring in from any source you connect: what it contains, and whether you may collect and share it, is your responsibility as the controller.

• We process your guests’ data only on your documented instructions. Your instructions are this agreement, the terms of service, the privacy policy’s description of what the product does, and what you do in the product: importing a list, running scoring, turning look-ups on, writing a note, sharing a report, pressing Push, erasing a guest, deleting your account.
• We will process it for no other purpose. We do not sell it, do not use it to train AI models, and do not let our subprocessors do so.
• If the law we are subject to requires us to process it otherwise, we will tell you before we do, unless that law forbids telling you on important grounds of public interest.
• If we believe an instruction of yours breaks data-protection law, we will tell you at once. We may pause that instruction until it is resolved.

Only people who need to see guest data to run the service, answer a support request or carry out an erasure can see it. Today that is a small number of operators with an administrative view across accounts. Each is bound to confidentiality, and every administrative action is written to an audit log that records what was done and to which account, without copying a guest’s name or email into the log.

Taking into account what the data is and how it could be misused, we keep the following measures in place. They are the same ones the privacy policy lists under Security, and this section serves as the description of technical and organizational measures (Annex II) where the Standard Contractual Clauses apply.

• Isolation between accounts. Every table is protected by row-level security, so a host’s queries can only reach that host’s rows. Service credentials never reach the browser.
• Private storage. Uploaded CSV files and generated PDFs live in private buckets and are served only through short-lived signed links.
• Secrets. Luma API keys and webhook secrets are stored in an encrypted vault; we display only the last six characters of a key.
• Encryption in transit. Connections to the site and to every subprocessor use TLS.
• Minimization toward AI models. Scoring prompts carry a compact fact sheet with email addresses and phone numbers removed; profile summaries omit the guest’s name; column mapping sees header text only; report narratives see aggregate numbers only.
• Logs and error reports are kept free of personal details by design, and errors are scrubbed of email addresses, phone numbers and LinkedIn slugs before they leave our systems. No user identity is attached to an error report.
• Access control and audit. A small number of operators have an administrative view, and every administrative action is written to an audit log.
• Backups. Our database provider takes daily backups and keeps them for 7 days.
• Erasure that stays erased. An erased guest leaves a suppression entry (Luma identifiers and a salted hash of the email, per event) so a later sync, webhook or re-import of the same event does not bring them back.

We may improve these measures over time and will not reduce the overall level of protection during the term of this agreement.

You give us general permission to use the subprocessors below. Each one is bound by written terms that impose data-protection obligations no weaker than the ones in this agreement, and we remain responsible to you for what they do with your guests’ data. All of them operate from the United States.

This table is the same list our privacy policy shows; both pages read it from one place, so they cannot disagree.

Changes. We update this table at least 30 days before a subprocessor that handles guest data is added or replaced. The table is the record. If you would rather be told than check it, write to support@vientic.com and we will email you each change before it takes effect. If a subprocessor has to be replaced at once to keep the service running, we update the table and email those hosts as soon as we can, and the 30 days run from then. If you object on reasonable data-protection grounds within the 30 days and we cannot offer a way around the change, you may end the agreement by exporting your data and deleting your account, as described under Return and deletion.

Requests from guests

Because you are responsible for your guest list, a guest who wants access to, correction of, or erasure of their data should write to you, and you can act on most requests yourself: you can see and edit a guest’s record, export any event’s guest list as a CSV, and ask us to erase a guest. If a guest writes to us instead, we will tell you within a few days and will not answer on your behalf except to say that we have passed the request on.

When you, or a guest through you, ask us to erase a guest, we carry out the erasure within 30 days, as the privacy policy describes under Deletion and erasure: the person record, notes, looked-up profile and cache entry and any CSV that carried them are deleted; their registrations are scrubbed of every identifying field while the anonymous fact of a seat remains; their entries in the AI call record are redacted; and a suppression entry keeps them from being re-imported.

Other help

Taking into account what we process and what we know, we will help you meet your own obligations: answering a guest’s request where you cannot do it yourself in the product, carrying out a data-protection impact assessment, consulting a supervisory authority, and demonstrating compliance. This page, the privacy policy and the security measures above are the first answer to most such requests; where you need more, write to support@vientic.com.

If we become aware of a breach of security that leads to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, your guests’ data, we will tell you without undue delay, by email to the address on your account. That is the standard data-protection law sets for a processor; we do not promise a number of hours.

The notice will say what we know at the time: what happened, which guests and which categories of data are likely affected, what the likely consequences are, what we have done and propose to do, and whom to contact. We will add what we learn as we learn it. We will help you notify your supervisory authority and your guests where you have to, and we will not tell your guests ourselves unless you ask us to or the law requires it.

• Return. You can export any event’s guest list as a CSV at any time, so there is nothing to ask us for. If you want your data back at the end, export it before you delete your account.
• Deletion at the end. When you delete your account under Settings → Account, it is scheduled for permanent deletion 30 days later and you are signed out. During those 30 days you can ask us to cancel. After the window we permanently delete the account and everything in it: events, guests, registrations, notes, reports and uploaded files. The purge is run by a person against a list of eligible accounts, not by a scheduled job, so it may happen some time after day 30.
• Backups. A deleted record can persist in a daily backup for up to 7 days after deletion, and is then gone.
• What survives a guest’s erasure while your account remains: a suppression entry per event (Luma’s identifiers for the guest and the registration, and a salted hash of the email; no name, no email), which keeps a later sync or re-import from bringing them back, and the cost and timing fields of their redacted AI call records. Luma’s identifiers can be tied back to the guest by Luma and by your account, which is what makes the suppression work; they are not readable as a person by anyone else. Both are deleted with your account.
• What survives the account purge. The operator audit log, which records what was done and to which account (counts and identifiers, no guest name or email). Looked-up profiles in the shared cache describe a public profile rather than your account: they stay in the cache with the link to your account removed, under the privacy policy rather than this agreement, and are deleted when that guest is erased. Anything else we are required by law to keep, we keep only for as long as that law requires, and we keep it confidential.

We will give you the information you reasonably need to show that we meet this agreement: this page, the privacy policy, the security measures above, and written answers to a reasonable security questionnaire within a reasonable time. We hold no third-party certification such as SOC 2 or ISO 27001 today, and this page does not claim one.

Where written answers are not enough to meet an obligation you have under data-protection law, you or an independent auditor you appoint and we accept may audit our processing of your guests’ data: no more than once a year, on reasonable notice, during business hours, remotely unless the law that binds you requires an inspection in person, under confidentiality, and without reaching another host’s data. Our systems run on the providers in the table, so an audit is of our configuration, records and answers, not of premises. You pay for your auditor and for our time at our then-current rate, unless the audit finds a material breach of this agreement, in which case our time is on us.

We process all guest data in the United States, and so do our subprocessors. We are not certified under the EU–U.S. Data Privacy Framework. If you are established in the European Economic Area, the United Kingdom or Switzerland, bringing your guests’ data into Vientic is a transfer to a country without an adequacy decision, and the following applies.

European Economic Area

The Standard Contractual Clauses adopted by the European Commission in Decision (EU) 2021/914 of 4 June 2021 are incorporated into this agreement by reference, in Module Two (transfer from a controller to a processor). You are the data exporter and we are the data importer. The clauses are read with these choices:

• Annex I (parties and description of the transfer) is the Parties and roles, Subject matter and duration, Nature and purpose, and Data subjects and categories sections of this page.
• Annex II (technical and organizational measures) is the Security measures section.
• Annex III (list of subprocessors) is the Subprocessors table.
• Clause 9: Option 2, general written authorization, with at least 30 days’ notice as described under Subprocessors.
• Clause 7 (docking clause) is not included. Clause 11’s optional independent dispute resolution is not included. Clause 13: the supervisory authority is the one for the member state in which you are established. Clause 17: the clauses are governed by the law of Ireland. Clause 18: disputes are resolved by the courts of Ireland.

United Kingdom

For transfers subject to UK data-protection law, the Standard Contractual Clauses apply as amended by the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses issued by the UK Information Commissioner (version B1.0, in force 21 March 2022), which is incorporated by reference. Its Tables 1 to 3 are completed by the information above. For Table 4, either party may end the Addendum as set out in its Section 19.

Switzerland

For transfers subject to the Swiss Federal Act on Data Protection, the Standard Contractual Clauses apply with these adaptations: the Federal Data Protection and Information Commissioner is the competent supervisory authority under Clause 13; references to the GDPR are read as references to the Swiss act; references to a member state include Switzerland, so that data subjects in Switzerland can bring claims in their own courts; and the clauses protect the data of legal entities to the extent the Swiss act does.

Each party is liable to the other for its own breach of this agreement. Our total liability under this agreement is subject to the limitation of liability in the terms of service, read as one cap across the terms and this agreement, except where the Standard Contractual Clauses say otherwise for transfers they govern.

• Term. This agreement lasts as long as we process your guests’ data: for the life of your account and through the deletion described above.
• Precedence. For personal data, this agreement prevails over the terms of service where they conflict, and the Standard Contractual Clauses prevail over this agreement for the transfers they govern.
• Changes. We may change this agreement. For a material change we will email hosts in advance, and the effective date at the top always says which version applies.
• Governing law. This agreement is governed by the laws of the State of Washington, and disputes under it are brought in the state or federal courts in King County, Washington, as the terms of service provide. The Standard Contractual Clauses are governed by the law and courts they name.

support@vientic.com
Vientic, a sole proprietorship based in Seattle, Washington
2801 Alaskan Way, Seattle, WA 98121

See also our privacy policy and terms of service.