Daybeat Data Processing Agreement

1. Definitions and precedence

1.1 This Data Processing Agreement is between the Customer and Function 365 Limited, trading as Daybeat, company number 10069330, registered address Third Floor, 95 The Promenade, Cheltenham, Gloucestershire, United Kingdom, GL50 1HH.

1.2 In this document the following definitions apply.

1.3 Controller, processor, personal data, processing, data subject, personal data breach and special category data have their UK GDPR meanings. A connector is the software implementing a delivery channel; a connection is the Customer's authorised link to that channel.

1.4 This DPA is incorporated into the Terms by reference and applies only to processing of Customer Data. It prevails over the Terms on data protection matters. A binding international transfer mechanism prevails over conflicting provisions of this DPA.

1.5 drafting note: [OPEN: solicitor to confirm how the Data (Use and Access) Act 2026 affects this DPA and its commencement; no position is asserted here.]

2. Roles and documented instructions

2.1 The Customer is controller and the Provider is processor of Customer Data. If the Customer is itself a processor for a client, the Provider acts as its subprocessor and the Customer warrants that it has authority from its controller to instruct the processing and authorise this DPA and its subprocessing chain.

2.2 The Provider is an independent controller for its own account administration, authentication, security and billing purposes, and for error monitoring and public marketing-site operation, as described at /privacy. Audit records and other information may serve both roles. Copies of Workspace content in audit snapshots remain Customer Data where held on the Customer's behalf; a record's location alone does not determine the role.

2.3 The documented instructions are this Agreement, Workspace settings, and the Customer's actions in the product and through the API, including actions of its Owners, Members and Authorised Agents. Instructions include connecting platforms, supplying material, Approvals, revisions, scheduling, test sends and requests for return or deletion. Additional written instructions may be sent to dpo[at@]function365.co.uk.

2.4 Oversight Mode defaults to none, which delegates no authority. L1_basic_setup_only permits scoped reading; L2_highly_autonomous_setup adds permitted interview completion, connection setup and brand actions; L3_full_autonomous_setup_and_run additionally permits topic selection, topic and Piece Approvals, change requests and confirmation of manual posting. Each action also requires the relevant token scope and other permissions. Only a human Owner changes the setting or issues tokens; a lowered mode applies to the next delegated call.

2.5 Approval by a Member or Authorised Agent is the Customer's instruction. At L3, an Authorised Agent with the relevant scope may approve a Piece without a human reviewing it at that moment. Go-live, the first approval of a topic's initial set of Pieces, remains a human Owner action. Billing and checkout cannot be delegated.

2.6 The Provider does not independently decide to publish Customer content. It publishes only Pieces with the Customer's Approval. Approval authorises scheduling, delivery and permitted retries to the approved channel. Withdrawal cannot recall an already dispatched delivery or remove a copy held by a destination.

2.7 The Customer is responsible for the lawful basis, required privacy information and permissions for Customer Data, its authorised users and delegates, and the accuracy, suitability, compliance and platform-terms implications of content it approves. These responsibilities do not relieve the Provider of its own obligations under this DPA or Data Protection Law.

2.8 This DPA is for business customers. drafting note: [OPEN: confirm the business acceptance mechanism and authority evidence, including sole traders and partnerships; assess any different treatment of those customers or recipients under applicable law.]

3. Details and limits of processing

3.1 Annex A specifies the subject matter, duration, nature, purposes, categories of personal data and data subjects. Clause 11 governs return and retention after the Workspace ends.

3.2 The Service is not designed for special category or criminal offence data. The Customer must not put special category data into the Workspace without an applicable Article 9 condition, any necessary Data Protection Act 2018 safeguards, a documented assessment of whether a data protection impact assessment is required, and agreement with the Provider on additional measures. drafting note: [OPEN: Article 9 condition and DPIA, private-clinic market.]

3.3 Criminal offence data requires compliance with Article 10 and applicable domestic safeguards and prior agreement with the Provider. If the Customer nevertheless supplies restricted data, it remains responsible for lawfulness, must promptly notify the Provider and instruct appropriate restriction or erasure. The Provider will assist and remain bound by its processor duties; receipt does not establish that the Service is suitable for that data.

4. Processor obligations and staff access

4.1 The Provider will process Customer Data only on documented instructions, including for transfers, unless applicable law requires otherwise. It will inform the Customer of that legal requirement before processing unless the law prohibits notice. If it considers an instruction unlawful, it will immediately inform the Customer and refrain from carrying out the disputed instruction while it is resolved.

4.2 People authorised to process Customer Data must be subject to confidentiality obligations. Operational staff access to Workspaces is limited by role and takes place through audited console paths. Staff mutations use the staff identity. The impersonation or view-as facility is read-only.

4.3 The Workspace's concierge consent flag is on by default and can be switched off by an Owner. While on, it authorises staff to approve a topic on the Customer's behalf, consuming the topic allowance and starting generation, and to carry out permitted concierge edits and image selection. Topic approval does not authorise publication of the resulting Pieces. Staff cannot approve a Piece for publishing or trigger its publication.

4.4 The concierge flag does not gate every staff action. Audited advisory fixes, safety retirement of offerings, generation reruns and email wrapper design approval or push can occur without it. Staff can also perform a single-recipient email design test send on the Customer's behalf. These service-support actions do not authorise publication of a Piece or a campaign send to an audience.

4.5 The Provider will maintain appropriate technical and organisational measures, taking account of the processing and risks, including Annex B. It will assist with security, data protection impact assessments, prior consultation, breach obligations and data subject requests, taking account of the nature of processing and information available to it.

4.6 The Provider will not sell Customer Data or share it for advertising, or use it to train, fine-tune or evaluate any artificial intelligence model. It may use models to generate and assess content for that Customer's own Workspace as instructed under this DPA; this does not authorise model training, fine-tuning or evaluation. Clause 6.3 governs AI provider processing.

4.7 The Provider will provide the assistance required by clause 4.5 at no additional charge. Where assistance is materially beyond that requirement, the parties will agree a reasonable fee in advance. No fee arrangement will delay or prevent assistance the Provider is required by law to give.

5. Subprocessors and customer destinations

5.1 The Customer gives general written authorisation for the Provider to engage subprocessors identified in Annex C and the maintained list at value to be confirmed: [SUBPROCESSOR LIST URL], subject to this clause. The list identifies onward model providers as well as direct vendors and distinguishes services outside the processor role.

5.2 Before a subprocessor receives Customer Data, the Provider will impose by written contract the same applicable data protection obligations as in this DPA, including appropriate security, assistance, transfer and deletion duties. It remains fully liable to the Customer for its subprocessors' performance of those obligations, subject to clause 12.

5.3 The Provider will give at least value to be confirmed: [NOTICE DAYS] days' written notice before adding or replacing a subprocessor, including an onward model provider, with its identity, purpose, data and locations. The Customer may object within that period on reasonable data protection grounds. The parties will seek a reasonable solution before the change affects that Customer's data.

5.4 If no solution is agreed, the Customer may give notice before the change takes effect to terminate the affected Service without penalty, with effect from the end of the then-current billing period. Fees already paid for that period are not refunded, except where the Terms' contractual promise to refund the first month's subscription fee applies to cancellation requested within 14 days of the first subscription charge. The onboarding fee is not refundable. The Provider will not apply the objected-to change to that Customer's data before termination takes effect. An emergency does not dispense with prior authorisation: a shorter notice period requires the Customer's specific written agreement.

5.5 WordPress hosts, LinkedIn, Meta/Instagram, X, Brevo and any export destination address are not Provider subprocessors. They receive content on the Customer's instructions under the Customer's own accounts and terms. Their roles are those of the Customer's own processors or independent controllers, as applicable. The second table in Annex C describes these destinations.

6. International transfers and AI processing

6.1 Annex C describes locations and onward routing. Main object storage uses Cloudflare R2's EU jurisdiction. Production database location is recorded as EU, with its exact region unconfirmed; the application host's actual datacentre is also unconfirmed. AI processing and transactional email involve the US and onward destinations. There is no promise that all processing remains in the UK or EEA.

6.2 The Provider will make restricted transfers only under documented instructions and a valid applicable safeguard, such as UK adequacy regulations covering the recipient and processing, the UK International Data Transfer Agreement or the UK Addendum to EU standard contractual clauses. drafting note: [OPEN: solicitor to select the UK IDTA or UK Addendum and complete Annex D for each relevant transfer.]

6.3 Generated content is routed through OpenRouter to the named model providers in Annex C under provider terms and the Provider's provider preferences which exclude training on and retention of Customer content. AI processing is subject to those exclusions, which the Provider must maintain throughout processing, including onward routing. Anthropic-direct calls are under Anthropic's commercial API terms, which exclude training on API inputs and outputs. The Provider will maintain the contractual arrangements and provider preferences necessary to fulfil these obligations.

6.4 The four council models receive drafts through OpenRouter: Moonshot AI's Kimi K2.6 and K2.5, DeepSeek's DeepSeek V4 Pro, and Google's Gemini 3.1 Pro preview. Moonshot AI and DeepSeek are China-headquartered. Other routed uses include Anthropic, OpenAI and Google models detailed in Annex C. Provider headquarters are not evidence of a particular processing location; onward locations and safeguards must be recorded in Annex D.

6.5 The Provider will carry out and keep under review required transfer risk assessments and supplementary measures, make relevant information available to the Customer and ensure safeguards address onward transfers. If a safeguard ceases to be valid, it will suspend affected transfers until a lawful replacement is in place. Annex D is an incomplete review skeleton, not evidence that safeguards have been executed.

7. Security

7.1 Annex B records confirmed controls and their limits. The Provider will maintain appropriate protection under Article 32 and may update measures without reducing the level of protection. A listed limitation does not waive statutory duties.

7.2 No security certification, penetration-test report or independent security audit report is held or claimed. Recovery targets and controls not verified in the facts are not represented as achieved safeguards.

8. Personal data breach

8.1 The Provider will notify the Customer without undue delay and in any event within value to be confirmed: [HOURS] hours of becoming aware of a personal data breach affecting Customer Data. It will use the Customer's notified contact details. drafting note: [OPEN: runbook must exist before the number is set.]

8.2 The notice will give, so far as known, the nature of the breach, categories and approximate numbers of affected people and records, likely consequences, measures taken or proposed, and the contact for further information at dpo[at@]function365.co.uk. Missing information will follow in phases without further undue delay.

8.3 The Provider will assist investigation, containment and remediation and provide information needed for regulatory and data subject notifications. The Customer remains responsible for its controller notification decisions, or for promptly escalating to its own controller where it acts as processor. The Provider will not publicly identify the Customer in a breach statement without agreement unless legally required.

9. Audit and compliance information

9.1 The Provider will first make available information necessary to demonstrate compliance and provide documented responses to the Customer or an auditor it mandates. Where those information rights do not reasonably answer the request, the Provider will allow for and contribute to an on-site audit or inspection under clauses 9.2 and 9.3. This sequence does not restrict an audit or inspection required by Data Protection Law or a supervisory authority.

9.2 Routine on-site audits require value to be confirmed: [NOTICE DAYS] days' notice, occur during business hours, and are limited to once in any 12 months. A breach or supervisory authority requirement permits additional audits and shorter notice as reasonably necessary. Arrangements must not frustrate statutory audit rights.

9.3 The Customer bears its own and the Provider's reasonable audit costs. Auditors must observe confidentiality and avoid unreasonable disruption. Access must protect other customers' data and security without preventing verification of this DPA.

9.4 A current third-party report may substitute for an inspection only if actually held and it reasonably answers the request. None is held today. A completed security questionnaire may answer particular information requests but does not extinguish inspection rights.

10. Data subject requests

10.1 The Provider will forward requests relating to Customer Data without undue delay and within value to be confirmed: [REQUEST FORWARDING DAYS] days, and will not answer their substance without the Customer's authorisation unless legally required. drafting note: [OPEN: set a short request-forwarding period supported by operations.]

10.2 The Provider will assist, through appropriate measures so far as possible, with access, rectification, restriction, portability, objection and erasure. Return and erasure requests are handled through dpo[at@]function365.co.uk as operations processes. There is no dedicated self-service data subject request, whole-Workspace export or account-deletion facility.

10.3 The Provider will act on an instructed erasure without undue delay and will confirm completion. It will agree a target period with the Customer, which it expects to be no longer than 30 days, subject to lawful retention under clause 11 and to the limitations recorded in clause 11.3. It will support earlier transcript deletion on request once the business profile has been approved. These are process commitments, not descriptions of an implemented deletion console. It will promptly identify any obstacle and assist the Customer in meeting applicable deadlines. An agreed target or operational limitation does not extend a statutory deadline.

11. Return, deletion and surviving records

11.1 For this clause, the Workspace ends when provision of its Service ends following termination, expiry or effective cancellation. The Provider will record that date for the retention process. An internal status change at the end of the reactivation window does not start a second 90-day period.

11.2 At the Customer's choice, the Provider will return Customer Data and delete remaining copies, or delete it, within 90 days after the Workspace ends, unless law requires retention. The Provider's ability to meet this period today depends on the operations process described in clause 11.3; the Provider will inform the Customer without undue delay if it cannot meet the period for a given Workspace. Return covers Workspace content, business profile, transcripts, research material, images and relevant audit records. Return is provided as an operations-assembled bundle in a commonly used machine-readable format, agreed with the Customer at the time of the request. No self-service export facility exists. If no return is requested, deletion is the default instruction. Earlier instructed deletion follows clause 10.3. Notification of an obstacle does not itself authorise longer retention or extend a statutory deadline.

11.3 Subject to that choice, data may be retained during the 90-day window for reactivation and return. The Provider commits to an operations-led Workspace return and erasure process which covers database records, original uploads, derivatives and object-storage files and confirms completion to the Customer. This process is to be established; no automated hard deletion, object purge or whole-Workspace export exists today, and Workspace hard deletion is structurally blocked. drafting note: [OPEN: establish, resource and validate the return and erasure process, including the database deletion dependency, before publication.]

11.4 The following records currently survive service termination or remain after access ends. The purposes below do not give a blanket right to retain Customer Data indefinitely.

11.5 To the extent surviving records remain Customer Data, the Provider will delete or return them under clause 11.2 unless retention is legally required or forms part of lawful documented instructions consistent with Data Protection Law. To the extent processed for the Provider's independent controller purposes, the Privacy Notice must identify the purpose, lawful basis and retention. drafting note: [OPEN: settle lawful roles, minimum fields and retention periods for audit snapshots, usage, email events and payloads, suppression addresses and referrals; implement the 12-month audit limit.]

11.6 Copies awaiting backup expiry will be put beyond ordinary use and protected; if restored for recovery, deletion instructions will be reapplied. The Provider will identify any legally required retention, its purpose and duration and restrict use accordingly. This is a process obligation, not a claim of a verified backup expiry period.

11.7 The Provider retains no diagnostic prompt or response logs. Stored transcripts, generated Pieces and audit snapshots are distinct Workspace records and remain subject to this clause. Expired authentication sessions are not automatically removed; independent account and security retention is covered by the Privacy Notice.

11.8 Deletion by the Provider does not delete copies already delivered to the Customer's platforms, export recipients or end audiences. The Customer must manage those copies through the relevant destination; the Provider will give reasonable assistance concerning its own transmissions.

12. Liability

12.1 Subject to clause 12.2, liability under this DPA shares the aggregate cap in the Terms, value to be confirmed: [LIABILITY CAP], rather than creating an additional cap. drafting note: [OPEN: whether data protection breaches take a higher cap; confirm the shared cap and exclusions satisfy UCTA 1977 reasonableness for these business terms.]

12.2 Nothing excludes or limits liability for death or personal injury caused by negligence, fraud, fraudulent misrepresentation or anything which cannot lawfully be excluded or limited. The cap does not prejudice data subjects' rights, regulatory powers or non-excludable rights under an applicable transfer mechanism. Customer Approval does not excuse the Provider's breach of its processor obligations.

13. Term and governing law

13.1 This DPA takes effect with the Agreement and continues for as long as the Provider or its subprocessors process Customer Data, including during return, deletion and permitted retention. Its precedence is set out in clause 1.4.

13.2 The law of England and Wales governs this DPA. The courts of England and Wales have exclusive jurisdiction, subject to mandatory rights and any overriding provision of a binding transfer mechanism.

13.3 Contact for instructions and data protection matters: dpo[at@]function365.co.uk. General contact: info@function365.co.uk. DPA location: /dpa.

Annex A: processing details

A.1 Subject matter: provision of the Service to the Customer as described in the Order. Processing occurs during the Workspace's life and the limited retention and deletion processes in clause 11, continuously or as actions and scheduled tasks require.

A.2 Nature and purposes: collection, recording, organisation, analysis, generation, storage, display, retrieval, revision, transmission, return and erasure. Processing supports research of the Customer's own website, automated or human-led onboarding interviews, the business profile and offerings, AI text generation, automated classification and moderation of uploaded images via OpenRouter, scheduling and delivery of approved Pieces, and instructed support. The Service also provides AI image generation from the Customer's brand guidance, involving no personal data; that activity is outside the processing of Customer Data governed by this DPA.

A.3 Research is limited to the Customer's own registrable domain, with robots.txt and request budgets. Social links and handles may be recorded; social profile content is not fetched. Extracted page text is sent for AI injection screening; retained research consists of findings, bounded quotes, citations and fetched URLs, not raw HTML or full page text. The server accepts plain text and markdown documents; the document paste/upload panel is not currently available in the interface.

A.4 Connection setup and maintenance include credential validation and health probes at least daily and before publishing. WordPress validation creates a temporary draft and attempts to force-delete it; a failed deletion may leave a draft. These calls follow the connection instruction and do not require a Piece Approval. WordPress content delivery creates a future-scheduled post or draft; WordPress controls subsequent publication.

A.5 Brevo delivery creates campaign drafts in the Customer's account. The Customer sends campaigns in Brevo; the Service does not send them to an audience. The separate email design test send uses one expressly supplied email address through that connection, is Owner-only in the Customer interface and rate-limited, and can also be performed by staff on the Customer's behalf. The address need not belong to a Workspace member. Email wrapper design management includes creation and updates of templates in that account.

A.6 Export delivery creates a per-Piece publishing bundle in object storage and may email it to one configured address. It is distinct from a return of all Workspace data. Brand logos use public hosting for display in email designs; original library uploads remain in private storage alongside processed copies.

A.7 Data categories: names, roles, work contact details, business and sender identities, interview answers and verbatim transcripts, website findings and excerpts, submitted documents, brand assets and logos, images of people, filenames and image metadata, original-upload metadata including possible GPS, offerings, business-profile prose, generated Pieces and versions, revision and support notes, connection credentials and identifiers, audience segment references and labels, test-send and export recipient addresses, and relevant actor identifiers and audit snapshots.

A.8 Data subjects: the Customer's Owners, Members, staff, representatives and delegates; clients, patients, case-study subjects, prospects, suppliers, partners and other people identified in supplied or generated material; people in researched website material and images; test-send and export recipients. Third-party personal data supplied by the Customer is within scope. End-audience contact lists remain in the Customer's Brevo account and are not imported or stored by the Service.

A.9 Special category and criminal offence data are restricted by clauses 3.2 and 3.3. The Customer determines what personal data it supplies and what generated content it approves. AI processing supports content production and image moderation; this DPA does not authorise decisions with legal or similarly significant effects on individuals.

Annex B: technical and organisational measures

B.1 Access and credentials: connector credentials are encrypted at rest with AES-256-GCM and a key held outside the database, with key identifiers supporting rotation. Passwords use scrypt hashing; API key material is hashed. Password resets revoke sessions.

B.2 Multi-factor authentication: TOTP is available, mandatory for operational staff and enforceable per Workspace by operations. Workspace enforcement defaults off and is not an Owner self-service control. TOTP lockout applies after 10 failures in 15 minutes. Trusted-device periods are 30 days for customers and 7 days for staff.

B.3 Sessions and staff access: customer sessions have a 30-day rolling expiry with 24-hour refresh; staff sessions are capped at 12 hours. View-as sessions are read-only and capped at one hour. Staff access is role-controlled through audited console paths. Session expiry is not row deletion.

B.4 Isolation and audit: data-layer Workspace scoping and isolation regression tests are merge blockers. Customer data must not enter another Workspace's prompt context. There are no shared prompt caches; prompt caching is not implemented. Audit records distinguish human, staff, system and delegated actors and record token attribution for delegates. A complete self-service audit page is not available.

B.5 Transport and browser requests: TLS is provided through the application hosting layer, with HSTS. Security headers include nosniff, SAMEORIGIN and strict-origin-when-cross-origin. Cookie-bearing browser API requests require an exact matching Origin header. This is Origin validation, not a CSRF token facility.

B.6 Rate limits: authentication, onboarding/agent routes and API keys have separate limiting layers. The limiters are in-memory and single-process, so their protection depends on the current single-container web deployment.

B.7 Input and uploads: research text, submitted documents and interview answers are fenced as data with nonce-based markers and hostile-input tests. Library image types and size are checked; processed copies are re-encoded to strip metadata including EXIF GPS and downscaled copies undergo automated classification and moderation of uploaded images via OpenRouter. Original upload bytes retain their metadata. Brand logos use a separate public upload path without that re-encoding.

B.8 Backups: Neon point-in-time recovery and temporary copy-on-write restore branches around database migrations are used. drafting note: [OPEN: PITR window and backup expiry cycle for production; confirm restore-drill evidence.] No object-storage versioning or recovery guarantee is claimed. Internal recovery targets are not contractual recovery times.

B.9 Change and secrets handling: platform secrets are held in environment configuration outside source control. Dependency audit through Dependabot and accelerated authentication-package patching are stated security requirements; no continuous scanning performance or fixed patch deadline is claimed. drafting note: [OPEN: confirm operational evidence for dependency audit and authentication patching.]

B.10 Known limits: no Content-Security-Policy is implemented. TOTP secrets, backup codes and Google sign-in OAuth tokens are not application-encrypted. drafting note: [OPEN: remediation of unencrypted TOTP secrets, backup codes and Google OAuth tokens.] No personal-data-breach runbook exists yet, as addressed in clause 8.1. No certification or penetration-test report is claimed.

Annex C: subprocessor list

C.1 This nine-vendor inventory distinguishes processing roles. Subprocessor obligations apply wherever a vendor processes Customer Data on the Provider's behalf. Inclusion of billing and public-site vendors does not bring independent controller processing into this DPA. Names below are provisional vendor identities from the facts. drafting note: [OPEN: confirm all vendor contracting entities, applicable DPAs and processing roles, including Stripe's own purposes and Google Fonts outside Workspace processing.]

drafting note: [RULING CONFLICT: the 3 September 2026 ruling 5 prohibited naming AI providers; the 7 September 2026 common brief supersedes it for this DPA. Annex C names vendors, models and onward providers.]

C.2 Configured models and defaults are listed. Model identifiers marked as defaults are configurable. Any change that introduces a new onward provider is a subprocessor change under clause 5.3. Changes remain subject to clauses 5 and 6; a model setting cannot bypass a required subprocessor notice or transfer safeguard. Better Auth is a self-hosted library, not a subprocessor. GitHub and its container registry handle code and images, not Customer Data, and are excluded.

Not subprocessors

Annex D: transfer mechanism skeleton

D.1 Complete this annex for each restricted transfer, including onward AI routing and relevant remote access. It does not itself execute an IDTA, Addendum or SCCs. Annexes A, B and C supply processing, security and recipient information, to be tailored to each transfer.

D.2 Parties and roles: for the Provider's transfers to subprocessors, exporter is Function 365 Limited, Third Floor, 95 The Promenade, Cheltenham, Gloucestershire, United Kingdom, GL50 1HH, contact dpo[at@]function365.co.uk, acting as processor or subprocessor; importer is value to be confirmed: [IMPORTER LEGAL NAME], value to be confirmed: [IMPORTER ADDRESS], contact value to be confirmed: [IMPORTER CONTACT], in value to be confirmed: [PROCESSING COUNTRIES]. OpenRouter's onward transfers require the actual exporter and recipient for each link. drafting note: [OPEN: complete transfer parties, roles, countries, signatures and effective dates for every link; distinguish any Customer-to-Provider transfer.]

D.3 UK IDTA option: complete the parties, transfer details, linked agreement, transferred data, security and any supplementary protections using the approved form. UK Addendum option: complete Table 1 parties; Table 2 selected EU SCCs and modules; Table 3 appendix information; and Table 4 rights on changes to the approved Addendum. drafting note: [OPEN: select IDTA or Addendum, approved version, SCC module and options, docking, general authorisation with [NOTICE DAYS] notice, optional dispute resolution and Table 4 parties.]

D.4 For SCCs, distinguish controller-to-processor Module Two from processor-to-processor Module Three. Complete Annex I parties, transfer description and competent supervisory authority, Annex II security and Annex III subprocessors where required. drafting note: [OPEN: select applicable SCC governing law, courts and supervisory authority; determine any separate EU GDPR transfer arrangements for EEA customers.]

D.5 Transfer description: use Annex A for subjects, data, purpose, frequency and retention and Annex B for actual measures, tailored to each importer. drafting note: [OPEN: complete and retain each transfer risk assessment, supplementary measures, onward-transfer safeguards and review arrangements before the relevant transfer.]