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.

2. Roles and documented instructions

2.1 The Customer is controller and the Provider is processor of Customer Data. The Service is supplied directly to the Customer for its own business; resale and white-labelling are not permitted at launch. A delegate authorised to act for that Customer does not become a separate contracting customer.

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 and is accepted with the Terms by an authorised person aged 18 or over ticking the acceptance box at Stripe Checkout. The Provider records the accepted document version and acceptance time.

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 Customer must not put special category or criminal offence data into the Workspace. There is no launch exception to this prohibition.

3.3 If the Customer nevertheless supplies such 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; incidental 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 subprocessor list, 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 30 calendar 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 remains refundable in full on cancellation requested before the interview is completed, as provided in the Terms. 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. The production database is hosted by Neon in the United Kingdom (London); Hostinger's application datacentre is in London, UK. Cloudflare also fronts the app. 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.

6.3 Generated content is routed through OpenRouter to the model providers named in Annex C, under those providers' terms. The Provider does not train, fine-tune or evaluate any model on Customer Data, as clause 4.6 requires. Each OpenRouter request carries a data-policy setting restricting routing to providers which do not collect user data. Text routing is additionally restricted to a reviewed set of recipients for each model, and a model with no reviewed recipient set is refused rather than routed. The recipients of a routed request may be hosting providers serving a model rather than the model's originating company; those recipients must be identified in the maintained subprocessor list and applicable transfer documentation. The Provider prefers providers offering zero data retention where available and compatible with the service, but does not guarantee zero data retention and does not enable it for every model. The Provider does not warrant any provider's retention behaviour or the terms on which a provider processes routed content, and those terms may change. The Provider will maintain the contractual arrangements and routing settings necessary to fulfil its own obligations under this clause.

6.4 Drafts are assessed through OpenRouter using a variety of OpenWeight models published by Moonshot AI, DeepSeek and Google. Moonshot AI and DeepSeek are China-headquartered. Other routed uses involve Anthropic, OpenAI and Google, as detailed in Annex C. Provider headquarters are not evidence of a particular processing location; onward locations and safeguards must be recorded in the maintained subprocessor list and applicable transfer documentation.

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.

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 after becoming aware of a personal data breach affecting Customer Data, using the Customer's notified contact details. No fixed-hour notification guarantee is given.

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. The Provider does not guarantee the timing of notifications it receives from subprocessors or suppliers. This does not reduce its own notification obligation under clause 8.1 or its obligations under clause 5.

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 30 calendar 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 two business days of receipt. Identity checks are not a precondition to forwarding. It will not answer their substance without the Customer's authorisation unless legally required.

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. Daybeat operations will agree case-specific timing with the Customer, subject to lawful retention under clause 11 and applicable statutory deadlines. It will support earlier transcript deletion on request once the business profile has been approved. 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. The 90-day reactivation window and the audit policy in clause 11.4 run from that Service end date; an internal status change does not restart them.

11.2 At the Customer's choice, the Provider will return Customer Data and delete remaining copies, or delete it, unless law requires retention. Daybeat operations will agree case-specific timing and inform the Customer without undue delay of any obstacle. 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, subject to clause 11.3. Notification of an obstacle does not itself authorise longer retention or extend a statutory deadline.

11.3 Subject to the Customer's choice, data may be retained during the 90-day reactivation window for reactivation and return. That window is not a deletion-completion deadline. Daybeat operations handles return and erasure across database records, original uploads, derivatives and object-storage files and confirms completion. No automated hard deletion, object purge or whole-Workspace export exists today, and Workspace hard deletion is structurally blocked. The Provider must identify and address any obstacle without undue delay, subject to Data Protection Law.

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.

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, the liability provisions of clause 16 of the Terms apply across the Agreement, including this DPA. This DPA creates no separate liability cap.

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 liability provisions do 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 prohibited under 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 cookies carry a 30-day Max-Age; staff trust is limited to seven days by a server-side record, giving an effective staff window of seven days.

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. 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. Automated dependency update proposals use a cooldown. No vulnerability-scanning coverage or fixed patch deadline is claimed.

B.10 Known limits: no Content-Security-Policy is implemented. 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 maintained 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. Annex C is the maintained subprocessor list linked from the legal page.

C.2 The model a provider serves for any listed use is configurable and is not stated here. 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: international transfer information

D.1 Clause 6 governs international transfers. You can request information and copies of applicable transfer safeguards through dpo[at@]function365.co.uk.