Obsedia Email.
Data Processing Agreement

Obsedia Email Data Processing Agreement

Version 1.1 · Last updated: 22 October 2026
Effective date: This DPA takes effect for the Merchant when it is first published and validly accepted as part of the Obsedia Email agreement, or when the parties enter into a separately executed copy. The date above does not represent a prior signature or retrospective adoption.

1. Parties, purpose and priority

This Data Processing Agreement (DPA) is between the business identified as Merchant in the accepted Obsedia Email agreement or merchant account (Merchant) and Genius Nutrition SRL, trading as OBSEDIA, VAT RO35355847, Tamasi nr. 20, Buftea, Ilfov, Romania (OBSEDIA). Our privacy contact is privacy@obsedia.ai; our service contact is support@obsedia.ai.

It governs personal data processed by OBSEDIA on the Merchant's behalf through Obsedia Email (Merchant Personal Data). It forms part of the Terms of Service or other accepted written service agreement (Agreement). The processing description in Annex 1, security obligations in Annex 2, and transfer requirements in Annex 3 form part of this DPA. The Subprocessor Register, Retention and Deletion Policy, and Security Overview provide the corresponding service-specific information.

Applicable mandatory data-protection law and binding international-transfer clauses prevail over conflicting commercial terms. This DPA prevails over other Agreement terms concerning Merchant Personal Data. It does not replace an applicable standard contractual clause with a less protective contractual summary.

Data Protection Law means the GDPR, applicable EEA and national legislation implementing or supplementing it, and other data-protection law that applies to the relevant processing, including UK or Swiss law where applicable. Terms such as personal data, controller, processor, processing, personal data breach and supervisory authority have their applicable legal meanings. A personal data breach includes an actual confidentiality, integrity or availability breach; it is not limited to a malicious intrusion.

2. Roles and responsibility for instructions

The Merchant ordinarily acts as controller and OBSEDIA as processor for Merchant Personal Data. If the Merchant acts as processor for another controller, OBSEDIA acts as its subprocessor. In that case the Merchant must hold the upstream controller's authority to give instructions, engage OBSEDIA and its authorised subprocessors, and agree the relevant safeguards. The Merchant must communicate an upstream restriction that affects the service before supplying the affected data.

The Merchant determines the purposes, audience, content and lawful basis of its communications, the relevant customer relationships and the features it enables. OBSEDIA may choose appropriate non-essential technical means to perform those instructions, without changing their permitted purposes.

OBSEDIA separately determines the purposes of certain limited account-administration, business-contact, security, billing, legal-compliance and dispute records, as described in the Privacy Policy. That independent processing is subject to the law applicable to OBSEDIA as controller. This exception does not authorise us to relabel a merchant's audience, message content or AI conversation as our own data to escape processor obligations. The actual activity, rather than a label in this DPA, determines the legal role.

3. Documented instructions and permitted processing

OBSEDIA will process Merchant Personal Data only on documented instructions from the Merchant, including instructions concerning transfers, unless processing is required by applicable Union or Member State law or another mandatory legal requirement compatible with Data Protection Law and the applicable transfer terms. In that case, we will inform the Merchant of the requirement before processing unless the law prohibits that information on important public-interest grounds.

The initial instructions are to provide the selected Service as described in the Agreement and Annex 1: receive authorised store data and imports; store and organise it; apply merchant-selected audiences, creative tasks and enabled automations; prepare and transmit approved communications; process feedback, suppression, privacy requests and reporting; and maintain the necessary security, integrity, financial and delivery reconciliation. A valid instruction may be recorded through an authenticated feature, accepted order or written communication from an authorised representative. Access to a record or a session does not itself authorise an unrelated purpose.

OBSEDIA will not:

• sell or rent Merchant Personal Data, use it for unrelated advertising, or create another merchant's customer audience from it;
• use Merchant Personal Data to train its own general-purpose AI model or authorise a subprocessor to use it for general-purpose model training under this DPA;
• combine identifiable or pseudonymous customer records across merchants for an independent commercial purpose; or
• make an unapproved marketing, payment, discount-activation or other merchant business decision merely because we hold the data.

An AI request can include information the Merchant places in prompts, drafts, attachments or relevant task context. It is not an instruction to disclose an entire recipient list to a creative model. We must limit the disclosed context to what is appropriate for the requested feature. Temporary provider processing, safety checks and legally required provider records must remain within the applicable disclosed contractual and legal controls; this DPA does not promise zero vendor retention or create a model-training permission.

We will immediately inform the Merchant if, in our opinion, an instruction infringes applicable data-protection requirements. We may suspend only the affected processing while the parties resolve the concern or where suspension is otherwise necessary under the Agreement or law. A disputed instruction does not authorise us to ignore a valid data-subject right or indefinitely hold unrelated data. A materially different purpose, category of sensitive data or processing activity requires an appropriate documented agreement and safeguards before it begins.

4. Merchant obligations

The Merchant must provide lawful, accurate and proportionate instructions, appropriate notices, and the legal basis or permissions required for the data and channel. For email marketing through Obsedia Email, the service contractually requires valid, recorded email-marketing consent even where local law might permit another marketing basis. Purchasing a product, creating an account, or appearing in Shopify does not itself establish that consent. The Merchant must honour withdrawals and objections, retain appropriate consent evidence, assess tracking requirements, and use the Service's privacy and suppression functions appropriately. Imports, purchases and ordinary synchronisation must not override unsubscribe, suppression or deletion protections; a valid renewed opt-in must pass the supported safeguards.

The Merchant must not supply data it has no authority to disclose, unnecessary sensitive data, authentication secrets in creative content, or data for an unsupported high-risk purpose. If it discovers an unlawful disclosure or an incorrect instruction, it must promptly notify OBSEDIA and provide an appropriate correction or deletion instruction.

The Merchant remains responsible for its controller duties, including selecting a suitable processor, maintaining its notices and processing records, handling customer requests and assessing whether a DPIA or regulatory consultation is required. OBSEDIA's assistance does not transfer those decisions to OBSEDIA. Equally, the Merchant's responsibilities do not remove any direct legal obligation imposed on OBSEDIA.

5. Confidentiality and personnel

OBSEDIA will ensure that persons authorised to process Merchant Personal Data are subject to confidentiality commitments or an appropriate statutory duty of confidentiality. Access must be limited to an authorised business need and the person's role, kept under review and removed when no longer required. Personnel must receive appropriate instructions concerning confidentiality, security, handling requests and reporting suspected incidents.

Support and administration must use the minimum data needed for the task. Customer datasets, tokens and other secrets must not be copied into public issue trackers, demonstrations or ordinary collaboration channels. Confidentiality continues after access or engagement ends. Disclosure to an authorised subprocessor remains subject to Section 7 and does not convert the data into unrestricted third-party information.

6. Security of processing

Taking account of the state of the art, implementation costs, the nature, scope, context and purposes of processing, and the risks to individuals, OBSEDIA will implement and maintain appropriate technical and organisational measures meeting applicable Article 32 GDPR requirements. Annex 2 and the Security Overview specify the applicable service measures and responsibilities.

We will assess measures over time and may improve or replace an individual measure with an appropriate alternative without materially reducing the agreed overall protection. We will consider the risk of unauthorised access or disclosure, loss, alteration, accidental destruction and unlawful restoration or reuse. Changes cannot reduce a mandatory legal standard or evade an agreed transfer safeguard.

The Security Overview is not an independent certification or a guarantee that every incident, outage or misuse can be prevented. No ISO 27001, SOC 2 or similar certification is claimed for OBSEDIA merely because a provider holds one. No numerical recovery-time, recovery-point or availability commitment applies unless expressly agreed. Those qualifications do not reduce the contractual duty to implement appropriate security.

7. Subprocessors

The Merchant gives general written authorisation for the subprocessors identified in the Subprocessor Register at the time it accepts this DPA, within the functions and processing scope stated there. OBSEDIA must maintain an accurate register identifying the actual legal entity, service, relevant processing locations and applicable safeguards. A provider's brand or group name is not a substitute for identifying the contracting and processing entity where that information is needed to assess the arrangement.

Before a new or replacement subprocessor begins the relevant processing, OBSEDIA will give the Merchant at least 30 days' prior written notice, through its designated contact or a meaningful authenticated service notice, identifying the change and enough information for a data-protection assessment. We will keep the published register current and make a notification route available through privacy@obsedia.ai. Merely publishing a change without the required notice does not eliminate the Merchant's objection right.

The Merchant may object within that notice period on reasonable, documented data-protection grounds relating to the proposed processing. The parties will work in good faith on a suitable alternative, additional safeguards or avoiding the affected processing. This is not an unrestricted veto over all provider choices. However, an unresolved reasonable objection will not be treated as permission to send that Merchant's data to the disputed subprocessor. If no lawful, commercially reasonable solution is available, either party may terminate the affected service before that processing starts, without a termination penalty, with the return/deletion and unused-paid-amount rules of the Agreement preserved.

Where an urgent legal or security need makes the full notice period impracticable, we must seek specific prior authorisation for an earlier change or suspend the affected processing until it can lawfully proceed. An emergency does not remove mandatory authorisation or transfer requirements. An additional provider expressly and specifically authorised by the Merchant after adequate information can be used within that specific authorisation.

Each subprocessor must be bound by a written agreement imposing data-protection obligations that provide the protection required by Article 28 and this processing, including appropriate security and applicable transfer safeguards. OBSEDIA remains responsible to the Merchant for performance of the subprocessor's data-protection obligations as required by Article 28(4). We will provide relevant information or contractual evidence on request, with reasonable redaction for unrelated data and confidential commercial detail, without withholding information necessary for compliance.

Shopify, a recipient's mailbox provider, and a merchant-selected third-party service are not automatically OBSEDIA subprocessors for every activity. Their actual roles and separate arrangements are described in the Privacy Policy and Subprocessor Register. We remain responsible for any processing that we in fact entrust to them as our subprocessor.

8. International processing and transfers

OBSEDIA is established in Romania. A transfer from an EEA Merchant to OBSEDIA in Romania is not, solely for that reason, a transfer to a third country under Chapter V GDPR. Nor does the use of an AI provider automatically make every Merchant the exporter in a controller-to-processor SCC arrangement with OBSEDIA.

Access, hosting, support or onward processing outside the relevant protected territory can nevertheless require a transfer safeguard. Before making a restricted transfer, the party responsible for it must identify the actual exporter, importer, roles, locations, categories and legal mechanism. OBSEDIA will ensure that onward transfers it makes have a valid basis, such as a relevant adequacy decision within its scope or an appropriate Article 46 safeguard, and any required assessment and supplementary measures. The existence or scope of adequacy must be checked for the actual recipient and processing; a group's location or certification is not enough.

Where the standard contractual clauses adopted by Commission Implementing Decision (EU) 2021/914 (EU SCCs) are an appropriate instrument, the actual exporter and importer must enter into them with the applicable module, options and annex information completed before the transfer. Module Two applies to an eligible controller-to-processor transfer; Module Three applies to an eligible processor-to-processor transfer. OBSEDIA's onward processor-to-subprocessor transfers commonly require the latter analysis. Clauses cannot be used outside their legal scope simply by naming a module.

Annex 3 sets out the required transfer record and the choices applicable to a qualifying direct Merchant–OBSEDIA SCC arrangement, if one is separately needed and completed. An onward provider arrangement uses its actual executed transfer agreement and completed annexes, not an unsigned selection in this DPA. Accepting this DPA does not purport to sign for a provider, silently designate every Merchant an EEA exporter, or certify that every worldwide disclosure is covered by one set of SCCs.

If UK or Swiss law governs a restricted transfer, the appropriate recognised mechanism and necessary adaptations must likewise be completed before that transfer. Annex 3 addresses the UK Addendum and Swiss requirements. Applicable transfer terms prevail over conflicting forum, audit, liability or other restrictions in the Agreement.

OBSEDIA will provide information reasonably necessary for the Merchant's transfer assessment. Where required, we will assess relevant local law and access practices, apply appropriate supplementary protections, and suspend or end a transfer that can no longer lawfully continue. A demand for disclosure must be assessed for lawfulness and scope; where lawful and required by the applicable transfer terms, we will notify the relevant party, challenge an unlawful demand and disclose only what is required. We cannot promise advance notice where a valid legal prohibition applies.

9. Assistance with individual rights

Taking account of the processing, OBSEDIA will assist the Merchant with appropriate technical and organisational measures, insofar as possible, to fulfil its duties concerning access, rectification, erasure, restriction, portability, objection and other applicable individual rights. This includes reasonably available information and supported export, suppression and deletion functions or proportionate assistance where a request cannot be completed through the interface.

If we receive a request concerning data controlled by the Merchant, we will promptly direct or forward it to the appropriate Merchant contact, where lawful and reasonably identifiable. We will not independently decide the Merchant's substantive response unless instructed or legally required. This does not prevent us from immediately giving effect to an applicable unsubscribe or other protective action within the service instructions, verifying identity proportionately, or complying with our own legal duties.

The Merchant must respond within its applicable legal deadlines and give us sufficient information and timely instructions. We will not make the exercise of a mandatory right depend on an individual becoming a customer or waiving a claim. We must avoid disclosing another person's or merchant's records in a response.

10. Breaches, risk assessments and authorities

OBSEDIA will notify the Merchant without undue delay after becoming aware of a personal data breach affecting Merchant Personal Data. Initial notice must not wait for a completed forensic investigation or a final assessment of every consequence. We will use the designated contact and provide available information in stages where necessary.

To the extent known, the notice and updates will describe the nature of the breach, affected data and people or approximate categories/numbers, likely consequences, containment and remediation measures, and a contact for further information. We will reasonably cooperate in investigation, mitigation, evidence preservation and accurate follow-up. An initial notice is not an admission of liability and does not shift our legal duties to the Merchant.

The Merchant ordinarily decides its notifications to supervisory authorities and individuals. We will assist with the information available to us so it can meet applicable deadlines, without limiting any independent notification or cooperation duty imposed on OBSEDIA. A blocked attack that did not compromise personal data is not automatically a personal data breach, but must be assessed according to its actual effect.

Taking account of the processing and information available, OBSEDIA will also assist the Merchant in ensuring compliance with Articles 32–36 GDPR, including security assessments, DPIAs and necessary prior consultation with an authority. We will provide relevant service and safeguard information, identify material processing changes within our control, and cooperate with a competent authority as the law requires. The Merchant remains responsible for its controller assessment and decision to consult.

11. Information, records and audits

OBSEDIA will make available information necessary to demonstrate compliance with the applicable processor obligations and allow for and contribute to audits, including inspections, by the Merchant or an auditor it mandates. We will maintain the records required of us under applicable law and provide relevant processing, subprocessor and safeguard information.

The parties will ordinarily start with available documentation, relevant records and appropriate independent assurance evidence where it is sufficient for the issue. A supplier's report does not by itself audit OBSEDIA, and documentary review cannot replace an inspection or other information that is actually necessary under law.

Ordinary audits should use reasonable advance notice, a defined relevant scope, normal business hours and confidentiality safeguards. Ordinarily one routine audit in a 12-month period is proportionate; this is not a limit on an audit required by law, a competent authority, a material breach or incident, or reasonable evidence of significant non-compliance. Urgent or mandatory access must not be defeated by a routine notice period or frequency rule.

We may require a suitably independent, competent auditor and reasonable protections for other merchants, secrets and infrastructure security. We must offer an effective alternative if a proposed method would unnecessarily expose such information; these protections are not a right to refuse the audit or withhold information needed to establish compliance. Audits must not involve unauthorised destructive or intrusive testing of a shared system.

Each party ordinarily bears its own routine compliance costs. Reasonable additional assistance outside normal service support may be agreed in advance at a proportionate fee, but payment negotiations must not obstruct a statutory right, an authority's inspection, a required breach notification or our obligation to remedy our own non-compliance.

12. Duration, return, deletion and restricted retention

This DPA applies for the duration of the relevant processing, including a lawful winding-down or required restricted retention. The Merchant may choose return or deletion of Merchant Personal Data when the processing service ends and may give a valid earlier instruction. OBSEDIA will carry out the choice without undue delay, provide reasonably available return in an appropriate commonly used format or agreed secure method, and delete existing copies as required by Article 28(3)(g), unless applicable Union or Member State law requires retention or another compatible mandatory rule lawfully requires it.

The Retention and Deletion Policy provides category-specific criteria, review rules and the handling objective for ordinary verified requests. Its normal periods are not minimum periods that defeat an earlier valid erasure instruction, a shorter legal deadline or an applicable platform requirement. A receipt acknowledging a request is not confirmation of completion.

A legal preservation or necessary unresolved-outcome hold must be specific, documented, access-restricted, assigned to an owner and reviewed. Only evidence needed for the identified purpose may remain. We must communicate material completion restrictions where lawful and resolve or escalate them; a billing dispute does not justify keeping the entire customer dataset indefinitely. Where OBSEDIA separately retains its own legally required controller records, their purpose, basis and limits follow the Privacy Policy rather than a new marketing-use permission.

Suppression and deletion-prevention records may be retained in a minimised form where necessary to honour a withdrawal, prevent prohibited reimport or meet an applicable obligation. A pseudonymous or hashed identifier is not presumed anonymous. Removing a suppression record must not silently re-subscribe a person.

Backup and provider copies may not be removable in the same way or at the same instant as an active record. OBSEDIA must document the applicable lifecycle and safeguards, restrict unavoidable recovery copies from ordinary use, delete them as that lawful lifecycle ends, and reapply erasure and suppression instructions before restored data returns to normal processing. Any legal retention exception remains limited to what the law requires. This DPA does not invent a universal physical-backup purge deadline or permit backups to become permanent marketing archives.

We will provide appropriate confirmation of completed scope and explain necessary residual restrictions. Uninstall, unsubscribe, customer erasure and store erasure have different effects as described in the retention policy. We cannot recall an already delivered email or delete a recipient's independently held copy, but must perform the deletion and assistance within our control. Confidentiality and applicable safeguards continue for any data lawfully retained after termination.

13. Requests, cooperation and changes

The Merchant's designated privacy contact is its authorised business contact recorded in the account, accepted order or a subsequent verified instruction. Notices and requests to OBSEDIA go to privacy@obsedia.ai. The Merchant must keep a usable contact current. We may seek proportionate verification of authority and scope, without demanding unnecessary sensitive information.

A material amendment affecting the processing must be documented and accepted where required. No amendment may unilaterally reduce mandatory rights, alter a processing purpose beyond instructions, or contradict applicable transfer clauses. Subprocessor changes follow Section 7, rather than a shorter general website-notice process. The parties will cooperate on a lawful adaptation when legislation or binding guidance changes; affected processing must not continue unlawfully while that adaptation is unresolved.

14. Liability, remedies and governing law

The Agreement's lawful commercial liability provisions apply between the parties, subject to this DPA's priority and mandatory law. They do not restrict a data subject's compensation rights under Article 82 GDPR, mandatory rights of contribution, the liability required by binding transfer clauses, or a supervisory authority's powers. Neither party contracts away its own duties or makes the other responsible for its own unlawful conduct merely by using an indemnity. Any allocation of fines must be lawful.

The Agreement's Romanian-law and business-dispute provisions apply unless an applicable transfer clause or mandatory law requires otherwise. Nothing obliges an individual to bring a complaint or claim only in Bucharest, limits the competent authority's jurisdiction, or excludes an effective statutory remedy. A party may seek necessary urgent relief without first exhausting an informal support process.

Annex 1 — Description of the processing

A. Parties and acceptance record

B. Subject matter, nature, purpose and duration

Subject matter: Provision of Obsedia Email for the Merchant's authorised store and customer communications, creative workspace, permitted integrations and related privacy, delivery and usage administration.

Nature: Collection through authorised integrations or import; recording, storage, organisation, retrieval and consultation; merchant-selected segmentation and personalisation; creation and revision of drafts; requested AI inference or image processing; preparation, scheduling and transmission of approved messages or enabled automations; processing of delivery and interaction events; suppression, reconciliation, export, restriction, deletion and secure return. Not every operation applies to every Merchant or feature.

Purposes: Carrying out the Merchant's lawful communication and creative instructions, measuring the selected service's results, preventing unlawful or duplicate delivery, enforcing current consent and installation state, protecting the processing, and assisting with the Merchant's legal obligations. The DPA grants no independent data-sale, cross-merchant targeting or general-purpose training purpose.

Duration and frequency: Processing can be continuous while the authorised integration and features are active, event-driven when a campaign, automation, interaction or privacy event occurs, or one-off for an import, creative task or return. Duration follows Section 12 and the retention schedule, including earlier valid instructions and strictly limited lawful residual retention.

C. Categories of people and information

Full payment-card data, account passwords, government identifiers, special-category data and criminal-offence data are not an intended processing category. The Merchant must not deliberately submit them without prior written agreement and the required legal and technical safeguards. Incidental discovery must be handled securely and minimised or removed; it is not permission to expand the service's purpose. The Service is not intended to invite children to create business accounts or to process sensitive information about children through marketing content.

Annex 2 — Technical and organisational measures

These are contractual, risk-based requirements for the processing, read with the service-specific Security Overview. They do not claim that OBSEDIA has passed a particular certification, that a supplier's certification covers us, or that an unverified infrastructure setting exists.

Infrastructure settings, backup mechanisms, location choices and subprocessor controls must be assessed for the actual service used. A statement that application credentials are encrypted does not represent that every database field is separately encrypted or that every recipient mail server offers the same transport protection. An agreed measure cannot be omitted merely because a provider offers a similarly named feature.

Annex 3 — Transfer instruments, parties and SCC completion

A. Determine the actual transfer first

For each restricted transfer, OBSEDIA must maintain or obtain an identifiable transfer record stating the actual exporter and importer legal entities and contacts, their controller/processor roles, countries and access locations, relevant processing and data categories, frequency and duration, subprocessor chain, legal mechanism, applicable security annex, and required assessment/supplementary measures. Where signatures or another valid execution record are required, they must be completed before the transfer.

For an OBSEDIA onward transfer, OBSEDIA is the exporter where that matches the facts, and the actual provider legal entity is the importer. The provider register, executed provider agreement and completed transfer annexes must be consistent. This DPA neither signs on an unnamed provider's behalf nor claims a direct Merchant-to-US-provider agreement simply because an AI feature is used. Relevant evidence is available through Sections 7 and 11, subject to appropriate confidentiality protections.

A service hosted in a European application region is not, by itself, evidence that every storage, support, AI or onward operation remains in the EEA. Recipient mail systems and Merchant-selected destinations also require assessment of the actual processing and responsibilities; they are not all OBSEDIA-appointed subprocessors.

B. EU SCCs

The authoritative clauses are the unmodified Annex to Commission Implementing Decision (EU) 2021/914, not a reconstructed text in this DPA.

If a qualifying restricted transfer directly between the Merchant and OBSEDIA separately requires those SCCs, the parties must record their actual exporter/importer roles and validly execute the applicable SCC arrangement before that transfer. For that direct arrangement, unless a lawfully completed transfer instrument specifies otherwise, the following completion instructions apply:

• Module: Module Two for controller exporter to processor importer; Module Three for processor exporter to processor importer. Only the module matching the actual roles and legal scope applies. No direct SCC arrangement is activated merely by an ordinary EEA-to-Romania service instruction.
• Clause 7: The optional docking clause is included; an additional party must actually complete the required accession information and agree to be bound.
• Clause 9: Option 2, general written authorisation, with at least 30 days' prior notice and the objection process in Section 7, where that clause applies.
• Clause 11: The optional independent dispute-resolution mechanism is not added. Mandatory complaints and judicial remedies remain available.
• Clauses 17 and 18: Romanian law and the courts of Romania, insofar as that selection meets the SCCs' requirements. The SCCs' data-subject forum rights, including the applicable Member State of habitual residence, remain unchanged.
• Annex I.A: The actual exporter and importer are identified by legal name, business address, relevant contact, role and execution date in the accepted transfer record. For OBSEDIA, the legal identity and privacy contact are those in Annex 1.A. An account record identifies the Merchant only where it actually identifies the relevant legal entity and authorised acceptance; a brand, generic customer label or publication date alone does not complete a signature.
• Annex I.B: The relevant activity, categories and duration from Annex 1 apply only to the transfer actually recorded, together with any stricter feature-specific scope. The purposes may not be expanded to data sale or general-purpose training.
• Annex I.C: Select the competent authority under SCC Clause 13 for the actual exporter. For an OBSEDIA exporter established in Romania, this is the Romanian National Supervisory Authority for Personal Data Processing (ANSPDCP), subject to the applicable legal competence rules. Another exporter's establishment, representative or relevant data subjects may require a different authority under Clause 13.
• Annex II: Annex 2 and any additional transfer-specific measures identified in the executed transfer record apply.
• Annex III: The authorised subprocessor identities, functions and relevant locations are those actually identified in the corresponding completed register/transfer record and notified changes, not an unrestricted list of future unknown providers.

An actual provider SCC agreement may lawfully use different permitted options, governing law or annex information. That executed agreement, its lawful module and completion record govern the onward transfer; the direct-arrangement choices above do not silently rewrite a provider's contract. OBSEDIA must ensure the resulting arrangement satisfies the Merchant's lawful instructions and Data Protection Law. The SCCs' hierarchy, third-party-beneficiary, security, audit, notification, suspension and termination requirements are not reduced by the Agreement's commercial clauses.

C. UK and Switzerland, where applicable

For a UK restricted transfer not covered by a valid adequacy regulation or other lawful mechanism, the responsible parties must put in place an appropriate UK-recognised instrument before transfer. Where the ICO's International Data Transfer Addendum to the EU SCCs is used, its applicable approved mandatory clauses, including amendments under their own revision mechanism, must remain intact. Its tables must identify the actual parties and execution record, the selected EU SCC version/modules/options, and the corresponding Appendix information from the completed transfer record. Both exporter and importer may exercise an ending right to the extent the approved Addendum permits that selection. The UK Addendum's compulsory law, authority and jurisdiction provisions take priority over inconsistent EU or commercial selections.

For a restricted transfer governed by Swiss data-protection law, the responsible parties must use a mechanism recognised for that transfer and complete the necessary Swiss adaptations before transfer. These include the applicable Swiss statutory references, the competent Federal Data Protection and Information Commissioner where required, and preservation of the relevant Swiss individuals' rights and forum protections. A bare reference to EU law is not treated as completion of those adaptations.

These requirements apply only where the relevant regime and transfer are actually engaged. OBSEDIA must provide the applicable completed instrument and relevant safeguards information through the DPA process; this Annex does not claim that an unexecuted future transfer or every possible country is already authorised.