Privacy Policy

1. Information We Collect

1.1 Information You Provide

When you use Orchard72, we collect information that you provide directly to us. This includes:

Account Information: When you create an account, we collect your name, email address, phone number, and password. This information is essential for establishing your identity and securing your account.

Passkey and WebAuthn Credentials: When you enrol a passkey, we store the public-key portion of a FIDO2/WebAuthn credential generated on your device, an encrypted copy of the credential identifier (with a deterministic HMAC shadow used solely for credential lookup at sign-in), a sign-counter, the authenticator type (platform authenticator such as Face ID, Touch ID, or Windows Hello, or a cross-platform security key), the authenticator attestation identifier (AAGUID), supported transport types, a user-friendly device label that you supply, the user-agent string and browser fingerprint identifier of the device at enrolment, and the timestamps of enrolment and last use. The private key (and the biometric or PIN unlock that protects it) never leaves your device; we never receive your fingerprint template, face vector, or PIN. Credential identifiers and public keys are encrypted at rest. You may rename, deactivate, or delete any passkey at any time from your account security settings.

Device Trust Attributes: For each device that signs in to your account, we store a fingerprint hash derived from non-biometric signals (browser, operating system, device type, screen resolution, timezone, language) together with the device's IP address and IP-derived country, region, and city. We compute a device trust level on a 0 to 100 scale together with a progressive trust score that increases with successful sign-ins from the same device and decays over time when the device is not used. We also record successful and failed authentication counts, the last successful authentication timestamp, whether the device currently requires re-verification, and any nickname or user-set trust preference you apply. These attributes power our adaptive authentication risk scoring (flagging unrecognised devices, unusual locations, or anomalous sign-in patterns) and are visible to you in the Login Activity and Trusted Devices sections of your account; you may revoke trust for any device at any time. No advertising identifier, cross-site tracker, or biometric template is included in this profile.

Authentication Event Log: We log each authentication attempt (timestamp, success or failure, the multi-factor method used, the IP address and device label involved, and any risk-assessment outcome) so we can detect compromise, support your right to review account activity, and meet our security record-keeping obligations under UK GDPR Article 32. You can review your own authentication history from the Login Activity section of your account. The detailed log (including device and location details) is kept for 12 months; a summary record of each event (what happened and when) is kept for seven years in our audit log. The IP address and browser details are removed from that summary record after 13 months.

Lawful basis for authentication data: Passkey credentials, device-trust attributes, and authentication event logs are processed on the lawful basis of legitimate interests (UK GDPR Article 6(1)(f)): specifically, our and your shared interest in protecting your account against unauthorised access, phishing, and credential theft. WebAuthn/FIDO2 authentication is designed so that biometric matching happens entirely on your device; Orchard72 does not receive, store, or process biometric templates, vectors, or images, and we therefore do not process special-category data under UK GDPR Article 9 in respect of authentication. If you would prefer not to use passkey authentication, you may use a password together with a TOTP authenticator app or, where supported, SMS as your second factor instead. If you have any concerns about this categorisation, contact our Data Protection Officer through our contact form. The lawful basis for each authentication-data purpose is also summarised in the table in Section 2 (Legal Basis for Processing).

Will Information: To create your will, we collect personal details about you, your family members, asset information, and beneficiary details. This includes names, relationships, addresses, and descriptions of how you wish to distribute your estate. When you upload existing will documents, we process these through AI-powered extraction to help populate your digital will.

Life Changes: If you tell us about a change in your life that may affect your will (for example a move to another country or a new home, a marriage, civil partnership, separation, divorce or dissolution, the birth or adoption of a child, or the death of someone named in your records), we record the kind of change, any date you give us (encrypted at rest), the country concerned where relevant, which of your completed wills it may affect, and when any resulting review is complete. We also record some changes automatically from information already in your account, for example when a child named in your records turns 18, or when your profile no longer matches a will you have completed. This information can relate to other people, including children and people who have died, and can reveal sensitive details of your family life, so we protect it in the same way as your will information. We use it only to show you to-do items suggesting that you review your will, and to send you will reminders. If you tell us you plan to marry or enter a civil partnership and give an approximate timeframe, we store the date on which we will check in and the date we did so, and once that date has passed we send you one reminder about that plan and add a to-do item where you can tell us what happened; we never send more than one reminder about a plan you have told us about. If you tell us you plan to move to another country, we show you a to-do item once the date you gave has passed, without sending a reminder. We do not follow up plans to have children or pets at all, and we do not ask about or record a planned separation; instead, the regular will review reminder asks, in general terms, whether anything has changed in your life that might affect your will. We never infer a life change from your age, how long you have had an account, or your marital status. The subject line of a reminder email, the preview of a push notification and the title of a notification never name the life change; the detail is shown only after you sign in. When you report a change yourself, we confirm it in your account only and do not email you about your own action. After a bereavement we send no email or push notification about it, and we pause marketing emails and to-do digest emails to you for 30 days. You can dismiss any life-change to-do item, or turn off will reminders, at any time; retention follows the will-content rule in Section 8.

Power of Attorney and Advance Decision Information: If you prepare a power of attorney (for health and welfare, or for property and financial affairs) or an advance decision to refuse treatment, we collect the details needed to generate that document from your answers, for example the people you wish to appoint as attorneys, how they should act, any restrictions you place on their authority, and, for a health-related document, your treatment wishes. Where we hold a reviewed template for your jurisdiction, your answers are composed into a draft using our self-hosted AI (a health and welfare power of attorney and an advance decision involve special-category health data, processed under the “Special Category Data” heading below); where we do not, we do not generate the document and, with your agreement, may refer you to a verified legal professional who can, sharing your details with them only when you actively approach or accept them. Before you finalise or download a document, we record an immutable acknowledgement that you have seen the disclaimer and execution-requirements checklist we show you (capturing the exact wording, the timestamp, and the jurisdiction) on the basis of our legitimate interest in keeping a tamper-evident record of what you were told, since execution formalities (signing, witnessing and, where required, registration) are your responsibility.

Residence History: If you choose to use our cross-border planning tools, we may collect details of your residence history, for example, the number of tax years you have been resident in a country over a look-back period and the tax year you left. This is optional and provided entirely at your discretion. We use it solely to show you a factual indicator of how a country's residence-based rules (such as the United Kingdom's long-term-residence test for inheritance tax) may apply to your circumstances. It is information only, not legal or tax advice, and you can update or remove it at any time.

Platform Succession Settings: If you use our Business Action Centre, we collect information about which digital platforms you have configured succession or continuity features on (such as GitHub Account Successor, Apple Legacy Contact, or multi-admin access). This includes the platform name, the type of succession feature, its configuration status, the date you completed it, and any notes you add. We use this information to generate appropriate clause language in your will and to help your executors understand which platforms already have succession tools in place. You may delete any platform succession setting at any time via the Action Centre.

Licence and Permit Details: Where a possession you record can only lawfully be held under a licence, certificate or permit, for example a firearm or a shotgun held on a certificate, you may record that permission alongside the item. For each one we store the kind of permission it is held under, the body that issued it, the reference or number printed on the permission document, the date the permission expires, and where you keep the certificate itself. The permission reference and the certificate location are encrypted at rest, and the certificate location is governed by the same access-hint visibility setting as the rest of that possession, so it is released only to the people you have chosen. We use these details to tell your executors what exists and who to contact, and to include a generic fallback direction in your will for an item that a named beneficiary may not be able to receive. We do not contact any licensing authority, we do not apply for or renew anything on your behalf, and we do not check that a permission is genuine or still in force. We collect this only because you chose to enter it, and we process and store it on our own servers. Our lawful basis is your consent, and carrying out your instructions (UK GDPR Article 6(1)(a)). You may clear these details, or delete the possession entirely, at any time from your account; retention follows the will-content rule in Section 8.

Official Will Registration Record: After your will is signed, you may choose to note that you have registered it with an official register or deposit service in your jurisdiction. If you do, we store the date you registered it and, if you enter one, the reference the official body gave you; the reference is encrypted at rest. You register with the official body yourself: we do not contact it, send it your will or any of your data, or check that the registration took place. A legal professional who prepared your will for you can see only whether a registration has been noted (not the date or reference), and may send you a reminder email about your registration choices, at most once every seven days. Our lawful basis is carrying out your instructions under our contract with you (UK GDPR Article 6(1)(b)). You can edit or remove the record at any time from your will page, and retention follows the will-content rule in Section 8.

Key Contacts Directory: You may record the people and organisations that whoever steps in for you would need to reach, for example your GP, solicitor, accountant, funeral director, landlord or boiler engineer. For each contact we store the details you enter: the person's name and/or the organisation's name, what they do and how they relate to you, a phone number and its international dialling code, an email address, a website, a postal address and country, free-text instructions about what to contact them regarding, an ordering hint so the most important contact is listed first, whether the contact is a next of kin, when you last confirmed the details are current, and an optional link to a family relationship already recorded on your account. Names, organisation names, phone numbers, email addresses, postal addresses and instructions are encrypted at rest; alongside them we keep a one-way cryptographic hash of the two name fields, used solely to spot when the same contact has been entered twice. Because these are other people's details, our lawful basis is legitimate interests (UK GDPR Article 6(1)(f)): your interest in leaving your affairs actionable and ours in providing that service. You should record only details you are entitled to share, and ideally with that person's knowledge; any contact may ask to access or erase what you have recorded about them by contacting our Data Protection Officer through our contact form. Sharing is opt-in and per contact: a contact is included in the emergency information pack only if you switch that on for that individual contact (it is off by default), and the pack is visible only to a trusted person to whom you have separately granted key-contacts access. You may revoke that access, turn off any contact's inclusion, or delete any contact, at any time from your account; retention is set out in Section 8. Where you had previously recorded contact details as household information under a “Key Contacts” heading, those entries have been copied into this directory and the originals retained, so the same details may appear in both places until you tidy them up.

Emergency Access Requests from Your Emergency Contacts: Emergency access is off unless you switch it on for an individual emergency contact, and only a contact who has accepted that role can ask. For each contact you choose what they could see (your will, or only the vault documents you pick from your own documents) and how long the waiting period lasts. When a contact asks, we record the request and when it was made, and we tell you straight away. Nothing is released while the waiting period runs, and you can deny the request at any time during it. If you do not deny it, at the end of the waiting period we disclose only what you chose, to that one contact, read-only and for a limited time, and we record each time they view it. If a death report about you has been verified, a contact who is also your executor can skip the waiting period. We keep the record of each request, including whether you denied it or it was granted. All of this is processed and stored on our own servers. Our lawful basis is the performance of our contract with you (UK GDPR Article 6(1)(b)), because we are carrying out your instructions. We use the contact's own name and contact details only to reach them about this arrangement. You can change or switch off a contact's emergency access at any time from your account settings.

Identity Verification Documents: To verify your identity and comply with legal requirements in certain jurisdictions, we may collect copies of identity documents (passports, driving licences, national ID cards) and address proof documents (utility bills, council tax bills, bank statements). When you upload these documents, we process them through our self-hosted AI verification pipeline, which includes: machine-readable zone (MRZ) parsing, optical character recognition (OCR), large language model (LLM) extraction of identity fields, cross-referencing of extracted data against your account information, and image quality assessment. By default, all document processing occurs on our own infrastructure and your identity documents are not sent to any third-party AI provider. Only if our self-hosted result is not good enough, and only on your explicit, per-document instruction, may you choose to send that one identity document to a third-party AI provider (named in our sub-processor list) for enhanced extraction; we record that consent (the disclosure you were shown, the timestamp, and your IP address and device) as the lawful basis for the transfer (UK GDPR Article 6(1)(a), and Article 9(2)(a) where the document reveals special-category data). This never happens silently or by default, and you may decline and remain entirely on our own servers. We store the original uploaded file, extracted data fields (name, document number, expiry date, address), quality assessment scores, and verification audit logs. Identity documents are classified as sensitive personal data and are stored with enhanced encryption in private cloud storage (Cloudflare R2) with access restricted to authorised verification processes only.

Identity Documents of Executors and Witnesses You Provide: When preparing your will, you may optionally upload an identity document for an executor or witness you have named, on their behalf. This is never required to complete your will, and those individuals do not need an account with us. Where you provide such a document, you confirm that you have a lawful basis to share it. You should only do so with that person's knowledge and agreement. We process the document through the same self-hosted verification pipeline described above (by default it is not sent to any third-party AI provider; as with your own identity documents, an external provider is used only where you give explicit, per-document consent to enhanced processing), comparing only the extracted name and date of birth against the details you recorded for that executor or witness, to record an optional “identity verified” indicator against them. Our lawful basis for processing this third party's data is our and your legitimate interests (UK GDPR Article 6(1)(f)) in supporting the integrity of your will arrangements; the document is held under the same enhanced encryption and access controls as your own identity documents and is retained under the will-content retention rule in Section 8. The executor or witness may, by contacting our Data Protection Officer through our contact form, ask to access or erase the identity document you uploaded about them, subject to the retention obligations set out in this policy.

Identity Checks for Witnesses in an Electronic Signing Ceremony: If you are invited to witness a will electronically, you accept the invitation with your own account and are then asked to confirm your identity before you can sign as a witness. Before any check runs, we ask how your identity document may be processed and record your answer (the disclosure you were shown, the timestamp, and your IP address and device) against that will. You then upload a photo of your identity document, which goes through the same self-hosted verification pipeline described above. By default it is not sent to any third-party AI provider; an external provider is used only if you choose enhanced processing for that document. Where the will's arrangements call for a stronger check, you may also be asked to record a short video of your face and voice. We ask for your separate, explicit consent to being recorded before the recording starts (UK GDPR Article 9(2)(a)), and the recording is checked only by authorised members of our team. We record the outcome (verified, or not verified with a suggestion to try again or contact support) against your role in that signing ceremony. The person making the will sees only that outcome, not your document or recording. We process this on the basis of your consent and of the legitimate interests (UK GDPR Article 6(1)(a) and 6(1)(f)) of you and the person making the will in being able to show later who witnessed it. Your document and any recording are held under the same enhanced encryption and access controls as other identity documents and are retained as described in Section 8. You may ask our Data Protection Officer through our contact form to access or erase them, subject to those retention obligations.

How You Plan to Sign Your Will: When you tell us about your witnesses, you may also tell us how you plan to sign your will on paper: in the usual way, by making a mark, by having someone sign in your name at your direction, after the will has been read over to you, or, where the law of your will's jurisdiction provides for it, by a notary or other authorised person signing for you. Depending on the option, we record the name and address of the person signing for you, the name and capacity of the notary, the reason you cannot sign yourself, whether the will is to be read to you, and whether you plan to record a video of the signing (we record only that you plan to; we do not receive or store the video). We use these details only to print the matching signing and witnessing wording in your will and to remind you of your choice when you upload the signed will. Recording that you will sign by mark, at your direction, after a read-over or notarially, and the reason you cannot sign (for example, that you are blind or unable to write), can reveal information about your health, so we treat it as special category data under the “Special Category Data” heading below, on the same Article 9 bases as the rest of your will instructions. We process the name and address of the person signing for you, and the notary's name, on the basis of our and your legitimate interests (UK GDPR Article 6(1)(f)) in producing correctly worded will documents; you should tell that person you have given us their details. These details are held with the same encryption and access controls as the rest of your will, form part of your will content, are shared only in the ways this policy describes for your will content, and are retained under the will-content retention rule in Section 8.

Organisation Domain Verification Records: Where an organisation asks us to confirm that it controls the web domain its listing points at, we keep a record of that claim and of every attempt to prove it. Against the claim we store the domain claimed and its registrable form, what the claim is for (showing a verified badge on the listing, or enrolling staff accounts automatically on that domain), the challenge token we issue together with the times it was issued and expires, the proof method chosen, when the claim was last checked and when the next check falls due, how many attempts have been made, the outcome and any error we recorded, and the account that started the claim. Alongside it we keep an append-only attempt log: for every attempt, successful or not, we record the method used, the outcome, the value we observed (the DNS TXT record we read, the body of the file we fetched, or the mailbox that replied), which resolver or endpoint answered us, any error detail, and the time of the check. That log holds no IP address and no device or browser information. Carrying out a check means looking up your domain's DNS records, fetching a file we issue over HTTPS from the site you have claimed, and sending mail to the role address you nominate, so the operators of that domain, its DNS and its mail service may see those requests; you should only start a claim for a domain you are authorised to act for. Our lawful basis is legitimate interests (UK GDPR Article 6(1)(f)): confirming that a listing points at a domain the organisation actually runs, and keeping the attempt log as the audit trail behind each decision. The entry in the table in Section 2 (Legal Basis for Processing) sets this out, and retention is covered in Section 8. A completed check confirms one narrow fact, control of that domain on the day it was made; it says nothing about an organisation's regulatory standing, and verification lapses after 90 days unless it is proved again.

Documents Emailed to Your Vault: You may forward documents into your Document Vault by emailing them as attachments to a single personal, unique ingest address we generate for you (beginning docs- followed by your unique token, and shown in your Document Vault). If you were previously given a separate address for forwarding travel itineraries (of the form travel+<your-unique-token>@inbound.thewill.ai) we continue to accept mail sent to it, so a saved contact or a mail-client forwarding rule you already set up keeps working, but it is no longer the address we show you and it is governed by exactly the same controls as the address above. Inbound delivery is yours to control: you can switch it off entirely, in which case mail that arrives afterwards is rejected and its contents are not stored, and you can decide who may send to you, choosing between only your own verified addresses, a list of senders you name (an accountant or a solicitor, for example), or anyone. Mail from a sender your setting does not allow is rejected and its attachments are discarded without being stored. We also apply a per-account hourly limit and ignore a repeated delivery of the same message, so a forwarding loop cannot fill your vault. When we accept an email we process the sender address (to authenticate it against your setting), the attachment files themselves, the message text and the subject line, and basic delivery metadata; we record an audit entry of each accepted or rejected attempt, storing the sender address as a one-way hash and never in the clear, together with the sender's domain, which address the mail arrived at and the outcome, so that we can investigate misuse and troubleshoot a delivery that did not arrive. Accepted attachments are virus-scanned, encrypted, and placed in your vault exactly as if you had uploaded them in the app, and they then flow through the same self-hosted classification pipeline. At this stage no document content is sent to any third-party AI provider, and nothing is applied to your will or asset records until you review and confirm it. (If you later choose to extract data from a vault document and our own AI's result is not good enough, you may give explicit, per-document consent to send that document to a third-party AI provider for enhanced extraction, as described under “Identity Verification Documents” above; this never happens by default or without your approval.) When the email also contains a meaningful message body, we render that text to a PDF and place it in your vault as a separate document, using the subject line as its title (or a date-based fallback when the subject is blank); you can review or delete that body document like any other. Where you have switched travel extraction on, we additionally keep a record of the message itself, holding the sender address and subject line as provenance and the body encrypted at rest, because reading your travel dates out of an itinerary needs the text of the email; the dates it finds are proposed to you as draft travel records that you confirm or reject. That record is deleted 30 days after the email has been processed, and you can delete it and its stored body yourself at any time from your account; the delivery audit entries described above are deleted after 180 days. With travel extraction switched off, the attachments are filed in your vault and no record of the message is kept. The reading is carried out on our own servers, and the message never leaves our servers without your approval. One consequence is worth stating plainly: once that 30-day window has passed, the original wording of an itinerary is gone, so a draft travel date can no longer be checked against the email it came from, although the documents filed in your vault and the travel records themselves are unaffected and are kept until you delete them. You can rotate your ingest address at any time from your Document Vault, which immediately stops both the previous address and the earlier travel address from working. We email you to confirm when documents arrive this way, and to alert you if an email was rejected.

Support Requests: When you contact our support team, we store your request, our replies and any files you attach in our support ticket system. If you email our support address, your email stays in our support mailbox and a copy of it (your name and email address, the subject, the message text, any attachments and the technical email headers) is passed by our email delivery provider into the same ticket system. We use the headers only to set aside automatic replies, bulk mail and likely spam, which do not become tickets. So that the same email never becomes two tickets, we keep a one-way fingerprint of each email's message identifier for 30 days. Where your sending address matches an account on our service, our team is shown that match as an unverified hint; we never link a request to an account on the strength of an email address alone, because a sender's address can be forged. Emailed attachments are virus-scanned, and files of a type or size we do not accept are not stored; our team is told that they were left out. To help our team respond, a staff member may ask our own self-hosted AI to prepare a first draft of a reply from the text of your request and the conversation so far. That processing happens on our own servers: your name, email address and attachments are not given to the AI, nothing is sent to any third-party AI provider, and a draft is never sent to you automatically. A member of our team reviews and edits every reply before it is sent. Support tickets are kept for the period shown in Section 8.

Payment Information: To process your subscription and professional services, we collect billing addresses and payment method details. Your payment card information is processed securely by our payment providers and is not stored on our servers. We also generate and store invoices for services rendered. When you pay on behalf of an organisation you manage (for example, a charity), the payment is made on the organisation’s own billing account: we store the organisation’s billing email and record which team member added its card on file, so that the organisation’s other owners and administrators can see it and be told if that person leaves. If you pay by Direct Debit (BACS, SEPA, ACH, or BECS), we collect your bank account details (such as sort code and account number, or IBAN) solely for the purpose of mandate setup and payment collection. These details are transmitted directly to and processed by Stripe. They are not stored on our servers. We also collect mandate identifiers, payment method type, and payment confirmation status to manage your subscription and prevent fraud.

Communication Data: When you contact our support team or provide feedback, we collect the messages and correspondence you send to us. This includes feedback submissions and screenshots you may share through our in-app feedback system.

Help Hub Interactions: When you use our Help Hub chatbot, we log your questions and the chatbot's responses for quality assurance and service improvement. If you are signed in, your queries are linked to your account; if anonymous, only the session identifier is retained. You may optionally provide feedback (helpful, not helpful, or incorrect with correction text) which is stored alongside the query. No IP addresses or user agent strings are stored with Help Hub queries.

Appointment Text Messages: If you book an appointment with a legal professional, including as a guest without an account, we may send you short text messages about that appointment, such as a reminder or a request to reconfirm it. We text an account holder only at a mobile number they have verified on their account, and a guest only at the phone number they gave on the booking form, and only when it is entered in full international format (for example +44…). These texts are about the appointment you booked and are never marketing. Every text tells you to reply STOP to opt out; if you do, we stop texting that number and keep a record that it has opted out so that we honour your choice. That record holds only a one-way cryptographic fingerprint of the number, not the number itself, and is removed if you later reply START. Texts are delivered by our SMS providers, Twilio and Telnyx (see Section 4).

Video Consultation Data: When you participate in video consultations with legal professionals through our platform, we may collect meeting recordings (video and audio), AI-generated transcripts, chat messages, shared documents, meeting metadata (duration, participants, timestamps), and consultation notes. Video consultations are facilitated through Daily.co, our video infrastructure provider. AI transcription is performed locally on our self-hosted infrastructure (using the open-source whisper.cpp engine); audio data is not transmitted to any third-party transcription provider. You will be asked for explicit consent before any recording begins, and you may decline recording without affecting your ability to have the consultation. Any participant can also withdraw their consent while a recording is in progress, using the “Withdraw consent” control in the call. When consent is withdrawn, we stop the recording immediately on our servers and every participant is told who withdrew. The part recorded before the withdrawal is kept, marked with the time of the withdrawal on both the recording and its transcript; withdrawal does not affect the lawfulness of recording that took place before it. Recording can only restart if fresh consent is given. Every participant, client and legal professional alike, can also pause, resume or stop a recording at any time; each pause, resume and stop is recorded with who did it and when, and everyone on the call sees the recording's current state. A paused recording captures nothing until it is resumed, and the paused stretch is marked on the transcript. If you mute your microphone while a recording is running, your voice is kept out of the recording. Stopping a recording also withdraws the stopping participant's consent, so it cannot restart without their fresh consent. Our video provider may also end a recording on its own (for example at its maximum length, or when the call has been idle), in which case everyone is told it stopped automatically. Whenever a recording is stopped, the part already recorded is kept, marked with who stopped it (or that it stopped automatically) and when; you can ask for it to be deleted through your data rights described in Section 6. A legal professional may also record an in-person appointment on their own device, again only with your consent. If you ask them to stop, they stop recording and record your request on our platform, with who recorded it and when; this counts as withdrawing your consent, and the part recorded before your request is kept. After an in-person recording is stored, we email you to say where you can view it and how to ask for it to be deleted.

Recording Consent Records: We record whether each participant consented to recording, when consent was given, when any consent was withdrawn, and the IP address and device (browser user-agent string) at the time of consent. This creates an auditable record of consent for legal compliance purposes.

Electronic Signature and Engagement Metadata: When you sign or accept a document electronically on the platform (for example, signing or countersigning an engagement letter, or recording a consent) we record signing metadata so that the signature can be evidenced. This includes the typed signature and the exact text agreed to, the date and time of signing, your IP address, your browser user-agent string, the authentication method used, and a cryptographic hash (digital fingerprint) of the signed document. We process this metadata to provide reliable evidence that a document was executed and by whom, and to detect any later alteration or tampering (fraud prevention). Our legal basis is our legitimate interests in maintaining a tamper-evident record of agreements and, where the metadata supports performance of a contract you have entered into, the performance of that contract; it is processed separately from, and is not bundled with, your acceptance of any contractual terms. Retention is set out in Section 8.

Uploaded Video Confirmation Records: When you upload a video message rather than record it in the app, we ask you to confirm a short set of statements about it (for example, that you appear in it and that it has not been altered to change how you look or sound, or what you say). When you confirm, we keep a record with the video of which statements you confirmed (by the version of the wording shown to you), the date and time you confirmed, and your IP address at that moment. We keep this only as a record of your confirmation, because we cannot ourselves confirm when or where an uploaded video was recorded. Our legal basis is our legitimate interests in keeping a reliable record of what you confirmed about a video you uploaded. The record is stored with the video it relates to and is retained for as long as that video is, as set out in Section 8.

Professional Service Offer Consent Records: When a legal professional you are engaged with sends you a proposal for an additional service through the platform (a “Service Offer”), and you accept or decline, we record an immutable consent row capturing your response, the verbatim anti-circumvention disclosure shown to you at decision time, a frozen snapshot of the fee shown alongside the prevailing catalogue listing price (so the fee fairness shown to you cannot be edited after the fact), the timestamp, your IP address, your browser user-agent string, and the authentication method used. Our legal basis is our legitimate interests in maintaining a tamper-evident record of the cross-sell proposal and your response, the performance of the resulting engagement contract (where you accepted), and our regulatory obligation under the Solicitors Regulation Authority Code of Conduct (and equivalent codes for other professional bodies) to evidence the anti-circumvention promise made to you. Retention is the SRA / professional-indemnity window described in Section 8 (approximately six years from the offer's last lifecycle event); on account closure your IP address, user-agent string, email address on the consent row, and authentication method are nulled, while the verbatim disclosure (which contains no personal data) and the frozen fee snapshot are retained as the audit fact.

Chat Messages and File Attachments: When you use in-consultation chat, we collect and store messages exchanged between you and the legal professional. File attachments shared via chat are stored in encrypted private object storage (Cloudflare R2) and are served to authorised participants through short-lived signed URLs that expire five minutes after issue. These attachments are scanned for malware by an automated virus scanner, which runs after the file is stored and gates whether the file can be downloaded. Hash-based illegal-content (CSAM) detection and EXIF metadata stripping for these attachments are planned safeguards that are not yet implemented. See “Known limitations of file attachment safety controls” below. Chat messages related to will preparation are retained as part of the will file under the will-content retention rule set out in Section 8 (duration of your account plus 2 years after closure, subject to any litigation or compliance hold).

Direct Messages: When you use our standalone direct messaging feature (outside of scheduled consultations), we collect and store the following data: message content (encrypted at rest using industry-standard symmetric encryption, currently Fernet), conversation subject lines, participant identity and roles, message timestamps, read receipts, typing indicators (transient, not stored), edit history, file attachments (name, size, type, and binary content stored in encrypted private object storage on Cloudflare R2; downloaded by authorised participants through short-lived signed URLs that expire five minutes after issue), unread message counts, and conversation state (active, muted, archived, blocked). For inbox functionality, a plaintext preview of the last message in each conversation (up to 200 characters) is stored unencrypted. When you delete a message, the content is cleared but metadata (timestamp, sender, edit history) is retained for compliance purposes. Message drafts are stored and automatically deleted after 90 days of inactivity. Email notifications about new direct messages contain the sender name and unread count only. No message content is included in notifications, to protect the confidentiality of communications.

Known limitations of direct messaging and file attachment safety controls: we record these as known limitations so that you can decide what to share through the platform with awareness of the current control set. We will update this Privacy Policy when each control is implemented.

• Plaintext message preview: the last-message preview stored for inbox display (up to 200 characters) is retained unencrypted at rest. Anyone with database-level access (including a hypothetical attacker with that access) could read those previews even though full message bodies are encrypted. This is disclosed so you can avoid placing highly sensitive content in the opening of a message.
• Privilege expectations: direct messages exchanged through our platform are not automatically protected by legal professional privilege. Whether a particular communication attracts privilege depends on the nature of the communication and your relationship with the legal professional you are messaging. The platform does not determine or guarantee privilege status; for advice that must be privileged, discuss the appropriate communication channel with your legal professional.
• Attachment malware scanning can fail open: attachments shared via in-consultation chat and direct messaging are scanned for malware by an automated virus scanner, and a file the scanner reports as infected is blocked. The scan runs after the file is stored rather than before it is stored, and if the scanner is unavailable or the scan does not complete, the attachment is released for download without a completed scan. Hash-based illegal-content (CSAM) detection and EXIF metadata stripping are planned safeguards that are not currently implemented. You should treat received attachments with the same caution as any file received from an external party.

Professional Credentials: If you register as a legal professional, we collect your professional qualifications, regulatory body registration details, practising certificate information, professional indemnity insurance details, areas of expertise, and office locations.

Change-Request Evidence: When you submit a change request to amend your firm’s verified registration details (legal name, regulatory body, company or VAT number, registered addresses, or established date), we retain the evidence you provide (either an uploaded document or a link to an official register) alongside the proposed values, the submission timestamp, the identity of the submitter, and the admin review outcome. This record is kept for the lifetime of your professional account plus seven years to meet our regulatory record-keeping obligations and to support future audits.

Marketing Preferences: We collect your email preferences and subscription choices to ensure we only send you communications you want to receive.

Subscription and Billing Data: When you subscribe to a paid plan, we collect your plan tier, billing interval (monthly or annual), billing platform (web, iOS, or Android), subscription status, and billing history. This data is processed to manage your subscription and deliver plan features.

Geo-Pricing Data: We collect your payment card's issuing country (provided by our payment processor) and IP-based geolocation (using the locally hosted MaxMind GeoLite2-City database; for pricing we use only the country-level resolution it provides). This information is used for regional pricing determination, local currency resolution, EU VAT location evidence, and fraud prevention. No precise location data is stored for pricing. Only country-level geolocation is used.

Referral Data: If you participate in our referral programme, we collect your unique referral code, invited email addresses, invite context (the relationship type you select, such as Friend, Professional, Client, or Colleague; used only for email template selection), referral status, referral type (automatically detected when the referral completes), and reward details (duration and plan tier). When you invite someone by email, the invitee's email address is collected solely for sending the invitation and matching the referral upon registration. If the invitee does not register within 90 days, their email address is deleted. We also set a referral cookie (thewill_ref, 30-day duration, SameSite=Lax) on the invitee's browser when they visit the platform via a referral link. This cookie is used for referral attribution and is classified as strictly necessary (no cookie consent required). Referral data is shared only between the referrer and the platform, not with other users, with one exception you control: if you joined through someone's referral, you can choose to let the person who referred you see how far you have got with your will, as one of three steps (signed up, will started or will completed) with the date of each. Nothing in your will, and nothing about who or what it covers, is shared with them. This sharing is off unless you turn it on; we record when you agreed and, if you withdraw, when you withdrew, and from the moment you withdraw the referrer sees none of it.

Signup Attribution Data: When you create an account, we record once, at that moment, where the account came from: which of our brands you signed up on, whether you signed up on the website, in our iOS app or in our Android app (or whether a member of our staff created the account for you), any campaign tags that were on the link you arrived through (the standard “utm” source, medium and campaign labels), the name of the website that sent you (its domain only, never the full address of the page), the path of the first page you landed on (never its query string), a short campaign or community code if the link carried one, and the country your connection appeared to come from at signup. We work out that country from your IP address at the moment of signup and then discard the address; we do not store your IP address for this purpose, and the country is not a precise location. We use this record, in aggregate, to understand which of our brands, apps and channels people come from so that we can improve them. It is first-party: it involves no third-party tracker or advertising service, and it is not shared with anyone. Our legal basis is our legitimate interests (Art. 6(1)(f)) in understanding how people find our services. The record is kept for as long as your account exists and is deleted with it; you can object to it at any time by contacting us, and we will remove it.

Partner Referral Data: Some legal professionals and firms send people to a page carrying their branding, from which you can start a will with us (a “partner page”). When you press the button to start a will on a partner page, we set a cookie (thewill_partner, 30-day duration, SameSite=Lax) holding that partner's public page reference and nothing about you. It is set only on that action and is classified as strictly necessary (no cookie consent required). If you then start a will, we record that the will was started through that partner, whether it has been completed, and when. We use this to show the partner's name and colour in some emails about your will and to tell the partner how their page is performing: if the partner has set up notifications, we send them a random reference and whether the will has been started or completed, and nothing else. We never send the partner your name, contact details or any content of your will through a partner page; your will is written and stored by us and we remain the controller of your data. The partner learns more about you only if you choose to engage them separately. This record is kept for as long as the will it relates to exists and is deleted with it.

Changes Your Legal Professional Is Told About: If you have engaged a legal professional through the platform and your will is shared with them (because you have consulted them, signed their engagement letter or are having your will reviewed), and you later update details that may affect your completed will (for example your marital status, your children or where you live), we send that professional an in-app notice that your circumstances have changed so they can check whether your will still reflects your wishes. The notice names you but does not say what changed; the professional sees the detail only through the access you have already given them. We do not send this notice to a professional whose relationship with you has ended or who has not yet been engaged. Our legal basis is the performance of your engagement with that professional and our legitimate interests in helping keep your will up to date.

Community Participation Data: When you participate in our community (the Discourse forum), we record your posts, the upvotes you receive, accepted-solution events, and trust-level milestones. We use this data to compute karma grants under our Karma Programme. This data is shared between Discourse and our backend via the Discourse single sign-on bridge, identified by your platform user ID. We retain this data for as long as your account is active; on account closure, your community contributions remain visible in the community in line with Discourse's standard retention, but the attribution that links them to your karma grants is severed.

Gift Purchase Data: When you purchase a gift card, we collect the recipient's email address and any personalised message you include. This data is used solely for gift delivery and redemption.

Guest Gift Purchase Data: A gift card can be bought without an account, and in that case we hold no user record for you. What we collect instead is the email address you give at checkout, the recipient details described above, the payment record our payment processor returns to us, and a unique order reference we generate for the order. The order reference is a random value with no meaning outside our systems; it is what identifies your order to us in place of an account, so that you can check the status of the order, ask us to resend the gift, and later attach the order to an account if you create one with the same email address. Our lawful basis for all of this is performance of a contract (Art. 6(1)(b)): we cannot sell you a gift card, deliver it, or handle a refund without it. To protect the guest checkout from card fraud and abuse we also record the network address the order came from and the card fingerprint our payment processor supplies, together with the processor's own risk assessment; the lawful basis for those is our legitimate interests (Art. 6(1)(f)) in preventing fraudulent transactions. We keep the guest email address for as long as the gift can still be redeemed and for the statutory financial-record period that follows, after which an automated process removes it from the purchase record while leaving the anonymous transaction record in place. We do not add a guest buyer's email address to marketing lists.

Founding Member Data: If you purchase a Founding Member package, we collect your FM status, purchase date, and associated benefits. This data is retained for as long as the benefits are capable of being delivered (that is, for the life of the service) and is deleted when the service ends or when you close your account, whichever is sooner. We do not retain it beyond the purpose it serves.

Mirror Will Partner Data: When you use the Mirror Will Service, we collect your partner's email address to send an invitation on your behalf. We process this email address on the basis of your legitimate interest in creating Mirror Wills together.

Digital Content Waiver Consent Records: When you subscribe to a paid plan, we collect a record of whether you consented to waive your statutory cooling-off right, the timestamp of your consent, and your IP address at the time of consent. This creates an auditable record of consent for legal compliance purposes.

Checkout Consent Records: When you complete a purchase on our signed-in checkout page, we record the consent you give there before payment (including your confirmation that you want any immediate-supply digital content to begin straight away and that you understand this affects your statutory right to cancel) together with the timestamp, your IP address, and the browser user-agent string at the time. Each record is keyed to the payment session it relates to, so that it can be matched to the specific purchase. This creates an auditable record of your pre-contract and immediate-supply consent for legal compliance purposes. Retention is set out in Section 8.

Public Cancellation Requests: Our “Cancel contracts here” page lets anyone ask us to cancel a subscription without signing in. The form asks for a name, an email address and, optionally, a contract reference. We use the email address only to look for a matching account; if one exists with an active subscription, we schedule that subscription to end at the close of its billing period and send the confirmation to the email address on the account, never to any other address. The name and contract reference are checked for format and then discarded: we do not store them. The email address is not stored with the request either; where it matches an account, the account's own subscription record notes when the cancellation was requested and that it came through this page. To stop the form being used to flood someone with emails, we count requests per network (IP) address and per submitted email address, which we hold only in hashed form for this purpose. Both counters are kept in a short-lived cache and expire on their own, the IP address count after one hour and the email address count after one day. Our lawful basis for acting on the request is performance of a contract (Art. 6(1)(b)) and compliance with a legal obligation to offer an easy online cancellation route (Art. 6(1)(c)); our basis for the abuse counters is our legitimate interests (Art. 6(1)(f)) in protecting account holders and the service from misuse.

Special Category Data: In the course of creating your will or during consultations, you may provide us with special category personal data as defined by GDPR Article 9. This may include information about your health (e.g. terminal illness or mental capacity considerations), religious beliefs (e.g. burial or funeral wishes), family relationships that may reveal racial or ethnic origin, or details about a spouse or partner that reveal sexual orientation. We process this data only with your explicit consent, which you provide when submitting your will information or participating in a consultation. This data is processed solely for the purpose of creating your legal documents and facilitating consultations, and is subject to enhanced security measures.

1.2 Information We Collect Automatically

When you use our Service, certain information is collected automatically:

Usage Data: We track which pages you visit, what features you use, and how much time you spend on different parts of the platform. This includes analytics data collected through Google Analytics to understand user behaviour and improve our services.

Feature-Usage Counts: Separately from Google Analytics, and whether or not you accept analytics cookies, our own servers keep a small count of the main features you use, for example starting or signing a will, uploading a document to your vault, adding an asset or liability, tracking an investment account, recording a stay in the residency tracker, confirming a check-in, booking a consultation or sending a message to the AI assistant. For each feature we store only which feature it was, which of our brands you were using at the time, how many times you have used it, and when you first and last used it. We do not record what you entered, where you were, or your IP address in these counts, and they are never shared with a third party. We use them to understand which features are used on each of our brands and to make the service better; our legal basis is our legitimate interests (UK GDPR Article 6(1)(f)). Retention is set out in Section 8.

Device Information: We collect information about the device you use, including your browser type and version, operating system, device model, screen resolution, device fingerprints, and IP address.

Belongings Map Records: If you use the Belongings Map, we store what you choose to record about where your belongings, keys and original documents are kept and how to reach them, together with the people you choose to share each entry with and when (straight away, on incapacity or after a verified death). We store this text encrypted at rest. It is shown only to you and, once the release you chose has happened, to the people you named and to your accepted executors after a verified death, and every time one of them views an entry we record it in our audit log. We never hold, collect, insure or check any physical item. We do not ask for PINs, codes or passwords and warn you if an entry looks like one. Our legal basis is the performance of our contract with you (Art. 6(1)(b)). Entries are kept until you delete them or close your account.

Location Data: We collect location data derived from your IP address (city, region, country) for security monitoring and to comply with regional laws.

Security Data: We monitor login attempts including timestamps, success/failure status, IP addresses, and device information. We track changes to security settings and monitor for suspicious activity patterns.

Session Information: We track your active sessions across devices, including session duration, last activity time, and session type.

Error and Diagnostic Data: When the platform encounters a fault, we automatically generate an error report so that we can diagnose and fix it. These reports include technical details of the error (such as the error message and stack trace), the page or feature where it occurred, and information about your browser, operating system and device. If you are signed in when an error occurs, your account identifier may be attached to the report as context; before the report is stored, it is passed through a redaction filter that removes directly identifying personal data (see Section 5). Error reports are processed by a self-hosted error-monitoring system (GlitchTip) running on our own infrastructure and are not transmitted to any third-party error-tracking provider.

1.3 Cookies and Tracking Technologies

We use cookies and similar technologies to enhance your experience. We categorise cookies as follows:

• Strictly Necessary: Required for the platform to function (authentication, security, session management). These cannot be disabled.
• Functional: Remember your display preferences (your light or dark theme, your sidebar layout, and which guidance messages you have dismissed). You may disable these in your cookie preferences.
• Analytics: Help us understand how you use the platform (Google Analytics). You may opt out of these.

You can manage your cookie preferences at any time through the cookie settings available on our platform. Non-essential cookies are only set after you provide consent, in compliance with the Privacy and Electronic Communications Regulations (PECR) and the ePrivacy Directive.

The same categories and the same consent govern the information we keep in your browser's own storage (local storage and session storage), not only cookies: storage in a category you have not granted is not written, and withdrawing a category clears what was already stored under it. Our Cookie Policy publishes the full inventory of both.

1.4 Information You Are Required to Provide, and the Consequences of Not Providing It

Under UK GDPR Article 13(2)(e), we must tell you whether you are obliged to provide your personal data (because the law requires it, or because it is necessary to enter into or perform our contract with you) and what happens if you do not provide it. Most of the information described above is provided entirely at your discretion, but a limited set of fields are required for the reasons set out below.

• Account information (name and email address), a contractual requirement: we need this to create your account and provide the Service to you. If you do not provide it, we cannot open an account or make the platform available to you.
• Identity-verification and address-proof documents, a statutory requirement in certain jurisdictions: where identity verification applies, we collect these to meet our anti-money-laundering and regulatory obligations. If you choose not to provide them, you will be unable to complete identity verification, and we may be unable to offer you a paid plan or any feature or jurisdiction that depends on a verified identity. You remain free to use the parts of the Service that do not require verification.
• Payment and Direct Debit details, a contractual requirement: if you choose a paid plan, we need your payment method (and, for Direct Debit, your bank account details) to activate and collect your subscription. If you do not provide them, we cannot activate a paid subscription, although you may continue to use any free features.

Everything else is optional. All other personal data (including your will content, family and beneficiary details, residence history, marketing preferences, and the documents you choose to upload) is provided voluntarily. You are not obliged to provide it, and withholding any of it does not prevent you from holding an account; it simply means the related feature cannot be completed or kept up to date until you do. You can update or remove optional information at any time, and you can ask our Data Protection Officer through our contact form if you are unsure whether a particular field is required.

2. Legal Basis for Processing

Under the UK GDPR and EU GDPR, we process your personal data on the following legal bases:

Why we use consent for recording: Given the sensitivity of legal consultations, the potential vulnerability of individuals seeking legal advice, and the privileged nature of solicitor-client communications, we have chosen explicit consent as the legal basis for recording. This provides you with maximum control over whether your consultation is recorded.

Special-category data (UK GDPR Article 9): Will instructions, video consultations, AI transcripts, and AI-assisted will composition can incidentally reveal data about your health, religious or philosophical beliefs, racial or ethnic origin, or sexual orientation. We rely on your explicit consent under Article 9(2)(a) as the special-category basis for all of these purposes; that consent is captured when you submit the relevant will information or accept the consultation-recording / Third-party AI processing prompts. Retention of executed wills and the supporting documents that substantiate them additionally relies on Article 9(2)(f) (establishment, exercise, or defence of legal claims). You may withdraw consent at any time as described in Section 10; withdrawal does not affect the lawfulness of processing carried out before withdrawal.

Where Article 9 is not engaged: Passkey credentials and device-trust attributes (Section 1.1) are processed using non-biometric signals only. Biometric matching happens on your device and we never receive biometric templates. Identity-verification documents are processed only for identification, not for any special-category purpose, and are not transmitted to any third-party AI provider unless you give explicit, per-document consent to enhanced external processing (UK GDPR Article 6(1)(a)).

Legitimate Interests Assessment: For each purpose above where we rely on legitimate interests (Art. 6(1)(f)), we have conducted a Legitimate Interests Assessment that weighs our interest against your rights and reasonable expectations. You may request a summary of any of these assessments from our Data Protection Officer through our contact form.

2B. Information We Receive from Others

Most of the personal data we hold is provided by you directly. In a limited number of flows, however, we receive personal data about you from someone other than you, for example, from a person who invites you, or from your employer. Where this happens, UK GDPR Article 14 requires us to tell you the categories of data concerned, the source it came from, the lawful basis on which we process it, and how long we keep it. The table below sets out each of these indirect-collection flows.

The other standard disclosures still apply. The purposes for which we process indirectly collected data, the recipients we may share it with, any international transfers, and your rights are the same as for data you provide directly; they are described in Sections 3, 4, 9 and 6 respectively. None of the data in the flows above is obtained from publicly accessible sources.

Notifying you (Article 14(3)). Where Article 14 requires it, we aim to inform affected individuals about this processing, at the latest within one month of receiving the data, or, if we use the data to communicate with you, no later than our first communication with you. If you receive an invitation or notification from us and you did not expect it, you may object to the processing or ask us to erase your data at any time by contacting our Data Protection Officer through our contact form (see Section 6 for your full rights).

3. How We Use Your Information

3.1 Service Provision

We use your personal information to provide our will creation and management services, facilitate video consultations between you and legal professionals, process payments, and provide customer support. Your will information is used to generate legally compliant documents according to your wishes and jurisdiction requirements.

3.2 Service Improvement

We analyse anonymised, aggregated usage patterns (how users navigate and interact with the platform) to identify areas for improvement. This is analytics about how the platform is used, and is separate from AI model training. Your raw documents, entries and personal details are never used to train any AI model. To improve our own models we may use de-identified interaction data from which names, addresses and other identifying details have been removed. Third-party AI providers are contractually prohibited from training on your data.

Help Hub Improvement: We analyse Help Hub chatbot questions and feedback to identify gaps in our frequently asked questions, improve answer quality, and derive new help articles. Feedback marked as “incorrect” is reviewed by our team to correct inaccurate responses.

3.3 Communication

We send essential service-related notifications (account updates, security alerts, booking confirmations, and reminders about invoices a legal professional has issued to you through the platform). With your explicit consent, we may send marketing communications about new features and special offers. You can opt out of marketing communications at any time.

Reminders and account-closure warnings: If you leave something part-way, we may email you a short reminder: a will you have not begun or a draft that has stalled, a professional application that is unfinished, waiting on your reply or taking longer than usual to review, or practice set-up steps still open after your professional account is approved. We send each reminder at most twice and stop as soon as you make progress. These reminders use only the state of your account (for example, whether a will exists, the step you reached and when you were last active) and never the contents of your will or your Document Vault. Our lawful basis is our legitimate interests (UK GDPR Article 6(1)(f)) in helping you complete what you started on the platform. They belong to the “Suggestions and prompts” email category, which you can switch off at any time from the link in any reminder or from your email preferences. Warnings that your account is due to be closed after a long period without sign-in are different: they precede the deletion of your data, so they are sent as service messages and cannot be switched off.

3.4 Legal and Security

We process your information to comply with legal obligations (tax reporting, anti-money laundering), detect and prevent fraud, enforce our terms of service, and protect the rights and safety of our users.

3.5 Artificial Intelligence and Machine Learning

Self-Hosted AI: We operate self-hosted AI systems on our own infrastructure for privacy-sensitive processing tasks. These systems process your data without transmitting it to any third party. Identity document verification, insurance document analysis, and the default processing mode for will document import and will generation all use self-hosted AI exclusively.

Document Processing: When you upload will documents, we use AI to extract information and populate your digital will, including OCR for handwritten documents.

Will Generation: When generating a will using AI-assisted composition, you choose how your data is processed. With Internal private processing (the default), your will data is processed entirely on our self-hosted AI system and no personal information is shared with any third party. With Third-party AI processing (opt-in), your will data is anonymised (names, addresses, and values replaced with placeholders) and sent to our third-party AI provider for clause composition (see sub-processors for the current provider). The anonymised data contains no personally identifiable information. You make this choice each time you generate or regenerate your will.

Document Import: When importing existing will documents, you choose how your document is processed. With Internal private processing (the default), your document is processed entirely on our self-hosted AI system and no document content is shared with any third party. With Third-party AI processing (opt-in and with your explicit consent), your full document content is transmitted securely to our third-party AI provider for structural analysis. It is not anonymised (the provider receives the complete document, including any personal details it contains), which is why it is sent only with your explicit consent. See sub-processors for the current provider and processing terms. You make this choice each time you import a document.

Professional Tools: If you offer professional services through the platform, two professional tools can use AI. Engagement-letter quality review checks the wording of your engagement letters; with Third-party AI processing (opt-in), the text is anonymised (names, addresses, and organisations replaced with placeholders) before it is sent to our third-party AI provider, and de-anonymised when the feedback returns. Service rate-card import extracts your fees from an uploaded document; with Third-party AI processing (opt-in and with your explicit consent), the full document content is transmitted to our third-party AI provider and is not anonymised. Both default to Internal private processing on our self-hosted AI, and you make the choice each time.

Consultation Transcription: Consenting to a recording does not by itself allow it to be transcribed or summarised. When you are asked for recording consent, you can also choose whether the recording may be transcribed and whether an AI-generated summary may be produced from the transcript; we store each choice with your consent record. We only transcribe a recording when the participants whose consent the recording needs have agreed to transcription, and only produce a summary when they have agreed to that as well; otherwise the recording is kept untranscribed and shown as such. Where you agree, audio from your consultation is transcribed locally on our self-hosted speech-to-text engine (the open-source whisper.cpp engine running on our own infrastructure). Your audio is not transmitted to any third-party transcription provider, and your raw recordings are never used to train any AI model. To improve our own models we may use de-identified interaction data from which names, addresses and other identifying details have been removed. Transcripts are AI-generated estimates and are not verbatim legal records.

3.6 Automated Decision-Making (UK GDPR Article 22)

Our platform uses AI to assist with will generation, document analysis, and consultation transcription. Under Article 22 of the UK GDPR (and the EU GDPR where it applies to you), you have the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects concerning you or similarly significantly affects you. We do not make decisions of that kind. Where an automated check could lead to such a decision, a member of our team makes the decision.

How we use automation: AI assists in drafting will documents based on your inputs and in extracting information from uploaded documents. These are assistance tools. The final will document is always subject to your review and approval before it has any legal effect. No binding legal decisions are made by AI alone.

Your rights: You may request human review of any AI-generated content or automated analysis. You may express your point of view and contest any output you believe to be inaccurate. To request human review, please use the contact form on our platform.

3.7 Community Forum Email Notifications

While browsing our community forum (community.thewill.ai) as an anonymous visitor, you may be offered an optional service to receive a single email notification if a qualified professional replies to the topic you were reading. This is entirely optional and separate from creating an account.

What we collect: your email address, the topic URL and identifier, the prompt that led to the capture, and the timestamps of opt-in, confirmation, and unsubscribe. We do not collect your name, address, or any other personal details through this service.

Purpose: to send one notification email when a new professional reply is posted to the topic you registered interest in, and to offer the option of creating a full Orchard72 account at that point.

Legal basis: your explicit consent under UK GDPR Article 6(1)(a). We operate a double opt-in process. After you submit your email, we send a confirmation message containing a unique token, and we will only send notifications once you have confirmed via that link.

Your rights: every notification email includes both an RFC 8058 List-Unsubscribe header and a one-click unsubscribe link. Unsubscribing removes you from the list immediately. You may also exercise any other right listed in Section 10 (Your Data Rights) in respect of this data.

Retention: the watch record is kept until you unsubscribe, or for 12 months of inactivity (whichever is sooner), after which it is deleted. If you later create a Orchard72 account using the same email, the watch record is linked to your user profile for audit purposes and otherwise follows the standard account-data retention schedule in Section 8.

4. How We Share Your Information

We do not sell your personal information. We may share your information in the following circumstances:

4.1 Sub-Processors

We work with trusted third-party service providers (sub-processors) who help us deliver our services. Each provider operates under a Data Processing Agreement (DPA) that contractually obliges them to protect your data. For a complete list of our sub-processors, please see our Sub-Processor List.

Key sub-processors include:

• Daily.co: Provides our video consultation infrastructure. Processes video/audio streams and connection metadata.
• Cloudflare: Provides CDN, R2 object storage (for documents and recordings), and edge computing. Documents, recordings, and videos are stored with the provider's server-side encryption at rest and accessed only through short-lived signed URLs; an additional per-document key (envelope) encryption layer seals each stored object under its own key before it reaches the provider.
• Stripe: Processes payments securely, including subscription billing, Direct Debit mandate management (BACS, SEPA, ACH, BECS), revenue share via Stripe Connect, and tax calculation. Your payment card and bank account information is handled directly by Stripe and is not stored on our servers. Stripe also processes professional bank details, revenue share calculations, and tax calculation data. For Direct Debit payments, Stripe creates and manages the mandate on your behalf and collects payments from your bank account in accordance with the applicable Direct Debit scheme rules.
• Brevo (formerly SendinBlue): Manages email delivery for transactional emails and, with your consent, marketing communications.
• Third-party AI provider: Provides AI for will generation, will document import, professional engagement-letter quality review, and professional service rate-card import, only when the user selects Third-party AI processing. For will generation and engagement-letter quality review, receives anonymised text (no PII). For will document import and service rate-card import, receives the full document content with the user's explicit consent. Broker and asset statements are never sent to a third-party AI provider. They are processed on our own servers only. Never used as default: requires per-operation opt-in. See our sub-processors list for the current provider and data processing terms.
• Google Analytics: Helps us understand how users interact with our platform (with your consent for analytics cookies).
• Infisical: Manages encrypted application secrets. Does not process your personal data directly.
• Apple Inc.: Processes in-app purchases for iOS subscriptions and one-time products. Data processed includes transaction receipts, subscription status, and Apple account identifiers. Located in the United States; transfers safeguarded by SCCs with UK Addendum and EU-US Data Privacy Framework certification.
• Google LLC (Google Play): Processes in-app purchases for Android subscriptions and one-time products. Data processed includes purchase tokens, subscription status, and Google account identifiers. Located in the United States; transfers safeguarded by SCCs with UK Addendum and EU-US Data Privacy Framework certification.
• MaxMind, Inc.: Provides IP geolocation for regional pricing, fraud prevention, and device-trust scoring used in login-activity security monitoring (IP-derived country, region, and city are stored against each sign-in device). We use a locally hosted MaxMind GeoLite2-City database; IP addresses are looked up locally and no personal data is transferred to MaxMind.
• Twilio Inc.: Delivers SMS-based multi-factor authentication codes and verifies mobile phone numbers via the Twilio Verify service, when you choose SMS as a second factor or verify a mobile number on your account, and delivers appointment text messages (reminders and reconfirmations) and receives your STOP / START replies to them. Processes mobile phone numbers, one-time verification codes (short-lived), message content, your replies, and delivery status metadata. Located in the United States; transfers safeguarded by SCCs with UK Addendum and EU-US Data Privacy Framework certification.
• Telnyx LLC: Delivers the same SMS messages as Twilio (verification codes and appointment text messages) for the destinations where it is our primary route, with Twilio as backup, and receives your STOP / START replies to them. Processes mobile phone numbers, message content, your replies, and delivery status metadata. Located in the United States; transfers safeguarded by SCCs with UK Addendum.

4.2 Joint Controller Arrangement (Video Consultations and Direct Messaging)

When you participate in a video consultation or exchange direct messages with a legal professional through our platform, Orchard72 and the legal professional act as joint controllers of the consultation and messaging data under GDPR Article 26. This means:

• Orchard72 is responsible for: The technical infrastructure (video platform, recording storage, transcription, messaging system), data security (encryption, access controls, audit logging), sub-processor management (DPAs with Daily.co, Cloudflare), facilitating your data subject access requests, and breach notification to supervisory authorities.
• The legal professional is responsible for: The legal basis for processing your data for legal advice purposes, managing legal professional privilege, communicating with you about how your data is used for their services, and notifying their own regulatory body in the event of a data breach. For direct messaging, the professional bears responsibility for the quality and accuracy of any advice given via messages.

Regardless of the internal allocation of responsibilities, you may exercise your data protection rights against either party.

4.3 Will Review Services

If you opt for will review services, we share relevant information with qualified legal professionals who are bound by professional confidentiality obligations and our data protection agreements.

4.3A Independent Second Opinions

If you ask for an independent second opinion on a will a legal professional prepared for you, we disclose that will to a second professional you have not previously engaged. This is a new disclosure to a new recipient, so we make it only on your explicit instruction, recorded at the point you make it. Nothing is disclosed by default, and you can see what was disclosed, to whom, and when, from your privacy dashboard.

What we disclose to the second professional:

• Always: the fixed version of the will they are opining on; the instructions and answers you gave when it was prepared, including your family, assets, jurisdiction and any concerns you recorded; and the scope of work agreed with your first professional, so that they do not criticise work your first professional was never engaged to do.
• Never: your first professional’s internal working notes, their internal tasks, or their fee.
• Only if you choose: your first professional’s written summary, their recommendations, and the decisions you made on them. This is off unless you turn it on, because an independent opinion is less independent once it has been anchored on someone else’s reasoning.
• Only if you send it: the second professional’s report, or individual points from it, going back to your first professional. Sending any point tells your first professional that you obtained a second opinion.

Mirror wills. Where your will is linked to a partner’s, a second opinion covering both wills means disclosing your partner’s will to a professional your partner did not engage. We do this only where both of you have given the explicit consent to compare the two wills that we ask for separately when the wills are linked, the same consent that governs every other cross-will comparison. Where that consent is absent, the second professional sees your will alone and the report says so. Where we tell one partner that the other has amended their will, we disclose that fact only, never any content of the other will.

Legal basis. Disclosing will contents to a second professional relies on your explicit consent (UK GDPR Article 6(1)(a), and Article 9(2)(a) where the will contains special category data such as health information). Disclosing a partner’s will in a mirror pair relies on that partner’s own explicit consent, given by them and not by you. You can withdraw consent at any time; withdrawal stops further disclosure but does not undo a disclosure already made, and the second professional will keep their own record of the engagement as their professional rules require. Each professional is a separate, independent controller of the information they receive.

4.3B Will-File Disclosure Requests Sent to Another Firm

Where someone has died and a legal professional using the Platform needs the file behind that person’s will, they can ask the firm that holds it for a copy. That firm is usually not on the Platform at all. When the request is raised, we send the correspondence ourselves, from our own systems, on that professional’s instruction and under their name, and we host a secure page on which the receiving firm can reply without creating an account. This is the one route on which we send correspondence to a third party on a user’s behalf; it is raised by a legal professional about a person who has died, and it is never used to contact anyone on a living account holder’s behalf.

What we hold about the receiving firm, and why:

• Correspondence details. The firm name, the email address and, where given, the telephone number the requesting professional supplies for the firm. We store these encrypted and use them to deliver the request, to confirm that the person opening the secure page is the addressee rather than someone the message was forwarded to, and to carry the reply back.
• The request and the reply. The name of the person who has died, the interest the requester has declared and the evidence they gave for it, and whatever the receiving firm chooses to send back. A reply is filed against the requesting professional’s matter.
• A record of the exchange. When the request was sent, whether it was delivered, when the secure page was opened, and the outcome. We keep this so that a firm which believes it was contacted wrongly can be told exactly what happened.

Legal basis. A firm we contact this way is not our customer and has asked us for nothing, so we do not rely on their consent and we do not pretend to. We process their correspondence details on the basis of legitimate interests (UK GDPR Article 6(1)(f)): the interest is in letting an estate be administered by putting a properly evidenced request to the firm most likely to hold the file, which is a long-established professional practice, and the processing is limited to a single named matter, uses only business contact details a firm publishes to be contacted on, and carries a refusal route in the message itself. We have weighed that against the firm’s own interests and consider it proportionate. A firm may object to our processing at any time using the contact details in Section 14, and may ask us to stop sending it requests altogether, which we will honour for every requester and not only the one who wrote.

Telling the firm where the request came from. Because we obtained the firm’s details from the requesting professional rather than from the firm, our Article 14 duty to tell them applies. We discharge it in the request itself: every message names the requesting professional and their practice, says that we sent it on their instruction, links to this notice, and gives the route to object. We do not send unattributed requests, and we do not let a requester suppress their own identity.

Limits. We do not add a receiving firm to any marketing list, we send them nothing except the requests addressed to them and the messages needed to handle one, and we do not sell, rent or publish their details. There are limits on how many requests a single requester may raise, and on how many may be aimed at one firm, so that the channel cannot be used to work through a list of firms.

4.3C A Partner's Own CRM, Only on a Consent You Give to That Partner

A legal professional who offers our service under their own brand (a white-label partner) can connect their own customer relationship management (CRM) system, such as HubSpot, so that people who come to us through their partner page appear in it. Partner CRMs are a separate category of recipient: the partner is an independent controller of what reaches its CRM, not our processor, and it decides for itself how that copy is used and kept, in line with the Information Commissioner's data sharing code.

• Off by default. Nothing is sent to a partner's CRM unless you have given that named partner your own recorded consent. Consent given to one partner is never read as consent for another, and consent you give for anything else on the platform never counts here.
• Three fields only. What is shared is your name, your email address and the status of your journey with that partner (for example, whether a referral is open or complete). Your will, your estate details, your documents and anything else you record with us are never sent.
• An agreement before anything is sent. A partner must first accept our Partner CRM Data-Sharing Agreement. We keep a versioned record of which version the partner accepted and when; if we change the agreement, sharing stops until the partner accepts the new version.
• You can withdraw it. You can withdraw your consent at any time from Professional access in your account, as easily as you gave it. Once withdrawn, nothing further is sent. What the partner already holds is then held by the partner as controller, so a request to access, correct or erase that copy should go to the partner as well as to us.

Legal basis. We disclose these fields to the partner on the basis of your consent (UK GDPR Article 6(1)(a)). The partner's CRM provider is chosen by the partner, not by us, so it does not appear on our sub-processor list.

4.3D WhatsApp Support, Only If You Choose to Start a Chat

On plans that include WhatsApp support, you can choose to message our support team on WhatsApp from your account support page or, while signed in, from our Contact Us page. Before the chat can start, we show you a notice that it takes place on WhatsApp, run by Meta, and ask you to tick to confirm you have read it; until you do, nothing happens. When you confirm and start the chat, we open a support ticket on your account (recording your name, email address, plan support level and the ticket reference) and open WhatsApp on your device with a message carrying that reference. When your first message arrives with that reference, we link your WhatsApp number to the ticket and keep your messages on it. Our support team's replies are then sent back to you on WhatsApp through Meta's WhatsApp Business service, which means the reply text and your WhatsApp number pass through Meta. We only send those replies while your confirmation of the current notice is on file; the email copy of every reply still reaches you either way. You can withdraw that confirmation at any time with the Withdraw WhatsApp consent action on your account support page; from then on we send you no replies on WhatsApp and no longer link your WhatsApp messages to your tickets, and starting a WhatsApp chat again asks you to confirm the notice first. If someone messages our WhatsApp number without a ticket reference, we send one automated reply pointing them to the support page and open no ticket. Anything you send in the chat travels through WhatsApp, which is operated by Meta under its own terms and privacy policy, because you chose that channel. The ticket is handled and kept like any other support request. Our lawful basis is performance of our contract with you (Art. 6(1)(b) UK GDPR). WhatsApp is never the only way to reach us: the support form and email remain available on every plan.

4.4 Legal Requirements

We may disclose information when required by law, including:

• Court orders or legal processes
• Government requests from competent authorities
• Protection of rights, property, and safety
• Investigation of suspected violations of our terms

Where a court order or legal request relates to consultation data that may be subject to legal professional privilege, we will notify the relevant legal professional before disclosure (unless prohibited by law) to allow them to assert privilege.

4.5 Business Transfers

In the event of a merger, acquisition, or sale of assets, your information may be transferred. We will notify you of any such change and ensure the receiving entity is bound by equivalent data protection obligations.

4.6 If We Discontinue the Service or Become Insolvent

The paragraph above describes a business sold as a going concern. A discontinuation, or an administration, liquidation or receivership, is a different situation, and a clause about mergers does not cover it. An administrator or liquidator is an officer with duties of their own and is not bound by a promise we made about a sale. We therefore set out separately what would happen to your personal data.

Who would hold your data, and who could receive it. If we decide to discontinue the Service, we remain the controller of your personal data throughout the wind-down. If an insolvency practitioner, administrator, liquidator or receiver is appointed over the company, that person, and the professional advisers assisting them, would be recipients of your personal data in the course of carrying out their statutory functions. We tell you this now because it is a realistic recipient, not a remote one, and Article 13(1)(e) of the UK GDPR is about telling you in advance rather than at the moment it happens.

If you are working with a legal professional through the platform. Where you have an open matter with a legal professional when we give notice, we would give that professional your contact details, and give you theirs, so that the two of you can continue directly without us. Our lawful basis is our legitimate interests and yours (Article 6(1)(f)) in your unfinished legal work not being stranded by our closure; the professional already holds your matter and already owes you duties under their own regulator's rules, so what we are sharing is the means of contact rather than anything about your affairs they do not already know. Matter content that includes health information (such as an advance decision or a health-and-welfare lasting power of attorney) is treated separately and is not passed on this basis. You may object to the exchange of contact details, in which case we will not make it.

Exporting your data. We would give not less than 90 days' notice before access ends, and throughout that period you would be able to export your documents and your personal data in a structured, commonly used and machine-readable format. This is the same right of portability you have under Article 20 of the UK GDPR at any other time; the commitment in our Terms of Service is in addition to it, not a substitute for it, and it is given without condition.

Some of the data we hold for you is encrypted under keys held in escrow, and the export therefore depends on those keys being available at the time. We treat that as an operational obligation we must meet rather than an excuse we may rely on, and we say so here so that the dependency is disclosed rather than discovered.

What happens after the window closes. Personal data is deleted after the export period ends, in accordance with the retention schedule in Section 8, and deletion is completed before the company is dissolved. Particularly sensitive information (including the content of advance decisions and health-and-welfare lasting powers of attorney, and identity-verification material) is deleted first. We do this because once a company is dissolved there is no controller: no one to answer an access request, no one to action an erasure request, and no one accountable for anything still held. Deleting everything beforehand is the only way that position can be made safe, and it is why dissolution is not filed until deletion is confirmed.

Records that are not personal data, such as the confirmation that deletion was completed, are retained with the company's own records.

Your rights are unaffected. Your rights of access, rectification, erasure, restriction, portability and objection continue to apply throughout a wind-down, and you may exercise them in the ordinary way described in Sections 6 and 7. Your right to complain to the Information Commissioner's Office is unaffected.

5. Data Security

We implement industry-standard security measures to protect your information:

Encryption: All data in transit is encrypted using TLS 1.2 or higher. Data at rest is protected by the storage provider's server-side encryption (Cloudflare R2, AES-256). On top of that, an application-level layer seals each file under its own key (envelope encryption), so a stored object cannot be read without that key. This layer is active and covers the documents you upload to your vault, your video messages, and consultation recordings. See “Known limitations of at-rest encryption” below for what it does and does not protect against.

Access Controls: We implement strict authentication and authorisation measures. Access to consultation recordings is logged with full audit trails (who accessed, when, why, from which IP address). Actions a legal professional takes on your client records are likewise recorded in an audit trail, for example verifying or rejecting an identity document, recording the outcome of manual identity checks, uploading verification captures, creating compliance documentation, or generating a compliance statement. Each entry records the professional involved, the action taken, the record affected, and the time, so that what was done with your information can always be evidenced. Access is restricted based on legal basis and role.

Known limitations of at-rest encryption: we record this so that you can decide what to store and share with awareness of the current control set. The application-level (envelope) encryption layer described above is active, and each stored file is sealed under its own key, so a copy of the object taken from storage is unreadable on its own. The key that unwraps those per-file keys is held by us and not by you, because our service has to be able to decrypt a file in order to show it to you. That makes this minimum-knowledge encryption rather than end-to-end encryption, and the practical remaining limitation is that a member of staff with production infrastructure access could technically cause a file to be decrypted. That path is constrained rather than open: access is restricted by role, privileged access is time-limited and reason-bound, and every use of it is recorded in an audit trail. It is not, however, mathematically impossible, and we would rather state that plainly than imply otherwise. No method of electronic storage or transmission is completely secure, and we cannot guarantee absolute security.

5.1 Staff Access Roles

Internal access to personal data is partitioned into role-based groups under the principle of least privilege (UK GDPR Article 32(1)(b)). Each role grants the minimum set of model permissions required for a defined business function. Role membership is auditable and reviewed on a recurring cadence.

• 5.1.1 Customer Support. Read-only access to a masked view of user records (name, registered email address, country, plan tier, and subscription status). No access to will content, asset registers, vault documents, beneficiary records, or any field designated as sensitive under our internal masking manifest.
• 5.1.2 Billing Operations (Customer Ops). The Customer Support permissions, plus read-write access to subscription and payment-status records for the purposes of refunds, plan changes, and dunning. Personal payment-card data is held by our payment processor (Stripe) and is not accessible to Orchard72 staff at any level.
• 5.1.3 Engineering. Read-only access to operational artefacts (application errors, deployment records, webhook logs). Application error reports are passed through a PII-redaction filter before storage so that identifying user data is not visible to engineering personnel. No access to will content, account records, or vault documents.
• 5.1.4 Professional Onboarding. Read-only access to the details extracted from a legal professional's submitted profile, and the ability to issue, resend and revoke onboarding invitations to legal professionals. The invitee's email address is masked, and each invitation action is recorded as an audit event naming the staff member. No access to consumer accounts, will content, asset registers or vault documents.
• 5.1.5 Quality Assurance (test environments). The ability to create and delete test legal-professional records, and their dependent verification and conflict-check records, for testing purposes. This role is granted only in our development and staging environments and holds no permissions in production. No access to consumer accounts, will content, asset registers or vault documents.
• 5.1.6 Quality Assurance (production, read-only). Read-only access to a masked view of user records, subscription state, support tickets and application error reports, for the sole purpose of confirming that a reported defect is real. No write access to anything, and no access to audit-event or security-event records. Unmasking a field is a separate action that is recorded as an audit event naming the staff member.
• 5.1.7 Marketing. Read-write access to the business-to-business lead register (law firms and the partners named in their public listings) and to outbound campaign records. Every personal-data column on a lead record, such as a named partner's work email address and direct line, is masked, and each reveal is recorded as an audit event naming the staff member. No access to consumer accounts, will content, asset registers or vault documents.
• 5.1.8 Content. Read-write access to published content only: news and blog articles with their sources and categories, and help-centre articles and frequently asked questions. No access to any record holding customer data, including the subscription records that determine who receives which news digest.
• 5.1.9 Charity Partnerships. Read-write access to charity records, charity applications and charity invitations, for onboarding and partnership management. Free-text application data, staff review notes, rejection reasons and invitee email addresses are masked, with each reveal recorded as an audit event. Charity team membership is read-only, so partnerships staff cannot add themselves to a charity's team, and the applicant's own user account cannot be read at all.
• 5.1.10 Business Analytics. Access to an aggregate business-metrics dashboard (counts and totals such as marketing funnel, subscription mix and charity uptake) and to nothing else. This role deliberately carries no record-level access to any of the data behind those counts.
• 5.1.11 Audit. Read-only access to audit-event records, security-event records, and backup-code metadata for the purposes of access review and compliance attestation. No access to underlying application data.
• 5.1.12 Founder (privileged). Override access reserved for documented exceptional circumstances (lawful disclosure orders, security-incident response, system faults where lower-privilege roles cannot complete recovery). Founder accounts see the same masked view as every other role by default. Reading an unmasked record requires a time-limited, reason-bound break-glass grant recorded against the authorising incident, and each reveal writes a structured audit event naming the account and the record. This role is not used for day-to-day operations.

Three controls apply across every role above:

• Mandatory two-factor authentication. All staff sessions to the administrative console require a confirmed TOTP authenticator. Sessions without a verified second factor cannot reach personal data, regardless of role.
• Default-masked sensitive fields. Date of birth, identity-document numbers, telephone numbers, and postal addresses are rendered as masked tokens in the administrative console by default. Revealing a masked field on a customer account requires a time-limited access grant tied to a support ticket and a stated reason. Every reveal, on any record, emits a structured audit event referencing the field and the staff member; the plaintext value is never copied into the audit record.
• Seven-year audit retention. Audit events are retained for seven years from creation in an append-only store: once written, a record cannot be changed, and the database itself blocks edits. Records are removed only by a scheduled retention task once they are older than the retention window. The detailed sign-in and security log behind these records is kept for 12 months.

On request through our contact form, users may obtain a copy of audit-event records pertaining to access to their own data, subject to identity verification.

Privilege Preservation: We do not access the content of consultation recordings except: (a) at the request of the legal professional for technical support, or (b) in response to a valid court order (with notice to the professional where possible). Our sub-processors are contractually bound to confidentiality.

Regular Audits: Our security team conducts regular assessments and vulnerability testing.

Incident Response: We have detailed procedures for managing security incidents, including rapid response protocols and communication plans to notify supervisory authorities within 72 hours of becoming aware of a personal data breach (as required by GDPR Article 33), and to notify affected users without undue delay where the breach is likely to result in a high risk to their rights and freedoms.

Data Protection Impact Assessments: In accordance with GDPR Article 35, we have conducted Data Protection Impact Assessments (DPIAs) for our high-risk processing activities, including AI-powered will generation, video consultation recording, and AI transcription services. These assessments evaluate the necessity, proportionality, and risks of our processing and identify mitigation measures. Summaries of these assessments are available upon request by contacting us through the contact form on our platform.

6. Your Rights by Jurisdiction

Your data protection rights depend on where you are located. Below is a summary of rights available under the major data protection frameworks that may apply to you.

6.1 UK and EU (GDPR / UK GDPR)

6.2 United States (CCPA / CPRA and State Laws)

If you are a resident of California or other US states with comprehensive privacy laws (Colorado, Virginia, Connecticut, Utah, Texas, Montana, Oregon, and others), you have the right to:

• Know what personal information we collect, use, and disclose
• Delete your personal information (subject to exceptions)
• Correct inaccurate personal information
• Opt out of the sale or sharing of personal information: we do not sell or share your personal information for cross-context behavioural advertising
• Limit the use and disclosure of Sensitive Personal Information (such as identity-document and financial details) to the purposes permitted under the California Privacy Rights Act (Cal. Civ. Code §1798.121). We use Sensitive Personal Information only to provide the services you have asked for and for the purposes described in this policy, and not to infer characteristics about you
• Opt out of automated decision-making technology, including profiling that produces legal or similarly significant effects, where the California Privacy Rights Act applies, and to request information about the logic involved
• Non-discrimination for exercising your privacy rights

Notice at Collection. Consistent with Cal. Civ. Code §1798.100(b), we give you notice at or before the point at which we collect your personal information. The categories of personal information we collect, the purposes for which each category is used, the categories we disclose, and how long we retain each category are described in Sections 1, 3, 4 and 8 of this policy. We do not sell or share your personal information for cross-context behavioural advertising. This Notice at Collection is made available through a link to this policy presented at or before the point of collection; it is distinct from, and provided in addition to, this overall privacy policy.

6.3 Canada (PIPEDA / Quebec Law 25)

If you are located in Canada, the Personal Information Protection and Electronic Documents Act (PIPEDA) and, for Quebec residents, the Act respecting the protection of personal information in the private sector (as modernised by Law 25) apply to our handling of your personal information. Consistent with section 5 of PIPEDA, we observe the ten fair-information principles set out in Schedule 1: we are accountable for personal information under our control and have designated a Data Protection Officer (Principle 4.1) reachable through our Data Protection Officer contact form; we identify the purposes for which personal information is collected at or before the time of collection (Principle 4.2); we obtain meaningful consent (express or, where appropriate, implied) for the collection, use and disclosure of personal information, and you may withdraw consent at any time subject to legal or contractual restrictions (Principle 4.3); we limit collection to what is necessary for the identified purposes (Principle 4.4); we limit use, disclosure and retention to those purposes and to the retention periods set out in Section 8 of this policy (Principle 4.5); we take reasonable steps to keep personal information accurate, complete and up to date (Principle 4.6); we protect personal information by security safeguards appropriate to its sensitivity (Principle 4.7); we make our policies and practices relating to the management of personal information readily available, including through this policy (Principle 4.8); on written request we provide you with access to your personal information together with an account of its use and disclosure (Principle 4.9); and we provide a procedure for challenging compliance with these principles by contacting our Data Protection Officer (Principle 4.10). You also have the right to be notified where a breach of security safeguards involving your personal information creates a real risk of significant harm. Complaints may be lodged with the Office of the Privacy Commissioner of Canada (OPC) at priv.gc.ca.

If you are located in Quebec, Law 25 confers additional rights, including the right to data portability (to receive the personal information you have provided to us in a structured, commonly used technological format), the right to request the cessation of dissemination, or the de-indexing, of personal information where its dissemination contravenes the law or a court order or causes you serious injury that outweighs the public interest, and the right to be informed when a decision concerning you is based exclusively on automated processing and, on request, to submit observations to a person in a position to review that decision. Complaints under the Quebec regime may be lodged with the Commission d’accès à l’information du Québec (CAI) at cai.gouv.qc.ca.

6.4 Brazil (LGPD)

Brazilian residents have rights to access, correct, delete, port, and anonymise their personal data, as well as to be informed about data sharing and to revoke consent.

6.5 India (DPDPA 2023)

If you are located in India, we are aware that the Digital Personal Data Protection Act 2023 (DPDPA) has been enacted. Its detailed rules and substantive obligations are being brought into force in stages and are not yet fully operative, so we are monitoring these developments and preparing so that, as and when the relevant provisions commence, we can meet the requirements that apply to us. We are not claiming compliance with obligations that are not yet in force.

In the meantime, you can exercise the rights described in this policy with us directly, including to access a summary of the personal data we process, to correct, complete, update and erase your personal data, to nominate another individual to exercise your rights in the event of your death or incapacity, and to raise a grievance. To do so, or to raise a grievance, you may contact our Data Protection Officer through our contact form, and we will respond within a reasonable time. The supervisory authority contemplated under the DPDPA is the Data Protection Board of India, and we will update this section as the Act’s provisions come into force.

Our services are intended only for adults aged 18 or over, and under section 9 of the DPDPA every individual under the age of 18 is treated as a child. We do not knowingly create accounts for, or process the personal data of, children, and we do not undertake any tracking, behavioural monitoring or targeted advertising directed at children. If we become aware that we hold the personal data of a child, we will delete it. Because our services are restricted to adults, we do not rely on any processing of a child’s data that would require verifiable consent from a parent or lawful guardian.

6.6 Australia (Privacy Act 1988 and the Australian Privacy Principles)

If you are located in Australia, the Privacy Act 1988 (Cth) and the 13 Australian Privacy Principles (APPs) apply to our handling of your personal information. Consistent with APP 1.4, this privacy policy is publicly available, kept up to date, and describes the kinds of personal information we collect and hold, how we collect and hold it, the purposes for which we collect, hold, use and disclose it, and how you may access and correct it. Consistent with APP 5, at or before the time we collect personal information from you (or as soon as practicable thereafter), we take reasonable steps to make you aware of our identity and contact details, the fact and circumstances of collection, the purposes of collection, the main consequences if we do not collect, the recipients to whom we usually disclose, and whether we are likely to disclose to overseas recipients. You have a right of access to, and a right of correction of, your personal information, and a right to complain about our handling of it. Complaints may be lodged with the Office of the Australian Information Commissioner (OAIC) at oaic.gov.au.

6.7 New Zealand (Privacy Act 2020)

If you are located in New Zealand, the Privacy Act 2020 and its 13 Information Privacy Principles (IPPs) apply to our handling of your personal information. Consistent with IPP 3, when we collect personal information directly from you, we will (at or before the time of collection, or as soon as practicable thereafter) make you aware of the fact and purpose of collection, the intended recipients, the name and address of the agency collecting and holding the information, the consequences (if any) for you of not providing the information, and your rights of access and correction. You have rights of access (IPP 6) and correction (IPP 7) in respect of personal information we hold about you. Complaints may be lodged with the Office of the Privacy Commissioner at privacy.org.nz.

6.8 Singapore (Personal Data Protection Act 2012)

If you are located in Singapore, the Personal Data Protection Act 2012 (PDPA) applies to our handling of your personal data. We have designated a Data Protection Officer in accordance with section 11(3) of the PDPA, contactable through our Data Protection Officer contact form. Consistent with section 20, before or at the time we collect, use or disclose your personal data, we will notify you of the purposes for that collection, use or disclosure and obtain your consent (or rely on a deemed-consent or statutory basis recognised by the Act). Under section 21 you have a right of access to your personal data and to information about how it has been used or disclosed within the past year, and under section 22 you have a right of correction. We also observe the Do Not Call provisions in Part IX of the PDPA in respect of marketing messages sent to Singapore telephone numbers. The supervisory authority is the Personal Data Protection Commission (PDPC) at pdpc.gov.sg.

6.9 Hong Kong (Personal Data (Privacy) Ordinance, Cap. 486)

If you are located in Hong Kong, the Personal Data (Privacy) Ordinance (Cap. 486) and the six Data Protection Principles (DPPs) made under it apply to our handling of your personal data. Consistent with DPP 1, we collect personal data only for lawful purposes directly related to a function or activity of ours, and we inform you (on or before collection) of the purposes of collection and the classes of persons to whom the data may be transferred. Consistent with DPP 6, you have a right of access to, and a right of correction of, your personal data held by us. To exercise these rights, contact our Data Protection Officer through our contact form. The supervisory authority is the Office of the Privacy Commissioner for Personal Data (PCPD) at pcpd.org.hk.

6.10 South Asia (Pakistan, Bangladesh, Sri Lanka, Nepal)

If you are located in Pakistan (Personal Data Protection Act 2023), Bangladesh (Data Protection Act, draft), Sri Lanka (Personal Data Protection Act 2022) or Nepal (Privacy Act 2018), you have rights to be informed about the collection and processing of your personal data, to access and correct that data, to withdraw consent where processing is based on consent, and to object to processing in certain circumstances. To exercise these rights, contact our Data Protection Officer through our contact form or submit a request through your account settings. Where the relevant statute is enacted but not yet fully in force, or where local guidance is still developing, we apply equivalent protections drawn from our overarching GDPR-aligned standards.

6.11 How to Exercise Your Rights

To exercise any of your data protection rights, please submit a request through your account settings or send one to our Data Protection Officer through our contact form. We will respond within the statutory timeframe applicable to your jurisdiction (typically 30 days under GDPR, 45 days under CCPA/CPRA).

7. Data Subject Access Requests (DSARs)

You may submit a formal data subject access request through your account dashboard. We support the following request types:

• Full Data Export: A complete copy of all personal data we hold about you, including a record of when other people accessed your data: our support staff, legal professionals you work with, people you gave delegated access to, and people you shared documents with. Each entry shows what was accessed, when, and the category of person who accessed it. We name staff by role only (for example “Support staff”) and leave out other people’s IP addresses. If we withhold any access records, for example during a fraud or security investigation into the account, the export says so, gives the reason, and states how many records were withheld.
• Recording Access: Access to specific consultation recordings (subject to verification and the consent of all parties)
• Data Deletion: Request deletion of your data (subject to legal retention obligations)

We process DSARs within 30 calendar days of receipt. If your request is complex or we receive a high volume of requests, we may extend this by a further 60 days with notice. There is no fee for exercising your rights, though we may charge a reasonable fee for manifestly unfounded or excessive requests.

8. Data Retention

We retain your personal information for as long as necessary to provide our services and comply with legal obligations. Below is a summary of our retention periods:

When these periods start and how data is deleted: Unless a row states otherwise, a fixed retention period (for example “7 years”) runs from the date the record is created or last updated. Where retention is tied to your account (for example “duration of account + 2 years after closure”), the deletion trigger is closure of your account followed by the stated run-off period. In every case data is deleted once the applicable period expires, whichever of the following occurs first or last as specified: you delete the underlying record (for example a will or document), your account is closed, you withdraw the consent the processing relies on, or a fixed legal or accounting period elapses, unless an active litigation, compliance, or will-review hold applies, in which case deletion occurs when that hold is lifted.

EU VAT Audit Trail: For all EU business-to-consumer transactions, we maintain audit logs of location evidence including the billing address you confirm at checkout, IP address, payment card issuing country, and profile country. These logs are retained for 10 years per EU VAT One Stop Shop requirements. The tax charged is determined by the billing address confirmed at checkout; the other location signals are retained as corroborating evidence.

Gift Card Redemption Location Evidence: A gift card is a multi-purpose voucher, so VAT or sales tax on it is due in the place where the person who redeems it belongs, at the time they redeem it. When you redeem a gift card we therefore record three items of location evidence against the redemption: the country of residence on your profile, the country your IP address resolves to at the moment you redeem (we store the two-letter country only; the IP address itself is not kept for this purpose), and, if you have paid us yourself before, the issuing country of the payment card on your most recent payment. Our legal basis is compliance with a legal obligation (UK GDPR Article 6(1)(c)): tax rules require us to hold two consistent items of evidence of where our customer belongs. This evidence is kept with our tax records for the same 10-year period as the EU VAT audit trail above.

Professional Commission VAT Evidence: If you are a legal professional or firm, the VAT we add to our platform commission depends on the country your practice belongs to, and we decide that country only from verified evidence, in this order: the country Stripe verified for your connected payment account; otherwise the country of your VAT number, once we have checked that number with the official registry (the European Commission’s VIES service for EU numbers, HMRC for UK numbers); otherwise the issuing country of the payment card on your own subscription with us, which we read from Stripe. We send your VAT number to the registry only to check it, and we store the result, the two-letter country and the date checked. We also record, on each commission invoice, which evidence was used and the tax country you declared, and our finance team reviews any case where the two differ. Our legal basis is compliance with a legal obligation (UK GDPR Article 6(1)(c)): VAT rules require us to establish where our business customer belongs. These records are kept with our tax records for the same period as the EU VAT audit trail above.

Litigation Hold: If data is subject to a litigation hold (e.g. a legal dispute), it will be retained beyond the standard retention period until the hold is lifted, regardless of the normal schedule.

Document Vault Deletion Restrictions: When you delete a document from the Document Vault, it enters a 90-day retention period before the underlying files are permanently purged from our cloud storage. During this period the document cannot be recovered. Documents subject to an active compliance access grant or an ongoing will review cannot be deleted; you will be informed if a deletion request is blocked. If you wish to request deletion of a protected document, you may exercise your rights under Section 10 (Your Data Rights) by submitting a data subject access request.

Account Deletion: When you request account deletion, we implement a 14-day cooling-off period during which you may reverse your decision. The deletion is scheduled rather than immediate: for the duration of the cooling-off period your account remains restorable from the same sign-in. After this period, your data is permanently deleted according to the retention schedule above.

Sole-Admin Succession for Professional Firms: If you are the only remaining administrator of a professional firm and you delete your account, ownership of the firm and any associated client records, engagement letters and appointments is automatically transferred to the next eligible member (preferring administrators, then other active members by tenure) before your account is anonymised. If no eligible successor exists, the firm is closed and its non-personal records are retained on a read-only basis in accordance with the retention schedule above. Affected firm members and clients are notified by email so they can act on the change. The succession runs as part of the deletion pipeline so no orphan firm records remain.

Fresh-Slate Re-Registration: Once the cooling-off period has elapsed and deletion completes, signing back up later using the same email address creates an entirely new account. No firm memberships, organisation roles, professional listings or other records from the previous account carry over: the new account starts empty.

9. International Data Transfers

Your information may be transferred to and processed in countries outside the UK and the European Economic Area (EEA). Several of our sub-processors are based in the United States.

We ensure appropriate safeguards are in place for all international transfers:

• Standard Contractual Clauses (SCCs): We use the European Commission's Standard Contractual Clauses, supplemented by the UK International Data Transfer Addendum, for transfers to the United States and other non-adequate countries.
• EU-US Data Privacy Framework (DPF): Where our US-based sub-processors are certified under the EU-US Data Privacy Framework, this serves as an additional safeguard.
• Adequacy Decisions: Where the UK or EU has recognised a country as providing adequate data protection, we rely on the relevant adequacy decision.

Apple Inc. and Google LLC, our mobile platform billing partners, process in-app purchase data in the United States. Both are certified under the EU-US Data Privacy Framework. In addition, we use Standard Contractual Clauses supplemented by the UK International Data Transfer Addendum for these transfers.

Where technically feasible, we use regional infrastructure to minimise cross-border transfers. For example, Cloudflare R2 storage can use EU-based buckets.

9.1 Sharing your information with a professional based abroad

The transfers described above are to our own suppliers. A different kind of transfer happens when you ask us to introduce you to a legal professional who is based outside the United Kingdom, which we do when the will you need is for another country or has to be written in a language we cannot produce. The professional is an independent controller of the information we pass to them, not our processor, and they decide how they use it in order to advise you.

We hold a record of whether each country is covered by UK adequacy regulations, and we resolve the professional's country from their registered place of practice. Where that country is covered, we rely on those regulations and share your information once you have chosen the categories to share. Where it is not covered, or where recognition applies only to organisations holding a particular certification rather than to the country itself, we treat the transfer as restricted and rely on your explicit consent under Article 49(1)(a) of the UK GDPR.

In that case we show you the destination country by name before anything is sent, together with a plain explanation of what the transfer means, and we ask you to agree to it. We record your decision, the country it named, the mechanism relied on and the exact wording you were shown. Nothing is disclosed to the professional unless that record exists, and a consent given for one country does not carry over to another. You may withdraw your consent at any time, which stops any further sharing, although information already sent to the professional cannot be recalled and remains subject to their own obligations to you.

Consent is a lawful basis with recognised limits: a country outside UK adequacy regulations may not give you the same rights or routes of redress as the United Kingdom, and enforcement against a recipient there may be harder. We tell you the destination so that you can weigh that before deciding, and you are free to decline and choose a different professional.

10. Children's Privacy

Our Service is offered only to adults. Under our Terms of Service you must be at least 18 years old to create an account or use the Service. This is a contractual eligibility rule, and it is separate from the statutory ages of digital consent set by data-protection law, which we explain below so that the position is clear.

Statutory age of digital consent. Data-protection laws set an age below which a child cannot give their own consent to an online service, and a parent or guardian must consent on their behalf. In the United Kingdom, section 9 of the Data Protection Act 2018 sets this age at 13. Under the EU GDPR the default age is 16, although individual member states may lower it to as young as 13. In the United States, the Children’s Online Privacy Protection Act (COPPA) applies to children under 13 and requires verifiable parental consent. In India, section 9 of the Digital Personal Data Protection Act 2023 treats every individual under the age of 18 as a child and requires verifiable consent from a parent or lawful guardian (see Section 6.5 for more detail). Because our Service is restricted to adults, we do not knowingly rely on any processing that would require a child’s own consent or the consent of their parent or guardian.

Clear language for children (UK GDPR Article 8). Where any part of our Service might be seen by a child, we aim to describe what we do with personal data in clear, plain language that a child could understand, and we do not use a child’s data for tracking, behavioural monitoring, or targeted advertising.

How we confirm age. When you create an account on any of our sites or apps, we ask you to confirm that you are 18 or over, and we record the date and time you gave that confirmation. This is a self-declaration: we do not send your details to a third party to estimate or verify your age. We also do not accept a date of birth under 18 in your profile, we prepare a will only for a person who has reached the minimum age to make one (never lower than 18 on our Service), and our community Forum admits only accounts that have given the confirmation (see Section 24.8).

If a child’s data reaches us. We do not knowingly collect personal information directly from children anywhere on the platform, not only on the Forum (see Section 24.8). If we become aware that a child has registered for or used the Service in breach of our age requirement, or has otherwise provided us with their own personal data, we will close the relevant access and delete that data from our systems as soon as is reasonably practicable, unless we are required by law to retain it. In practice, when a date of birth on record shows that an account holder is under 18, we deactivate the account straight away so that it can no longer be used to pay for services or to sign in to the Forum, we email the account holder to say that the account will be deleted, and we delete or anonymise the account and its personal data 14 days later through the same process we use when you ask us to delete your account. We keep an internal record that the account was closed for this reason. If you believe a child has provided us with personal information, please contact our Data Protection Officer through our contact form, and we will take steps to delete it.

Information about children that adults give us. This is distinct from information that an adult account holder may provide about their family members, including minor children named as beneficiaries or as people who need a guardian, for estate-planning purposes. That information is processed on the adult’s instruction and governed by the rest of this policy. We process it because it is needed to perform our contract with the adult (UK GDPR and GDPR Article 6(1)(b)); for the children themselves, we rely on legitimate interests (Article 6(1)(f)), both the adult’s interest in providing for their children after death and the children’s own interest in care and financial provision. We ask only for what the will or estate document needs, we do not use it for marketing or profiling, and we share it only with the professionals and executors the adult chooses. Where an adult describes a child’s health needs, we process that information because it is needed for the establishment, exercise or defence of legal claims, including the legal arrangements made for the child (Article 9(2)(f)), and we protect free-text descriptions of a child’s circumstances with additional encryption. We never rely on a child’s own consent for this processing.

11. Marketing Communications

We may send you marketing communications about our services with your explicit consent. You can:

• Opt out via the unsubscribe link in any marketing email
• Update preferences in your account settings
• Contact us through the contact form on our platform

Your marketing consent covers emails from every one of our sites: TheWILL.ai (estate planning), Expat183 (tracking the days you spend in each country) and Orchard72 (portfolio tracking). An email from one site may therefore carry a short note about another of our sites, and we send such a note only if you have given this consent. Withdrawing it stops marketing emails from all of our sites at once.

Each news digest you subscribe to is a separate consent for that digest alone. Subscribing to a digest does not opt you in to any other marketing communication, and turning off a digest leaves your other choices as they are. Unsubscribing from all marketing communications also stops every news digest. We keep a record of each consent you give or withdraw, including news digest subscriptions.

Service-related communications (security alerts, account updates, booking confirmations) cannot be opted out of while you maintain an active account, as they are necessary for the performance of our contract with you.

11.1 United Kingdom and European Economic Area

For recipients in the United Kingdom and the European Economic Area, the lawful basis for marketing communications is your consent under Article 6(1)(a) of the UK GDPR (and, where applicable, the equivalent national transposition of the EU GDPR). The electronic-communication channel is governed by the Privacy and Electronic Communications Regulations 2003 (PECR), regulation 22, or the corresponding ePrivacy transposition in your country. As stated in our lawful-basis table in Section 4, we do not rely on the PECR “soft opt-in” in regulation 22(3); marketing emails are sent only to recipients who have actively consented. You may withdraw your consent at any time without giving a reason, using the unsubscribe link in any marketing email or the channels listed above.

11.2 United States: CAN-SPAM Act

For commercial email we send to recipients in the United States, we comply with the Controlling the Assault of Non-Solicited Pornography and Marketing Act of 2003 (the CAN-SPAM Act, 15 U.S.C. §§ 7701 to 7713), as implemented by the Federal Trade Commission’s rule at 16 C.F.R. Part 316. Specifically:

• Accurate header and subject information. The “From,” “To,” “Reply-To” and routing information in every commercial email identifies us as the sender; subject lines are not deceptive and accurately reflect the content of the message (15 U.S.C. §§ 7704(a)(1) to (2)).
• Valid physical postal address. Every commercial email includes our valid physical postal address in the footer, as required by 15 U.S.C. § 7704(a)(5)(A)(iii) and 16 C.F.R. § 316.2(p).
• Clear opt-out mechanism. Every commercial email includes a working unsubscribe link that remains operational for at least 30 days after the message is sent (15 U.S.C. § 7704(a)(3)).
• Prompt honour of opt-out requests. Opt-out requests are honoured within 10 business days, as required by 15 U.S.C. § 7704(a)(4)(A)(i), and we do not charge a fee, require any information beyond your email address, or require any step other than sending a reply or visiting a single page on the internet to opt out.
• No onward transfer after opt-out. After you opt out, we do not sell, lease, exchange or otherwise transfer or release your email address to any other party for the purpose of sending commercial email (15 U.S.C. § 7704(a)(4)(A)(iv)).

11.3 Canada: Canada’s Anti-Spam Legislation (CASL)

For commercial electronic messages (CEMs) we send to recipients in Canada, we comply with Canada’s Anti-Spam Legislation (S.C. 2010, c. 23) and the Electronic Commerce Protection Regulations (CRTC) under it. Specifically:

• Express consent before sending. We obtain your express consent under section 6 of CASL before sending any CEM. We do not rely on implied consent under section 10(9) for our Canadian marketing programme; consent must have been actively given for us to send.
• Records of consent. For the purposes of section 10(2) of CASL (which places the burden on the sender to prove consent), we maintain a record of each express consent including the date and time consent was given, the source of the consent (the form or page on which it was collected), the wording of the request that was presented to you at the time, and supporting technical metadata such as the originating IP address and browser user-agent.
• Sender identification. Every CEM identifies the person who sent it and contains a valid mailing address by which we can be contacted for at least 60 days after the message is sent, as required by section 6(2) of CASL and section 2(2) of the Electronic Commerce Protection Regulations (CRTC).
• Working unsubscribe mechanism. Every CEM includes an unsubscribe mechanism that can be readily performed and is given effect without delay and in any event no later than 10 business days after the request is sent, as required by section 11(3) of CASL.
• Withdrawal of consent. You may withdraw your consent at any time using the unsubscribe link in any CEM, your account email preferences, or the contact form on our platform. Withdrawal does not affect the lawfulness of CEMs we sent before you withdrew.

Complaints relating to CEMs received in Canada may be lodged with the Canadian Radio-television and Telecommunications Commission (CRTC) via the Spam Reporting Centre at fightspam.gc.ca.

11.4 Campaign Engagement Data

Our email delivery provider, Brevo (Sendinblue SAS), measures what happens to a marketing email after we send it and reports those events back to us by webhook. The events we receive and store are: that a message was delivered; that it was opened; that a link in it was clicked; that it bounced; and that the recipient unsubscribed or reported it as spam. Open measurement works by means of a small tracking image embedded in the email, and click measurement by means of a redirect on the links in it. Both operate inside your email client when you open or click the message. Neither sets a cookie in your browser when you visit this website, and we run no third-party advertising or marketing-analytics trackers on your account pages; our cookie policy explains the distinction in its section on marketing cookies.

From those events we hold three kinds of record. We keep a per-send log of which template was sent to which recipient and when. We keep counts and timestamps derived from the events, such as how many of a recipient’s emails have been opened or clicked, when the most recent open or click was, and the equivalent totals for a campaign or a template. Where you are enrolled in a multi-email sequence, we use those counts to decide whether to send you the next email in it. We do not build an advertising or interest profile from this data, we do not combine it with data bought from a third party, and we never sell it or disclose it to an advertiser.

Lawful basis. For recipients in the United Kingdom and the European Economic Area, engagement measurement forms part of the marketing communication itself and rests on the same consent you gave us to send it, under Article 6(1)(a) of the UK GDPR. Because the tracking image and the click redirect store information on, or gain access to information stored in, your terminal equipment, they also engage regulation 6 of the Privacy and Electronic Communications Regulations 2003, and we rely on your consent for that too. There is no separate toggle for measurement because there is no separate decision to make: it stops when the emails stop. Withdrawing your marketing consent, by the unsubscribe link in any marketing email or from your email preferences, ends both the emails and the measurement of them from that point on. Withdrawal does not make the measurement we carried out beforehand unlawful, and it does not by itself erase the records already held, though you may ask us to erase them under Section 6.

Retention. The per-send log is deleted automatically one year after the date of the send. The derived counts and last-open or last-click timestamps are held on the recipient and campaign records for as long as we keep those records, and are removed when your account is deleted or anonymised under Section 8. Brevo’s own retention of the underlying event is governed by our contract with it as our processor, and is listed in our sub-processor register.

Service-related email, such as a security alert or a document reminder, is measured the same way for delivery and bounce purposes so that we can tell whether a message you need actually reached you. Bounce and complaint handling is not optional, because continuing to send to an address that rejects our mail would harm every other recipient’s deliverability.

12. Third-Party Links

Our Service may contain links to third-party websites. We are not responsible for their privacy practices and encourage you to read their privacy policies before providing any personal information.

13. Changes to This Policy

We may update this Privacy Policy from time to time to reflect changes in our services, legal requirements, or data processing practices. We will notify you of material changes via your registered email address or through a notice on our platform. Your continued use after changes indicates acceptance of the updated policy. If you do not agree with any changes, you may close your account.

14. Contact Us and Complaints

If you have questions about this Privacy Policy, our data practices, or wish to exercise your data protection rights, please contact us:

Data Protection Officer
Contact: Data Protection Officer contact form
Orchard72
For data protection enquiries and to exercise your rights under UK GDPR or other applicable law, use the Data Protection Officer contact form above, which goes to our Data Protection Officer directly. For account-specific requests requiring identity verification, you may also use the privacy controls in your account dashboard.

14.1 Data Controller

Orchard72 is the data controller for the personal data we process about you.

14.2 Supervisory Authorities

You have the right to lodge a complaint with a supervisory authority. The relevant authority depends on your location:

• United Kingdom: Information Commissioner's Office (ICO), Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF. Helpline: 0303 123 1113. Website: ico.org.uk
• European Union: Your local Data Protection Authority (DPA). A list is available at edpb.europa.eu
• United States: Your State Attorney General's office. California residents may also contact the California Privacy Protection Agency (CPPA).
• Canada: Office of the Privacy Commissioner of Canada (OPC). Website: priv.gc.ca
• Brazil: Autoridade Nacional de Proteção de Dados (ANPD). Website: gov.br/anpd

We encourage you to contact us first so we can try to resolve your concern directly. We take all privacy complaints seriously and will respond within 30 days.

For complaints about our services generally, not only about data protection, please see our Complaints Procedure, which explains how to complain, how we handle complaints, and how to escalate to a regulator if you remain dissatisfied.

15. Preparedness Assessment

Our free Preparedness Assessment collects the following information to generate your personalised readiness score and recommendations:

• Assessment responses: Your answers to questions about emergency access, life stage, personal circumstances (e.g. whether you have children, own property, own a business), planning status, password storage habits, motivation, and areas of interest.
• Country of residence: Used to tailor recommendations to your jurisdiction.
• Session tracking: A temporary session key is stored in your browser's sessionStorage to maintain your progress. This key is not a cookie and is cleared when you close your browser tab.
• Marketing attribution: If you arrive via a marketing link, we collect UTM parameters (source, medium, campaign) and referrer information to understand how people discover our service.

15.1 How We Use Assessment Data

Your responses are used to calculate a preparedness score and generate personalised gap analysis and recommendations. We also use aggregate, anonymised assessment data for product improvement and market research. We do not sell or share individual assessment responses with third parties.

15.2 Account Linking

If you create an account after completing an assessment, you may choose to link your results to your account for a personalised experience. Linking is optional and initiated by you. Once linked, assessment data is treated as part of your account data and is subject to the retention periods described in Section 8.

15.3 Data Retention

Unlinked assessment sessions (those not associated with an account) are retained for 12 months from the date of completion, after which they are permanently deleted. This retention period allows you to return and view your results. Linked assessment data follows the same retention policy as your account data.

15.4 Legal Basis

We process assessment data on the basis of legitimate interest (Article 6(1)(f) UK GDPR), specifically our interest in providing a useful self-assessment tool, improving our products, and understanding how people plan for the future. You can exercise your data subject rights as described in Section 10 of this policy.

16. Corporate and Bulk Licensing: Data Processing

This section describes how we handle personal data when an organisation ("Purchaser") acquires bulk subscription licences or gift batches on behalf of employees or other recipients, or enters into a Corporate Programme agreement with Orchard72.

16.1 Purchaser Data

We collect and process the following data about the Purchaser:

• Account information: Name, email address, and organisation details of the purchasing user.
• Order details: Plan selected, quantity, volume discount applied, billing interval, and Stripe subscription identifiers.
• Assignment records: Email addresses provided by the Purchaser for licence assignment. These are stored to send invitation emails and track licence status.
• Payment data: Processed by Stripe. We store Stripe subscription and payment intent identifiers but never card numbers or bank details.

16.2 Recipient Data

When a recipient accepts a bulk licence invitation, we process:

• Email address: Provided by the Purchaser for the invitation. Matched to an existing account or used to prompt registration.
• Subscription state: Whether the recipient has an existing personal subscription (which is paused, not cancelled, during the bulk licence period).
• Activation timestamps: When the licence was assigned, accepted, and (if applicable) revoked.

16.3 Data Isolation

The Purchaser cannot access any recipient's personal data. This includes wills, documents, digital asset records, beneficiary information, and all other account content. The Purchaser sees only:

• Which email addresses have been assigned a licence
• The name on the recipient's account, once the recipient accepts the licence
• Whether each licence has been activated (accepted by the recipient), and the date and time it was assigned and activated
• Aggregate programme statistics (e.g. "12 of 20 licences activated")

When fewer than five recipients use a particular feature, the count is displayed as "<5" to prevent identification of individual users.

16.4 Data Ownership and Portability

All personal data created by a recipient (wills, documents, digital asset records) belongs to the recipient, not the Purchaser. If a bulk licence is revoked or expires, the recipient retains ownership of their data. If the recipient had a personal subscription that was paused, it resumes automatically. If not, the recipient's account reverts to the free tier and their data remains accessible within free-tier limits. Consent to participate in a corporate programme or accept a bulk licence must be freely given by the recipient and is not a condition of employment.

16.5 Gift Batch Data

Gift batch codes are anonymous. The Purchaser receives a set of unique redemption codes but cannot see who redeems each code or access any redeemer's account data. We store the association between a redeemed code and the recipient's account for billing reconciliation only.

16.6 Legal Basis

We process Purchaser data on the basis of contract performance (Article 6(1)(b) UK GDPR). The bulk licence order constitutes a contract between the Purchaser and Orchard72. Recipient data is processed on the basis of legitimate interest (Article 6(1)(f) UK GDPR), specifically our interest in fulfilling the licence invitation on behalf of the Purchaser. Recipients may exercise their data subject rights as described in Section 10 of this policy.

16.7 Retention

Licence assignment records (email addresses and activation timestamps) are retained for the duration of the bulk licence order plus 12 months for billing reconciliation. Gift batch redemption records follow the same retention period. All other recipient data follows the standard retention periods described in Section 8.

16.8 Corporate Programme Data Roles

Bulk licensing: Orchard72 is the sole data controller. The Purchaser sees only licence assignment status and aggregate statistics as described in Section 16.3.

Per-employee activation status is disclosed to the employer. For both bulk licences and Corporate Programmes, the employer (or other Purchaser) is a recipient of each invited person's activation status: the invited email address, the name on the account once the invitation is accepted, whether the benefit has been activated, and the dates and times of assignment and activation. The employer may view this on its dashboard and may export it in bulk (for example as a spreadsheet file). Once exported, the employer is the controller of the copy it holds. The employer never receives will content, documents, beneficiaries, or any other estate details.

Corporate Programmes: The employer is the data controller for employee personally identifiable information provided for programme administration (email address, department, and employee identifier) under Article 28 of the UK GDPR. Orchard72 acts as data processor for this employer-provided data and as independent data controller for all will content, personal documents, digital asset records, and other personal data created by the employee on the platform.

Programmatic access by the employer: the employer's programme owner may create reporting API keys so that the employer's own systems, such as an HR or reporting tool, can read the same information its dashboard shows. A key carries only the access the owner chooses. With reporting access it reads aggregate programme statistics (overview, trends and feature adoption, with small groups suppressed as described in Section 16.3) and the employer's invoices. With roster access it reads the employer-provided work email, department and employee identifier for each seat, together with the seat's status and its invitation, activation and deactivation dates. It never reads the name or personal email on an employee's own account. No key can ever read will content, documents, beneficiaries or any other estate details. Each key is stored only in hashed form, may be given an expiry date, and can be revoked by the owner at any time. The employer is the controller of any copy its systems retrieve with a key, on the same terms as a spreadsheet export. When an employee activates the benefit, the employer may also receive a notification to a web address it registers, carrying only the employee identifier and the time of activation.

Workplace sign-in and directory sync: an employer may connect its own identity provider, using SAML 2.0 or OpenID Connect, so that its employees sign in with their work account, and may keep seats in step with its staff directory automatically. You enter your work password with the employer, never with Orchard72. On each company sign-in we receive a signed confirmation carrying your work email address and the identifier the identity provider uses for you; we check that it is genuine, addressed to us and not replayed, and we keep the identifier and the time of your last company sign-in. Directory sync sends your work email address, the employer's own reference for you, your department where supplied, whether your seat is active, and the directory groups the employer uses to decide who gets a seat. We use this data only to sign you in and to give, keep or end your seat. Nothing from your will, documents or account is sent to the identity provider, which is the employer's own supplier under its own terms and not one of our sub-processors. Company sign-in is available only once the employer has set it up and switched it on.

The following table summarises the data categories and their controller assignment:

• Employee email and department (Controller: Employer; Processor: Orchard72)
• Employee identifier (Controller: Employer; Processor: Orchard72)
• Identity-provider sign-in identifier, last company sign-in time and directory group memberships (Controller: Employer; Processor: Orchard72)
• Per-employee activation status and timestamps (Controller: Orchard72; Recipient: Employer, which is controller of any copy it views, exports or retrieves through the Corporate Reporting API)
• Will content and personal documents (Controller: Orchard72)
• Digital asset records (Controller: Orchard72)
• Subscription and billing data (Controller: Orchard72)
• Aggregate programme statistics (Controller: Employer, derived from anonymised data)

16.9 Employee Consent for Corporate Programmes

In accordance with Article 7 of the UK GDPR, consent to participate in a Corporate Programme must be freely given, specific, informed, and unambiguous. Consent is collected separately from any employment terms and conditions. An employee may withdraw consent at any time without adverse consequences to their employment.

Upon withdrawal of consent: (a) the corporate benefit is removed from the employee's account; (b) all personal data created by the employee (wills, documents, digital asset records) is retained under the employee's direct relationship with Orchard72; and (c) if the employee had a personal subscription that was paused, it resumes automatically. The employer is notified only that the employee has left the programme, not the reason for withdrawal.

16.10 Data Processing Agreements

Corporate clients requiring a Data Processing Agreement can access our standard DPA template at our Data Processing Agreement page. The DPA covers: data categories processed, processing purposes, sub-processor list, security measures, breach notification timelines, data deletion on contract termination, and audit rights.

16.11 Single Sign-On Data Flows

Where an organisation enables Single Sign-On (SSO) integration as part of a Corporate Programme, the following data flows apply. Data received from the organisation's identity provider (IdP) is limited to: email address, display name, and department (where provided). Authentication tokens are encrypted, scoped to individual sessions, and not retained beyond the session lifetime.

If SSO is subsequently disabled for a user, the user retains their account with standard email-and-password authentication. All personal data created during the SSO period is preserved in full. No data is deleted as a result of SSO removal.

16.12 HR System Data Synchronisation

Where an organisation connects a Human Resources Information System (HRIS) to the platform as part of a Corporate Programme, the following data synchronisation practices apply. Data synced from the HRIS is limited to: name, email address, department, employee identifier, and employment start and end dates. Synchronisation is triggered by webhooks from the HRIS; we do not poll the HRIS for data.

Where a conflict arises between HRIS-synced data and data on the platform, HRIS data takes precedence for employer-controlled fields (name, email, department, employee identifier). Employee-created data (wills, documents, digital asset records, beneficiary information) is never overwritten by HRIS synchronisation.

If the HRIS link is severed, previously synced records are retained on the platform. Future webhooks from the disconnected HRIS are ignored. The employee's account and all personal data remain accessible.

16.13 Dependant Cover

Where a Corporate Programme includes dependant cover, a covered employee may invite adult dependants (for example, a partner or an adult child) to join under the programme. To send the invitation we process the dependant's email address and their relationship to the employee, as given to us by the employee. A dependant who accepts has their own account, and everything they create on it (wills, documents, digital asset records) belongs to them. We are the controller of a dependant's data; the employer is not, and does not provide it.

The employer never has access to a dependant's personal data. It cannot see who a dependant is, nor any of their account content. It sees only aggregate figures, such as how many dependants are covered against the limit in its agreement. The employee who sent the invitation does not gain access to the dependant's account either.

We process invitation details on the basis of legitimate interests (Article 6(1)(f) UK GDPR), specifically our interest in delivering the invitation the employee asked us to send; once the dependant accepts, we rely on performance of our contract with them (Article 6(1)(b)). An invitation that is never accepted expires, and the invitation details are then erased. When the employee leaves the programme, or the programme ends, each dependant keeps their account and all of their data, and may continue on a personal subscription; otherwise the standard retention periods described in Section 8 apply.

17. Professional Organisation Team Management

This section describes how we collect, process, and retain personal data in connection with the organisation team management features available to legal professionals.

17.1 Invitation Email Data

When an organisation owner or administrator sends an invitation, we collect and store the invitee's email address, the role offered, any personalised message included, and the inviter's identity. This data is used solely to deliver the invitation email and to match the invitation when the recipient registers or signs in. Invitation records for declined or expired invitations are retained for audit purposes for a period of seven years.

17.2 Role Assignment Data

We record each member's role within the organisation, the date they joined, who invited them, and any subsequent role changes. This data is visible to organisation owners and administrators and is used to enforce permission-based access controls across the platform.

17.3 Audit Log Retention

All team management actions are recorded in an immutable audit log. Each entry includes the actor (who performed the action), the target (who was affected), the action type, a timestamp, and additional contextual details. Audit log entries are retained for seven years in accordance with UK regulatory requirements for professional services firms, after which they are permanently and irreversibly deleted.

17.4 GDPR and Account Deletion

When a user exercises their right to erasure under UK GDPR, the following applies to organisation team data:

• Membership records are anonymised. The user's name and email are removed, but the membership record is retained in anonymised form for audit continuity.
• Audit log entries referencing the deleted user are anonymised. The actor or target name is replaced with "Deleted User", preserving the audit trail without identifying the individual.
• Invitation records where the deleted user was the invitee or inviter are anonymised in the same manner.
• Ownership transfer: If the deleted user is an organisation owner, ownership is automatically transferred to the highest-ranking active member (preferring administrators) before the account is deleted.

17.5 Data Shared Between Organisation Members

Members of the same organisation can see the following data about each other: full name, email address, role, title within the organisation, and date joined. Client approaches, appointment records, and engagement letters may be reassigned between organisation members when a member is removed (see Terms of Service Section 23.3). No member's personal will data, identity documents, financial records, or private account information is shared with other organisation members.

Handing a client to a colleague: Within a firm, access to a professional client's records, including their health and mental capacity records, follows the client's managing professional: each client has one managing professional at a time, and the firm's other professionals do not see those records. The managing professional, or the firm's owner or an administrator, may hand the client to a colleague in the same firm. When that happens, access moves to the colleague and the previous professional no longer sees the client's records. Every hand-over is logged with who made it, which professional the client moved from, which professional they moved to, and when, and the log cannot be edited afterwards; the firm's owner and administrators can see it. If you shared documents with your professional for a particular matter, those shares are re-pointed to the new professional and we tell you by email, so you can review or withdraw them. Documents you shared with a named professional outside a matter are not re-pointed.

17.6 Legal Basis

We process organisation team management data on the basis of legitimate interests (Article 6(1)(f) UK GDPR), specifically the legitimate interest of the organisation in managing its professional team, enforcing role-based access, and maintaining a regulatory-compliant audit trail. For invitation emails, we rely on consent (the inviter confirms the invitee's email address) and contractual necessity (the invitation is a prerequisite to joining the organisation and accessing team features).

18. Portfolio and Investment Data

This section describes how we collect, process, and share data in connection with the Portfolio Tracker feature, which allows you to track securities and manage investment portfolios.

18.1 What We Collect

When you use the Portfolio Tracker, we collect and store:

• Securities tracked: Ticker symbols, ISINs, security names, and asset types (equities, ETFs, cryptocurrency, commodities) that you add to your portfolios.
• Portfolio composition: The structure of your portfolios, including tracked accounts, holdings, quantities, and cost basis information.
• Transaction history: Buy, sell, dividend, and other transactions you record, including dates, quantities, prices, and fees.
• Watchlists: Securities you add to watchlists for monitoring.
• Tax lot data: Cost basis and holding period information used for tax reporting calculations.
• Portfolio members: If you use the family portfolio feature, we store the display names, relationship labels, and colour preferences you assign to family members whose portfolios you oversee. These are linked to transactions and tax lots to provide consolidated family portfolio views. Member names and relationship labels are stored solely under your account: they are not shared with third parties, not used for marketing purposes, and are not visible to other users. If a managed person later creates their own Orchard72 account, their data can be exported or transferred with the account owner's consent by contacting us via the support form.
• DRIP preferences: Your dividend reinvestment preferences (cash or reinvest) per security and per account, used to automate dividend processing.
• Price alert settings: Target price thresholds you configure for watchlist items, used to send you email notifications when securities reach your specified prices.

18.2 How We Store Portfolio Data

Portfolio data is stored encrypted at rest in our database, subject to the same security measures described in Section 5. Portfolio data is retained for the duration of your account plus 2 years after closure, in line with the account data retention period described in Section 8.

18.3 Third-Party Data Providers

To display market prices and security information, we send ticker symbols and ISINs to the following third-party data providers. No personal data (your name, email, account details, or portfolio composition) is sent to these providers. They receive only the security identifiers needed to retrieve price data. The same applies to every market-data source we use, including the public end-of-day files we download from exchanges and official sources: only security identifiers are ever sent, never identifiers of you or your account.

• Finnhub: Delayed and end-of-day stock and ETF prices. Privacy policy: finnhub.io/privacy-policy (opens in a new tab)
• CoinGecko: Cryptocurrency prices and market data. Privacy policy: coingecko.com/en/privacy (opens in a new tab)
• Yahoo Finance: Supplementary stock and ETF price data (fallback provider). Privacy policy: yahoo.com/privacy (opens in a new tab)
• Alpha Vantage: Historical price data and technical indicators (fallback provider). Privacy policy: alphavantage.co/privacy (opens in a new tab)
• DCSC.ai: Sector and industry classification data for securities. Privacy policy: dcsc.ai/privacy (opens in a new tab)

18.4 Legal Basis

We process portfolio data on the basis of contract performance (Article 6(1)(b) UK GDPR): the Portfolio Tracker is a feature of the service you subscribe to. Transmission of ticker symbols to third-party data providers is processed on the basis of legitimate interests (Article 6(1)(f) UK GDPR): specifically, our interest in providing accurate market data to deliver the Portfolio Tracker feature.

18.5 Broker Statement Processing

When you upload broker statements (CSV, PDF, or image files), the files are stored in our secure private document storage and processed as follows:

• CSV files are parsed on our servers using broker-specific parsers. No file content is sent to third-party services.
• PDF and image files are processed using our self-hosted optical character recognition (OCR) and language model services. These services run on our own infrastructure: these files are never sent to external AI services or third-party APIs. Broker and asset statements are processed on our servers only; there is no third-party AI processing option for them.

Uploaded broker statement files are retained as VaultDocuments in your Document Vault, subject to the same retention and deletion policies described in Section 5. Parsed transaction data extracted from statements is stored as part of your portfolio data.

18.6 Data Retention

Portfolio data (securities tracked, transactions, tax lots, and watchlists) is retained for the duration of your account plus 2 years after closure. Historical price data retrieved from third-party providers is cached on our servers and retained indefinitely as it is non-personal, publicly available market data.

18.7 Scope of Portfolio Data Processing

The Orchard72 Portfolio Tracker processes the data you provide for analytics and display only. Specifically:

• Analytics display only. Portfolio data is processed to compute and display valuations, performance, allocation, cost basis, and related analytics against the records you have entered. It is not used for any other purpose.
• Never shared with brokers. We do not share your portfolio data, transaction history, or personal information with brokers, dealers, or any execution venue. The Orchard72 Portfolio Tracker is not connected to any broker account and does not send data to brokers under any circumstance.
• Never used for personalised advice generation. We do not use your portfolio data to generate personalised investment advice, recommendations to buy or sell, model portfolios, or rebalancing prompts. Orchard72 is not authorised by the Financial Conduct Authority and operates outside the FCA regulatory perimeter as described in our Terms of Service.

19. Tax Calculation Data

19.1 What We Store

When you use the Tax Centre feature, we store tax calculation results per jurisdiction and tax year, including aggregated gains, losses, dividend summaries, and individual disposal events. This data is derived from the transaction records you have entered and is stored alongside your portfolio data.

19.2 Purpose of Processing

Tax calculation data is processed solely to provide you with informational capital gains and dividend summaries. We do not share your tax calculation data with tax authorities, financial institutions, or any third parties. All calculations are performed on our servers using your transaction data. No financial data is sent to external tax calculation services.

19.3 Retention Period

Tax calculation data is retained for 7 years from the end of the relevant tax year, in line with HMRC record-keeping requirements (Self Assessment records must be kept for at least 5 years after the 31 January submission deadline). After this period, tax calculation data is automatically deleted. You may export your tax data at any time via the Tax Centre export function.

19.4 Your Rights

You may request deletion of your tax calculation data at any time by contacting us through the support form. Please note that deleting tax calculation data does not delete the underlying transaction records, which are governed by the portfolio data retention policy above. You may also export all tax data in CSV format before requesting deletion.

19.5 Public Inheritance Tax Calculator

Our public inheritance tax calculator at /tools/inheritance-tax-calculator lets you obtain a generic estimate without an account. The estate details you enter (such as the total estate value and whether a home passes to direct descendants) are sent to our servers solely to compute the estimate. They are processed transiently and are not stored, linked to any account, or retained once the estimate has been returned, and they are not shared with tax authorities or any third party. The estimate is general information only and is not legal or tax advice.

20. Consumer API Data

20.1 Data We Collect

When you use the Portfolio Tracker Consumer API, we collect and store:

• API usage logs: Endpoint accessed, timestamp, HTTP response code, and request duration. These logs are used for rate limiting enforcement, debugging, and abuse detection. Logs are retained for 90 days.
• API key metadata: Key name, granted scopes, creation date, expiry date, and last-used timestamp. The raw API key string is never stored. Only an argon2 cryptographic hash, the key's scheme (twai_ for keys created or rotated now, pk_ for older keys) and an 8-character prefix are retained.
• Last-used IP address: The IP address from which your API key was most recently used. This is stored for security monitoring and brute-force detection.
• Webhook endpoint URLs: The HTTPS URLs you register for webhook delivery, along with event subscriptions, delivery timestamps, and failure counts.

20.2 How We Protect This Data

API keys are hashed using argon2 (a memory-hard hashing algorithm) before storage. The raw key is displayed to you exactly once upon creation and cannot be recovered from the stored hash. Webhook signing secrets are stored encrypted at rest and are used solely to sign outbound webhook payloads.

20.3 Legal Basis

We process Consumer API data on the basis of contract performance (Article 6(1)(b) UK GDPR): the Consumer API is a feature of your subscription plan. Usage logging is also processed on the basis of legitimate interest (Article 6(1)(f)) for security monitoring, rate limiting, and abuse prevention.

20.4 Retention Period

API usage logs are retained for 90 days. API key records (hashed) and webhook endpoint records are retained until you revoke/delete them, or until your account is deleted. Upon account deletion, all Consumer API data is permanently removed within 30 days.

20.5 Connecting an AI Assistant of Your Choice

You can connect an AI assistant of your choice to your account through our Model Context Protocol (MCP) server, using a personal API key you create yourself. We never connect an assistant for you and never send your data to one on our own initiative: data goes only to the assistant you connect, only when that assistant calls us with your key, and only within the scopes you granted to that key.

Two optional read-only scopes are never granted by default and are not implied by any other scope. You have to tick each one when you create or edit a key:

• Estate plan (estate:read): read access to your estate-planning records, through both the assistant and the Consumer API. Section 20.6 lists exactly what it covers. It never includes the text of a will, the contents of a stored document or the document file itself.
• Residency day counts (residency:read): the number of days you were present in each country between two dates you or your assistant choose, taken from your confirmed presence records, and how close you are to each day-count threshold we track. It never includes a location history, and the counts are informational only: they do not determine your tax residence.

These tools only read. An assistant cannot create, change or delete anything through them. Each call is logged in the same way as other API use (section 20.1) and counts towards the same rate limit. Once the data reaches your assistant, its provider handles it under that provider's own terms and privacy policy, not ours. You can remove a scope from a key, or revoke the key entirely, at any time from your API key settings, and the assistant loses access straight away. We process this data on the basis of contract performance (Article 6(1)(b) UK GDPR), because you asked us to make it available to the assistant you chose.

20.6 Estate-Plan Read Access (estate:read)

A key that carries the estate:read scope can read the following records from your own account, through the Consumer API and through the assistant tools in section 20.5. It reads only records that belong to you, never another person's, and it cannot create, change or delete anything:

• Wills: the status and progress of each will. Not the wording of the will.
• People and gifts: the names and relationship to you of the people you have added, whether each is a minor or a dependant, the guardians you have chosen for children, and your gifts and trusts, including their descriptions, values, trustees and beneficiaries.
• Other assets: the assets you have recorded outside your portfolio, with their descriptions and estimated values.
• Powers of attorney: the type, jurisdiction, status and registration details of each one.
• Funeral wishes and organ donation: the wishes you have recorded, including the type of funeral, service details, music and readings, and your organ-donation choices.
• Document vault: the title, category, file type, size, status and dates of each stored document. Not its contents or the file.
• Appointments and engagement letters: your appointments with professionals, and the engagement letters they have sent you, including the professional's name, the dates and the quoted fee.
• To-dos: the items on your estate-planning to-do list.
• Residency tracker: your recorded country presence periods, journeys and accommodation stays, with their dates. Unlike the residency:read day counts, this does include where you were and when.

Funeral wishes, organ-donation choices and some will information can reveal your religious or philosophical beliefs or information about your health. These are special category data (see the “Special Category Data” heading above). They are sent only to the integration or assistant holding a key you created and gave this scope, and only when it asks for them. We treat granting the scope as your explicit instruction to send them (UK GDPR Article 9(2)(a)). Removing the scope or revoking the key stops any further reads straight away.

If you register a webhook endpoint (section 20.1), you can also subscribe it to three estate-plan events: a will changing status, a document being uploaded to your vault, and a snoozed to-do returning on its chosen day. Each event carries only a record identifier plus the will's status, the document's category and status, or the to-do's section and return date. It carries no names, titles, wording or document contents. Your integration reads any further detail with an estate:read key. Section 20.4 sets out how long we keep these records, and the lawful basis is the same as for the rest of the Consumer API (section 20.3).

20.7 Document Downloads (documents:read) and Leaked Keys

A key that carries the documents:read scope can download the original files stored in your document vault and the PDF of your will. It reaches only the documents you can open yourself when signed in, including documents someone else has shared with you, and nothing more. It is never granted by default, is not implied by estate:read or any other scope, and it only reads. To add it to a key you must confirm that you understand what it allows, re-verify your identity with two-factor authentication at that moment, and give the key an expiry date no more than 90 days away. We refuse a documents:read key without an expiry date.

A download returns a link that expires five minutes after it is issued. For every download we record which key was used (by its prefix), which document it fetched and when, in that document's access history, and we limit how many documents one key holder can download in an hour. The first time each key downloads a document we email the account holder from noreply@thewill.ai, naming the key and the document. This email cannot be switched off: it is how you would learn that a key you did not expect is downloading your files, so if you do not recognise it, revoke the key straight away from your API key settings. We process this on the basis of contract performance (Article 6(1)(b) UK GDPR), because you asked us to make your documents available to the integration holding the key, and the download record and email on the basis of legitimate interest (Article 6(1)(f)) in keeping your documents secure. Where a document contains special category data, we treat granting the scope as your explicit instruction to send it (Article 9(2)(a)). Once a file reaches your integration, it is handled under that integration's own terms, not ours.

Keys created or rotated now begin with twai_ and end in a checksum, so that code-hosting services that scan public code for leaked credentials, such as GitHub, can recognise them. When such a service reports a key it has found in public, it sends us the key and the address where it was found. If the key is one of ours we revoke it at once, record the report with the key's revocation, and you will see the key as revoked in your API key settings and can create a replacement. We process these reports on the basis of legitimate interest (Article 6(1)(f)) in stopping a leaked key from being used against your account. Older keys beginning pk_ keep working until you rotate them, but are not recognised by these scanners.

21. Cross-Product Data Sharing

Your account may be used across every one of our sites: TheWILL.ai (estate planning), Expat183 (tracking the days you spend in each country) and Orchard72 (portfolio tracking). These products are run by the same operator and share a single, secure account system. You have one account across them all. When you sign in on TheWILL.ai, the other sites sign you in when you visit them, without asking for your email address and password again; signing in on any other site signs you in on that site only. Signing out on any site signs you out of all of them in this browser, including a site you signed in to directly. To do that, each site keeps a random identifier for your browser in a strictly necessary cookie (see our Cookie Policy). The cookie holds no account details. On our servers we link the identifier to your sessions on our sites in that browser, only so that we can end them when you sign out, and we delete each link within 31 days of the session ending or last being used. The identifier is never shared with a third party.

21.1 Unified Account Data

Data entered on any of these products is stored in one secure account under your control. We do not duplicate or isolate data between products. All records belong to you regardless of which domain you use to access them.

21.2 Product Enrolment and Display

Two kinds of preference govern what happens across products. The first is enrolment: which of estate planning, portfolio tracking and residency tracking are part of your account. When you register, we enrol your account based on the site you registered on, and you can add or remove products at any time. Enrolment decides which products appear in your navigation, on your dashboard and in our suggestions. It never restricts or deletes the data you hold, which stays available to you whether or not the product is enrolled.

The second is a single display setting, which decides whether data from one product appears in another:

• Tracked investments in your assets overview: The value of portfolio accounts you track on Orchard72 but have not linked to an estate account appears as a read-only "Tracked investments" line in your assets overview total on TheWILL.ai. Off until you turn it on. This is a display-only figure: it never creates an estate asset record and never flows into will generation.

We operate no data bridge between residency tracking and the other two products. The days you record in each country, and the travel history behind them, stay within the Expat183 residency features.

21.3 Managing Your Preferences

You can change your enrolment and the display setting at any time in Settings > Product Features. Removing a product or turning the display setting off does not delete any data, and you can reverse either change at any time.

21.4 Consent Trail

Every change to your cross-product preferences is recorded with a timestamp, your IP address, and the domain from which the change was made. This audit log is available to you in Settings > Product Features and supports your right to withdraw consent under GDPR Article 7(3).

21.5 Account Deletion

When you request account deletion, all data is removed regardless of which domain you signed up from or which product features are enabled. This includes portfolio data, estate planning data, residency tracking data, cross-product preferences, and the associated consent audit log.

22. Mirror Will Partner Data Sharing

When creating Mirror Wills, certain personal data is shared between partners' will-generation sessions to ensure consistency between the two wills. This section explains what data is shared, how it is handled, and your rights in relation to it.

22.1 Data Shared Between Partners

When an invited partner accepts a Mirror Will invitation, the following data from the initiating partner's session is copied into the invited partner's session, so that the invited partner can review and edit it rather than re-enter it. The invited partner is shown this same list, and must consent to it, before accepting:

• Will jurisdiction and country of residence
• Residence addresses and residency history
• The invited partner's name, date of birth and contact details as the initiating partner entered them, and the initiating partner's own name and contact details
• Children and other dependants, pets, and the guardians and carers named for them
• An overview of the initiating partner's assets and how much detail they chose to give
• The individual assets listed and any specific gifts of them
• Business interests

22.2 Snapshot Model

Shared data is copied at the time of acceptance as a point-in-time snapshot. The data is not live-linked between partners' sessions. Changes made by either partner after acceptance are not automatically reflected in the other partner's session. Each partner retains full control of their own will data and may modify it independently at any time.

22.3 Declined Invitations

If a Mirror Will invitation is declined by the invited partner, the partner's email address provided during the invitation process is immediately and permanently deleted from our systems in compliance with the UK General Data Protection Regulation (UK GDPR). No data sharing occurs for declined invitations.

22.4 Expired Invitations

Mirror Will invitations expire after 30 days if not accepted. Upon expiry, the invited partner's email address is automatically deleted from our systems. The initiating partner is notified of the expiry and may choose to send a new invitation.

22.5 Right to Erasure

Either partner in a Mirror Will pair may request erasure of their own data independently, in accordance with your rights under Article 17 of the UK GDPR. If you request deletion of your account:

• Your own will data is deleted in accordance with our standard data retention policy
• Your partner's will data remains intact as their independent property
• Any reference to you as a partner within your partner's will data will be anonymised

22.6 Data Retention

Mirror Will pair records (the link between the two wills, invitation history, and consent records) are retained for as long as either will in the pair exists. This is necessary to maintain the integrity of both wills and to provide an audit trail of data-sharing consent. When both wills in a pair have been deleted, the pair records are removed in accordance with our standard data retention schedule.

22.7 Data Portability

When exercising your right to data portability (Article 20, UK GDPR), your exported data includes all will data, including any shared data that originated from your partner's session. The export clearly indicates which data was shared from your partner's session and which data you entered independently. Your partner's export likewise includes their own data with attribution of shared fields.

22.8 Alignment-Comparison Consent

Purpose: in addition to the snapshot described in Section 22.2, Mirror Will partners may opt in to an alignment-indicator feature. This feature compares a small set of high-level decisions across both partners' sessions and surfaces whether those decisions are aligned, partially aligned, or divergent. It is intended to help partners identify topics that may benefit from a conversation before the wills are finalised.

Legal basis: your explicit consent under UK GDPR Article 6(1)(a). This consent is collected separately from the snapshot consent in Section 22.2. Accepting the Mirror Will invitation does not enrol you in the alignment-comparison feature. You must opt in via a distinct, clearly labelled control. Either partner may opt out unilaterally; both partners must be opted in for the indicators to be visible.

What your partner sees: derived alignment indicators only, computed from the underlying answers without exposing the answers themselves:

• Whether each partner has named the other as a primary beneficiary
• Whether you have both appointed the same guardians for your children
• Whether both wills include a survivorship clause
• Whether your backup beneficiary arrangements follow the same pattern
• Which assets you have both left as a specific gift (the asset is identified, but not its value or who receives it)

What your partner never sees: the raw content of your will. This includes the names of beneficiaries other than themselves, asset values and account numbers, charitable choices, individual gift instructions, executor and guardian details, and any third-party identities referenced in your session. The alignment indicator never reveals any of this information, in either direction.

Educational note: in some jurisdictions, dependants and certain family members may have rights to claim against an estate (for example, under the Inheritance (Provision for Family and Dependants) Act 1975 in England and Wales). Rules and remedies vary by jurisdiction and circumstances. You may wish to consider taking advice from a qualified professional before finalising arrangements that diverge significantly from a partner's expectations. This note is informational only and is not legal advice.

See Section 22.10 for how to withdraw alignment-comparison consent and Section 22.11 for a coercion-safe exit from the Mirror Will pair.

22.9 Audit Trail for Alignment Comparison

What we record: for each alignment-indicator read, we record an audit row in a model named MirrorWillComparisonAccess. Each row contains the viewer (the partner who read the indicator), the Mirror Will pair identifier, a hash of the indicator set (a deterministic fingerprint of the indicators presented at the time of access, never the underlying answers), the timestamp of access, the viewer's IP address, and the viewer's user agent string.

Action types: three action types are recorded: read (your partner viewed the indicators), acknowledged (your partner confirmed they have seen a divergent indicator), and withdrawn (a partner withdrew alignment-comparison consent).

What we never record: the raw indicator values, the underlying will answers, or any free-text field content. Only the deterministic indicator-set hash is stored, so we can demonstrate which indicator configuration was active at the time of access without retaining the answers themselves.

Where it is visible: both partners can see the audit history for their own pair on the Mirror Will pair tile in the dashboard. This provides a symmetrical record so that neither partner can read the indicators without the other being able to see that a read occurred.

22.10 Right to Withdraw Alignment-Comparison Consent

You may withdraw alignment-comparison consent at any time. Under UK GDPR Article 7(3), withdrawing consent must be as easy as giving it. Withdrawal is available as a one-click toggle on the Mirror Will pair tile in your dashboard.

Effect of withdrawal: withdrawal blocks any further alignment-indicator reads immediately. Existing audit rows recorded before the withdrawal are retained for the purpose of evidencing past access in the event of a later dispute, in line with the retention schedule in Section 22.6. A withdrawn action is recorded in the audit trail so that both partners can see the withdrawal occurred.

What withdrawal does not do: withdrawing alignment-comparison consent does not sever the Mirror Will pair itself. The snapshot data described in Section 22.1 remains in place, because that data was shared on a separate legal basis and is required to keep both wills internally consistent. To fully sever the pair, see Section 22.11.

22.11 Coercion-Safe Exit from a Mirror Will Pair

We recognise that, in some relationships, a partner may need to exit a shared planning arrangement without alerting the other party to the reason or content of the change. A convert-to-solo path is available from your Mirror Will pair tile. It severs the pair and converts your session into an individual will without disclosing the content of any edits you have made.

What the other party sees: a content-free notification stating that the Mirror Will pair is no longer active. The notification contains no field-level data, no diff of changes, no indication of which partner initiated the conversion, and no reason. The fact that you chose to convert, as opposed to a system-driven outcome, is not disclosed.

What is preserved: your individual will continues as a solo session. Audit rows recorded under Section 22.9 prior to the conversion are retained for dispute-evidence purposes, and any references to the other partner within your session are anonymised in line with Section 22.5.

If you have concerns about your safety or the safety of someone you know, you may wish to contact a qualified professional or a relevant support organisation in your jurisdiction. This note is informational only and is not legal advice.

23. Digital Access Handover Plan Sharing

Business owners may share their digital access handover plan with designated successors or executors via a secure, time-limited link. This section explains what data is shared, how access is managed, and your rights.

23.1 Data Shared via Handover Link

When you create a handover share, the following data is included in the shared view: your name, platform succession settings (platform names, setting types, statuses, completion dates, and notes), and credential access plans associated with your business interests. The recipient's name and email address are collected to send the invitation and track access.

23.2 Access Mechanism

Handover plans are shared via a unique, cryptographically generated token embedded in a URL. The recipient does not need a Orchard72 account to view the plan. Each share link expires automatically after 7 days. You may revoke access at any time, immediately preventing further access regardless of the expiry date.

23.3 Access Tracking

We record the number of times a handover link is accessed and the date of the most recent access. This information is visible to you in the Platform Settings tab. We do not collect the recipient's IP address or device information when they view the handover plan.

23.4 Legal Basis

We process handover share data on the basis of your explicit action in creating the share (Article 6(1)(a), UK GDPR: consent). The recipient's email address is processed on the basis of your legitimate interest in communicating your succession plan. You may withdraw consent by revoking the share at any time.

23.5 Retention

Handover share records (including the recipient's name, email, access count, and share metadata) are retained for as long as your account exists. Revoked or expired shares remain in your share history for audit purposes but are no longer accessible via the token. When you delete your account, all handover share records are permanently removed.

24. Community Forum Data Processing

24.1 Forum Processing Activities

Our community forum at community.thewill.ai is powered by Discourse, a third-party open-source platform. When you use the Forum, we process the following personal data:

• Display name (set via your Orchard72 account or derived from your verified professional name)
• Email address (for notifications and account linking)
• User Content (posts, replies, and reactions you create)
• Usage data (pages viewed, topics read, time spent)
• IP address and browser information (for security and abuse prevention)

24.2 Sub-Processors

The Forum uses the following sub-processors in addition to those listed in our Sub-Processors page:

24.3 SSO Data Flow

Forum authentication uses Single Sign-On (SSO) with your Orchard72 account. When you access the Forum, we transmit the following data to Discourse via a signed, encrypted payload: your user ID, email address, display name, and professional verification status. No passwords are shared with Discourse. You may revoke Forum access by contacting us through the contact form in your account dashboard.

24.4 Retention

Forum User Content is retained for as long as the relevant discussion thread exists. If your Orchard72 account is deleted, your Forum posts are anonymised (display name replaced with a generic identifier) rather than deleted, to preserve discussion integrity. Forum usage data and session logs are retained for 90 days.

24.5 Erasure and Anonymisation

You may request deletion of specific Forum posts by contacting us through the contact form in your account dashboard. When you exercise your right to erasure under UK GDPR Article 17, we will anonymise your Forum profile and User Content. Where deletion of individual posts would not compromise the intelligibility of discussion threads, we will delete rather than anonymise.

24.6 Data Portability

You may request a machine-readable export of your Forum User Content (posts, replies, and profile data) by contacting us. This is provided in addition to any data export available through Discourse's built-in user data export feature.

24.7 Data Residency

The Forum is hosted on the same EU-based infrastructure as the main Orchard72 platform. Forum data does not leave the European Economic Area.

24.8 Children and Age Verification

The Forum is not intended for use by individuals under the age of 18. Forum access is only available through single sign-on from your Orchard72 account, and single sign-on admits only an account that has confirmed its holder is 18 or over (see Section 10). It refuses an account we know belongs to someone under 18, and that account is then closed and deleted as Section 10 describes. We do not knowingly collect personal data from children through the Forum. If we become aware that a Forum user is under 18, we will promptly suspend their Forum access and anonymise their User Content.

24.9 Private Messages and Staff Access

Forum private messages are not end-to-end encrypted. Platform staff with a moderator or administrator role on the Forum may access private messages where strictly necessary to investigate a reported abuse, safety, or policy violation, to respond to a lawful request, or to maintain the integrity of the service. This is distinct from the encrypted direct-messaging feature within the main Orchard72 application. Access is logged and limited to the minimum necessary to address the matter in hand.

25. Documents you upload

Orchard72 lets you upload documents (broker statements, bank statements, wills, identity documents, and others) so that we can show you previews, extract the information you need (such as transactions from a broker statement or beneficiaries from a will), and let you share documents with family members or professionals.

Proof of payment (professionals). If you are a professional and record a payment you received outside Orchard72 against one of your invoices, you may attach one proof-of-payment document to it, such as a bank transfer confirmation or a photo of a cheque. It is virus-scanned and stored in your vault like any other document you upload, linked to that payment, and visible only to you and your practice, not to your client. Uploading a replacement retires the previous copy. We keep it for as long as we keep the payment record it supports (see the retention table above).

25.1 Password-protected documents

Some documents you upload may be password-protected. To open them and provide the services you have asked us for, we need you to give us the password.

How we handle the password. You submit the password through an encrypted (HTTPS) connection. We use the password once, in our servers' memory, to open the document for that single request. We then discard it. We never write the password to disk, to our database, to our logs, or to any backup. We never send the password to any third party.

What we store. Once the document is opened, we save an unlocked copy of it in your vault. The unlocked copy is stored on servers in the EU/UK, encrypted at rest using AES-256 server-side encryption. An additional per-file (envelope) encryption layer, in which each file is sealed under its own key, covers this copy as well; see “Known limitations of at-rest encryption” above for what that layer does and does not protect against. Access is limited to you and to people you explicitly share the document with.

Your choice. Before you enter a password, we ask you to tick an explicit consent box. The box is not pre-ticked. You do not have to give us a password: if you choose not to, the document simply is not processed, and the rest of our service continues to work for you as normal.

25.2 Keeping the source document

When we extract information from your document (for example, when we read a broker statement and import the individual transactions into your portfolio view), we keep the source document alongside the extracted data.

Why we keep it. So that every number or value you see in the app can be traced back to the document it came from. If you (or your accountant, your executor, HMRC, or anyone else) ever asks “where does this figure come from?”, we can show you the original document, the page it came from, and the method we used to read it. This is part of the service you are paying for. You should never be left holding a number you can't explain.

Provenance. Every extracted value is stored with a link to its source document, the page number, the extraction method we used (optical character recognition or an AI model, with the version recorded), a confidence score where available, and a record of whether you have confirmed the value. You can see this in the “View source” link that appears next to every extracted value in the app, and you can download the full provenance bundle (source document + extracted data + extraction history) at any time from your vault.

Integrity. We store a cryptographic hash of every document you upload. This lets us (and you) verify that the document stored in your vault is exactly the document you uploaded, unchanged. We also keep a second hash of the version received from you. When we unlock a password-protected document we store the decrypted copy, and this pair of hashes lets us show you the full chain: what arrived, what we stored, and when the transformation happened.

Lifecycle log. We keep an append-only log of events that happened to each document in your vault: uploaded, unlocked, information extracted, you confirmed the extraction, you shared it, you deleted it. This log is what lets us answer “what happened to this document?” if you ever need to know.

25.3 Your rights

You can delete any document in your vault at any time. Deleting a document removes:

• The stored copy of the document
• Any previews or thumbnails we generated
• Any values we extracted from it (for example, the imported transactions from a broker statement)
• Any share links you created for that document
• The lifecycle log entries for that document

Deletion applies to our live storage immediately and to our backups within 30 days.

Legal-hold exception. In the rare case where a specific document has been flagged as relevant to an active or threatened legal dispute, we keep the source document and its lifecycle log for 6 years (the limitation period for contract claims under the Limitation Act 1980) so we can evidence what we did with it. This only ever applies to a specific flagged document, never by default.

Linked data. If you try to delete a source document while extracted values from it still exist in the app (for example, transactions imported from a broker statement), we will ask you whether you also want to delete those values. We will not silently remove the values you rely on.

25.4 Lawful basis

We process your document under UK GDPR Article 6(1)(b) (performance of our contract with you). The specific act of decrypting a password-protected document and storing an unlocked copy relies on your explicit consent under Article 6(1)(a). Where a document contains special category data (for example, health information or religious beliefs recorded in a will), we also rely on your explicit consent under Article 9(2)(a). Retaining the source document alongside extracted values relies on performance of contract (6(1)(b)) and our legitimate interest in being able to substantiate the figures we display (6(1)(f)), balanced against your interests in the way described in our legitimate-interests assessment (available on request).

25.5 Security

We limit incorrect-password attempts to 5 per document and 20 unlock attempts per hour per account, to prevent scripted guessing. We log the fact that an unlock happened (to give you an audit trail) but we do not log the password or the document's content. Our servers are hosted in the EU/UK; by default, data does not leave our infrastructure for OCR or AI processing, and a document is only ever sent to a third-party AI provider if you give explicit, per-document consent to enhanced external processing.

26. Wills drafted for you by a professional

A legal professional you work with through the platform can draft a will for you as their client and then hand it over to you for review. This section explains what we do with your personal data in that journey. It applies alongside section 2B (information we receive from others) and section 4 (how we share your information).

26.1 Before you accept

Your professional may begin drafting before you hold an account with us. Until you accept their invitation, we hold the draft will and the answers behind it for the professional, acting as their processor under Art. 28, in the same way as the client record described in section 2B. The invitation is matched to the email address your professional gave us, so a will drafted for you cannot be claimed by anyone else, and we tell you who invited you before you decide.

26.2 What changes when you accept

Ownership transfers to you. On acceptance the will and the drafting session become yours: they appear on your own dashboard, and from that point we hold them for you rather than for your professional. You can exercise all of the rights in section 6 over them directly with us.

Your professional keeps a limited view. Because they continue to act for you, the professional who drafted the will retains a professional-scope view of it on their own client screens. They do not keep ownership of it, and they cannot change it without your agreement (see 26.4). If your relationship with them ends, the will stays with you.

26.3 The record of changes

While a will is being drafted or reviewed we record each change as an event: who made it (you, your professional, or the platform acting on a state change), which part of the will it touched, the value before and after, and when. We show your professional the changes you made, and we show you the changes they made, so that neither side is asked to trust an unexplained edit. We do not share this record with anyone else, and we do not use it for profiling or automated decision-making.

26.4 Requesting changes and proposals

If you ask your professional to make changes, we pass the reason you give to them and open a recorded window in which they may edit the will again; that window closes when they confirm the changes are made and the will returns to you. After you have accepted, your professional can only propose a change, and the proposal (including anything they write to explain it) is shown to you so that you can accept or decline it.

26.5 Notifications

We email you, and show you an in-app notification, when you are invited, when a draft is ready for your review, and when your professional has made the changes you asked for. Your professional is notified when you accept, when you request changes, and when you decide on a proposal. These are service messages about your own will rather than marketing, so section 11 does not apply to them, and each one links to the specific will rather than to a general page.

26.6 Lawful basis

Handing the will over to you and running the review round trip is performance of our contract with you under UK GDPR Article 6(1)(b). Before you accept, we process the draft on your professional's instructions as their processor under Article 28, with their Article 6(1)(f) legitimate interest in servicing their own client as the basis for the underlying processing. The change record and the round-trip notifications rely on our legitimate interests in keeping an accurate account of who changed a legal document and in keeping both sides informed (Article 6(1)(f)). Where the will contains special category data (for example health information or religious beliefs), we rely on your explicit consent under Article 9(2)(a).

26.7 Retention

If you never accept the invitation, the draft stays with your professional and is kept or deleted under their own retention rules, and the pre-account contact details are deleted as described in section 2B. Once you accept, the will follows the retention periods for your own wills set out in section 8. The change record is kept for as long as the will it describes, because it is the evidence of how that will was produced.

26.8 Access across your professional's organisation

If your professional works within an organisation (for example a law firm) that uses our API, an owner or admin of that organisation can create an organisation-wide API key. That key can read the client records held by every professional in the organisation, including the records your professional holds about you, not only those of the person who created the key. The organisation is the controller of that access, and we act as its processor under Article 28 on the same terms as described above. Each request made with such a key is recorded (the key, the collection read and the number of records returned) and is visible to the organisation's owners and admins. The key stops working as soon as the organisation loses API access or is closed. An owner or admin can likewise register an organisation-wide webhook endpoint, which receives event notifications about the client records of every professional in the organisation; the same controller and processor roles apply, and it stops when the organisation no longer has webhooks on its plan. If you have questions about how your professional's organisation uses your data, please contact your professional directly.

27. Location Data

If you choose to let chosen family members see where you are, we process location data. This section explains what we collect, why we collect it, who sees it, how long we keep it and how you stop it. Everything described here is off by default: none of it happens unless you turn it on, and no other part of the service is degraded if you leave it off.

27.1 What we collect

Your consent record. Which family-safety options you have turned on, the date and time you turned each one on, and the IP address the consent came from. We keep this only as the record that you consented; it is not used for targeting, analytics, or to work out where you are.

Your sharing choices. For each person you invite: who they are, which details they may see, the level of detail you chose for them, when the share ends, and where it has got to (invited, viewed, acknowledged, declined, revoked or expired).

Position readings. If you turn on live location, your device reports your position while you have the website or one of our apps open and in front of you, after you have seen a plain-English explanation of what it is for and then granted the location permission your browser or your phone asks for. In our apps this is a single reading each time you ask for one, and the app never collects your position in the background. We store the coordinates, how accurate the reading was, and when it was taken and received.

We reduce the detail before we store it, not when we show it. The level of detail is worked out from the most detailed share you currently have active, and the coordinates are rounded to that level before the reading is written down. If nobody is entitled to see your exact position, no exact position exists anywhere in our systems: not in the database, not in a backup, not in a log. It follows that earlier readings are never made more detailed later: if you widen what someone may see, only readings taken from that point on carry the finer detail.

What we do not collect. We do not turn your coordinates into place names, addresses or points of interest, and we do not send them to any mapping or look-up service to do so. We do not record how long you stayed anywhere, your speed or direction of travel, any movement history beyond the window in 27.4, or any location-derived advertising or profiling signal. No error report, analytics event or other diagnostic message carries your position.

27.2 Why we collect it, and our lawful basis

The purpose is a narrow one: to let a small number of people you have named see roughly where you are, at the level of detail you chose for each of them, without you having to message them one by one. The lawful basis is your consent under Article 6(1)(a) of the UK GDPR. Every option and every sharing permission starts off, and a reading is refused outright if the consent behind it is not switched on.

Coordinates are not special category data under Article 9. We nevertheless treat them as highly sensitive, because a run of positions can suggest things about a person that Article 9 does protect. That is the reason we reduce the detail before storing it and keep readings for days rather than years.

27.3 Who sees it

The people you named, and nobody else. Recipients are drawn from the contacts already on your account and are reached through a private link. A recipient who has not yet accepted your invitation is shown only the invitation itself (your name, what you are offering to share, the end date) and no location, accommodation or contact detail at all. Anything a recipient is not entitled to see is left out of what we send them entirely, rather than sent and hidden.

No third parties. The map is served from our own systems, so opening it makes no request to any mapping vendor. There is no tile service, no geocoding service and no location analytics recipient, so this processing adds no sub-processor to the list in section 4.1. Position data is held in our UK/EU region database and is not transferred outside the UK or EEA.

27.4 How long we keep it

Position readings are deleted after seven days, on a rolling basis and permanently. We keep no archive, no summary and no derived travel history. The purpose of a live position is to answer “roughly where are they now”, and a longer window would serve no part of that purpose while turning the record into a movement history. Your consent record and your sharing choices are kept for as long as your account exists and are deleted when it is closed. Backups are on the same 30-day cycle described in section 8.

27.5 How to stop it

You can turn location sharing off at any time in your account settings. Switching it off stops new readings immediately, and this is enforced on our servers rather than on your device: recipients see that sharing is paused rather than continuing to see your last known position. You can also end an individual share at any time, which invalidates the link that person holds, and you can withdraw the location permission you gave your browser or your phone independently of us. Closing your account deletes the consent record, the shares and any readings still inside the seven-day window. Your wider rights, including access and erasure, are set out in section 6.

28. Documents Held in an Organisation Space

A firm, a charity or another organisation on the platform has its own document space, separate from the personal vault of each of its members. This section explains our role and the organisation's role in the data protection sense, what we process, and what happens when a member leaves or an organisation is closed. Section 25 continues to apply to documents you upload to your own vault.

28.1 Who is the controller

For a document in your own personal vault, we are the controller and section 25 sets out how we handle it. For a document filed into an organisation's space, the organisation decides what is filed there and why, so the organisation is the controller of that document within the meaning of Article 4(7) of the UK GDPR, and we act as its processor under Article 28. The responsibilities that Article 24 places on a controller, including deciding a lawful basis and telling the people concerned how their information is used, sit with the organisation for the documents it holds. Our processing terms with the organisation cover the matters Article 28(3) requires, including that we act only on its documented instructions and that our staff are bound by confidentiality.

If you are unsure which of these roles applies to your own situation, take independent advice; we cannot advise you on your obligations.

28.2 What we process, and who can see it

For each document in an organisation's space we hold the document itself, the account that filed it, when it was filed, the space it belongs to, and anything we have extracted from it. We also hold the record of who has been granted access to the space, at what level, limited to which matters, who granted it, and when it was withdrawn.

Documents in an organisation's space can be read by the accounts holding a profile in that organisation, and by anyone the organisation has separately granted access to. Access is checked on our servers on every request against the space a document belongs to, so a document is never returned to an account that is not entitled to it. Deleting, restoring and permanently removing a document remain with the account that filed it.

28.3 The access record

When an organisation withdraws someone's access we mark the record as ended rather than deleting it, so that the organisation can show who had access to which documents and over what period. We keep that record for as long as the organisation exists, because its purpose is accountability under Article 5(2) and it would not serve that purpose if it disappeared with the access it describes.

28.4 When a member leaves

Leaving an organisation ends the route into its space that membership provided. Documents the member filed there stay with the organisation, because they are the organisation's records rather than the member's. The member's personal vault is untouched and stays with them.

An access grant made to a person individually is held against their account rather than their membership, so it survives their departure until the organisation withdraws it. We do not withdraw it automatically, because we cannot know whether the organisation intended the access to end. Owners and administrators should review the grants on their space when someone leaves.

If a member exercises their right to erasure or closes their account, the documents in their own vault are erased. The organisation's space and the documents other members filed into it are not affected, because erasing one person's account must not destroy another controller's records.

28.5 When an organisation is closed

An organisation's space cannot be removed while documents are still filed in it, so the documents have to be dealt with before the organisation can be closed. We do not delete them for you and we do not generate an export automatically on closure, so download whatever the organisation needs to keep beforehand. Once the space is removed, the documents in it and the values extracted from them go with it, on the backup cycle described in section 8.

28.6 Requests about documents in an organisation's space

Because the organisation is the controller of those documents, a request to access, correct or erase one is for the organisation to decide. If you send us such a request we will pass it on and help the organisation respond, as Article 28(3)(e) requires of us, but we will not release or delete a document from an organisation's space without the organisation's instruction. Requests about your own personal vault are handled by us in the ordinary way under section 6.

28.7 Documents sent in by email

An organisation's space can have its own inbound email address, switched off until an owner or administrator turns it on. They choose whether only named senders or anyone may send to it. Where an allowlist is used we store each address as a keyed hash rather than in readable form, so the list can be checked without holding the addresses themselves. Mail from a sender the setting does not allow is rejected and its contents are not stored, and a repeated delivery of the same message is ignored. Anything that is accepted is filed into the organisation's space and is readable by everyone entitled to that space. A personalised address issued to an individual always delivers to that person's own vault and never to an organisation's space.

29. Your Travel Record and Day Counting

If you use the residency day counter, we hold a record of where you have been so that it can count your days for you. This section explains what that record contains, how entries get into it, what we do with them, and how you take them out again. Section 27 covers a different feature: letting people you choose see where you are now. The two are separate and you can use either without the other.

29.1 What the record contains

Where you were, and when. Each entry is a country, an optional region within it, the first day of the stay and the last, together with how the entry came to exist and whether you have confirmed it. A note you attach to an entry is encrypted at rest.

Where you stayed, and how you travelled. You can record the town or city and the dates of a stay, and the way you travelled with its scheduled departure and arrival times. The identifying detail attached to those, meaning the property name, its address and telephone number, the booking reference, the carrier and the flight number, is encrypted at rest and is never used to search or sort your records.

Your consent record. Which of the optional features in 29.2 and 29.4 you have turned on, when you turned each one on, and the IP address the consent was given from. As in section 27, we keep this only as the record that you consented; it is not used to work out where you are.

29.2 The two ways an entry can appear without you typing it

Both are off until you switch them on, and both produce a draft that counts towards nothing until you confirm it.

The country you signed in from. With this switched on, when you sign in we work out which country the request came from and propose a draft entry for that day. The resolution is to country level only, and we do not keep the IP address it was worked out from. Repeated sign-ins do not accumulate: at most one draft per country per day, so an entry you have already dealt with is never written over.

Travel emails you forward. With this switched on, an itinerary you forward to your personal inbound address is read on our own servers and the dates it contains are proposed as drafts. The reading is done by our own software, and the message never leaves our servers without your approval. What we keep of the message itself, and for how long, is set out under “Documents Emailed to Your Vault” in section 1 and in the retention table in section 8.

29.3 What we do with it

We add up the days your record shows in each country and compare the totals against published day thresholds we hold for a number of jurisdictions, each taken from an official source we cite alongside it. The count follows the rules those thresholds are written in: a day is counted where you were at midnight, overlapping entries are counted once rather than twice, and the period counted is the one the threshold itself uses, whether that is a tax year with its own start date, a rolling twelve months, or a run of several years.

Only entries you have confirmed are counted. A draft is ignored until you confirm it, so nothing inferred on your behalf changes a total on its own.

What the result is, and what it is not. The result is a total, the band that total falls into, and how close it sits to the next one, in wording we hold alongside the threshold itself. It is information about your own record and nothing more. It does not determine your tax residency, it is not a statement of your residence status in any country, and it is not tax or legal advice. Residence rules turn on much more than a day count, and only the relevant authority or a qualified adviser can tell you where you are resident. You are responsible for your own position, and you should check anything that matters with a professional.

29.4 Threshold emails

If you switch them on, we email you when your confirmed days cross into a new band for a jurisdiction you actually have entries for. The email carries the same wording we hold alongside that threshold, and we send one per band per counting period, so approaching the same threshold again in the same period does not email you twice. You can switch them off at any time in your account settings.

29.5 Who sees it

Your travel record is yours. We do not sell it, we do not use it for advertising or profiling, and we do not send it to any third-party AI provider. The one way another person sees any part of it is one you set up yourself: if you give someone a whereabouts share that includes accommodation, that share shows them the accommodation details it covers, on the terms described in section 27.

29.6 How long we keep it, and how to stop

Entries stay until you delete them or close your account. There is no automatic expiry, because a day count is only useful if the record behind it goes back far enough to cover the period being counted. You can delete any entry at any time from your account.

Switching a consent off stops the capture, and does so at once, but it does not remove what has already been recorded: drafts already proposed stay until you confirm or delete them, and that is deliberate, so that withdrawing a consent cannot quietly destroy entries you had already accepted. Closing your account deletes your entries, your accommodation and travel detail, your consent record, the record of which thresholds you have been emailed about, and the travel emails you forwarded, rather than leaving any of it to run out its own retention period. Your wider rights, including access and erasure, are set out in section 6.

30. Missing Will Enquiries

This section covers the enquiry channel, where someone searching for the will of a person who has died asks whether we hold anything that helps. It involves two groups of people at once: the enquirer, who is usually not a customer of ours, and the person the enquiry is about, who may be. Section 27 covers the registry record itself; this section covers the asking, the matching and anything we release as a result.

30.1 What an enquiry contains, and about whom

About the enquirer. Your name, your contact details, your stated relationship to the person you are searching for, your declaration that you have a genuine interest, your acceptance of the Acceptable Use Policy, and any evidence you choose to upload. We also keep a record of the enquiry itself, including when it was made and what happened to it.

About the person searched for. The identifying details you supply, which typically include a name, a date or year of birth, a date of death and one or more addresses. That person has not given us this information and may not be a customer of ours at all.

About third parties you mention. An enquiry often names other living people, such as a surviving spouse, a former adviser or a previous occupant of an address, because identifying someone reliably needs more than a name. We use those details only to judge whether the enquiry matches a record, and we do not build a profile of anyone from them.

To check for a match without holding a searchable copy of everyone who has ever been enquired about, we convert the identifying details into a keyed one-way digest and compare digests. The digest cannot be reversed to recover the details it was made from, and only records whose owner has chosen to be findable are represented in the index at all.

30.2 Our lawful basis

Where the person searched for is our customer, matching an enquiry against their record rests on their consent: nothing is indexed or matched unless they have chosen to be findable in that way, and withdrawing that choice removes them from matching. Consent is also what makes any release to you lawful.

Where you are the enquirer, we process your details on the basis of our legitimate interests in operating the channel, answering you, and protecting the people whose records we hold from misuse of it. We have weighed those interests against your interests and those of the people you name, and we have limited the processing accordingly: enquiry data is used to answer that enquiry and to prevent abuse, and for nothing else. It is not used for marketing, for profiling or for training models.

Where evidence of death is involved, we rely additionally on the establishment, exercise or defence of legal claims, and on the public interest in wills being carried out, because that evidence exists to support the administration of an estate.

30.3 Who we share it with

An enquiry may be passed to legal professionals on the platform so that one of them can tell you whether they hold or wrote the will. This is the point at which enquiry information leaves us, and it is limited in three ways: only professionals who have opted in to receive enquiries for the relevant area and jurisdiction are sent anything; only the details needed to recognise the matter are included; and the professional decides what to disclose under their own regulatory duty, not under our instruction. Those professionals are independent controllers of what they then hold.

Where a will we hold is in the care of a named custodian, we tell that custodian about the enquiry so that they can respond. We do not sell enquiry data, and we do not share it with anyone else beyond the sub-processors listed in section 4.1, which store and deliver it on our behalf.

30.4 People who have died

UK data protection law does not protect people who have died. The information rights in this policy belong to living people, so the person an enquiry is about does not, once they have died, have rights of access, erasure or objection over what we hold about them. We say so plainly rather than implying protections that the law does not give.

That is not the end of our obligations, and we treat it as a floor rather than a ceiling. Three things continue to apply. First, our duty of confidence in what we were told survives death, so we do not release a deceased person's information simply because the law would no longer stop us. Second, an enquiry about someone who has died almost always contains information about living people, including you and anyone you name, and they keep their full rights over it. Third, we apply the same security, retention and access controls to a deceased person's record as to a living customer's, and we keep releasing it only to those the deceased chose or the law entitles.

Where we cannot verify that the person searched for has died, we treat them as living and release nothing, because the alternative exposes a living person to being traced.

30.5 How long we keep it, and your rights

We keep an enquiry and its outcome for as long as we need it to answer you, to deal with a dispute about that answer and to detect repeated misuse of the channel, and we keep the audit record of what was released for the same period as the registry audit record described in section 27. Evidence you upload follows the retention set out there. You can withdraw an enquiry, and you can ask us to delete what you supplied, subject to the audit record we must keep to show what was disclosed and why.

If you have a record with us, you can turn findability off at any time, which stops future matching, and you can stop matching from the message we send you when an enquiry matches. Your wider rights, including access, correction, objection and complaint, are set out in sections 6, 7 and 14 and apply to enquiry data in the same way.

31. Files Digitised for a Professional Firm

Where a professional firm asks us to digitise its archive of client files, we are not the controller of what those files contain. The firm is the controller and we act as its processor, on its documented instructions, under the Article 28 terms published at Archive Digitisation Processor Terms. This section is for the people named in those files, who are often not our own customers and may never have heard of us: clients and former clients of the firm, deceased clients, and third parties named in the firm's correspondence.

Practically, that means the firm, not us, decides what is collected, how long it is kept and whether it is deleted, and the firm is who to approach about access, correction, objection or erasure. If you contact us directly about a file in a firm's archive, we will pass your request to that firm rather than answer it ourselves, unless the firm has instructed us to answer.

Content submitted for archive digitisation is processed by our own self-hosted models on our own servers. It is not sent to an external AI provider in this service: there is no default, silent or fallback route to a third-party model, and if our own processing is unavailable the work waits or is returned to the firm rather than being routed elsewhere. What a model produces is a suggestion for the firm's own review, and a person at the firm decides what the final record is.

We never take custody of the original paper documents, and we never certify that a scan is a true copy of an original. Digitised records are stored encrypted and scoped to that firm's own space, and how long they are kept follows the firm's instructions rather than any subscription of ours.

32. Features of Our Mobile Apps

Our iPhone and Android apps offer some features that use your phone's own hardware. Each one is optional, and each one is described here: what it collects, where that is processed, and how long we keep it.

32.1 Residency check-ins

If you turn on location check-ins for the residency day counter, your phone works out which country you are in and sends us only that country, the date and time, and how accurate the reading was. We never receive or store your coordinates: our servers refuse a check-in that contains them. To name the country, your phone uses its built-in location lookup, which on some devices asks Apple or Google to turn the position into a place name under their own privacy terms. Check-ins stay off until you turn them on, you can turn them off at any time, and each check-in becomes an entry in the travel record described in section 29.

32.2 Photographs of possessions

You can photograph a valuable item so that we suggest its details for you. The photograph is analysed by an AI model that runs on our own servers, and it is never sent to any outside AI service. If our engine is unavailable, we ask you to try again later rather than sending it anywhere else. The photograph is kept in your vault like any other file you upload, until you delete it. The suggested details are discarded after 24 hours if you do not save them.

32.3 Your emergency Wallet pass

You can add an emergency pass to Apple Wallet or Google Wallet. It shows your name, up to three emergency contacts (their names and phone numbers), whether you have an advance decision and a health and welfare power of attorney on file (a yes or no only, never their contents), and a QR code that links to your emergency information page. The pass contains no medical details. Once you add it, the pass is held on your device and by Apple or Google's wallet service, whose own privacy terms apply to what they hold. You can revoke the pass at any time from your account. Apple Wallet then removes it the next time it checks with us. A pass saved to Google Wallet stays there until you delete it, so please delete it there as well.

32.4 Passport chip verification

A professional who checks a client's identity with our app can read the chip in the client's passport on the professional's own phone. The phone reads the passport's personal details, the facial image stored on the chip where there is one, and the chip's digital signature. It never reads fingerprints or iris images. That data is sent to our servers, where we check the signature to confirm that the chip is genuine and has not been altered, and we record the result. The facial image is kept under the same rules as the other identity captures the professional holds for that client, and it is deleted with them.

For this check the professional is the controller of their client's data and we act as their processor. The professional relies on the legal obligations that require them to verify a client's identity (UK GDPR Article 6(1)(c)). The facial image is treated as special category data, and the professional processes it on grounds of substantial public interest (Article 9(2)(g)) under Schedule 1 of the Data Protection Act 2018.

32.5 Dictating visit notes

When a professional dictates a visit note, speech is turned into text by the phone's own on-device recogniser, and the audio never leaves the device. On devices that cannot do this, and on our website, the audio is sent to our own servers and transcribed by our own speech engine. That audio is deleted as soon as it has been transcribed, and only the text is kept.

32.6 Transcripts and captions for video wishes

If you ask for a transcript of a video message, it is produced by a speech engine that runs on our own servers, and the video is never sent to an outside service for this. The transcript and captions are stored with the video and deleted when you delete the video. Only you can see them unless you choose to share the captions with the people who can watch the video.

33. Tax Numbers and Platform Seller Reporting

This section covers the tax numbers we hold for businesses that buy from us or sell through us, and the information we must collect about professionals who are paid through the platform.

33.1 Tax numbers of business buyers

When a professional firm or a company buys a plan or an add-on from us, it may give us its VAT, GST or similar business tax number at checkout, and in some countries a statement that it is registered for that tax. We use the number, its type and any statement only to decide whether tax is charged on the sale and to show the number on the invoice, and we keep them with the record of the sale as evidence of that decision. Where a country requires us to report business customers we did not charge, such as Chile, we keep the full number, encrypted, for that report. Our payment provider, Stripe, holds the number on the customer record it keeps for us. A UK VAT number is checked with HMRC and an EU VAT number with the European Commission’s VIES service; the official register receives only the number. Our lawful basis is legal obligation (Art. 6(1)(c)): the tax rules require the evidence. We keep these records for the same period as our other tax and accounting records (Section 8).

33.2 Professionals’ VAT and tax numbers

If you are a professional and give us your practice’s VAT or tax number, or a client’s VAT number for the invoices you send through us, we check a UK number with HMRC and an EU number with VIES when it is saved and again every month, and we store the result and the date of the check. If a number that was valid is reported as invalid, we email its holder and our finance team is alerted. The result decides the VAT on our commission, as the Professional Terms explain. Our lawful basis is legal obligation (Art. 6(1)(c)).

33.3 Platform seller reporting (DAC7 and the UK rules)

The UK Platform Operators (Due Diligence and Reporting Requirements) Regulations 2023 and the EU rules known as DAC7 (Council Directive (EU) 2021/514) require us to identify the professionals who are paid for services through the platform and to report what they earned. Our lawful basis is legal obligation (Art. 6(1)(c)).

• What we collect: your legal name; your date of birth if you sell as an individual; your primary address; each tax identification number you hold and the country that issued it, or the reason you do not have one (and, only if you have no tax identification number, your place of birth); your business registration number and VAT number where you have them; the identifier of the account we pay you through; and any countries in which you have a permanent establishment. For each quarter we also record the total paid to you through the platform, the fees and commission we withheld, and the number of paid engagements.
• How we check it: we compare it with the other information we hold about you and check the format of each tax identification number. EU VAT numbers are checked with VIES.
• If it is missing: we send two reminders. If the information is still incomplete 60 days after the first, the rules require us to pause your payouts and suspend your listing until it is complete.
• Who receives it: HMRC, if you are resident in the United Kingdom or in a country HMRC exchanges this information with; the Irish Revenue Commissioners, where we are registered for DAC7, if you are resident in any other EU member state. The receiving authority may pass the report to the tax authorities of the countries where you are resident or have a permanent establishment. We send you a copy of what we reported by 31 January each year.
• How we protect it: dates of birth and tax identification numbers are held encrypted, are masked for staff who do not need them, and are never shown in your public listing. We use this information only to meet the reporting rules.
• How long we keep it: six years after the end of the last year we reported on you (the UK rules require five and the Irish rules six), and then we delete it.

34. Death Reports by Executors

An executor who has accepted their role on someone's will can tell us that the person has died. To do so they give the date of death and upload a copy of the death certificate. We use this to decide whether to record the death, which is what opens the releases the person set up in advance, such as video messages and the executor's read-only estate view. Our lawful basis is our legitimate interest, and the person's own instructions, in carrying out their wishes after death, and in protecting a living person from a false report.

The certificate is read by our own self-hosted model on our own servers, which checks that it is a death certificate and reads the name and date of birth so we can compare them with the account holder. It is never sent to an external AI provider: there is no default, silent or fallback route to a third-party model, and if our own processing is busy the check simply waits. We also check for duplicate reports and note whether a second executor agrees. A member of our staff makes the final decision before a death is recorded.

Before anything is released, we tell the person named in the report, by email, push notification and an in-app notice, that a report has been made and by whom. They can reject it during a contest period, and rejecting it closes every open report on their wills. The executor who made the report sees its status and, if it is rejected, the reason, but not the details of our checks.

The certificate is stored encrypted in the person's document vault as part of their estate records. The report, its status history and its audit trail are kept for as long as the will is held with us and are deleted with it. A rejected certificate cannot be used again for 24 hours, so we keep a fingerprint of the file to enforce that.