Parent account privacy notice candidate.

1. Proposed controller and scope

The proposed controller would be ECOMMERCE ONLINE LTD, company number 12568562, registered office 27 Old Gloucester Street, London, United Kingdom, WC1N 3AX, trading as How2Revise. This candidate covers an adult site visitor or parent account, the account's one subordinate pupil profile and related subscription, support, safety and security processing. It does not appoint or claim a data protection officer.

2. Proposed information categories and sources

• Adult account: email address, password verifier, verification/recovery state, account settings, agreement records and security events supplied by the adult or generated by the service.
• Pupil profile: profile name, the parent's 13–16-at-creation declaration, selected UK nation, protected PIN, accessibility choices and method-progress records supplied through the parent and pupil journeys. No date of birth or continuing age tracking is proposed; the same non-replaceable profile may continue as that pupil gets older.
• Revision use: method choices, session outcomes, return timing, guidance level and limited first-party reliability/safety records—not a marketing profile.
• Real scan, if separately approved: one locally protected image derivative, pupil assent and parent-authorisation version, closed classification and safety/uncertainty result. A full OCR library or ordinary raw transcript would not be retained by How2Revise.
• Billing: Stripe customer, checkout, subscription, invoice and payment-status references. Stripe would receive card details; How2Revise should not receive a full card number or card security code.
• Support, complaints and safety: the message and minimum evidence a person chooses to provide, access/audit records and the resulting decision.
• Technical security: network, browser, request, authentication, rate-limit, error and abuse-prevention information generated when the service is used.

The proposed service would not require the pupil's own email, legal name, exact date of birth, school, home address, phone number or precise location. It would not buy pupil data from a broker or build an advertising profile.

3. Proposed purposes and working lawful-basis hypotheses

• Adult account, checkout and subscription: steps requested before and performance of the adult contract.
• Pupil profile and revision method: a child-best-interests legitimate-interest hypothesis, subject to a completed balancing assessment and the final age/authority analysis.
• Security, fraud prevention and service integrity: legitimate interests and any applicable legal obligation, with minimised logs and no pupil profiling.
• Finance and legally required records: legal obligation and contract administration.
• Optional adult public-page analytics: consent, never bundled with purchase and never enabled in the pupil, scan or revision space.
• Safety or sensitive information unexpectedly provided: a separately documented legal basis and, where needed, UK GDPR Article 9 or Data Protection Act condition.

These are drafting hypotheses, not concluded legal opinions. The final notice must match each real purpose to an approved basis and explain whether information is required for a contract or law and what happens if it is not supplied.

4. Parent and child roles

The adult would own the account and billing relationship; the pupil's information and data-protection rights would still belong to the pupil. The parent view would show suitable method progress and settings, not every answer, ordinary AI exchange or safety disclosure by default. A competent child could exercise a right directly where appropriate. Read the separate child privacy candidate.

5. Proposed recipients and providers

Minimum information could be handled by authorised How2Revise personnel and assessed providers for hosting/database, transactional email, payments, error/security monitoring and the narrow image-classification task. Professional advisers, insurers, auditors, regulators, courts, police, social care or emergency services could receive information only where lawful and necessary. The final notice must name important providers and link to a current subprocessor record where transparency requires it.

6. International transfers

Some proposed providers may process information outside the UK. Before any account or scan opens, the processor contract, subprocessor locations, UK adequacy status or approved contractual safeguard and transfer-risk assessment must be recorded and explained in an accessible form. This candidate does not claim that those checks are complete.

7. AI and real-image boundary

A future provider would receive only the protected image needed to suggest a revision-method route, with application-state storage disabled where supported. Provider abuse-monitoring and child-safety retention may still apply and the exact treatment is not approved. No pupil input or output could be used for general model training under the proposed design. The approved notice must state the exact provider, model category, retention, processing location, training restriction and deletion limits rather than saying information is simply “not stored”.

8. Proposed retention and deletion

Account identity, pupil profile, progress, agreement, billing, security, complaint and safeguarding records need different purpose-based schedules. A future image should exist only for the shortest tested processing period. Provider and backup deletion must finish before the service reports final erasure. Finance, contract, safety or legal-hold records may require restricted retention after account closure.

The exact periods remain provisional and require privacy, safeguarding, legal and accounting approval. The final notice must give intelligible periods or criteria that match the database, provider and backup implementation.

9. Proposed rights and choices

Depending on the circumstances, an adult or child may ask for access, correction, deletion, restriction or portability; object to legitimate-interest processing; withdraw consent; and complain. Identity checks would be proportionate and would not disclose pupil information to the wrong person. Withdrawing optional analytics would not affect the account or cancellation. A child would not be forced through an unsafe parent to ask for help.

The privacy address is delivery-tested, but monitored human handling is not yet verified, so the public email route remains closed. Write to ECOMMERCE ONLINE LTD, 27 Old Gloucester Street, London, United Kingdom, WC1N 3AX, marked “Privacy”, with only the minimum information. Future authenticated export, correction and deletion controls remain closed.

A person can also complain to the Information Commissioner's Office.

10. Automated decisions and human review

The proposed revision classifier would suggest a route, not make a legal or similarly significant decision about a pupil. A pupil could correct it, choose the manual path, report an output and ask for human review. Safety automation would support—not replace—trained human judgement. The complaints and human-review candidate shows the proposed route, but staffed operation is not yet verified.

11. Security and breach handling

The proposed service uses minimisation, role separation, protected credentials, restricted provider keys, rate limits, redacted logs, tested deletion and incident response. No system can promise perfect security. The final notice and security-reporting processmust match the independently tested service and named incident owner before activation.

12. Changes and approval still required

The final notice must have an effective date, immutable archive and fair material-change notification. A new purpose or incompatible use would require a fresh legal analysis and, where required, a new choice or agreement. Provider terms, transfers, lawful bases, retention, parent visibility, rights handling and four-nation child rules remain unresolved. This candidate cannot be accepted as part of an account policy bundle.