Data Processing & Residency Statement

Last modified: September 26, 2026

Introduction

This statement is published by Solodigitalis Inc. ("Company", "We") as a companion to our Privacy Policy. Where the Privacy Policy describes what personal information we collect and why, this statement describes where user information (including but not limited to personal information) is processed and stored, which sub-processors are involved at each stage, and what the Operator's account region does and does not control.

It is intended for prospective and current customers, particularly those with regulatory, contractual, or internal requirements about data residency, who need a precise picture of the data lifecycle across the Platform (as defined in the Privacy Policy). It supplements the Privacy Policy and our terms of use with operational detail. Contractual processor obligations are set out in the applicable Data Processing Addendum. A description in this statement does not reduce an obligation in that addendum, and an operational change does not amend the addendum unless made in accordance with its amendment provisions. For processing governed by the Data Processing Addendum, the documents apply in the following order to the extent of a conflict: an executed customer-specific data processing agreement, the published Data Processing Addendum, the Privacy Policy, this statement, and the terms of use. No licence or other provision in the terms of use authorizes processing inconsistent with the purposes, instructions, retention limits, or individual-rights obligations stated in the Data Processing Addendum or required by applicable law.

Who and what this statement covers

Throughout this statement we use the following terms:

• Operator — the customer who signs up at dashboard.booth.events, configures one or more events, pays for the service, and operates our software, such as the Booth.Events app, at an event where the Platform is used.
• Guest — a person whose photograph or video is taken at an Operator's event, and who may optionally enter contact information (such as email or phone number) to receive a copy of their content.
• Operator Data — the Operator's identity (name, email, account credentials), billing information, the configuration of their events (templates, branding, prompts, and questions presented to Guests), support interactions with us, and other data provided by or collected about the Operator in accordance with the Privacy Policy (see Information We Collect and How We Collect It).
• Guest Data — photographs and videos captured at an event, together with any contact details, survey responses, free-text answers, and other event data a Guest provides through the Platform (see Information We Collect and How We Collect It in the Privacy Policy).
• Sub-processor — a third party that processes Operator Data or Guest Data on our behalf.
• Operator's account region — the cloud region selected by the Operator at sign-up in which the core guest data plane processes and stores Guest Data, subject to the specific cross-border processing, delivery, caching, analytics, and Operator-selected destination exceptions described in this statement.

Internally we run two distinct data planes: the operator data plane (referred to in our infrastructure as "booth.events") for Operator Data, and the guest data plane (referred to as "shared.gallery") for Guest Data. They are separate databases, separate object storage, and separate server-side services. References to these data planes throughout this statement use those names.

For Guest Data collected through an Operator-configured event, the Operator determines the purposes and material means of processing and is responsible for providing required notices and obtaining any consent or other lawful authority required before collection, including before photographs or videos are captured. We process that Guest Data on the Operator's behalf and in accordance with the Operator's documented instructions, except where we independently determine the purposes and means of processing for account administration, security, fraud prevention, legal compliance, or another purpose expressly described in the Privacy Policy. This allocation does not limit obligations that apply directly to us under applicable law.

Operator's account region

Each Operator selects an account region once during sign-up. The default suggestion is derived from the Operator's sign-up IP and may be changed during sign-up. The choice is bound to the Operator's account at creation time. The currently available account regions are:

• United States - Iowa, Oklahoma, South Carolina
• Canada - Montréal
• Germany - Frankfurt

References elsewhere in this statement to the Operator's account region refer to whichever of these regions the Operator selected. This section is the current list of available core guest data-plane regions. It does not override the disclosures below concerning processing or caching outside the account region. We may add further account regions over time.

Data residency: what the account region controls

The Operator's account region has the following effects:

• Core Guest Data is processed and stored in the account region. The database, object storage, and server-side processing that we operate for photographs, videos, Guest contact details, and gallery sessions run in the Operator's account region, except where Guest Data leaves that region for one of the specific purposes described below, including delivery, AI processing, content delivery, analytics, support, security, or an Operator-selected destination.
• Operator Data is always processed and stored in the United States. Account identity, event configuration, billing records, and support data live in the operator data plane regardless of the account region.
• Email and SMS delivery to Guests is processed in the United States. When a Guest requests their gallery by email or SMS, the message and the recipient address transit United-States-based delivery providers (see the sub-processor table below) regardless of the Operator's account region. The delivery provider is used solely for the purpose of dispatching the message the Guest has requested.
• AI-enabled processing is not confined to the account region. When an Operator enables an AI feature, the source photograph and relevant prompt material may be sent to the applicable AI service provider identified in the Sub-processors section. Processing may occur in the countries identified for that provider and is not limited to the Operator's account region. The generated output is returned to and stored in the Operator's account region.
• Guest media is cached outside the account region. Photographs and videos are served through a content delivery network so that they load quickly. Copies may be held at edge locations worldwide and at an origin cache in France, regardless of the Operator's account region. Cached copies may remain retrievable through an existing link for up to seven days unless purged earlier, and we will implement an expedited purge where required to comply with a valid deletion request.
• Website analytics are not region-bound. The public gallery records the page visited, country, device type, and a visitor identifier generated by our analytics provider in a database hosted in the United States, with a read replica in the European Union, regardless of the Operator's account region. These records do not contain a Guest's name, email address, phone number, photographs, or answers. Where the analytics technology stores or accesses information on a Guest's device or otherwise requires prior consent under applicable law, it is disabled until that consent is obtained; separate consent is not required for technology that is strictly necessary to provide the gallery or another service requested by the Guest.

Data lifecycle

International transfer safeguards. Where Guest Data or Operator Data is transferred from the European Economic Area to a country that the European Commission has recognized as providing an adequate level of protection, including Canada for qualifying commercial organizations, we rely on that adequacy decision where it applies. For transfers that are not covered by an adequacy decision, including transfers to United States service providers and processing in other non-adequate countries, we rely on the European Commission's standard contractual clauses as incorporated into the applicable provider's standard data-processing terms, together with any supplementary measures required by law. For personal information governed by Quebec law that is communicated outside Quebec, the enterprise responsible for the information must comply with any privacy impact assessment, contractual safeguard, and cross-border transfer requirements imposed by applicable law before the communication. The applicable mechanism and safeguards depend on the origin of the data, the destination, the provider, and the capacity in which each party acts.

The table below shows, at each stage, what happens to Operator Data and Guest Data, who processes it, and where it sits.

Data at rest

• Operator Data rests in the operator data plane (booth.events) in the United States.
• Guest Data rests in the guest data plane (shared.gallery) in the Operator's account region, including both database records and object storage of photographs and videos.
• Encryption. All data is encrypted at rest using AES-256 under our cloud provider's managed keys. All data in transit between Operators, Guests, our servers, our sub-processors, and the Booth.Events app is protected with TLS 1.2 or above. Customer-managed encryption keys are not currently offered.
• Backups. Regular database exports are taken in the same region as the source database and stored in same-region object storage. Backups inherit the residency of the region they are taken in and are retained for 30 days, after which they are permanently deleted.

Sub-processors

The following table lists sub-processors currently identified as processing Operator Data or Guest Data in connection with the Platform, the categories of data they receive, and the regions in which they process it. We engage each sub-processor under its standard published terms of service and data-processing terms, which are linked in the table below along with its privacy documentation. We have not negotiated customer-specific terms with those providers. We provide each sub-processor only the categories of data listed for it and only for the purpose listed. We review and update this list as our services and provider arrangements change.

We also use ordinary business tools that are not listed here — for example, a form for taking an Operator's order for a custom design. Those tools may receive limited Operator Data; they never receive Guest Data.

Several sub-processors engage service providers of their own. Where they do, those arrangements are governed by the sub-processor's own terms and described in its documentation.

Destinations you choose

Some features send Guest Data to services that an Operator connects or designates. The Operator holds or controls the destination account, chooses whether to activate the transfer, and determines its subsequent use of the data. Our transmission is made on the Operator's documented instruction, but we remain responsible for securely implementing that instruction and for obligations that apply directly to us while the data is in our possession or being transmitted. Once the data reaches the Operator-selected destination, the Operator and the destination provider are responsible for the subsequent processing, retention, deletion, notices, permissions, security, and responses to individual-rights requests, subject to applicable law. Our retention and deletion schedules do not reach copies held at that destination.

• Cloud storage. An Operator can connect a Dropbox, Google Drive or SmugMug account, and we will copy that event's photographs and videos into it.
• Webhooks. An Operator can configure a webhook address. When a Guest is sent their photos we post the details of that session to it, including any email address, phone number and answers the Guest provided.

Separately, when a Guest shares a gallery or photo link, the messaging app or social network they share it to will usually fetch the photograph in order to show a preview, and may keep its own copy of it.

AI processing and model training

AI features are optional: a Guest photograph is sent for AI generation only when an Operator has configured an AI feature on the event. AI portraits and filters are generated by our AI partner Magipic AI. AI Prompts are generated by Google Cloud's Vertex AI or by OpenAI, depending on the model the Operator selects. Authorized personnel may review AI inputs or outputs where reasonably necessary to investigate errors, provide support, maintain service quality, or verify platform functionality.

We do not use Guest photographs or videos, or data derived from them, to develop, train, fine-tune, or improve any machine learning or artificial intelligence model. This applies to every AI feature described in this statement.

We require AI service providers that process Guest photographs or videos on our behalf to comply with the data-use restrictions contained in their applicable standard terms and data-processing documentation. We do not instruct or authorize those providers to use Guest content, or data derived from it, to develop, train, fine-tune, or improve any machine learning or artificial intelligence model. Where a provider's standard terms do not support that restriction, we will not describe the provider as contractually prohibited from that use.

Google's standard Google Cloud terms govern Vertex AI processing. Section 18 (Training Restriction) of the Service Specific Terms provides that Google will not use Customer Data to train or fine-tune AI or machine-learning models without the customer's prior permission or instruction, as further described in Google's Vertex AI data governance documentation. Google may retain limited prompt data for abuse monitoring under those terms; that separate purpose does not authorize model training.

OpenAI's standard business terms govern OpenAI processing. Under those terms and OpenAI's API data-usage documentation, OpenAI does not use data submitted through its API to train its models unless the customer opts in, and we have not opted in. OpenAI retains API inputs and outputs in abuse-monitoring logs for up to 30 days; that separate purpose does not authorize model training.

Facial recognition and biometric data

We do not perform facial recognition or facial correlation. We do not create, derive or store a facial template, faceprint, face embedding or any other biometric identifier, and we do not use a face to identify a Guest, to match one photograph to another, or to link photographs across events or galleries. We do not offer face-based photo search.

Some features locate where a face sits in a photograph so that a filter or effect can be applied to it. That happens on the Operator's device, produces only the position of a face, and is not retained. Some features detect facial landmarks or face position within a photograph solely to apply a visual effect.

Where an Operator uses an AI feature, the applicable AI sub-processor handles the photograph under the agreement governing our use of that service, including its standard data-processing terms where applicable. The provider's public privacy documentation is linked in the sub-processor table above for additional information, but a provider's privacy policy does not replace the contractual processor terms required for processing on our behalf.

Network and platform protections

Access to Operator Data and Guest Data is limited to the personnel who need it to operate and support the service, and is controlled by role-based permissions in our cloud provider.

Our infrastructure runs on Google Cloud Platform, which maintains SOC 2, ISO 27001 and equivalent certifications for the services we use; Google publishes the current list in its compliance documentation. Solodigitalis Inc. does not itself hold a SOC 2 or ISO 27001 certification.

Card payments are processed by Stripe, which is certified as a PCI DSS Level 1 service provider. Full card numbers and security codes are never transmitted to or stored by us. Where our other sub-processors hold security certifications of their own, these are published in their compliance documentation, which is linked from the sub-processor table above.

All endpoints that accept Operator Data or Guest Data require TLS. We apply web-application firewall protections in front of the guest data plane, including IP-based rate-limiting and filters for common attack patterns aligned with the OWASP Core Rule Set (such as injection, cross-site scripting, and automated scanner detection).

Requests from the Booth.Events app to the guest data plane may additionally be authenticated using Apple's device-attestation features (DeviceCheck and App Attest), so that an Operator's event can only be uploaded to from a genuine, registered installation of the app on Apple hardware.

Privacy and security incidents. We maintain procedures to identify, investigate, contain, document, and remediate privacy and security incidents. Where we process Guest Data on an Operator's behalf, we will notify the Operator without undue delay after becoming aware of an incident affecting that data and will provide reasonable information and assistance for the Operator's investigation, risk assessment, notices, and communications. Where applicable law imposes a direct notification or record-keeping obligation on us, we will comply with that obligation. This commitment does not transfer to the Operator any obligation that applies directly to us.

Retention and deletion

• Photographs and videos. Galleries are deleted when the Operator deletes the event, or when the gallery expires. The Operator does not choose an expiry date; it is normally set from the plan level of the individual event. An Operator may delete an event, and with it the gallery, at any time before expiry. When a gallery is deleted the files and any zip exports are hard-deleted (see Backups and recovery below). A free event's gallery is soft-deleted on expiry instead, so that the Operator can restore it by purchasing within 21 days of the expiry date; if that does not happen, it is hard-deleted at the end of that period.
• Copies on the Operator's device. Photographs and videos are saved to the photo library on the Operator's device by default, so the Operator keeps a separate copy under its control. Our deletion processes do not remove that copy. Where we process Guest Data on the Operator's behalf, we will notify or assist the Operator as required by our contractual and legal obligations so that the Operator can address a valid deletion request across copies it controls. The default local saving function can be turned off, for one device or for all of an Operator's devices, on request. The app also keeps a temporary copy of media it downloads while an Operator browses a gallery, which it clears when the Operator opens a different gallery.
• Cached copies. Photographs and videos served through our content delivery network may remain cached and retrievable through an existing link for up to seven days after the source files are removed from active storage. We treat those cached copies as retained personal information during that period. When deletion is required in response to a valid erasure request, we purge without undue delay rather than waiting for ordinary cache expiry. If a technical limitation prevents immediate removal, we restrict access where feasible, document the limitation, complete the purge as soon as possible.
• Copies sent for AI generation. When an AI feature is used, how long the AI sub-processor keeps the photograph and the generated output is governed by its own terms, linked in the sub-processor table above. Deleting a gallery does not reach those copies.
• Gallery records and media metadata. Deleted with the gallery they belong to, when the gallery is deleted.
• Guest contact details and per-Guest delivery records. The Guest's email address, phone number, free-text answers, and the records of which messages were sent to which Guest are hard-deleted together with the gallery they were collected for, when the gallery is deleted.
• Short links. When a gallery link is sent by SMS we create a short link that redirects to it. The redirect record contains the link target and the Operator who created it, not the recipient. It is kept after the gallery it points to is deleted, at which point it no longer resolves to anything.
• Backups and recovery. Deleting data removes it from the Platform straight away, but copies are kept briefly so we can recover from accidental deletion or technical failure. Deleted photographs and videos remain restorable for 7 days, and each regional database can be rolled back to any point in the previous 7 days. Regional database exports are separately retained for 30 days. Copies held for these purposes cannot be reached through the Platform or a gallery link, are used only to restore the service, are deleted automatically at the end of these periods, and stay in the region they were taken in.
• Operator Data. Retained for the life of the account. On account closure the account record and its billing history are deleted, except for records we are required to keep in order to satisfy legal, accounting or reporting requirements. Answers an Operator has given to our own product research surveys are not deleted automatically on closure; they can be deleted on request.
• Export. While an account is active, an Operator can download an event's photographs and videos as a zip file, and can export Guest contact details and data-collection answers as a CSV. Once the periods described above have passed, we are not able to recover data that has been deleted.
• Deletion on request. Operators and affected Guests may request deletion of personal information ahead of these schedules by emailing media@solodigitalis.com. We will delete the information where required by applicable law, subject to lawful retention grounds and other exceptions. Where we process Guest Data only on an Operator's behalf, we may refer the request to the relevant Operator or assist that Operator in responding. We will address requests within the period required by applicable law. Copies held for backup and recovery are removed on the schedules described above, and cached media will be purged on an expedited basis where required to comply with a valid deletion request.

Changes to this statement

We will publish updates to this statement on this page, with the revision date at the top of the document.

Data Processing Addendum. Where we process Guest Data on an Operator's behalf, the Data Processing Addendum set out below is incorporated into and forms part of the agreement between the Operator and us. It applies automatically to that processing without requiring a separate signature, unless the parties have executed another data processing agreement that expressly supersedes it. If there is a conflict concerning the processing of personal information, the Data Processing Addendum prevails to the extent stated in that addendum.

Operator particulars and transfer annexes. The Operator may complete the controller details, processing particulars, and applicable transfer annexes through its account or an electronic request form. Completion of those particulars does not amend the standard Data Processing Addendum or require negotiation. Where the European Commission's standard contractual clauses apply, the completed particulars are incorporated into the relevant annexes, and the parties are deemed to have selected the modules and options specified in the Data Processing Addendum.

We will add a new sub-processor to the table on this page at least 30 days before it begins processing Operator Data or Guest Data, so that Operators have notice before the change takes effect. Where a sub-processor must be engaged sooner to maintain the security or continuity of the service, we will publish the change as soon as we can. Operators who want to raise a concern about a new sub-processor can write to media@solodigitalis.com.

Contact

Questions, due-diligence requests, and data-deletion requests may be sent to our Privacy Officer at media@solodigitalis.com. The Data Processing Addendum set out below applies automatically where incorporated into the Agreement. This statement allocates operational responsibilities between us and Operators but does not transfer or exclude any obligation that applies directly to us under applicable privacy or data-protection law, including obligations concerning processor terms, security, incident notification, and assistance with individual-rights requests.

Data Processing Addendum

Effective date: The date on which the Operator accepts or otherwise enters into the Agreement.

This Data Processing Addendum ("DPA") forms part of the agreement between Solodigitalis Inc. ("Company") and the individual or entity that has accepted such agreement as an Operator ("Operator" and such agreement the "Agreement"). It applies to the extent the Company processes Guest Data on behalf of the Operator in connection with the Platform. Capitalized terms not defined in this DPA have the meanings given in the Agreement, the Privacy Policy, or the Data Processing & Residency Statement.

1. Definitions and interpretation

In this DPA: Applicable Data Protection Law means privacy and data-protection law applicable to the processing of Personal Data under the Agreement, including, where applicable, PIPEDA, the GDPR, the UK GDPR, substantially similar provincial private-sector privacy laws, and Quebec's Act respecting the protection of personal information in the private sector; Controller, Processor, Data Subject, Personal Data, Process, and Supervisory Authority have the meanings given by Applicable Data Protection Law; GDPR means Regulation (EU) 2016/679; Personal Data Breach means any act or omission that compromises the security, confidentiality, or integrity of Personal Data or the safeguards maintained to protect it, including accidental or unlawful destruction, loss, alteration, unauthorized disclosure, access, acquisition, copying, use, corruption, or unavailability, whether or not the incident meets a statutory reporting threshold; Restricted Transfer means a transfer of Personal Data to a jurisdiction that requires an approved transfer mechanism under Applicable Data Protection Law; SCCs means the European Commission standard contractual clauses adopted by Implementing Decision (EU) 2021/914; and UK Addendum means the then-current United Kingdom addendum to the SCCs issued by the Information Commissioner's Office.

2. Roles and instructions

The Operator is the Controller of Guest Data and determines the purposes and means of its processing. The Company is the Processor of Guest Data, except to the extent the Company independently determines the purposes and means of a processing activity expressly described in the Privacy Policy and permitted by Applicable Data Protection Law. The Operator is responsible for providing required notices and obtaining any consent or other lawful authority required before Guest Data is collected, including before photographs or videos are captured.

The Company will process Guest Data only on the Operator's documented instructions, including the Agreement, this DPA, the Operator's use and configuration of the Platform, and other written instructions accepted by the Company, unless Applicable Data Protection Law requires otherwise. If law requires processing beyond those instructions, the Company will inform the Operator before processing unless legally prohibited. The Company will promptly notify the Operator if, in its reasonable opinion, an instruction infringes Applicable Data Protection Law and may suspend the affected processing until the parties resolve the issue.

The Company may rely on instructions given through the Operator's account or by a person whom the Operator represents as authorized to administer the account or give processing instructions. The Operator is responsible for managing those authorizations. The Company has no duty to investigate the completeness, accuracy, or sufficiency of a specific instruction or the Personal Data supplied by the Operator, except as required by Applicable Data Protection Law.

3. Compliance, confidentiality, and security

Each party will comply with the obligations that apply to it under Applicable Data Protection Law. The Company will limit access to Guest Data to personnel who require it to operate, secure, or support the Platform and only to the categories of Guest Data required for their duties. The Company will ensure that authorized personnel are informed of the confidential nature and use restrictions of Guest Data, receive privacy and security training appropriate to their duties, and are bound by confidentiality obligations. The Company will implement and maintain appropriate technical and organizational measures designed to protect Guest Data against accidental or unlawful destruction, loss, alteration, unauthorized disclosure, or access, taking into account the state of the art, implementation costs, and the nature, scope, context, purposes, and risks of the processing. The measures currently maintained are summarized in Annex 2 and the Data Processing & Residency Statement and will be reviewed at least annually and following a material change in the processing or identified risk.

4. Personal Data Breaches

The Company will notify the Operator without undue delay after becoming aware of a Personal Data Breach affecting Guest Data. To the extent information is reasonably available, the notice will describe the nature of the breach, the categories of affected Data Subjects and Personal Data, the likely consequences, and the measures taken or proposed. The Company may provide information in phases and will reasonably cooperate with the Operator's investigation, risk assessment, notifications, and communications, including by preserving and providing relevant records, logs, files, and other information available to the Company. The Company will maintain records of Personal Data Breaches as required by Applicable Data Protection Law. The Company will not notify affected Data Subjects, regulators, law-enforcement authorities, or other third parties concerning a breach processed solely on the Operator's behalf without first consulting the Operator, unless notification is required by law. Each party remains responsible for any notification, communication, remedy, or record-keeping obligation imposed directly on it. The Company's notice is not an admission of fault or liability.

5. Individual rights and regulatory assistance

Taking into account the nature of the processing, the Company will provide reasonable assistance through appropriate technical and organizational measures to enable the Operator to respond to requests to exercise rights under Applicable Data Protection Law. If the Company receives a request, complaint, notice, inquiry, or other communication concerning Guest Data processed solely on the Operator's behalf or either party's compliance in relation to that processing, the Company will notify the Operator without undue delay, may refer the requester to the Operator, and will not respond substantively except on the Operator's documented instruction or as required by law. The Company will provide reasonable information and assistance for data-protection impact assessments, consultations with Supervisory Authorities, and demonstrations of compliance, taking into account the information available to the Company.

6. Sub-processors

The Operator grants the Company general written authorization to engage the sub-processors listed in the Data Processing & Residency Statement. The Company will maintain an up-to-date list and give at least 30 days' prior notice of a new sub-processor where practicable, or notice as soon as reasonably possible where urgent engagement is required for security or service continuity. The Company will impose data-protection obligations on each sub-processor that are no less protective in substance than the obligations applicable to the relevant processing under this DPA, to the extent required by Applicable Data Protection Law. The Company remains responsible for the performance of its sub-processors to the extent required by law.

The Operator may object to a new sub-processor on reasonable data-protection grounds by written notice within 15 days after notice of the change. The parties will work in good faith to identify a commercially reasonable alternative. If none is available, the Company may suspend the affected feature or permit the Operator to terminate the affected service without penalty, and any prepaid fees for the terminated period will be refunded on a pro rata basis.

7. International transfers

For a Restricted Transfer from the European Economic Area, the parties will rely first on an applicable adequacy decision. Where no adequacy decision applies, the SCCs are incorporated into this DPA as specified in Annex 4. For a Restricted Transfer governed by United Kingdom law, the SCCs apply as modified by the UK Addendum. The Company will implement supplementary measures where required by Applicable Data Protection Law. For personal information governed by Quebec law that is communicated outside Quebec, the enterprise responsible for the information will complete any required privacy impact assessment and enter into any written agreement required by law before the communication. The Operator authorizes the locations and transfers described in the Data Processing & Residency Statement, subject to this section.

The parties will reasonably cooperate in assessing the law and practices of a destination country, completing any transfer impact assessment or Quebec privacy impact assessment for which either party is responsible, documenting the applicable transfer mechanism, and implementing supplementary measures where required. The Company will provide information reasonably available to it concerning the nature of the transfer, the destination, relevant sub-processors, and applicable contractual and technical safeguards. If the Company can no longer comply with an applicable transfer mechanism, it will notify the Operator without undue delay and suspend the affected transfer unless another lawful mechanism is implemented.

8. Audit and compliance information

The Company will make available information reasonably necessary to demonstrate compliance with this DPA, including relevant policies, summaries of security measures, sub-processor information, and third-party audit reports or certifications available to the Company. If that information is insufficient, the Operator may request one audit in any 12-month period, and additional audits following a material Personal Data Breach or where required by a Supervisory Authority. Audits must be conducted on reasonable notice, during normal business hours, by an independent auditor bound by confidentiality, in a manner that avoids unreasonable disruption and does not compromise other customers' information or security. The Operator will bear its audit costs and reimburse the Company's reasonable costs unless the audit identifies a material breach by the Company.

The Company will maintain accurate and up-to-date records concerning the processing of Guest Data to the extent required by Applicable Data Protection Law, including the categories and purposes of processing, authorized sub-processors, processing locations, security measures, and Personal Data Breaches. The Company will review the processing particulars and annexes at least annually and update them when required to reflect material changes in the services or processing.

9. Return, deletion, and termination

During the term, the Operator may export or delete Guest Data using available Platform functions. On the Operator's documented instruction, the Company will provide a copy of Guest Data in a commonly used format supported by the Platform. On termination or expiry of the services, and at another time on the Operator's documented instruction, the Company will delete or return Guest Data as required by Applicable Data Protection Law, except to the extent retention is required by law. The Company will protect retained Guest Data, use it only for the legally required retention purpose, and delete it when that requirement ends. Backup and recovery will be handled in accordance with the periods and expedited-purge commitments in the Data Processing & Residency Statement. The Company's deletion processes do not reach copies held on the Operator's devices or at Operator-selected destinations; the Company will provide reasonable assistance so the Operator can address those copies. On written request after the applicable deletion periods have expired, the Company will provide written confirmation that it has completed deletion in accordance with this DPA.

The Company represents that it will process Guest Data in accordance with this DPA and the obligations that apply directly to it under Applicable Data Protection Law. The Operator represents that its collection and processing instructions, including the configured collection of photographs, videos, contact details, survey responses, and location information, comply with Applicable Data Protection Law and that it has provided required notices and obtained any consent or other lawful authority required for that processing. Neither party makes a representation concerning facts or processing controlled exclusively by the other party.

10. Liability, precedence, and term

The liability limitations and exclusions in the Agreement apply to this DPA to the maximum extent permitted by law, except that they do not exclude or limit liability that cannot lawfully be excluded or limited. If there is a conflict concerning the processing of Personal Data, this DPA prevails over the Data Processing & Residency Statement, the Privacy Policy, and the terms of use, and any applicable SCCs or UK Addendum prevail over this DPA to the extent required by their terms. This DPA remains in effect while the Company processes Guest Data on the Operator's behalf, and provisions that by their nature protect Personal Data survive termination. A material failure to comply with this DPA is a material breach of the Agreement. If a change in Applicable Data Protection Law prevents either party from performing the affected processing lawfully, the parties will suspend that processing and cooperate in good faith to implement a compliant alternative; if none is reasonably available, either party may terminate the affected service without penalty. This DPA may be accepted electronically and may be executed in counterparts.

Annex 1 — Processing particulars

Subject matter: Processing Guest Data to provide Operator-configured event capture, upload, storage, gallery, delivery, sharing, AI-enabled, security, support, and related Platform features. Duration: For the term of the Agreement and the deletion periods described in the Data Processing & Residency Statement. Nature of processing: Collection, recording, organization, storage, retrieval, transmission, display, analysis, generation, support, deletion, quality assurance, and other processing necessary to provide the configured services. Purposes: The purposes documented in the Agreement, this DPA, the Privacy Policy, the Data Processing & Residency Statement, and the Operator's use and configuration of the Platform.

Data Subjects: Guests and other individuals appearing in event content or providing information through an Operator-configured event. Personal Data: Photographs, videos, email addresses, telephone numbers, survey responses, free-text answers, device and network information, gallery and delivery records, location data where enabled or contained in metadata, and other event data configured or submitted through the Platform. Sensitive data: The Platform is not intended to infer biometric identity or collect special-category data as such, but event content or responses may reveal sensitive information depending on what the Operator captures or requests. The Operator will not direct such processing unless it has a lawful basis and applies appropriate safeguards.

Annex 2 — Technical and organizational measures

• Encryption of data in transit using TLS 1.2 or above and encryption at rest using AES-256 under cloud-provider managed keys.
• Physical-access protections provided by the applicable hosting and infrastructure providers for facilities in which Guest Data is processed.
• Unique user identities, authentication controls, role-based access, least-privilege permissions, and periodic review of access for personnel who require Guest Data to operate and support the Platform.
• Segregation of the operator and guest data planes and logical separation of customer data, with Guest Data stored in the Operator's account region subject to the disclosed processing exceptions.
• Transmission controls, including encryption, documented destinations, and controls designed to prevent unauthorized interception or disclosure.
• Logging and monitoring designed to record relevant access, security events, and material administrative actions.
• Web-application firewall protections, IP-based rate limiting, and filters aligned with common OWASP attack patterns.
• Apple device-attestation controls for eligible app requests.
• Regional backups, defined retention periods, restoration procedures, and measures designed to preserve availability, integrity, and recovery after an incident.
• Vulnerability management, security testing, incident-response procedures, and review of technical and organizational measures at least annually and following a material change or incident.
• Sub-processor diligence, contractual data-protection terms, and controls described in the Data Processing & Residency Statement.
• Procedures for access, correction, deletion, portability, restriction, objection, and confidentiality-incident handling as required by applicable law.

Annex 3 — Authorized sub-processors

The authorized sub-processors, purposes, data categories, and processing regions are those listed in the Sub-processors section of the Data Processing & Residency Statement, as updated under the notice and objection process in section 6 of this DPA. Operator-selected destinations are not authorized sub-processors of the Company merely because the Platform transmits data to them on the Operator's instruction; their status depends on the Operator's relationship with the destination provider and Applicable Data Protection Law.

Annex 4 — Restricted transfers

For EEA Restricted Transfers where the Operator is a Controller and the Company is a Processor, Module Two of the SCCs applies. For onward transfers where the Company, acting as a Processor, transfers Personal Data to a sub-processor in a third country, Module Three applies through the agreement between the Company and that sub-processor as required by Applicable Data Protection Law. Clause 7 (docking) applies; in Clause 9, Option 2 applies with the authorization and notice periods in section 6; the optional language in Clause 11 does not apply; in Clause 17, the governing law is the law of Ireland; and in Clause 18, the courts of Ireland have jurisdiction. Annex I of the Module Two SCCs is completed by the Operator and Company identities in the Agreement and the processing particulars in Annex 1. Annex II is completed by Annex 2. Annex III is completed by Annex 3. If a mandatory local-law selection requires another governing law or forum, that mandatory selection applies.

For United Kingdom Restricted Transfers, the UK Addendum applies to the SCCs as completed above. The parties' details, processing description, security measures, and sub-processor information are incorporated from the Agreement and Annexes 1 to 3.

The Company may update this Annex only as necessary to reflect a change in applicable approved clauses, provided that the update does not materially reduce the protection of Personal Data.