Privacy Policy

Quick summary

Tasks4Access is a family app-restriction and task-approval product: a parent chooses tasks and which apps stay restricted on a child’s paired device, and restrictions lift once the parent reviews and approves completed work. We collect the account, family, task, device and billing information needed to run that service, we never sell personal data, we don’t read messages or private on-device content, and a parent can delete the account and associated data at any time. The rest of this page explains exactly what we collect, why, and for how long – including the specific technical detail Android and iOS require us to be precise about.

Who we are and how to contact us

Tasks4Access (“we”, “us”, “our”) operates the Tasks4Access mobile app and website (together, the “Service”) and is the data controller for the personal data described in this policy. The Service is operated by Tasks4Access Ltd, a private company limited by shares registered in England and Wales (company number 17481457). Registered office: 30 Bath Road, Middlesbrough, TS6 9PH, United Kingdom. For any question about this policy, to exercise a data protection right, or to raise a concern, contact us at info@tasks4access.com or via our Contact page – this is our primary and fastest channel for privacy requests. We have not appointed a Data Protection Officer; the contact above is responsible for privacy requests.

Scope of this policy and roles within a family account

A parent creates and controls the Tasks4Access family account using their own name, email address and password. A child does not have an independent login, email address or password of their own – their device is connected to the family account through a secure device-pairing process that only a parent can initiate, and the app treats the parent as responsible for the child’s profile and settings within that family account. Where this policy refers to “you”, it means whichever of these roles applies to the reader; where the distinction matters, we say “parent” or “child” specifically.

Information we collect, and where it comes from

• Account information you provide when a parent registers: name and email address. Passwords are stored as a salted hash, never in a reversible or plaintext form.
• Child profile information a parent enters when adding a child to the family account, such as the child’s display name (a nickname is fine) and a chosen avatar. We also store the avatar’s appearance settings (gender, age group, skin tone, hair colour and style, and eye colour). A child does not enter this themselves.
• Family, task and approval data created within the product: task descriptions, which apps a task restricts, approval/rejection status, and reward or access periods. If a parent marks a submitted task “Needs More Work”, the short written explanation they give is stored temporarily – see “Temporary task feedback” below.
• Device and app-restriction data needed to enforce restrictions, which differs by platform – see “Android-specific data” and “iOS-specific data” below for the exact technical detail.
• An app-generated device identifier (a random identifier created by the app itself, not your device’s IMEI, Android ID, hardware serial number, or advertising ID) used to recognise a paired device to our servers.
• A push-notification device token for each parent and child device that has notifications enabled, used only to deliver notifications to that device – see “Push notifications” below.
• An optional photo a child may attach when handing in a task, to show it is done – see “Optional task-completion photos” below.
• A short activity record of actions in a family account (for example “task approved”), kept so we can investigate problems and resolve disputes. It contains numbers and event types, not names or task titles.
• Subscription and billing information, handled by Apple (subscriptions bought in the iPhone app), Google Play (subscriptions bought in the Android app) or, for a small number of existing accounts, our payment processor Stripe – see “Payment and subscription data” below. We do not collect or store your full card details ourselves.
• A free-trial and free-month record: to stop the same person starting the free trial, or taking a partner-referral free month, more than once, we keep a one-way fingerprint (a hash) of the email address and the date it started. A +tag or dots in a Gmail address are ignored when the fingerprint is made, so a variation of an address counts as the same person. For a referral free month we also keep the store’s reference and the dates of the offer. These are kept even after an account is deleted, for that purpose only.
• Device health details for each paired device: its name, the operating-system and app versions, and protection-status indicators (for example whether protection is switched on, or has been disabled or tampered with), so a parent can see at a glance whether a device is protected.
• Family settings you choose, such as saved chores (including pictures from our built-in chore set) and the apps you mark as always allowed.
• Messages you send us through our contact form (your name, email address, subject and message), used only to reply to you.
• Waitlist information if you joined our waitlist (now closed) – see “Waitlist and marketing emails” below for exactly how this is collected and by whom.
• Partner-programme information if you apply to, or enquire about, our Partner Referral / Fundraising Programme – see that dedicated section below.
• Rate-limiting data used transiently for security: to slow down abuse of login, pairing and account-deletion endpoints, we briefly track attempt counts keyed by IP address and/or device identifier in a rolling, short-lived counter. This is not stored as a persistent per-person profile and is not used for any other purpose.

What we do not do

Tasks4Access does not read the content of messages, browsing history, or other private in-app content on a connected device. We do not request or use location access anywhere in the app. We use only the device permissions required to enforce app restrictions and report device/app status, and we describe the exact scope of those permissions below rather than asking you to take our word for it.

Android-specific data: installed apps and foreground-app detection

On Android, app restrictions are enforced using an Accessibility Service, which Google requires us to disclose precisely because the underlying Android API is broad. Here is exactly what our implementation does and does not do with it:

• Installed-app inventory. We read the list of launchable apps installed on a paired Android device (each app’s name, its package identifier, and a small icon thumbnail from the operating system, not a personal photo) so a parent can choose which apps to restrict. This is scoped to apps that expose a normal home-screen launcher entry point – not an unrestricted enumeration of every package on the device.
• Foreground-app detection. While the Accessibility Service is enabled, it detects which app is currently in the foreground on the device so the app can decide, on the device itself, whether to show a lock screen for a restricted app. To make this decision the service reads the foreground app’s package name, and it never reads on-screen text, images, keystrokes, or any other window content. The decision happens locally on the device; we do not keep a server-side history of which apps a child opened or when.
• The Accessibility Service is declared as an enforcement tool, not an assistive technology, and does not claim the broader access-for-disability purpose Android’s Accessibility API is designed for. Even though the underlying Android permission technically allows reading on-screen window content, our code never reads on-screen text, images or keystrokes. To do this reliably, the service listens for window-change events and checks which window is in the foreground at short intervals, but it reads only two things: the foreground app’s package name and the technical class name of the window (not what is shown in it).
• Tamper detection. The window class name is used only to recognise Android’s Accessibility and Device Administrator settings screens. If the child opens one of them, the app can report a tamper attempt to our servers (that it happened, when, and which of the two screens it was) so that a parent can be told that protection may have been switched off. If a removal PIN has been set for the child, the app asks for it first.
• Optional Device Administrator permission. The app can offer an optional “Enable extra protection” step that makes the app a device administrator on the child’s device. It requests no device-management policies; its only effect is that Android requires it to be switched off before the app can be uninstalled. It is not needed for the app to work.
• Removal PIN. A parent can set a removal PIN for a child. We store it on our servers only as a hash (a one-way scramble), never as the PIN itself.
• Install referrer. On Android the app reads the Google Play Install Referrer once, when it starts, to pick up a partner referral code if you installed the app from a referral link. Only a well-formed public referral code is kept. It is held in the app’s secure storage on the device for up to 30 days, until a parent registers, so the sign-up can be credited to that partner.
• Before this permission is requested, the app shows an in-the-moment, plain-language explanation of exactly this scope and requires you to actively acknowledge it before you are taken to Android’s own settings screen to enable the service.

iOS-specific data: Screen Time / Family Controls opaque tokens

On iOS, app restrictions are enforced using Apple’s own Screen Time (Family Controls / Managed Settings) system, which is deliberately designed by Apple so that a third-party app like ours cannot see which real apps a person has chosen to restrict. Specifically:

• When choosing apps to restrict, you use Apple’s own system picker. It returns Apple’s opaque, non-reversible “application token” or “category token” values for whatever you selected – Apple provides no API for us to turn these back into a real app name, bundle identifier, or icon.
• These opaque tokens are stored and used only on the device itself, to apply the restriction directly through Apple’s on-device Managed Settings system. The app keeps them on the device and does not send them to our servers.
• Because we cannot see the real app identity, the app asks you to type a short label for each restricted slot (for example, “Games app”) purely so you can recognise your own choice later. Only that label and a random identifier generated on the device – not any Apple-issued token or real app identity – is sent to our servers, so a parent’s dashboard can show the restriction exists.
• iOS authorisation is requested as an individual, on-device authorisation on the child’s own device (this app does not use Apple’s separate Family Sharing “child account” system), and there is no background monitoring extension installed beyond what Apple’s Screen Time framework itself provides.

Families using a mix of Android and iOS devices

Our servers store restriction and inventory data the same way regardless of platform (a display label plus a platform-scoped identifier), so a parent and child on different platforms, or on the same platform, are handled by the same underlying data model. We have not published a dedicated technical walkthrough or exhaustive end-to-end test report of every specific parent/child platform combination, so while we have no reason to expect different data-handling behaviour between combinations, we note this as an area we have not separately documented beyond what is described above.

How we use information, and our legal bases (UK GDPR)

We only use your information for the purposes below, and we rely on one of these UK GDPR lawful bases for each:

• To provide the Service to a parent – account creation, login and subscription. Necessary to perform our contract with you (Article 6(1)(b)).
• To run the family service for a child – a child’s profile, paired device, tasks, app restrictions and optional task photo. The contract is with the parent, so for information about a child we rely on our legitimate interests (Article 6(1)(f)) in running the parental-control service that families ask us to provide. We have weighed this against the child’s interests: we show no advertising, do not profile children, do not use location, do not read messages or other app content, and keep this information to what the service needs and for no longer than it needs it.
• To stop repeat free trials and to keep an activity record – our legitimate interests (Article 6(1)(f)) in preventing abuse and in investigating problems and disputes.
• To process payments and manage subscriptions – necessary to perform our contract with you (Article 6(1)(b)).
• To keep the Service secure and reliable – rate-limiting abusive requests, investigating suspected fraud or misuse, and maintaining service integrity. Based on our legitimate interest in operating a secure service (Article 6(1)(f)), balanced against your interests in not being over-monitored – which is why this data is minimal and short-lived, as described above.
• To send account and transactional communications (verification, password reset, billing and product notices related to your account) – necessary to perform our contract with you (Article 6(1)(b)).
• To send waitlist/marketing product updates, and to enable optional push notifications – based on your consent (Article 6(1)(a)), which you can withdraw at any time as described below.
• Partner-programme processing – see the dedicated legal-basis note in that section below.

Parental authority and children’s data

A child’s profile, task data, and device-restriction data are set up and controlled by their parent as a family arrangement – a child does not have their own account, sign up separately, or buy anything. We do not treat a parent’s set-up as the child’s “consent” under data protection law; our basis for children’s information is described under “How we use information” above. Because the parent is the family account holder, requests to access, correct, or delete a child’s data (or the whole family account) normally come from a parent on that family account, as described in “Deleting your account” below.

If you are a child or young person: this app was set up by your parent. Your parent can see your tasks, whether protection is switched on and, on Android, the list of apps on your phone so they can choose which ones to lock. They cannot see your messages, your browsing or where you are. A photo you choose to attach goes only to your parent and is deleted as soon as they say yes or no to your task. You can ask us a question, ask what we hold about you, or ask us to remove something, through our Contact page – tell us it is about a child account and we will reply in plain language. Because a parent is responsible for a child’s account we may need to check with the account holder, and we will take your wishes seriously. Disagreements between family members about who may see or control information are family matters we cannot decide for you.

Optional task-completion photos

When a child hands in a task, they may choose to attach a photo to show it is done. It is always optional. The photo is sent over an encrypted connection and stored privately on our servers, not on any public web address. Only the logged-in parents of that child’s family can view it, and only while the task is waiting to be reviewed. We remove location and device details embedded in the photo when we receive it. We delete the photo when the task is approved, sent back, cancelled or withdrawn, and if the child or the whole family account is deleted. We never use photos for anything except letting a parent review that task, and never share them with anyone else. Please do not photograph other people’s faces or anything private.

Authentication and email

Logging in uses your email address and password (or, on a paired child device, a device-scoped session set up by a parent during pairing – not a separate email/password login for the child). Account, verification, password-reset, and partner-programme transactional emails are sent through our hosting provider’s own outbound mail service, not a separate third-party marketing email platform. Session, pairing, and password-reset tokens are stored in hashed form, not as reusable plaintext secrets, and are revoked when you log out or your account is deleted.

Push notifications

Tasks4Access delivers push notifications through Firebase Cloud Messaging (FCM), a service provided by Google; on iOS devices, Firebase in turn relies on Apple’s Push Notification service (APNs) to reach the device, which is how Firebase delivery works on iOS generally. When a parent or child logs in on a device, that device registers a push token with our servers, linked to that person and that device within your family account. We use this token only to deliver notifications relevant to that person – for example: a task has been assigned to a child, a child has submitted completed work for a parent to review, a parent has approved a task, a parent has marked a task “Needs More Work”, or a device’s protection has been disabled and needs re-enabling. Every notification is a short, generic preview – it never contains task-feedback text or other private task content, which is only ever visible after opening the app. Google/Firebase (and, for iOS delivery, Apple) process the token only to route the notification to the correct device and do not receive the notification’s private content from us beyond what is in the generic preview. When a device is unpaired or removed, when the account logs out, or when the account is deleted, that device’s push token is deactivated at once and permanently deleted about 30 days later. Push notifications are optional – declining them never blocks any task, approval, or pairing functionality.

Payment and subscription data (Apple, Google Play and Stripe)

Subscriptions bought in the iPhone app are billed by Apple. Apple handles the payment and the cancellation. We receive from Apple a transaction reference, the plan, the subscription status and dates, and an anonymous account token generated by the app so the purchase can be matched to your family account. We never receive your card details or Apple ID.

Subscriptions bought in the Android app are billed by Google Play. Google handles the payment, the cancellation and any refund. We receive from Google a purchase token and order reference, the plan, the subscription status and dates, and an anonymous account identifier generated by the app so the purchase can be matched to your family account. We never receive your card details or Google account password. We keep these references for as long as your subscription and account exist and for financial record-keeping afterwards, as described in “Deleting your account” below.

A small number of existing accounts are billed by Stripe, our payment processor. When such an account subscribes, Stripe creates a customer record and we store a reference to it (a Stripe customer ID) together with the subscription and billing status (for example, which plan, whether the subscription is active, past-due, or cancelled, and the current billing period). We do this so the app can reflect the account correctly. This also lets support help if something goes wrong. Tasks4Access does not collect or store your full card number or other full card details – these are entered directly into Stripe’s own secure checkout and billing-portal pages and are never seen by our servers. Stripe retains payment and billing records as required for its own regulatory, fraud-prevention and accounting obligations, independent of Tasks4Access. Stripe is a US-headquartered company, so this necessarily involves an international transfer of billing information to Stripe – see “International data transfers” below.

Waitlist and marketing emails

Our public waitlist closed when the apps launched in November 2026 and the form is no longer on our website. While it was open, it submitted your email address directly to Brevo, our email marketing platform, rather than through our own servers. Brevo used a double opt-in process, meaning you received a confirmation email before you were actually added to the list. If you completed that process, your email address is stored with Brevo so we can send you product updates you opted in to receive. You can unsubscribe at any time using the link in any email we send, and Brevo is a processor acting on our instructions for this purpose only – your waitlist email address is not used for anything beyond the updates you opted into.

Partner Referral / Fundraising Programme

This section covers information specific to the Partner Referral / Fundraising Programme. It applies in addition to the rest of this policy.

• Partner applications. When you apply to become a partner, we collect the information you submit on the application form: your name, partner type, contact email, contact phone (optional), approximate audience size (optional), and a preferred referral code (optional). Which other fields are required depends on your partner type. If you apply as an individual creator, your website or social profile URL and how you intend to promote your referral link are both required, so we can review your public presence. If you apply on behalf of a school/PTA, club, charity, or other organisation, your organisation name, your role (for example “Treasurer”), and how you intend to promote your referral link are all required; your website is optional unless you are applying as a Charity, in which case it is also required. A charity registration number is required only if you apply as a Charity, and is used to verify your charity before your referral link goes live. We never collect bank or payment details as part of an application.
• Charity partnership enquiries. If you send a “discuss a charity partnership” enquiry before formally applying, we collect only what you submit on that shorter form: organisation name, charity registration number (optional at this stage), your name, your role (optional), contact email, approximate audience size (optional), and your message (optional). An enquiry does not create a partner application and is not automatically turned into one – it is used only to reply to your question by email.
• Referral tracking. Your referral link and code are not secret and are designed to be shared. When someone visits your referral link, we resolve the code and issue a single-use, non-guessable visit token so a resulting sign-up can be attributed to you; this token is stored only in hashed form, and we deliberately do not record the visitor’s IP address or browser/device details against it (see “Referral links” below for exactly what a link visit records).
• Sharing activity. When you use the sharing tools in your partner dashboard (for example to copy a message or a link), we record which partner it was, the kind of action, the message template and the channel, so the dashboard can show which messages work. No visitor or customer details are involved.
• Report/dashboard authentication. Partner reporting access (/partner/report) is passwordless: you request a one-time login link by email, which is single-use and expires after 15 minutes. Once used, it sets a secure, HTTP-only session cookie (scoped only to the reporting page) valid for 30 minutes; the underlying token is never exposed in the address bar, stored in the page itself, or accessible to page scripts.
• Commission and payout records. We keep a record of each commission calculated for you (the qualifying payment, the rate applied, and the resulting amount) and, once a payout is made, an external bank-transfer reference and date. We do not store your bank account details in Tasks4Access – payout details are verified and arranged with you directly, outside this system, before a transfer is made.
• Separation from family/user data. Partner reporting shows only your own aggregate totals (visit counts, sign-ups, paying referrals, and earnings). A partner never sees a referred family’s name, email address, or payment details, and a parent/family account never sees who referred them beyond having entered a referral code themselves.

Legal basis for processing. We process partner application and programme data because it is necessary to consider your application and, if approved, to perform our Partner Agreement with you (tracking referrals, calculating and paying commission, and giving you reporting access). Fraud and abuse prevention around referral codes (for example, rate-limiting) is based on our legitimate interest in keeping the Programme working correctly for genuine partners.

Retention. We retain partner application and commission/payout records for as long as your partner status is active and for a reasonable period afterwards, as needed for our own financial record-keeping and legitimate business or legal purposes (for example, audit trail of commission calculations and payments already made). A rejected or withdrawn application is retained only long enough to prevent duplicate pending applications and for our own records.

Partner data-subject rights. If you are a partner, you have the same rights described in “Your rights” below over your own partner application and account data. Note that a completed commission or payout record forming part of our financial history cannot always be deleted on request while still needed for legitimate accounting purposes, but you can always ask us to stop future referral tracking by asking us to suspend your partner status.

Cookies and website analytics

tasks4access.com uses Google Analytics 4 to count visits and understand which pages are useful, but only if you accept it in the banner shown on your first visit. Until you accept, no Google Analytics script is loaded and no analytics cookie or identifier is set; if you decline (or ignore the banner) it stays off. Your choice is remembered in your browser’s local storage and you can change it at any time: change my analytics choice. When enabled, Google Analytics collects pages viewed, approximate location and device/browser type using an analytics cookie, with IP anonymisation switched on; Google acts as our processor and may process this outside the UK (see the transfers section below). We do not use Meta/Facebook Pixel or any advertising or cross-site tracking script. The only other cookie our own website code sets is the secure, HTTP-only partner-report login session cookie described above, scoped only to the partner reporting page. Our website is built on WordPress hosting, which may set its own strictly necessary technical cookies (for example, to keep the site working correctly); we do not use these for tracking or advertising purposes.

After you accept analytics, our website also sends landing-page views, button clicks and any campaign labels in the address (utm_source, utm_medium, utm_campaign and utm_content) to our own API (not to Google), together with a random identifier that is kept in your browser’s session storage for that tab only. Nothing is sent, and no such identifier is created, until you accept. Separately, the help chat keeps your conversation in your browser’s session storage for that tab, and it is cleared when you close the tab.

Referral links. When you open a partner’s referral link (tasks4access.com/refer/…) we record which partner’s code was opened, when, any campaign labels in the link (for example utm_campaign), and a one-way, day-rotating hashed visitor key with a flag for automated/link-preview traffic. This is used only to count unique visitors and attribute a later sign-up to the right partner. We do not store your IP address or your browser’s identification string for this purpose, and we set no cookie for it. The same applies to partner applications reached from an outreach link: only the validated campaign labels in the link are kept.

The app. The Tasks4Access app does not collect analytics by default. Usage analytics (Firebase Analytics on the parent side) are switched off unless enabled with your consent, and are never enabled for child devices. Once a parent has given analytics consent, the app can also send simple funnel events to our own API (for example, that account creation was started), with a random identifier that exists only while the app is open and is not saved. Separately, our servers record sign-up and subscription milestones (sign-up, trial start, first payment, renewal, cancellation and refund) against the family account, together with any campaign or referral attribution. These come from the sign-up itself and from Apple, Google Play and Stripe payment events, not from the app’s analytics, so they are recorded whether or not analytics consent was given.

Crash and error reports (optional). The app can send crash and error reports to us using Firebase Crashlytics (a Google service). This is off by default: a parent must switch it on under Account → Privacy, separately from usage analytics, and can switch it off again at any time. It is never available on child devices, so a child device never sends reports. A report contains technical information about the problem (the error and where it happened in the app), the device model, operating system and app version, and an app-installation identifier. It does not contain task titles or descriptions, child names, photos, messages or login details, and we limit how often the app can send reports. We use the reports only to find and fix faults, and Google processes them on our behalf as a service provider.

Organisations we contact

To tell schools, parent-teacher associations, clubs, charities and similar organisations about the Service and our partner programme, we collect publicly available contact details from their own websites and public registers. These are the organisation’s name, a contact person’s name and role, a publicly listed email address or phone number, and notes about our contact with them. We rely on our legitimate interests in promoting the Service to relevant organisations. We stop contacting an organisation and delete its details if asked, and review contacts that do not reply. You can ask us to stop contacting you, or to remove your details, through our Contact page.

We also use an artificial intelligence service provided by OpenAI to help us research these organisations. For that we send it the text of publicly available web pages about them. Those pages are public, but a page can name a person, such as a contact person, and we cannot guarantee that every name is removed before the text is sent.

Automated decision-making and profiling

We do not use automated decision-making or profiling that produces legal or similarly significant effects about you. Our rate-limiting described above is a simple, mechanical throttle (a maximum number of attempts in a time window) rather than individualised scoring, and it never automatically suspends or closes an account by itself. The help chat may use an artificial intelligence service only to choose which of our help articles answers a question (see “Website support assistant” below). Separately, an artificial intelligence service helps us research organisations we may contact (see “Organisations we contact” above). Neither makes a decision about you, your account, your subscription or your children.

Data sharing

We do not sell your personal data. We share information only with service providers who help us operate Tasks4Access, and only as needed to provide the Service:

• Stripe – payment processing for a small number of existing accounts (see “Payment and subscription data” above).
• Google / Firebase Cloud Messaging, and by extension Apple’s Push Notification service for iOS delivery – push notification delivery (see “Push notifications” above).
• Google / Firebase Crashlytics – optional crash and error reports from a parent’s device, only if the parent switches them on (see “The app” above).
• Brevo – waitlist/marketing email delivery, for waitlist subscribers only (see “Waitlist and marketing emails” above).
• Apple – App Store subscription billing for iPhone purchases (see “Payment and subscription data” above).
• Google Play – Google Play subscription billing for Android purchases (see “Payment and subscription data” above).
• OpenAI – only if our website help chat finds no matching help article by its normal rules, a small AI service chooses which of our existing help articles best answers your question. We send it the text of your question with email addresses, phone numbers and links removed (and shortened to 300 characters) and a list of our help article titles; we do not send names, email addresses, account details or information we hold about your children, and we ask you not to type names or other personal details into the chat (see “Website support assistant” below). OpenAI is also used for research on organisations we may contact: we send it the text of publicly available web pages about those organisations (see “Organisations we contact” above).
• Our hosting provider – stores our database, files and backups and runs our servers, and acts only on our instructions.
• Our hosting provider’s own outbound mail service – account/transactional and partner-programme email delivery (see “Authentication and email” above); this is not a separate third-party marketing platform.

No data is shared for advertising or cross-app/cross-site tracking purposes with anyone.

International data transfers

Some of the service providers above are based outside the UK – notably Stripe, Google/Firebase and OpenAI, all US-headquartered. Where we transfer personal data to a provider outside the UK, we rely on that provider’s own standard contractual safeguards (such as the UK’s International Data Transfer Addendum or equivalent Standard Contractual Clauses) as part of our agreement with them. We have not independently verified the exact physical server region used by every provider for every data type, so we describe this transfer as arising from the use of these named providers rather than asserting a specific data-residency guarantee beyond what each provider itself publishes.

Security

All traffic between the app and our servers is encrypted in transit (HTTPS/TLS). Passwords are stored as salted hashes, never in plaintext or a reversible form. Session, pairing, and password-reset tokens are stored hashed, not as reusable plaintext secrets, and are revoked when you log out or your account is deleted. We have not independently verified or published a specific statement about at-rest database encryption at the hosting-layer level, so we do not claim that here beyond the transit-encryption practices described above. No method of transmission or storage is 100% secure, and we cannot guarantee absolute security.

Data retention

We retain account and family data for as long as your account is active, and for a reasonable period afterwards as needed for legitimate business or legal purposes (for example, financial record-keeping) – see “Deleting your account” below for what is deleted immediately versus retained. Routine database backups are taken as part of normal operations; a backup taken before data is deleted or before a retention period (such as the 7-day limit described below) expires can still contain a copy of that data as of the backup’s date. We have not yet finalised or published a specific backup retention length or access-control policy, so we cannot currently guarantee erasure from every historical backup within a specific time frame – only that data stops being live and visible in the product once its stated retention period ends or it is deleted from the live database.

In summary: task photos are deleted when the task is reviewed, cancelled or withdrawn (or the child or account is deleted); the “Needs More Work” note is kept for at most 7 days; expired login sessions, reset links and pairing codes are of no further use and are removed on a routine schedule; the push token of a revoked device is deleted about 30 days after it is revoked; the website chat records are described under “Website support assistant” and “Contacting support”; and payment and subscription records are kept for as long as accounting and tax rules require. Messages sent through our contact form (a WordPress form on our website) are used to answer your enquiry and kept for as long as needed for that. We are still setting fixed periods for the short activity record, for the records of push notifications we have sent, and for the free-trial record. Until those periods are set, these records are kept until they are removed by a routine schedule that we are still setting, and we will publish the periods here.

Website support assistant

The “Ask Tasks4Access” help chat on our website answers questions from our own written help articles. It mostly works by matching your question to an article using fixed rules. If those rules find no match, a small artificial intelligence service provided by OpenAI may be used for one limited purpose: to choose which of our existing help articles best answers your question. It does not write the answer. You see the help article exactly as our team wrote it, and the chat tells you when an article was chosen this way.

To do this we send OpenAI the text of your question, with any email addresses, phone numbers and links automatically removed and shortened to 300 characters, together with up to 12 of our help article titles that share words with your question. We do not send your account details, information we hold about your children, or the rest of your conversation. Names and other personal details you type cannot be reliably removed, so please do not type passwords, your child’s name or other personal details into the chat. OpenAI processes this text only to return that choice for us.

When you use the chat we record the questions you type (with any email addresses, phone numbers and links automatically removed), which help topics were shown, whether you said an answer solved your problem, any Android or iPhone choice you made, and a basic device type (desktop, tablet or mobile). We do not store your IP address or browser details in these chat records. The questions and the other records of what happened in the chat are deleted after 90 days. We keep an anonymous record of each chat for statistics: the device type, any Android or iPhone choice, how many questions were asked and whether it was marked as solved. It holds no questions, name, email address or IP address. To limit how often one connection can use the chat, the contact form, email codes or the help-article step, our server keeps a scrambled (hashed) form of your connection address in a small counter file; these files are removed automatically when they have not been used for 7 days. Questions we could not answer may be kept for longer, up to two years, without any link to you, so that we can write new help articles.

Account checks and quick fixes in the chat

If you ask the chat to check your account or fix something for you, we first email a 6-digit code to the address on your Tasks4Access account to check it is you. The code lasts 10 minutes. A correct code lets the chat, for 30 minutes, read the status of your own account (for example whether a subscription is active, when each child device last contacted our servers, and whether notifications can reach your phone) without showing children’s names. Only if you confirm each one, it can also send you a new verification email or create a 6-digit pairing code for a child. A pairing code is shown once on screen and is never emailed. It works for 10 minutes, and we keep only a scrambled copy so your child’s device can use it. That record is removed by our daily clean-up about a day after the code expires. The email address you type to check your account, and the code we send, are kept in scrambled form for up to a day. We keep a short record of each check or action (what was done and the result, never a code) for 90 days.

Contacting support

If you choose “Contact Tasks4Access Support” in the chat, we store the name, email address, message and optional device details you enter, the steps you tried in the chat, and our conversation with you. We email them to our support team (the email also notes your browser and device type). We email you only a reference and a private link to follow the conversation. A member of our team reads and replies to every request; we may use the AI step above to help find the right help article for your message, but a person decides what is sent to you. We delete your name, email address, message and the conversation 12 months after a request is closed. A request nobody has touched for 60 days is closed automatically, without a reply, so that it is deleted too. We also delete requests that used your account’s email address when you delete your account. If you wrote to us from a different email address, ask us and we will find and delete it. Copies of the email we receive are kept in our support mailbox only as long as needed to help you.

Temporary task feedback (“Needs More Work”)

When a parent marks a submitted task “Needs More Work” instead of approving it, they must write a short explanation (up to 300 characters) of what still needs fixing. This explanation is stored only so the child who owns the task can see why it was sent back and correct it. It is never used for any other purpose, and only the child and the authorised parent(s) on that child’s family account can see it.

The explanation stays visible through resubmission and review, because resubmitting the task does not clear it. It is kept live for a maximum of 7 days. It is deleted sooner if the task is approved or cancelled (or the task itself is deleted), and it is replaced the next time the task is sent back with a new explanation. The child is notified of a “Needs More Work” decision by a generic push notification that never contains the explanation text. The explanation is visible only after opening the app, is not stored permanently on your device, and is fetched fresh from our servers each time.

This 7-day limit applies to our live, in-use database. A routine full database backup taken before an explanation is deleted can still contain a copy of it as of that backup’s date. We have not yet finalised how long such backups are retained, so we cannot yet guarantee that this text is erased from every historical backup within 7 days. We can only say that it stops being live and visible in the product within that time.

Deleting your account, and cancelling a subscription

You can delete your Tasks4Access account and associated data at any time, directly from the app (Account → Danger zone → Delete account) without needing to reinstall it, or by request if you no longer have the app. Our Account deletion page explains exactly how, and exactly what is deleted versus retained.

In short, your name, email and password are erased. If you are your family’s only parent, your children’s tasks, devices, app restrictions, saved chores and task photos are deleted too. An empty, anonymised account and family record remains, in a form that no longer shows your name or email. It is kept together with billing/payment history, store purchase references and any referral or partner-commission records (the payment providers keep their own records), for financial record-keeping. The free-trial and free-month fingerprint described above is also kept, so a deleted account cannot be used to start a second free period.

If you are one of multiple parents on a shared family account, deleting your own account removes your own login and access. It does not delete the shared family, children, or their data, since another parent still relies on it.

Cancelling a paid subscription is a separate action from deleting your account. It stops future billing, but it does not, by itself, delete your account or family data. You cancel in your Apple ID’s subscription settings for iPhone subscriptions, in Google Play’s subscription settings for Android subscriptions, or through Stripe’s billing portal for the few Stripe accounts. Deleting your account does not cancel a subscription held with Stripe, Apple or Google Play.

Your rights

Subject to applicable exceptions, you have the right to: request access to the personal data we hold about you; request correction of inaccurate data; request erasure of your data; request that we restrict certain processing; object to processing based on our legitimate interests; and request a portable copy of data you provided to us. You can exercise any of these by contacting us at info@tasks4access.com or via our Contact page. Some data – such as completed financial/commission records described above – cannot always be erased on request while we still need it for legitimate accounting or legal purposes. If you are unhappy with how we have handled your personal data, you also have the right to complain to the UK’s data protection regulator, the Information Commissioner’s Office (ICO), at ico.org.uk.

Withdrawing consent

Where we rely on your consent (for example, waitlist/marketing emails, or push notifications), you can withdraw it at any time – using the unsubscribe link in any marketing email, or by disabling notifications for your device in the app or your device’s system settings. Withdrawing consent does not affect the lawfulness of anything we did with your data before you withdrew it, and does not affect the separate, contract-based processing needed to run your account (for example, transactional account emails, which are not marketing).

Changes to this policy

We may update this policy from time to time, for example as the product changes or to improve clarity. The “Effective and last updated” date at the top of this page reflects the current version. Where a change is material, we will take reasonable steps to make it noticeable, such as an in-app notice or an email to account holders.

Contact us

If you have questions about this policy, contact us at info@tasks4access.com or via our Contact page.