Daybeat Privacy Notice

Definitions

For this notice, the following terms have these meanings.

Daybeat means the content-marketing service provided by Function 365 Limited. References to we, us and our mean that legal entity.

Owner means the person with the workspace role responsible for billing, membership and go-live. Member means a person with the invited staff role, who can review and approve content.

Authorised Agent means a third-party delegate acting under an API token minted by a signed-in human Owner, within its granted permissions, the workspace's oversight mode and applicable access limits. An agent creating a restricted account before a person claims it is not, merely by doing so, that person's Authorised Agent.

Approval means the customer's explicit decision permitting a piece to publish, made by an Owner, a Member or an Authorised Agent with the required permission. Go-live, the approval of the first topic's content, remains a human Owner action.

Customer Content means the workspace material described in clause 2.3. DPA means our Data Processing Agreement at /dpa.

UK GDPR means the UK General Data Protection Regulation. PECR means the Privacy and Electronic Communications Regulations 2003. ICO means the Information Commissioner's Office.

1. Who we are

1.1 Function 365 Limited, trading as Daybeat, is registered in England and Wales under company number 10069330. Our registered office is Third Floor, 95 The Promenade, Cheltenham, Gloucestershire, United Kingdom, GL50 1HH.

1.2 We are the controller for the uses of personal data described in clause 2.2. Our ICO registration number is ZA539196.

1.3 Contact dpo[at@]function365.co.uk for privacy questions, rights requests or complaints. General enquiries go to info@function365.co.uk.

1.4 Data Protection Officer: drafting note: [OPEN: Confirm whether a Data Protection Officer is required or appointed and insert their contact details, or state that none is appointed.]

2. What this notice covers

2.1 This notice explains our use of personal data under the UK GDPR and the Data Protection Act 2018. It covers people associated with business customers as well as visitors and people who have not become customers.

2.2 We act as controller for our relationship with Owners, Members, invited users, people associated with Authorised Agents and other API actors, billing contacts, support correspondents, referral participants and marketing-site visitors. This includes people whose details an agent supplies to create a restricted account before they have consented or claimed it.

2.3 We act as processor for Customer Content on the customer's instructions under the DPA: verbatim interview answers, business research findings and source references, supplied text, offerings, business profiles, topics, generated pieces and versions, images and brand assets, and publishing records. These may identify staff, customers or case-study subjects. Interviews are either automated in the portal or, if you chose the team onboarding option, run by a member of our team. Our staff can access interview answers through the recorded administrative paths described in clause 6.7. Original library uploads remain stored unaltered, including any embedded metadata, alongside the copies re-encoded for publication with metadata removed; brand logos use a separate public hosting path.

2.4 Audience contact lists remain in the customer's own Brevo account. We hold audience segment references and labels and the sender identity, and create campaign drafts for the customer to send in Brevo. A separately requested email-design test can send to a specified recipient through that connection; we do not import or hold the audience list.

2.5 If your data appears in Customer Content, the customer is the controller for that use. Contact them about it, or you can contact us and we will pass the request to the relevant customer and assist them as our agreement with them requires under the DPA. Our controller uses, such as security and activity records, remain covered by this notice.

2.6 We do not seek special category or criminal offence data about account holders. The service is not designed for such content; customers should not put it into their workspace without resolving the requirements with us. drafting note: [OPEN: Settle the position on health and other special category data, including clinic case studies, Article 9 conditions and any required impact assessment, consistently with the DPA.]

2.7 Daybeat uses AI image generation from the workspace's brand guidance, involving no personal data. Separately, we carry out automated classification and moderation of uploaded images, which may contain personal data.

3. Personal data we collect

3.1 Owners, Members and account holders. We hold user identifiers, name, email address, email-verification status, avatar URL where supplied, account timestamps, workspace membership, role and status. Account security records can include restrictions, reasons and expiry dates.

3.2 Sign-in and security. Where applicable, we hold a password hash, verification and password-reset records with expiry dates, multi-factor authentication settings, the time-based one-time password (TOTP) secret and backup codes, failed-verification counts and lockout times. If Google sign-in is configured and used, account records include Google sign-in tokens, permissions and expiry dates.

3.3 Sessions contain a token, expiry, IP address, user agent (browser and device information), active workspace identifier and any staff view-as marker. A trusted-device cookie records the user's choice to remember a device for multi-factor authentication. Section 13 covers cookies.

3.4 Invited users and restricted-account invitees. Invitation records contain the invitee's email, inviter identifier, status and expiry. For an agent-created restricted account we record the declared owner's email and supplied registration and setup details, together with the account's claim and review state. The person may not yet have agreed to use Daybeat.

3.5 Authorised Agents and API actors. We hold hashed API token material, display prefix, workspace reference, granted permissions, expiry, last-request information and rate-limit counters. We record the oversight mode and changes to it. Activity records distinguish a human action from an Authorised Agent's action and link the latter to its token and the human who minted it.

3.6 Activity records. Our audit trail records the actor identifier and kind, action, affected record, timestamp and before-and-after information or other event details. These snapshots may repeat personal data from a changed record. Records include Approval, publishing, permission changes and staff actions. Removing access or revoking a token does not remove the trail.

3.7 Billing contacts. We hold plan and subscription details, the selected onboarding option, payment status, billing periods, Stripe customer and subscription identifiers and a flag indicating whether a tax identifier is present. Billing name, email, address and tax identifier are held by Stripe and used for billing and tax treatment. Stripe collects card details directly; we do not see or store them.

3.8 Support correspondents and referral participants. We keep support emails, their sender details and contents, and the free-text notes you send us in the portal, such as an onboarding help request or a note explaining how you want content changed. Referral records associate referral tokens with the referring and referred workspace and reward attribution. We also hold transactional email recipient addresses, delivery-event details and provider event payloads, and suppression addresses used to prevent further delivery.

3.9 Marketing-site visitors. The public marketing pages set and read no cookies and use no analytics. Requests still reach our hosting infrastructure, and Google Fonts receives your IP address and user agent when your browser loads the site's fonts; that font request sets no cookie.

3.10 Server request logs may be held by the hosting and reverse-proxy infrastructure. drafting note: [OPEN: Confirm the server request-log fields, purposes, access and retention; do not describe these logs as short-lived until verified.]

3.11 People using the website or service. Where Sentry is enabled, error events, stack traces and request context are sent to it to diagnose faults; this context may contain personal data. drafting note: [OPEN: Confirm production Sentry enablement, collected fields, personal-data filtering and retention.]

3.12 Connections. We store the credentials you supply for your connected platforms and associated configuration, including an export delivery address where supplied, identifiers, expiry and health information. These enable the connector to act on the customer's instructions; they do not give us an audience contact list.

4. Where the data comes from

4.1 We receive data directly from you when you register, sign in, supply credentials, use Daybeat, participate in onboarding or contact support. Session and activity information arise from your use of the service.

4.2 Your Owner supplies your email when inviting you. An agent can supply a declared owner email and registration or setup information through the public onboarding endpoint before that person has consented; we create a restricted account and email an invitation to claim it. The endpoint does not require authentication. Email verification binds the person to the account, and payment is a separate step.

4.3 We receive billing identifiers, subscription information and payment outcomes from Stripe, and transactional email delivery and suppression information through our email provider.

4.4 For connections, you supply the platform credentials directly. The connected platform then returns operational information such as permission checks and publication results when the connector acts on the customer's instructions. This is not a sign-in or consent record obtained through a platform authorisation redirect.

4.5 Customer Content may also come from research of the customer's own website during onboarding. The crawler stays on the same registrable domain and respects robots.txt. It records findings, bounded excerpts and source references; social links yield a platform, URL and possible handle, without fetching social profile content. Extracted page text can be sent for AI screening even though full page text and raw HTML are not retained as research records.

4.6 drafting note: [OPEN: Confirm how this notice is supplied to ordinary invitees and restricted-account invitees at the required time, including in the first communication where applicable, and how the source of their details is explained.]

5. Purposes and lawful bases

5.1 The table describes our controller uses. Contract applies only where processing is necessary for a contract with you personally, or steps you ask us to take before entering one. For employees and other representatives of a business customer who are not personally contracting with us, the stated service-administration legitimate interests apply instead.

5.2 drafting note: [OPEN: Complete and record the necessity and balancing assessments for the legitimate interests above, including invitations, referrals, audit snapshots, error monitoring and third-party fonts; confirm the specific accounting obligations.]

5.3 Necessary service, billing and security messages are part of operating the account. They are separate from marketing. If we send Daybeat marketing, we will provide an unsubscribe link and you can also opt out through info@function365.co.uk.

5.4 drafting note: [OPEN: Confirm the Daybeat marketing process and PECR basis, including consent and any applicable exception for individual subscribers. Sole traders and ordinary partnerships may be individual subscribers despite the business-only service; distinguish corporate subscribers and do not assume all partnerships have the same status.]

5.5 The service needs identity and authentication details to operate an account, and billing details to administer a paid subscription. If necessary details are not provided, the relevant account or paid service cannot be provided. Marketing consent is not a condition of using Daybeat.

5.6 Approval and an Owner's delegation choices are instructions about operating Daybeat. They are not, by themselves, the consent of every person mentioned in content, and do not remove our own data protection obligations. The customer remains responsible for deciding whether its approved content is accurate and lawful and complies with its platforms' terms. Our Terms of Service are at /terms.

6. Who we share personal data with

6.1 We use the following providers for the stated functions. A provider acting for us as controller is our processor; for Customer Content it may be our subprocessor. Some recipients have independent responsibilities. See value to be confirmed: [SUBPROCESSOR LIST URL] and the DPA for the live list and further details.

6.2 OpenRouter routes text processing to these named model providers. The identifiers below describe the text models used; the live list must reflect the models actually used.

6.3 Direct Anthropic calls use claude-opus-4-8 for text generation and synthesis, claude-opus-4-6 for ranking and claude-sonnet-5 for interviewing. These calls are under Anthropic's commercial API terms, which exclude training on API inputs and outputs. Content is routed through OpenRouter under Daybeat's provider preferences, which exclude training on and retention of Customer Content.

6.4 drafting note: [RULING CONFLICT: The 3 September 2026 ruling against naming AI providers is superseded by the current privacy brief's requirement to name vendors and routed models; clauses 6.1 to 6.3 follow that requirement.]

6.5 drafting note: [OPEN: Confirm each provider's contracting legal entity and controller or processor role, including Stripe, Google Fonts and Google sign-in if enabled, and populate the live subprocessor list and DPA consistently.]

6.6 The customer's WordPress host, LinkedIn, Meta/Instagram, X and Brevo are customer-authorised destinations. They receive approved content or operational requests through the customer's connections under its direct relationship with them. They are independent controllers or the customer's own processors, not Daybeat subprocessors. Brevo receives campaign drafts and separately requested test emails as described in clause 2.4. A per-piece export may also be delivered to an address configured by the customer.

6.7 Workspace access follows membership and permissions; Authorised Agents receive the access the Owner permits. Our staff access data as needed for support and operations through recorded administrative paths. Staff view-as access is read-only; staff edits and other administrative actions are separately attributed. A staff view-as session lasts at most one hour and is recorded against the session. Our staff can also edit workspace content where the workspace's concierge-edits setting permits it. That setting is on by default and the Owner can switch it off. Some safety actions, such as an advisory correction or retiring an offering, are taken regardless and always generate a notification to the workspace with the change. Staff can also approve and re-push the email wrapper design outside this setting; that approval is attributed to staff and shown to the workspace. These permissions do not allow staff to approve a piece for publication.

6.8 We may also disclose relevant data to professional advisers, regulators or law enforcement where required, and to a buyer or successor if the business is sold or reorganised. We would tell you about a transfer to a buyer or successor. We do not sell personal data or share it for third-party advertising.

7. International transfers

7.1 Our database and object storage use UK/EEA hosting. Neon production is recorded as EU-hosted; the confirmed London region, eu-west-2, relates to staging. Cloudflare R2 uses EU jurisdiction storage, including the separate brand-logo bucket. drafting note: [OPEN: Confirm Neon's exact production region and Hostinger's actual datacentre; Hostinger is specified as UK/EU but the location is unconfirmed.]

7.2 UK/EEA storage does not mean all processing stays there. Anthropic, OpenRouter, Resend, Stripe, Sentry and Google involve US providers or processing; Resend stores transactional email data in the US. Sentry's region depends on configuration. drafting note: [OPEN: Confirm Sentry's production region and the access and transfer arrangements for UK/EEA-hosted vendors, including Cloudflare and Neon.]

7.3 OpenRouter also makes onward disclosures to the providers in clause 6.2. Moonshot AI and DeepSeek are headquartered in China, outside adequacy-covered jurisdictions; Google, Anthropic and OpenAI involve US providers. Headquarters are not a guarantee of the processing location. Daybeat's provider preferences exclude training on and retention of Customer Content, but these preferences do not replace the need for a valid transfer mechanism.

7.4 For transfers outside the UK requiring contractual safeguards, the proposed choice is the UK International Data Transfer Agreement or the UK Addendum to the EU standard contractual clauses. drafting note: [OPEN: Mechanism to be selected by the solicitor; verify and document the applicable safeguards, processing countries and transfer risk assessments for each recipient and OpenRouter onward route, including Google Fonts. Do not treat safeguards as executed merely because they are named here.]

7.5 You can request details and copies of the applicable safeguards through dpo[at@]function365.co.uk. drafting note: [OPEN: Confirm EU GDPR applicability, any EU representative requirement and EU transfer documentation if EU customers are served.]

8. How long we keep personal data

8.1 We will keep personal data only for as long as needed for its stated purpose, legal obligations and properly justified claims or security needs. The current system does not automatically apply a general deletion schedule. The table explains what expiry and cancellation actually do; it does not present indefinite storage as a lawful retention policy.

8.2 Account deletion, workspace hard deletion, transcript deletion and data delivery are commitments to be carried out by our staff on request under the DPA and section 10. There is no automated erasure workflow or self-serve workspace archive export. The documented content-deletion target is workspace life plus 90 days after churn, and the audit target is workspace life plus 12 months; these are process targets, not current automated behaviour. drafting note: [OPEN: Approve and resource the manual deletion and delivery procedure, resolve the workspace-deletion block, and settle the retention trigger consistently with the DPA and cancellation wording before making these targets operative.]

8.3 Audit rows, suppression addresses and usage records survive the current workspace closure process by design, as do the other records identified above. A request must assess each remaining record separately: suppression addresses may be needed to prevent further email, while justified legal or security records may need to remain. drafting note: [OPEN: Set lawful periods or specific review criteria for accounts, expired sessions, invitations, restricted accounts, audit snapshots, usage, referrals, email events and payloads, suppressions, billing, support, public logos, backups and provider records; resolve the facts files' inconsistent descriptions of usage-record survival on a future hard deletion.]

8.4 Daybeat does not keep a separate diagnostic log of model prompt and response text. This does not mean the underlying content is absent: transcripts, business profiles, generated pieces and image-generation prompts attached to asset records remain stored as Customer Content. Usage metering records provider, model, counts and attribution rather than prompt and response text.

8.5 Backup history may retain data beyond its removal from active records. drafting note: [OPEN: Confirm the configured Neon point-in-time recovery period, restore-copy handling and how erasure is preserved after a restore; do not substitute an engineering target for the configured period.]

9. Security

9.1 We use TLS for data in transit, password hashing, available multi-factor authentication, session controls, rate limiting, workspace-scoped data access and recorded staff access. Connector credentials are encrypted at rest with a key held outside the database; this does not describe all authentication data, as TOTP secrets, backup codes and Google sign-in tokens are not application-encrypted. Staff view-as sessions are read-only, and staff sign-in sessions last at most 12 hours. No security certification is claimed. Where a breach triggers legal notification duties, we will notify the ICO and affected people as required; for Customer Content, notification to the customer is governed by the DPA.

10. Your rights and complaints

10.1 You have rights to information about processing, access to your personal data and correction of inaccurate or incomplete data. In the circumstances provided by law, you may also request erasure or restriction and object to processing based on legitimate interests.

10.2 Data portability applies to personal data you provided where processing is automated and based on consent or a contract. It is distinct from a customer's request for a full workspace archive. Rights are subject to applicable conditions and exemptions. The ICO explains these rights.

10.3 You may object to direct marketing at any time. Where we rely on consent, you may withdraw it through dpo[at@]function365.co.uk; withdrawal does not affect the lawfulness of earlier processing.

10.4 Send rights requests to dpo[at@]function365.co.uk. We will respond without undue delay and normally within one calendar month. Our process commitment is to complete valid deletion requests within 30 days of confirming the request and identity, subject to lawful exceptions and to clause 8.2 where records cannot presently be removed from a workspace record. This qualification does not extend any statutory deadline or create an exception to the right to erasure. If a lawful extension is needed, we will explain the reason and timing within the applicable initial period.

10.5 We may request information reasonably needed to verify identity or authority. Requests are normally free. We will explain any lawful refusal or retained information and the complaint route. Access and erasure are handled by our staff, including manual data delivery and deletion; the portal's per-piece export connector is not a data-subject export tool.

10.6 For Customer Content, you can contact us and we will pass the request to the relevant customer and assist them as our agreement with them requires under the DPA. We will separately address any part for which we are controller. A workspace Owner can request a workspace export under that agreement, subject to protecting other people's data.

10.7 Complain to us at dpo[at@]function365.co.uk. You also have the right to complain to the ICO through its complaints route. Where EU GDPR applies, you may complain to the relevant EU/EEA supervisory authority.

10.8 drafting note: [OPEN: The brief refers to the Data (Use and Access) Act 2026; verify the correct legislative reference, commencement and any implications for lawful bases, rights deadlines, complaints and automated decisions. No position on that Act is asserted in this draft.]

11. Automated decision-making

11.1 We do not use personal data to make solely automated decisions producing legal or similarly significant effects on individuals: Daybeat generates content for Approval, with human approval or approval delegated by a human Owner to an Authorised Agent, and does not independently decide to publish it. The only automated gate affecting a person's account access in this context is a two-factor security lockout after repeated failed verification, which protects the account rather than profiling the person.

12. Children

12.1 Daybeat is offered to businesses and is not directed at children. We do not knowingly seek children's personal data for accounts, and we do not operate an age gate. If you believe a child's data has reached us, contact dpo[at@]function365.co.uk so we can address it, including with the relevant customer where the data is Customer Content.

13. Cookies and browser storage

13.1 The three cookie classes are authentication/session cookies, two-factor trusted-device cookies and the referral-attribution cookie daybeat_ref; see /cookies.

13.2 Authentication sessions and trusted-device choices support sign-in and security. Trusted-device cookies last 30 days for customer users and 7 days for staff. The referral landing route sets daybeat_ref for 30 days to carry attribution to checkout; it is a functional/marketing cookie, not described here as strictly necessary. drafting note: [OPEN: PECR regulation 6, settle the referral cookie's consent requirement and implement any required consent before setting it.]

13.3 The public marketing pages themselves use no cookies or analytics. The portal also uses local storage for in-progress piece edits and dismissed billing banners. Stripe may set its own cookies on its hosted checkout domain. Google Fonts requests are described in sections 3 and 7 even though they set no cookie.

14. Changes and contact

14.1 We may update this notice at /privacy. The date at the top identifies the version. We will take reasonable steps to tell you by email or in the portal before a material change takes effect, unless the change is required by law or by a change at one of our providers, in which case we will tell you as soon as we can. This does not limit any legal requirement to inform you before processing changes.

14.2 Privacy questions, rights and complaints: dpo[at@]function365.co.uk. General enquiries: info@function365.co.uk. Postal contact: Function 365 Limited, Third Floor, 95 The Promenade, Cheltenham, Gloucestershire, United Kingdom, GL50 1HH.