Data processing addendum

What this is, and why you already have it

When your guests reply on your site, you are the controller of what they send and we are your processor. Data protection law requires a written contract between those two, setting out what the processor may and may not do. This is that contract.

It takes effect automatically when you accept the terms of service. You do not need to sign it, request a copy or negotiate it. If your circumstances mean you need a signed counterpart, write to legal@vows.day and we will provide one.

In this document, you is the account holder as controller, we is Migambi Global, LLC as processor, and data protection law means the UK GDPR, the EU GDPR, the Swiss FADP, and any US state privacy law that applies to the processing, whichever of them applies to you.

Scope, and who does what

This addendum applies to personal data that guests submit through the reply form on your site, and to anything derived from it, such as the notification email we send you and the spreadsheet you export. That is the guest data.

You are responsible for:

• having a lawful basis for collecting what you collect, and for only asking questions you actually need the answer to;
• telling your guests what happens to their answers. The page at section 3 of the privacy policy is written for this and you may point them at it;
• the accuracy of your instructions to us, and for the lawfulness of the guest data you send us;
• answering your guests when they exercise their rights, using the export and delete tools in the studio.

We are responsible for:

• processing guest data only on your documented instructions;
• everything in sections 4 to 10 below.

Your instructions

We process guest data only as needed to provide the service and only on your instructions. Your instructions are:

• the terms of service and this addendum;
• your use of the product: which questions the form asks, whether replies are open, whether notifications are on, when you export, and when you delete;
• anything else you tell us in writing that we agree to.

We will tell you if we think an instruction breaks data protection law, and we may decline to carry it out. If we are required by law to process guest data for something else, we will tell you before we do it unless that law forbids it.

We do not use guest data for our own purposes. Not for advertising, not for analytics, not for building products, and not for training any model. Nothing in the product that talks to an AI provider reads the replies.

Confidentiality

Access to guest data is limited to the people who genuinely need it to run or support the service. Everybody with access is under a duty of confidentiality that survives them leaving, and access is removed when it stops being needed.

Security

We keep appropriate technical and organisational measures under Article 32, taking account of what is being processed and what it would cost somebody if it went wrong. Annex II describes them. We may change them as the product changes, and we will not reduce the overall level of protection.

Subprocessors

You give us general authorisation to use subprocessors. The current list is Annex III below, and section 7 of the privacy policy is the live version of it.

Every subprocessor is bound by a written contract with data protection obligations no weaker than these, and we stay fully liable to you for what they do.

Before a new one starts handling guest data, we will update that page and email account holders at least 30 days beforehand. If you object on reasonable data protection grounds within that time, write to legal@vows.day and we will try to find a way round it. If we cannot, you may end the agreement for the affected part of the service and we will refund the unused portion of what you paid.

Helping you answer your guests

Most of this you can do yourself and immediately, which is better than a request to us: the studio exports every reply and deletes any one of them or all of them.

Where a guest’s request needs something the studio cannot do, we will help you within a reasonable time, taking into account what we can see. We will also help you, so far as we reasonably can, with your obligations on security, breach notification, impact assessments and prior consultation.

If a guest contacts us directly, we will not answer them on your behalf. We will tell them to contact you, and tell you that they got in touch.

If something goes wrong

If we become aware of a personal data breach affecting guest data, we will tell you without undue delay, and in any event within 48 hours of becoming aware. We will tell you what we know: what happened, which categories and roughly how many records, the likely consequences, and what we are doing about it. Where we do not yet know everything, we will send what we have and follow it up rather than wait.

Notifying your supervisory authority and your guests is yours to do, since you are the controller, and we will give you what you need in order to do it.

International transfers

We are in the United States and so are our subprocessors, so guest data collected in the UK, the EEA or Switzerland is transferred out of it.

For those transfers the European Commission’s Standard Contractual Clauses of 4 June 2021 are incorporated into this addendum by reference, Module Two (controller to processor), with:

• Clause 7, the docking clause, included;
• Clause 9, option 2, general written authorisation, with the 30 days’ notice in section 6 above;
• Clause 11 optional redress body: not used;
• Clause 17: governed by the law of Ireland;
• Clause 18(b): the courts of Ireland;
• Annexes I, II and III of the Clauses are the annexes below.

For the UK, the ICO’s International Data Transfer Addendum (version B1.0) is incorporated and applies to those Clauses, with Tables 1 to 3 completed from the annexes below, Table 4 marked neither party, and the start date being the date you accepted the terms. For Switzerland, references to the GDPR are read as references to the FADP, the Federal Data Protection and Information Commissioner is the supervisory authority, and the Clauses also protect data about legal entities until the FADP stops requiring it.

Where a subprocessor is certified under the EU-US Data Privacy Framework, that certification applies in addition to, and not instead of, the Clauses.

Deletion and return

You can delete guest data yourself at any time, and it goes at once. When your account or a site is deleted, all of its guest data is deleted with it.

At the end of the service we delete guest data, unless the law requires us to keep it. Anything still held in an infrastructure provider's disaster recovery copy remains protected by this addendum until it ages out on their cycle, and is never restored.

Export before you delete. There is no undo, and we cannot recover it for you.

Showing our working

We will make available the information reasonably needed to show we are meeting these obligations, and will contribute to an audit you carry out or mandate.

In practice, and because we are a small company with many customers’ data on shared systems, the first answer is documentation: this addendum, our security description in Annex II, and our subprocessors’ own audit reports and certifications, which we will pass on. An on-site audit is available where a supervisory authority requires one or where the law otherwise entitles you to it, on 30 days’ written notice, no more than once a year unless there has been a breach, during business hours, without disrupting the service, and subject to confidentiality. You cover your own costs and ours.

Precedence, and how long this lasts

This addendum lasts as long as we hold guest data for you. Sections 4, 5, 9, 10 and 11 survive the end of the agreement for as long as they need to: confidentiality, security, transfers, deletion and the duty to show our working.

Where this addendum conflicts with the terms of service, this addendum wins on anything about the processing of guest data. Where the Standard Contractual Clauses conflict with either, the Clauses win. Each party’s liability under this addendum is subject to the limits in the terms of service, except where data protection law does not allow that.

Annex I. The parties and the processing

A. The parties

Data exporter (controller): the account holder, as identified by the email address on the Vows account. Activities: operating a wedding website and collecting replies from invited guests. Contact: the account’s email address. Role: controller.

Data importer (processor): Migambi Global, LLC, 131 Continental Dr, Suite 305, Newark, DE 19713, United States. Activities: providing the Vows website building, hosting and reply service. Contact: legal@vows.day. Role: processor.

B. Description of the transfer

C. Competent supervisory authority

The supervisory authority of the EEA member state in which the controller is established, or, where the controller is not established in the EEA, the authority of the member state in which their guests are located, in accordance with Clause 13. For UK transfers, the Information Commissioner’s Office.

Annex II. Technical and organisational measures

Written from what the system does rather than from a checklist, so that each one can be checked.

Access control

• Database rules deny every read and write from a browser. Guest data is only ever returned by a server function that has verified the caller’s token and confirmed they own the site.
• Ownership is checked against the record itself and never inferred from an identifier in a URL. A request for somebody else’s site is answered identically to a request for a site that does not exist, so the API cannot be used to enumerate sites.
• Authentication is by one-time email code or Google sign-in. There are no passwords. A code is stored only as a keyed hash under a per-code salt, expires in ten minutes, allows five attempts, and is deleted when spent.
• Administrative access to production is limited to the people who need it and is protected by multi-factor authentication.

Encryption

• TLS on everything in transit. Published sites are served over HTTPS with HSTS.
• Encryption at rest by the storage providers for the database, file storage and object storage.

Minimisation

• A guest’s network address is hashed on arrival and only the hash is stored. It is used to count abuse and to recognise a duplicate, and nothing else.
• Answers to questions the site does not ask are discarded rather than stored, and an answer outside the offered options for a multiple choice question is discarded. A posted form is markup somebody can edit, so the declared question list is the allowlist.
• Every field has a maximum length, applied on the server.
• Location metadata is stripped from uploaded photographs and video before storage.

Integrity of the collection path

• The reply form is a component we own, injected at build time in place of whatever the design drew. Neither a design template nor the AI can author a field, so nothing can create a form that posts elsewhere or that skips validation.
• Published sites carry a content security policy restricting scripts to the site’s own origin and network connections to our own endpoint, which is what prevents an injected script exfiltrating a reply.
• Rate limits per caller and per site, on counters that nothing else can clear, plus a honeypot field and a minimum time on screen.

Resilience and recovery

• Managed, replicated infrastructure from the providers in Annex III.
• Every change to a site is recorded as an immutable, content-addressed version, and any of the retained versions can be restored.
• Deletion is a single code path shared by every caller, so a new kind of stored file cannot be missed by one of two lists.

Organisational

• Written contracts with every subprocessor, with data protection terms no weaker than these.
• A breach process with a 48 hour notification commitment to controllers.
• Security reports accepted at legal@vows.day and handled without retaliation against good faith reporters.

Measures the subprocessors are relied on for

Physical security of the data centres, network security, hardware disposal, and platform level certifications including ISO 27001 and SOC 2 where the provider holds them. Their own reports are available from them and we will pass on what we can.

Annex III. Subprocessors

Stripe does not receive guest data. It is listed because it is a subprocessor of the account holder’s own personal data, and this annex is the complete list rather than the partial one. Section 7 of the privacy policy carries the live version and each one’s own data protection terms.