Privacy Policy

1. Who we are and our two roles

Beenest is software for childcare centres. It is provided by Triple Peak Software Systems, [legal form, e.g. LLC] organised in [state of formation], [registered address] ("Beenest", "we", "us"). We are not established in the United Kingdom. Privacy contact: [privacy contact email]. General contact: hello@beenest.co.

Our UK representative under Article 27 UK GDPR: [OPEN: UK representative name and address]. You can contact our representative instead of us about any question on how we process personal data.

ICO registration: [OPEN: ICO registration number]

This policy explains how we handle personal data under the UK GDPR and the Data Protection Act 2018. We act in two different roles:

• Beenest as controller. For visits to beenest.co, contact and sales enquiries, customer accounts, billing and support, we decide why and how personal data is used. This policy is our privacy notice for that data (Sections 2 to 4).
• Beenest as processor. When a nursery, childcare setting or its operator (the "Customer") uses Beenest, the data the centre and its staff, parents and other users enter about children, families and staff ("Centre Data") is processed on behalf of the Customer. The Customer is the controller of Centre Data; we are its processor under Article 28 UK GDPR and act only on its documented instructions. Our obligations to the Customer are set out in the Data Processing Agreement (DPA) and the Terms of Service.

The Customer, as controller, must give parents, carers and staff the privacy information that Articles 13 and 14 UK GDPR require, and decides the lawful basis for Centre Data. As employer, the Customer is also responsible for telling staff about any monitoring of their work, in line with the ICO's guidance on monitoring workers. Section 5 describes what the platform does with Centre Data so that centres, parents and staff can understand it; it does not replace the centre's own privacy notice. Questions about Centre Data are best sent to the centre (Section 12).

2. Personal data we use as controller

2.1 Visits to beenest.co

beenest.co is hosted by Netlify, Inc. (United States). When you open a page, Netlify automatically records server log data:

• IP address
• Date and time of access
• Requested URL and referrer URL
• Browser type, operating system and device information
• HTTP status code and amount of data transferred

Purpose: delivering the site, keeping it secure and stable, detecting abuse.
Lawful basis: Article 6(1)(f) UK GDPR (our legitimate interest in a secure and working website).

The website's fonts are served from our own host, so your browser does not contact a font provider.

Analytics and marketing, only with your consent. The home page, the pricing page and some product pages show a cookie banner. Nothing beyond the necessary storage of your choice runs until you agree. If you accept analytics, we load Google Analytics (Google), which collects pages visited and navigation paths, session duration, approximate location (country or city level, derived from the IP address), device type, browser and screen resolution. If you accept marketing, we load the Meta Pixel (Meta Platforms), which collects page views, interactions, referral source and device information to measure ad campaigns and deliver relevant ads. Pages without the banner load neither service. See Section 8.
Purpose: understanding how the website is used; measuring ad campaigns.
Lawful basis: your consent (Article 6(1)(a) UK GDPR and regulation 6 of the Privacy and Electronic Communications Regulations 2003, PECR). You can withdraw it at any time with "Cookie Settings".

[OPEN: Meta Pixel and Google Analytics on beenest.co (known blocker). Decide whether to keep them for the UK. If kept: describe Meta's and Google's role (independent or joint controller for the data collected through their tools), the UK transfer mechanism to the US, and confirm the Google Analytics settings and retention.]

2.2 Contact and sales enquiries

The contact form on beenest.co asks for your name, email address, organisation, country or region and your message. It also sends the site version you used (market and language) and contains a hidden anti-spam field that people do not fill in. Submissions are received and stored by Netlify Forms (Netlify, Inc.). If you email us, we receive your email address, name and whatever you write.

Purpose: answering your enquiry, giving you information about Beenest and preparing a consultation you asked for. We do not use it for marketing without your separate consent.
Lawful basis: Article 6(1)(b) UK GDPR (steps you ask us to take before a contract) and Article 6(1)(f) UK GDPR (our legitimate interest in answering enquiries from organisations).

2.3 Customer accounts, billing and support

• Name, email address, password (stored in hashed form), and where provided phone number and organisation
• Account information such as role and the centres an account belongs to
• Subscription, order and AI credit information, and billing history
• Support requests and our correspondence with you

Operator accounts. An operator account can see the data of the centres assigned to that operator. Account holders can invite more users by email; after accepting, those users have the same access and can view and edit the data of those centres. Nobody can see another operator's data. Inviting users and assigning access is the Customer's responsibility as controller.

Card payments. If a Customer pays its subscription fees by card, Stripe [OPEN: Stripe contracting entity] processes the payment. Stripe receives the name, email address, billing details and card data; only Stripe receives the card data, we do not. Stripe receives only the Customer's contract and payment data, never data about children, parents or staff, and it is not a sub-processor of Centre Data.

Purpose: performing the contract, authenticating users, managing accounts, billing, support and keeping business records.
Lawful basis: Article 6(1)(b) UK GDPR (contract); for users who are not themselves our contract party (for example invited staff of an operator), Article 6(1)(f) UK GDPR (our legitimate interest in providing the service the Customer ordered); for billing and tax records, Article 6(1)(c) UK GDPR (legal obligation).

2.4 Support via WhatsApp

[OPEN: is WhatsApp support offered in the UK?] If we offer support via WhatsApp (a service of Meta Platforms), please do not send personal or sensitive information there (for example children's names, dates of birth, health information, photos or documents with personal content). The channel is only for general questions and technical support. WhatsApp messages are processed and stored on Meta's servers under Meta's terms, which may be outside the United Kingdom, in particular in the United States. For anything involving personal data, use email (hello@beenest.co) or the communication features in Beenest.
Lawful basis: Article 6(1)(a) UK GDPR (consent, by actively choosing this channel).

2.5 Error monitoring and platform security

We use error reports and server logs of the platform (Section 5.5) also for our own legitimate interest in a stable and secure service (Article 6(1)(f) UK GDPR), as far as they relate to our accounts and billing. For Centre Data, they are processing on behalf of the Customer.

3. How we use personal data as controller

We use the personal data described in Section 2 to:

• deliver, secure and keep beenest.co stable, and detect abuse
• answer enquiries, give information about Beenest and prepare consultations you ask for
• create and manage customer accounts, authenticate users and provide support
• bill subscription fees and AI credits and keep business records
• detect and fix errors and keep the platform secure
• understand website use and measure ad campaigns, only if you consented in the cookie banner
• comply with the law and protect our rights

We do not make decisions about you based solely on automated processing that produce legal or similarly significant effects.

4. What we do not do with Centre Data

We use Centre Data only to provide the platform to the Customer as described in Section 5 and in the DPA, as the Customer instructs. We do not use Centre Data for our own purposes, we do not combine it with other data for our own purposes, we do not sell it, we do not use it for advertising, and we do not use it to train AI models.

5. Centre Data we process for centres

5.1 Categories of data

Which fields are required and which are optional is set out in the DPA. A child's full name is not required; if it is left empty, the software shows "No name". The age group follows from the date of birth. For each staff member, a name or initials, an identifier or pseudonym, check-in and check-out timestamps and, where configured, the staff type are required. Centre and configuration data (for example thresholds, opening hours, meal cancellation deadlines, operator rules) is optional. Depending on what the centre uses, Centre Data can include:

• Child records: names, date of birth, type and mode of care, group membership; optional identifiers the operator uses and the care period (contract start and end)
• Further child details: gender, contracted care hours, lunch participation, school attendance, weekend care, admission, leaving and archiving dates; optionally email addresses and phone number of parents or carers on the child record (for documents and meal billing receipts, the QR letter, consent requests and confirmations of meeting appointments)
• Attendance times (drop-off and collection via the check-in terminal)
• Discarded check-in actions, which are deliberately kept after the person is deleted (see Section 9)
• Staff working and attendance times (terminal, remote check-in and time reports in the staff app), including a work location flag per timestamp (remote, outing, off site)
• Staff time reports for managers and operators (per centre and across centres, including export); staff can see their own times
• Staff records and planning: staff type, employee number, contract data (start date, fixed term, end date, employment by a third party, mentoring, work areas), daily, weekly and monthly working hours, planned shifts, absences, rota templates, hours balance, staff app session data (stored hashed)
• Optional free-text notes about a child, also visible to staff in the group view; what they contain depends on what is entered
• Optional photo of a child so staff can recognise the child, only if the parents have given the permission "Photo of the child on the centre's devices"; it is not processed with AI and is deleted if the permission is withdrawn
• Special category data (Article 9 UK GDPR): allergies and intolerances (health data) and an optional meal note in free text (in practice allergy and diet information); if the operator activates supplier access, these go to the meal supplier the operator names
• Optional statistical or regulator reporting fields [OPEN: does the UK build contain any reporting fields? The DE product has optional fields for official statistics and state reporting, including disability, origin and main family language. Remove this line if not.]
• Email addresses of parents or carers and a send log (which document was sent to which address and when)
• Group reports, daily reports and incident notes in free text. Parents see daily reports and child notes in the parent app only if staff explicitly choose "Share with parents" and the centre has turned on display in the parent app (off by default)
• Permissions per child with when and how they were given (by the centre or the parents, with the wording) and withdrawn; parent consents confirmed by email. Confirming stores neither name, IP address nor device; the confirmation is proven by the stored address, not the person
• Authorised collection persons (name, relationship, source; if reported by parents, the authorisation text and time of confirmation; the time an ID was checked, without ID data), reported collections and handover records (person collecting, reason for an exception, confirming staff member, time)
• Events with acceptances and declines per child; meeting requests and staff appointments; room bookings
• Poll votes with a device ID (one vote per device, to prevent multiple votes)
• Application error logs of the software, where the context contains a person ID (in addition to Sentry, see 5.5)
• Interactions within the app, timestamps
• Optional: parent payments and membership fees (payment items, reference code, cash payments with the name or initials of the person who took them, invoice recipient) and, with a bank connection, amount, booking date and reference of transactions that are or should be matched to a parent payment (the payer's name and account details are processed only while fetching, not stored) [OPEN: is the bank connection available in the UK?]
• Optional: recording of a parent meeting with prior consent (name, role, signature or confirmed email); the recording is deleted after it has been analysed
• Optional (operator): applications for a childcare place through the enrolment portal

Purpose: running the centre's daily operations, keeping attendance and capacity records, communicating with parents (including documents and meal billing receipts) and managing meals, as the Customer instructs.

5.2 Communications and free text

• Messages between the centre and parents, including to a single family (in the parent app and, if the centre chooses, by email in the centre's name). Parents reply only with a set action ("OK", "Accept", "Appointment", "Join") with a timestamp, not free text. Parents give permissions only by confirmed email.
• Meal cancellations and other notices through the parent app
• Documents sent to parents by email (address on the child record), with a send log
• Internal staff chat (content, timestamp, sender name or initials). It is not meant for sensitive content. It is deleted automatically after the retention the centre chooses (1 to 7 days, default 1 day) at midnight in the centre's time zone; pinboard messages are exempt. Per rule, the centre decides whether the system posts automatic working time notices to the chat (mandatory break off by default; "planned but not here" and "daily working time reached" on by default; "not checked out" always on). These notices name the person and are visible to the team. Time corrections from the staff app go to the manager as an adjustment request, not to the team chat.
• Emails to parents in the centre's name: QR letter (with or without the parent password, as the centre sets), consent requests, confirmation of an agreed meeting. They are sent as "[centre name] via Beenest" to the one address the centre stored for the child. The software does not track whether they are delivered. Permission and recording requests are logged with the recipient address.
• Messages between the centre and the operator, including email copies to the centre's distribution list and forwarding by the operator
• Contact requests and support messages
• Uploaded files (for example documentation)

Free-text fields. In many places users can type freely: notes, messages, reasons, chat. The content depends only on what is written and can in some cases include health data or data about other people. Next to fields the AI assistant can read, the interface asks users not to enter health data; the text is transmitted and stored as written. The centre instructs its users what belongs in free text. We do not analyse free text for our own purposes. Who can read it and when it is deleted depends on the feature (see the DPA). Free text appears to parents or on the centre's website only after the centre explicitly releases or publishes it.

5.3 Device and session data

• Browser type, operating system, device identifier
• Device ID for poll votes (only to ensure one vote per device)
• Session IDs
• Pseudonymous push tokens (when notifications are enabled); in the parent app linked to groups and the child identifiers stored on the device

To protect against password guessing, after a failed attempt we store for about one hour a one-way hash of the network and of the wrong value entered, not the IP address or the value itself.

5.4 AI features

Beenest offers AI features in the admin interface, the operator area, on the group tablet (voice dictation) and, only if the centre turns it on, in the staff app. The check-in terminals have no AI features; the parent app has only AI translation, and only at the "All" level. Each feature can be switched on and off.

What the AI learns about people is set by the centre's AI privacy level: "Off", "Pseudonymised" (children and staff only as labels such as "Child 7F3A") or "All" (real names of staff and children; the default, and a later switch back to "All" must be confirmed separately). The operator can set a maximum level; the lower level applies. The level governs the features that read operating data (Autopilot, rota AI, daily analysis, staff app AI helper, operator Autopilot, monthly report). What the team writes itself (team chat, pinboards, notes, events) is read by the AI at every level except "Off", as written, including names in it. Absence reasons are never sent to the AI linked to a person.

Features that only process what you type, say or upload (dictation, email helper, parent meeting, AI text drafts, website builder, floor plan, hazard AI, handbook draft, help and DPA chat) do not depend on the level: data goes to the AI only when you call the feature yourself; if you do not use it, nothing is sent. The website builder, voice dictation (and with it the email helper, parent meeting and AI text drafts) and floor plan can also be switched off; image generation and the staff app AI helper run only after being switched on. AI features are marked the same way throughout the software (purple buttons with a sparkle icon).

Protection for inputs. You or your centre are responsible for what you enter into AI features. In addition, the AI rejects inputs containing health data, other special category data, login credentials or, depending on the centre's level, names, and stops. Such inputs are not stored; until then they were processed only on the EU endpoint, without training.

The AI provider is Google (Google Cloud Vertex AI / Gemini), under the Vertex AI data processing terms [OPEN: Google contracting entity for the UK setup; the DE AVV names Google Ireland Ltd.]. Inputs are not used to train AI models. Google generally does not store inputs; only if automated filters flag suspected abuse, for up to 90 days for abuse review in the EU. Text, voice and image content is processed on the EU multi-region endpoint. The exception is image generation (website images, terminal logo, preview images for hazard topics) on Google's global endpoint; only image descriptions without personal data go there, and with the image generator's non-EU model also your free text and reference images.

The data flows in short:

• Autopilot chat and "custom export" (manager, after admin password): questions, key figures, per-person logs according to the level, group names, the team's free text. Suggested actions run only after the manager confirms.
• Rota AI: rota, people with contract hours, demand; runs only at the "All" level; changes the rota directly, every change is marked and can be undone.
• Daily analysis (automatically before closing on days with high occupancy, email to the manager): the first without asking, further ones only after consent.
• Staff app AI helper (only when switched on): answers questions about what the app already shows the person; for staff always with labels.
• Operator Autopilot: key figures of the centres, staff data according to each centre's level, absence reasons only as counts; centres at "Off" are excluded. Monthly report: aggregated monthly figures without names; the operator can switch it off.
• Help chat and DPA chat: your questions and product documentation or the DPA text; no operating data; not stored.
• Voice dictation (group tablet): recording only to convert it to text; it can contain children's voices, names and observations. The recording is never stored, the text is stored in the daily report.
• Email helper: your sample emails (which can contain correspondence with parents) and your request; the draft is stored until you delete it and is never sent.
• Parent meeting: recording up to 30 minutes only with consents saved beforehand, including at least one parent's. The AI writes an internal report and a version for the parents; the report stays stored until you delete it; the recording is deleted after analysis. The child's name and child data from the software are not sent to the AI.
• AI text drafts (permission texts, feedback to the operator): only your keywords.
• Website builder and image generation: your entries in the assistant (EU endpoint) and style descriptions for images (global endpoint).
• Hazard AI, preview image, handbook draft, floor plan: topics and notes of the team, photos (floor plan and handbook photos are not stored). A hazard topic's preview image is created automatically and can be switched off with the operator's "outside the EU" lock.
• AI translation (only at the "All" level): the centre's emails to parents (the software first replaces names, dates, links and codes with placeholders), parent app content (messages, events, blog, group reports, diary notes, with everything in them) and, when the manager clicks, the topic of a meeting request back into the centre's language. Only the translation is stored, for at most 30 days, not the original. Push notifications are not translated.
• Internet research (Autopilot, operator Autopilot, feedback to the operator, hazards): the AI can research a general question without names or personal details via Google Search and shows the sources. Google may store these search queries for up to three days.
• Image generator (only after the operator unlocks it and it is switched on): you describe an image and can upload reference images; you choose an EU model or a non-EU model, and the software shows for each where it processes. Reference images and text must not contain people or personal data. You download the images; we store neither them nor the reference images.
• Parent letters: an uploaded letter goes in full to the AI, which replaces personal details with placeholders; only the cleaned template is stored. When writing and translating, the AI sees only placeholders, never names or details of children; the software fills in the values. Sending by email requires the admin password and is logged; undelivered emails show as a notice without the address.
• AI data guard (on by default): checks texts to parents and the public before sending, first without AI against the children's names, then with AI (children's names replaced by placeholders). It runs only at the "All" level; without AI credits only the name check without AI runs. The AI does not change the text; only the manager can send a flagged text, with the admin password. None of this is stored.

The notice shown before first use of some AI features is for transparency; it is not a request for consent under Article 6(1)(a) UK GDPR. Details are in the AI annex of the DPA.

5.5 Error monitoring

To detect and fix technical errors we use Sentry (Functional Software, Inc.) in its EU region Frankfurt (Germany). It receives error messages, stack traces and technical metadata. Chat content, prompts, audio and form data are not sent; for dictation errors at most the byte size and file type. Session replay is also active: it records screen sequences of the web app to reproduce errors, including on tablets and on public pages for parents (for example the enrolment portal and the confirmation page). Text and inputs are masked, images and media are not recorded. Where masking fails in an individual case, visible names can be included.

Separate from this are the software's own error logs in the centre database. They can contain a person ID in the error context so that a technical incident can be linked to the check-in or record action concerned. They stay in the centre database in Frankfurt and are not sent to Sentry.

5.6 Camera and microphone

Check-in terminal: the camera is used only to read QR codes. Although it may stay on, it is not CCTV or video surveillance: no images are recorded or stored, no people or surroundings are observed or analysed, nothing is passed on, and recognition happens locally on the device.

Photo of a child (optional): in the group view, staff can take a photo of a child with the camera or choose a file, only if the parents have given the permission "Photo of the child on the centre's devices". The photo is reduced in size and stripped of location data on the device before it is stored.

Other photos (optional): for hazard topics, the floor plan and handbook drafts, photos can be taken or uploaded (see 5.4).

Microphone (optional): voice dictation records only while the user actively starts it; the recording is only converted to text and never stored. The manager can record a parent meeting only with consent of at least one parent saved beforehand; the recording is deleted after analysis.

5.7 Parent app and staff app

The parent app is a separate app without user accounts; parents use it with a pseudonymous child code. It offers optional push notifications and digital wallet cards. Its requests (for example meal cancellations, absence notices, early collection, general messages, centre status, poll votes) are relayed through Cloudflare Workers to the centre database (Supabase), with pseudonymised child and centre IDs. Poll votes are linked to a device ID so each device counts once; the device ID is used only for that. Children's check-in and check-out times are not processed through Cloudflare. Parents enter names or contact details only if the centre turns on the related features (for example reporting a new collection person or requesting a meeting; both off by default). Pseudonymised data is still personal data under UK GDPR. Using the parent app is voluntary.

The staff app (separate store app for phones) sends its requests directly to the application in Frankfurt. Staff see their working times and the team's daily plan and can submit remote check-in, absence and sickness notices and internal chat messages; a wallet staff badge is optional. Time corrections go to the manager as an adjustment request. The centre can turn off the app and single features (team chat, clocking in and out, messages to parents) in its settings (on by default). In the privacy mode "Private phones" (default) the app shows no child records, only numbers about children; in the mode "Work devices", which the centre chooses only for its own devices, it may show names of children in the person's own group where a feature needs them. It never shows child codes. Free text from colleagues or the manager and the topic a parent gave for a meeting can contain details about children. The manager can send one person a message to their inbox in the app. The centre can turn on an AI helper for the staff app (off by default; see 5.4). Only people who allow push notifications on their own device receive them. We recommend running the staff app on centre-owned work devices.

Users of both apps accept the app's privacy notice and terms in the app; without accepting, the app cannot be used. Push notifications are explained there and can be turned off in the device settings at any time. Full notices: Parent App Privacy Notice and Staff App Privacy Notice.

5.8 Whose data the platform may contain

• Children at the centre
• Parents and carers
• Centre staff
• Users of operator accounts, including invited users
• Authorised collection persons
• Applicants for a childcare place (children and parents)
• Invoice recipients for membership fees; payers of parent payments (only with a bank connection)
• Participants in recorded parent meetings
• Recipients of email copies and forwarded messages

5.9 Lawful basis for Centre Data

The Customer, as controller, decides and is responsible for the lawful basis of Centre Data. Depending on the processing, this can be the childcare contract with parents (Article 6(1)(b) UK GDPR), a legal obligation of the centre (Article 6(1)(c) UK GDPR, for example the daily attendance record required by the EYFS in England), the centre's legitimate interests (Article 6(1)(f) UK GDPR) or consent (Article 6(1)(a) UK GDPR, for example for optional photos, recorded parent meetings and push notifications). For special category data such as allergies, the centre also needs a condition under Article 9(2) UK GDPR and, where that condition requires it, under Schedule 1 to the Data Protection Act 2018. Using the parent app is voluntary; the attendance record kept at the centre is not optional where the centre's legal duties require it.

6. Who receives personal data

We disclose personal data only:

• to service providers who help us run the website and the platform, under written contracts that limit their use of the data (for Centre Data: sub-processors under Article 28 UK GDPR)
• to recipients the Customer chooses (for example the meal supplier, see below)
• when the law requires it, or to protect rights, safety and security
• with your consent
• to a successor in a merger, acquisition or sale of assets, subject to this policy [OPEN: keep this clause?]

Platform (UK customers). The sub-processors and locations below are the same as for our service in Germany. [OPEN: confirm which provider entities contract with Triple Peak for the UK; the DE AVV names Google Ireland Ltd. and Apple Distribution International Ltd. as contracting parties.]

The full list with the data each provider receives is in the DPA. Push providers receive data only if the person allows notifications on their device. Message content passes through them in transit and is not stored there; device tokens are kept by them while the token is valid.

Website and our own business.

For the web app we use Vercel's web analytics: aggregated page statistics, without cookies. We do not use tracking or advertising tools in the platform.

Meal supplier. If the optional supplier access is turned on, the meal supplier named by the operator can see meal notes (including allergy and diet information). The supplier is a recipient on the Customer's instructions, not our sub-processor.

Bank connection (optional). [OPEN: available in the UK? DE provider is Qonto] If a centre connects its own bank account, Beenest reads transactions there, read-only and on the centre's instructions, to match parent payments. The bank is the centre's contracting party, not our sub-processor. The payer's name and account details are fetched but not stored; only the reference, amount and booking date of incoming payments that are or should be matched, and of outgoing payments the centre assigns to an occasion, are stored. All other transactions are discarded.

7. International transfers

Core data stays in the EEA. For UK customers, Centre Data is stored in the European Economic Area: databases, application hosting, error monitoring and Cloudflare KV in Frankfurt (Germany), our mailbox in the Netherlands, and technical and feature emails (Brevo) hosted in France and Germany and stored in Belgium. Transfers from the UK to the EEA are covered by the UK's adequacy regulations for the EEA.

Transfers outside the UK and the EEA. Some data flows go to, or can be accessed from, countries without UK adequacy regulations, in particular the United States:

• push notifications (Expo, Firebase Cloud Messaging, Apple Push Notification service) and wallet passes (Google Wallet), which the iOS and Android platforms require;
• optional AI image generation on Google's global endpoint (Section 5.4), which receives only image descriptions without personal data, and with the image generator's non-EU model also your free text and reference images;
• published centre websites, delivered through Cloudflare's global network;
• possible access by US parent companies of our providers (Supabase, Vercel, Sentry, Google, Cloudflare);
• beenest.co hosting and contact form (Netlify), and Google Analytics and the Meta Pixel if you consent;
• access by Beenest itself, which is established outside the UK [OPEN: from which countries does Triple Peak access Centre Data (support, operations)?].

For these transfers we rely on the UK Extension to the EU-US Data Privacy Framework where the recipient is certified under it, and otherwise on the International Data Transfer Agreement (IDTA) or the UK Addendum to the EU Standard Contractual Clauses. [OPEN: confirm the mechanism per provider. The DE AVV relies on the EU-US Data Privacy Framework and the EU SCCs (Vercel, Google, Cloudflare, Sentry, Expo; SCCs only for Supabase) and on Apple's EU-US DPF certification for APNs, for which Apple offers no SCCs. UK Extension certification, IDTA or UK Addendum per provider is not documented in the sources. Same question for Netlify, Google Analytics, Meta and Triple Peak's own access.] You can ask us for a copy of the relevant safeguards using the contact details in Section 14.

The core product needs none of the push, wallet, image generation or website flows. The centre can switch off AI features, and push notifications only run if the person allows them on their device.

8. Cookies and similar technologies

Website. Under PECR, we store or read information on your device only where it is strictly necessary for a service you asked for, or with your consent. Your cookie choice is stored in your browser's local storage (strictly necessary, always active). Analytics and marketing cookies are set only after you agree. You can change your choice at any time with the "Cookie Settings" button on the pages that show the banner; withdrawing consent deletes the related cookies and reloads the page.

Platform. The web app uses only strictly necessary cookies and similar storage (for example session management and authentication). It uses no tracking or marketing cookies.

9. How long we keep personal data

Website and business data (Beenest as controller)

• Website server logs: up to 30 days.
• Contact form and enquiry data: as long as needed to handle your request, then deleted, unless the law requires longer retention or you become a customer.
• Google Analytics data: 14 months, then deleted automatically.
• Meta Pixel data: under Meta's retention policies.
• Cookie choice: in your browser's local storage until you clear it or change your settings.
• Account (registration) data: for the term of the contract plus 30 days after termination (data export period).
• Billing records: [OPEN: retention period for billing and tax records]

Centre Data (Beenest as processor)

We keep Centre Data only as long as needed for the purposes or as long as the Customer instructs. In particular:

• Attendance data (drop-off and collection times): the centre may have to keep attendance records under its regulator's requirements. In England, the EYFS requires a daily record of the children cared for, their hours of attendance and their key person, and requires records about individual children to be kept for a reasonable period after they leave, which each provider decides. That duty is the Customer's. We store the data on its behalf as long as it decides and at most until the contract ends. Before that, the Customer can export all data; afterwards we delete it (see the DPA).
• Discarded check-in actions: deliberately kept after the person concerned is deleted or archived (documented retention so terminal actions can be traced). They are deleted or returned with the rest of the contract data.
• Platform server logs: at most 90 days, unless there is a security incident.
• Internal staff chat: deleted automatically after the retention the centre chooses (1 to 7 days, default 1 day), at midnight in the centre's time zone; this includes automatic notices in the chat. Pinboard messages are exempt and stay until removed manually or the contract ends.
• Group reports, daily reports and incident notes (free text): as long as the Customer keeps them or the contract lasts.
• Child notes, child photo, parent contact details on the child record: as long as the child record exists or the contract lasts; the child photo is deleted when the permission is withdrawn.
• Consent requests by email: recipient address and link hash are deleted on confirmation, when replaced by a new request, or at the latest about one hour after the one-hour link expires; unconfirmed requests after 30 days. Confirmed requests remain as proof. The send log of permission and recording requests stays until the centre deletes it, at most until the contract ends.
• Consents to recording a parent meeting: unused ones after 30 days, with the image of the signature; used ones stay with the meeting until the centre deletes it.
• Enrolment portal applications: unconfirmed after seven days; rejected or withdrawn ones twelve months after closing.
• Failed password attempts: hashes after about one hour.
• Bank transactions (with a bank connection): reference, amount and booking date of stored transactions as long as the Customer keeps them or the contract lasts; name and account details never. Incoming payments the centre sets aside keep only the transaction ID and amount, so they are not imported again.
• Send log to parents: as long as the Customer keeps it or the contract lasts.
• Poll votes: with device ID, as long as the poll or the contract lasts.
• The software's own error logs: including a person ID in the error context, as long as needed to fix the error or the contract lasts.
• AI features: Autopilot and rota AI history after the period the centre chooses (1 to 7 days, default until the end of the calendar day), then deleted automatically; translations at most 30 days (only the translation, not the original); help chat, DPA chat, operator Autopilot and staff app AI helper are not stored. Confirmed Autopilot actions, rota AI changes, daily analyses and monthly reports as long as the Customer keeps them or the contract lasts. Email drafts, parent meeting reports and recording consents until the centre deletes them, at the latest when the contract ends. A usage record without content per AI call (for AI credits) until the contract ends. Voice recordings never permanently. At Google only on suspected abuse, up to 90 days (see 5.4).
• Dictation audio: used only for transcription and never stored; only the transcribed text in the daily report, as long as the Customer keeps it.
• Error reports (Sentry): technical events without chat, prompt or audio content and masked session replays, limited to the retention configured at Sentry in the EU region Frankfurt.

After the contract ends, Centre Data is deleted or returned, as the Customer chooses, within 30 days (see the DPA). The Customer is responsible for meeting its own record keeping duties before deletion.

10. Security

We use appropriate technical and organisational measures under Article 32 UK GDPR, including:

• Encryption: TLS 1.2/1.3 for every transfer (HTTPS only, no unencrypted interfaces), AES-256 at rest.
• Access control: role-based access and authentication; tenant separation at database level through row-level security on every table. Operator accounts (including invited users) see and edit the data of the centres assigned to that operator, not of other operators.
• Availability: regular backups, redundant infrastructure, DDoS protection.
• Pseudonymisation: child codes instead of names in the parent app; the web app can optionally be run with pseudonyms (initials instead of full names) for children and staff. For more options, contact hello@beenest.co.
• Review: regular security audits and evaluation of the measures.
• Website: HTTPS only, restricted and authenticated administrative access, collecting only what is needed, and no tracking scripts before consent.

Personal data breaches. If a personal data breach affects Centre Data, we notify the Customer without undue delay and at the latest within 24 hours after we become aware of it, so the Customer can meet its duty to report to the ICO within 72 hours under Article 33 UK GDPR and, where required, to inform the people affected. Detailed security measures are available on request.

11. Children

Beenest is not directed at children, and children do not use it. Information about children is entered by the centre or by parents, as part of the care relationship between the centre and the family, and children are data subjects, not users. The web app is used by centre staff and operators, the parent app by parents and carers, and the staff app by employees. We therefore do not consider Beenest an online service likely to be accessed by children within the meaning of the ICO's Age appropriate design code (Children's code). [OPEN: confirm that children never operate the check-in terminal or other parts of the platform themselves, for example in out of school clubs or school settings]

Photo and video documentation of children is not a core feature of Beenest. A photo of a child for recognition exists only with the parents' permission "Photo of the child on the centre's devices", and it is not processed with AI. Meeting recordings exist only with prior consent and only until they are analysed. We do not process biometric data such as facial recognition or fingerprints [OPEN: confirm].

12. Your rights

Under UK GDPR you have these rights, subject to the conditions and exceptions in the law. Parents and carers can exercise them on behalf of their child where the law allows.

• Access (Article 15): to get confirmation whether we process your personal data and a copy of it.
• Rectification (Article 16): to have inaccurate or incomplete data corrected.
• Erasure (Article 17): to have your data deleted, subject to legal retention duties (for Centre Data, those of the centre).
• Restriction (Article 18): to have processing restricted.
• Data portability (Article 20): to receive data you gave us in a structured, commonly used and machine-readable format.
• Objection (Article 21): to object to processing based on legitimate interests, and at any time to direct marketing.
• Withdrawing consent (Article 7(3)): at any time, for example with "Cookie Settings" on the website. Withdrawal does not affect processing before it.

Data we control. For data in Section 2, email [privacy contact email] or hello@beenest.co, or contact our UK representative. We respond within one month; where the law allows us to extend this because a request is complex or one of many, we will tell you why within the first month. We may ask you to confirm your identity, for example by replying from the email address of your account or your enquiry.

Centre Data. If you are a parent, carer, staff member or other person whose data a centre entered in Beenest, the centre is the controller and decides about your request. Please send it to the centre. If you send it to us, we forward it to the centre without undue delay and support the centre in answering it, as the DPA requires.

13. Complaints

If you are unhappy with how we handle your personal data, please contact us first so we can try to put it right. You also have the right to complain to the Information Commissioner's Office (ICO), the UK supervisory authority for data protection (ico.org.uk). [OPEN: check whether the ICO has been replaced by the Information Commission under the Data (Use and Access) Act 2025 by the effective date] Complaints about Centre Data are best addressed to the centre first.

14. Changes and contact

We may update this policy from time to time. The current version is always available at beenest.co/uk/privacy. We will announce material changes on the website and, for Customers, by email or in the software [OPEN: confirm notice method for Customers].

Triple Peak Software Systems, [registered address]
Privacy requests: [privacy contact email]
UK representative: [OPEN: UK representative name and address]
General questions: hello@beenest.co

Related documents: Terms of Service, Data Processing Agreement, Parent App Privacy Notice, Staff App Privacy Notice.