Vivat Lex Web legal information
Privacy policy
Terms, policies and contact details for your use of Vivat Lex Web.
Business details
Trader, controller and contact
Trader and course provider: Stanislav Lynnyk, a sole trader trading as Vivat Lex.
Data controller: Stanislav Lynnyk, a sole trader trading as Vivat Lex.
Geographic business and address for service: 32/1 Tudsbery Avenue, Edinburgh, EH16 4GX, United Kingdom
Business telephone: +447442194285
Email for this document: sqe1practice@gmail.com
The SQE and SOLICITORS QUALIFYING EXAMINATION trade marks belong to the Solicitors Regulation Authority. References to SQE identify the assessment for which Vivat Lex provides independent preparation materials. Vivat Lex is not affiliated with, approved, endorsed or accredited by the Solicitors Regulation Authority.
Who is responsible for your personal information
The data controller for Vivat Lex Web is Stanislav Lynnyk, a sole trader trading as Vivat Lex.
- Geographic business address
- 32/1 Tudsbery Avenue, Edinburgh, EH16 4GX, United Kingdom
- Address for service and controller contact
- 32/1 Tudsbery Avenue, Edinburgh, EH16 4GX, United Kingdom
- Privacy email
- sqe1practice@gmail.com
- Telephone
- +447442194285
This policy applies only to Vivat Lex Web. The iOS and Android products are separate products and contracts. Their accounts, purchases, entitlements, progress and privacy arrangements are not shared with the web product.
Status and factual scope of this policy
This policy describes information processed by the features and providers actually used by Vivat Lex Web. A planned provider, cookie, analytics tool, transfer, automated decision, retention period or security feature is not treated as active merely because it has been planned or tested.
A processing category applies only where the corresponding feature is used and the applicable purpose, lawful basis, recipient and retention information below supports it.
Information that may be processed
| Processing area | Information limited to what the used feature requires |
|---|---|
| Public website request | IP or network information, request time, requested route, basic browser or device information and necessary security logs. |
| Web account and sign-in | Email or approved account identifier, verification and session state, account ID, authentication events and recovery records. |
| Eligibility and country gate | Declared habitual residence, billing country, limited provider location signals, approximate network country and review outcome. |
| Order and payment | Order ID, product, amount, currency, tax result, provider references, payment status, refund or dispute status and limited card metadata such as brand or last four digits where supplied. |
| Entitlement | Web account ID, order link, entitlement status, start or provisioning time, fixed cutoff and revocation or restoration history. |
| Learning activity | Progress, answers, results, saved settings and content or release identifiers used by the web feature. |
| Support and complaints | Contact details, message, order or account references, evidence, outcome, accessibility need and correspondence. |
| Security and misuse review | Authentication, session, request and entitlement signals needed to identify compromise, extraction or malicious activity. |
| Consent and objection records | Policy and notice versions, category choice, timestamp, evidence hash and minimal region-policy state where such a choice exists. |
| Transactional communications | Contact address, message type, delivery or status metadata and relevant order or account reference. |
| Accessibility requests | Functional barrier, preferred format or contact method and only the minimum additional information needed. |
Vivat Lex does not ask for full card data, credentials or unnecessary identity, medical or behavioural information as part of these ordinary categories.
Email addresses, external identity-provider user identifiers, Vivat Lex account, order, receipt, entitlement and session identifiers, IP or network information, security-event records, hashes and opaque handles are treated as personal data wherever Vivat Lex can link them directly or indirectly to an identifiable person.
Hashing, tokenisation, opaque identifiers and other pseudonymisation techniques reduce identifiability and breach impact, but they do not make information anonymous while Vivat Lex or a relevant provider holds the additional information or practical means needed to link it back to a person.
Vivat Lex minimises this information by avoiding unnecessary names and identity documents, keeping payment-card credentials with the payment provider, using random server-side handles, separating linkage information where practicable, restricting access, suppressing sensitive request data from ordinary error monitoring and applying the retention and deletion controls stated below.
Only information that is no longer attributable to an identified or identifiable person using means reasonably likely to be used is treated as anonymous. A label, hash or removal of an email field alone does not establish anonymisation.
Why information may be used
- Contract, where processing is objectively necessary to take requested pre-contract steps or perform the accepted Vivat Lex Web contract.
- Legal obligation, where applicable law requires records, tax handling, consumer responses, sanctions action or data-rights handling.
- Legitimate interests, for a documented, necessary and proportionate interest such as service security, fraud prevention, limited operational records or legal claims, after balancing the individual’s rights.
- Consent, where freely given, specific, informed and unambiguous consent is the appropriate basis, including optional technologies where required.
- Another basis only where it lawfully applies to the verified processing.
Contract is not used for processing that is merely convenient or optional. Legitimate interests are not used retrospectively to replace invalid consent. A provider label does not determine Vivat Lex’s lawful basis.
Principal purposes
- Respond to a request or determine whether a web order may be offered.
- Create, secure and recover a web account.
- Verify payment and form an accepted order.
- Create, maintain, expire, restore or revoke the correct web entitlement.
- Provide saved learning features included in the web product.
- Send necessary contract, security, service and support communications.
- Handle cancellations, refunds, chargebacks, complaints and legal rights.
- Prevent or investigate fraud, account compromise, malicious access or material misuse.
- Meet tax, consumer, sanctions, accounting, legal-claim and regulatory obligations.
- Provide accessibility adjustments and alternative formats.
- Maintain evidence of privacy choices where optional technologies are introduced.
Personal information is not repurposed for advertising, cross-product profiling, AI model training, behavioural personalisation or another incompatible purpose without a new documented assessment and, where required, a valid new choice.
Payment information
The checkout and durable confirmation identify the payment chain and the roles that apply to the actual order. No provider is assigned a controller, processor, merchant-of-record, tax or refund role merely because such a service is planned or generally offered.
Vivat Lex does not ask customers to send full card numbers, PINs, CVV/CVC values or one-time payment codes. Limited payment information available in production requests, logs, dashboards, exports, support tools or incident paths is processed only for the disclosed purpose.
Payment-provider success does not itself create a web entitlement. Order and entitlement evidence are linked through the verified server-side process.
Authentication and account information
Only sign-in methods actually offered by the current web service apply. For each used method, Vivat Lex limits processing to the information received for authentication, the provider role, account-linking and duplicate-account handling, session and recovery operation, deletion effects and applicable transfer safeguards.
Web sign-in and account data are not shared with the separate iOS or Android products as common account authority.
Learning data and product separation
Where the web product stores answers, progress, scores, statistics or history, it processes the fields needed to provide those features and applies the stated retention and deletion or export effects.
Web learning data does not synchronise with iOS or Android. A web purchase, refund, deletion or progress record does not automatically alter a mobile product, and vice versa. No future connection is promised.
Results Intelligence and profiling are not implemented. Vivat Lex does not claim a working parser, learning profile, recommendation engine or outcome model unless that feature, its data, logic, accuracy, fairness and customer controls are separately introduced and described.
Security and anti-abuse information
Vivat Lex uses only information lawfully held and disclosed for a specific security or service-protection purpose. This policy does not authorise hidden device fingerprinting, location tracking, process monitoring, clipboard monitoring, behavioural scoring, watermarking or another surveillance practice.
A new device, IP address, VPN, travel, shared network, rapid revision or assistive technology is not conclusive proof of misuse. A permanent adverse account decision receives meaningful human review and a proportionate explanation and appeal route.
Security measures are described without claiming absolute security, certification or controls that have not been tested.
Cookies and similar technologies
The Cookie Policy governs storage and access technologies. Optional analytics, advertising and personalisation remain off by default and do not load before a valid choice where consent is required.
Accepting the Terms, creating an account, making a payment, scrolling, closing a notice or continuing to browse is not optional-cookie consent. The Privacy and Cookie Policies use the same inventory for this website.
Marketing
Necessary service and transaction messages are not disguised as marketing, and marketing is not bundled into contract acceptance.
If direct marketing is introduced, its audience and source, consent or soft-opt-in route, suppression records, sender identity, withdrawal method, retention and enabled-country rules are stated before use. Every marketing message provides the required easy opt-out.
Who may receive information
| Recipient or category | Role | Data and purpose |
|---|---|---|
| Google Cloud and Firebase | Processor and technical service provider for Vivat Lex | Website hosting and necessary operational/security records. When the corresponding account, learning or purchase feature is available and used: Firestore, private-content delivery, Firebase Authentication and Firebase App Check with reCAPTCHA Enterprise; account, session, security, learning and order data only as required for that feature. |
| Google sign-in services; Apple only if offered | Separate identity-account and sign-in providers selected by the user | They process the user's external provider account and return the identity assertion needed for the selected sign-in. Vivat Lex does not receive the provider password. |
| Cloudflare Turnstile | Processor and security service provider for Vivat Lex | When protected sign-in is available and requested: challenge token and browser or network security signals used for bot and abuse prevention. |
| Cloudflare Email Routing | Processor and communications-routing service provider for Vivat Lex | For messages sent to an existing Vivat Lex domain alias: sender and recipient addresses, message headers, message content and attachments, and routing metadata needed to forward the message. All published business, support, privacy and cancellation contacts use sqe1practice@gmail.com and receive correspondence directly through Google Gmail. |
| Google Gmail | Communications and mailbox service provider used to receive and store customer correspondence | Business, support, privacy and cancellation correspondence sent directly to sqe1practice@gmail.com, including message content, attachments and delivery metadata. Google Gmail also receives messages forwarded from existing Vivat Lex domain aliases. |
| Resend | Processor and communications service provider for Vivat Lex | When an authentication or service email is requested: email address, one-time-code or necessary service-message content and delivery metadata. Resend stores customer data in the United States; choosing a European sending region does not relocate that storage. |
| Sentry, when enabled for the environment | Processor for privacy-minimised error monitoring | Technical error data only. The configured boundary disables default PII, request bodies, cookies, headers, query strings, fragments, tracing, logs and automatic session tracking. |
| Sold through Link / Stripe Managed Payments | Merchant of record and independent controller for the managed transaction | The transaction is displayed as “Sold through Link”, and Link is the merchant of record for the Managed Payments transaction. Stripe Managed Payments supplies the hosted checkout and handles billing and payment details, applicable tax, fraud prevention, disputes, refunds, transaction receipts or invoices and transaction support. Limited order and fulfilment data is returned to Vivat Lex. |
| Banks, card networks, wallets and other selected payment-method providers | Independent providers and controllers for their payment functions | Payment authorisation, settlement, fraud checks and any provider fee under the customer's selected method. |
| Legal or accounting advisers, courts, regulators and public authorities | Independent recipients only where reasonably necessary or legally required | The minimum relevant record for advice, legal claims, tax or accounting obligations, regulatory response or enforcement. |
Vivat Lex does not sell personal data. Questions about Vivat Lex-controlled processing may be sent to sqe1practice@gmail.com. Link, Stripe, Google, Apple, a bank or another independent provider answers separately for processing it controls.
International transfers
The providers listed above operate global services and may process personal data outside the United Kingdom. Resend stores customer data in the United States. For other providers, the destination depends on the service and its subprocessors; a UK business address or European hosting or sending region does not mean that all processing stays in the UK. Only the providers needed for the feature or communication you use receive its data.
UK restricted transfers require an applicable adequacy regulation or appropriate contractual safeguards. Google Cloud and Cloudflare publish data-processing terms that address international transfers. Resend's data-processing terms incorporate standard contractual clauses and the UK Addendum for UK transfers. Independent identity and payment providers describe the processing and transfers they control in their own privacy notices.
You can ask sqe1practice@gmail.com for information about the providers and transfer safeguards relevant to your data and for a copy of those safeguards, subject to any necessary redaction of confidential information. We review the relevant processing and safeguards before adding a provider or opening a new customer feature.
Retention
| Record | Operational validity or deletion target | Basis |
|---|---|---|
| Pre-authentication and anti-forgery state | 15 minutes | From creation. It becomes invalid at expiry and is scheduled for automatic deletion. |
| Email one-time-code challenge, including hashed email and code, attempts and state | 5 minutes | From creation. It becomes invalid at expiry and is scheduled for automatic deletion. |
| Authentication rate-limit hash and counter | Until the end of the 1-hour request window | The record expires at the end of that request window and is scheduled for automatic deletion. |
| Web session and session-principal records | 12 hours; earlier logout or revocation makes the session unusable | From session creation. Expired or revoked sessions cannot be used, and the records are scheduled for automatic deletion. |
| Turnstile replay-prevention hash | 5 minutes for an email-code request; 15 minutes for a Google or Apple federated bootstrap; single use in both flows | From successful verification. The record expires after the applicable 5-minute or 15-minute sign-in window and is scheduled for automatic deletion. |
| Checkout anti-forgery token | Operational validity: 10 minutes | From issue. The token cannot be used after 10 minutes; it does not reserve a payment or checkout. |
| Checkout intent and hosted payment session | Operational validity: 31 minutes; checkout-intent record delete-at target: 400 days | The checkout request and hosted payment session expire together. Retaining the record does not allow an expired checkout to be used. |
| Checkout request index, Stripe event inbox and event-idempotency record | Delete-at target: 400 days | Respectively from creation, receipt of the payment event or completion of its processing. |
| Order, receipt, entitlement and reconciliation observation | Delete-at target: 2,562 days | Respectively from the current update, creation of the confirmation or completion of payment reconciliation. |
| Learning access lease | Operational validity: 5 minutes | From issue. An expired or otherwise invalid learning session is rejected immediately; automatic deletion of its stored record may occur later. |
| Reserved but unserved learning attempt | Delete-at target: 24 hours from reservation, or earlier if the access-based deadline is earlier | An item reserved but never displayed uses this shorter deadline. Displaying it replaces that deadline with the period after access ends, shown below. |
| Served or answered learning attempt, learning progress, registered learning device, contact-email binding and contact-email claim record | Delete-at target: 30 days after the customer's actual paid-learning access ends | For a normal course term, the period runs from the fixed access cutoff. A final earlier end of access is handled as described below. |
| Support, complaint, privacy-right and legal-claim material | Only as long as required for the request, legal obligation or establishment, exercise or defence of a claim | There is no single shorter period for all such records. Access is restricted and deletion is reviewed when the purpose ends. |
Automatic deletion is not instantaneous. Where it applies, the database provider normally deletes records after their expiry rather than at the exact expiry second.
The 400-day and 2,562-day deletion targets apply to the checkout, payment-event, order, receipt, access-entitlement, duplicate-payment-prevention and payment-reconciliation records listed above. Automatic deletion is enabled for these records.
If a final early refund, payment reversal or chargeback lost by Vivat Lex ends paid-learning access before the fixed cutoff, Vivat Lex shortens the applicable private-learning deletion deadlines to 30 days after access actually ended. A temporary dispute suspension does not start that deletion period because access may be restored.
Vivat Lex stops private-learning access immediately when any required account, session, contact-email, entitlement, device or course-access permission is no longer valid. Automatic record deletion may happen later; access does not continue while deletion is pending.
The 400-day and 2,562-day payment and order evidence periods are separate from private-learning retention. Shortening or completing deletion of private-learning records does not replace or shorten the applicable payment and order evidence period.
A documented legal hold may pause deletion only for the records and period reasonably required by the relevant obligation or claim.
Children and age
The paid Vivat Lex Web account is for a purchaser and holder aged 18 or over. That rule does not mean that no person under 18 can visit a public page.
Any age-related design or assurance is proportionate. Passport, biometric or other intrusive information is not collected by default merely to enforce the purchaser rule.
Accessibility and health information
A customer may describe an accessibility barrier or requested adjustment without providing a medical diagnosis. Vivat Lex asks first about the functional need and preferred solution.
Information revealing disability or health may be special-category data. It is intentionally collected only with an applicable Article 6 basis, Article 9 condition, minimisation, restricted access, secure communication and a short justified retention rule.
Special-category information is not placed in ordinary unrestricted defect trackers or relayed through informal channels.
Automated decisions and profiling
No solely automated production decision with legal or similarly significant effect is made unless it is expressly described with the required safeguards.
Country, fraud, security or eligibility tools may provide signals, but an adverse outcome is not described as human-reviewed unless meaningful review occurs. Any qualifying automated decision is explained at an appropriate level, including its significance, consequences, safeguards and challenge route.
Absence of a positive signal is not consent, and nationality, ethnicity, name or language is not used as a proxy for residence or sanctions status.
Your rights
- Be informed.
- Obtain access to personal information.
- Correct inaccurate information.
- Erase information.
- Restrict processing.
- Object to processing.
- Receive portable information.
- Withdraw consent without affecting earlier lawful processing.
- Challenge qualifying automated decisions.
These rights are subject to applicable law and exemptions. A request does not require a special form or legal wording. Vivat Lex requests proportionate identity evidence only where reasonably necessary and does not request a full identity document by unsecured email as a default.
The general UK response period is as soon as possible and no later than one calendar month, subject to a lawful extension for complex or multiple requests and the required notice and reasons.
No contractual liability limit, disclaimer or description of pseudonymisation waives, excludes or caps a data-protection or ePrivacy right, a statutory right to compensation, a complaint to a supervisory authority or a regulator's lawful powers where applicable law does not permit that result. The applicable legislation governs causation, proof, remedies and any prevention of double recovery.
Privacy complaints
A privacy complaint may be sent to sqe1practice@gmail.com, made by telephone at +447442194285 or posted to 32/1 Tudsbery Avenue, Edinburgh, EH16 4GX, United Kingdom. A complaint and a data-rights request may arise in the same message but are tracked separately where different duties or deadlines apply.
For a UK data-protection complaint, Vivat Lex provides a clear route, acknowledges the complaint within 30 days, makes appropriate enquiries without undue delay, keeps the person informed and communicates the outcome without undue delay.
A person may complain to the Information Commissioner’s Office or another applicable supervisory authority. Contacting Vivat Lex first is not an absolute bar to approaching a regulator or court.
Personal-data breaches
Vivat Lex maintains a breach-assessment record. Where a personal-data breach is reportable under UK law, the ICO is notified without undue delay and, where feasible, within 72 hours after awareness. Affected individuals are informed without undue delay where the applicable high-risk threshold is met.
The response preserves the incident time, decision evidence, customer notification and relevant provider escalation.
Changes to this policy
This policy is versioned and dated. A material new purpose, provider, recipient, transfer, retention period, automated decision or optional technology receives a fresh assessment and, where required, a new choice before processing begins.
A Privacy Policy update does not by itself amend an accepted commercial contract or create consent.
Version and effective date
- Document version
- 2026-09-12.5
- Effective and last reviewed
- 12 September 2026
The version accepted at checkout is recorded with the order and forms part of the customer's durable confirmation. A later publication does not retrospectively replace that accepted version or reduce any mandatory consumer right.
Legal information