ITSM Ltd SaaS legal set — Part 2
Privacy Policy
Version 2.0 · In force from 24/09/2026
Supersedes Privacy Policy version 1.5.
1. Introduction
This Privacy Policy is provided by ITSM Ltd, a company registered in England and Wales under company number 17339600, with registered office at 167-169 Great Portland Street, 5th Floor, London, W1W 5PF (“we”, “our” or “us”). It covers our standalone software services — the ones we sell directly, each under its own brand and each named in an annex at the end of this policy. For each of them, the website and the software application together are a Service, and together they are the Services. What is true of every Service is in the body of this policy. What is true of one Service only is in that Service's annex, which forms part of this policy; the annexes are lettered in turn, starting with Annex A. Every annex has the same seven sections, so a reference in the body of this policy to section A1, A3 and so on means that section of the annex for the Service concerned (B1, B3 and so on in Annex B).
We take your privacy very seriously. Please read this policy carefully, as it contains important information on how and why we collect, store, use and share any information relating to you (your personal data), your rights in relation to it, and how to contact us or the regulator if you have a complaint. Our handling of your personal data is regulated by law, including the UK General Data Protection Regulation (UK GDPR).
Which of us is responsible for what
There are two kinds of personal data here, and different people are responsible for each. Getting this right matters, because it decides whose privacy notice governs and who you should ask when you want something done.
We are the controller — the organisation that decides how and why the data is used — for the data we hold about you as a user of the Services: your sign-in account and the email address it uses, your sign-in session, your membership of the organisations you belong to and the invitations you send or receive, billing, the record of which of our documents you accepted, your support enquiries, and the messages we send you, other than any reminders that section A7 of a Service's annex says are sent on your organisation's instructions. We are also the controller for what you send us through a Service's public forms — an enquiry or a waitlist registration, for example — and for the list of addresses we are not to send a reminder to, for any count a Service keeps of visits to its pages, and for the record of which reminders and notices have been sent. This policy governs that data, and requests about it come to us.
We are a processor, and your organisation is the controller, for everything your organisation records in a Service (its Records). What that covers is defined in the Service Schedule for each Service and listed in its Data Processing Particulars (section 11.5 of that Schedule). Your organisation decides what goes in, why, and how long it stays. We process it on its documented instructions under clause 11 of our SaaS Terms and Conditions and the Data Processing Particulars in section 11 of the Service Schedule, and for no purpose of our own. Your organisation's privacy notice governs that content, not this one.
If you want something removed from an organisation's Records, or want to know why you appear in them, ask that organisation. We will help it answer, but we cannot decide on its behalf what belongs in its records. Section 12 explains this further.
2. What this policy applies to
This policy relates to your use of the Services only. The Services may link to or rely on other apps, websites, APIs or services owned and operated by us or by trusted third parties. Those other services may gather information about you under their own separate privacy policies, which you should consult. For more information, see section 8.
3. Personal data we collect about you
The personal data we collect depends on the activities carried out through the Services. Across our Services we collect and use the following personal data about you; the categories specific to each Service, and the detail, are in section A1 of its annex.
| Category of data | In more detail |
|---|---|
| Identity and account data (an account is needed to use a Service's application, but not to read its public pages or use its public forms) | Your email address, which is also your username, held in your sign-in account. How you sign in, and when your account is created, is in each Service's annex |
| Organisations, memberships and invitations | The organisations you belong to in a Service, your role and your access in each, a copy of your email address held against each membership, and the invitations you send or receive — the address invited, the role and access offered, who sent it and when. Other people in your organisation can see some of this; each Service's annex says who and what |
| Technical data | The IP address and request information that reach the providers who host a Service whenever your browser contacts it, and the dates and times a Service stores against what is done in it — for example when a document was accepted or a record created. We do not use this to build a profile of you. Where a Service counts how its pages are used, section A2 of its annex says exactly what it records, from which pages, and for how long |
| Data collected when you make an enquiry with us | Your name, your organisation's name and your email address, what you write, any other details the form asks for, and the IP address the request came from. Each Service's annex says which forms it has, which details are required, and how long the IP address is kept |
| Waitlist | If you ask to be told when a Service launches: your name and your email address, any optional details you choose to add, and the IP address the request came from — handled as the annex for that Service describes |
| Content your organisation records in a Service | The Records described in section 1. These are free text, and may name or describe any person. Where this content contains personal data, your organisation is the controller and we are its processor |
| Security and sign-in data | Your sign-in session, and the record of which legal documents you accepted and at which version (see section 7) |
| Billing data | The billing contact's email address, the billing address your invoices are made out to, any purchase-order reference you give us, and the payment provider's customer and subscription identifiers for your organisation. Card details are entered by you on the payment provider's own pages and never reach us |
| Support and correspondence | What you write to our support address or, where a Service has one, in our support portal, and our replies |
If you do not provide personal data we ask for where it is required, it may prevent us from providing the Services to you.
4. Sensitive data
Sensitive personal data (also known as special category data) means information revealing racial or ethnic origin, political opinions, religious or philosophical beliefs or trade union membership, genetic data, biometric data used for identification, and data concerning health, sex life or sexual orientation.
We do not ask for sensitive personal data, or information about criminal offences, in order to give you an account, and we do not seek it for our own purposes.
Sensitive personal data can nevertheless reach a Service, and it is better to be plain about it. Section A1 of each Service's annex names the realistic routes by which it can. Where an organisation records that kind of information, the organisation is the controller of it and we process it on that organisation's instructions. The organisation is responsible for identifying a condition under Article 9(2) of the UK GDPR and, where that condition requires one, a condition in Schedule 1 to the Data Protection Act 2018, with an appropriate policy document meeting Part 4 of that Schedule where the condition requires one — and, for anything about a criminal offence that is not processed under the control of official authority, a condition in Part 1, 2 or 3 of that Schedule, because Article 10 of the UK GDPR has no conditions of its own and section 10(5) of that Act supplies them. Clause 11.2(f)(i) of our SaaS Terms and Conditions sets the full list out, starting with a lawful basis under Article 6. The organisation's own privacy notice governs that information, not this one. Our Acceptable Use Policy asks the people using a Service not to record special category or criminal offence data unless their organisation has told them to, and then only as far as its purposes need.
We do not treat information recorded in a private, access-controlled Record as having been made public by the person it concerns.
5. Children
The Services are not intended for children. They are not intended for use by anyone under 18, and we do not knowingly collect personal data from anyone under 18 for our own purposes. If you believe someone under 18 holds an account, tell us and we will remove it.
That is separate from what an organisation records in a Service, which may describe or show a child. Where that happens, the organisation is the controller of that content, is responsible for having a lawful basis for it and for the additional care that children's data requires, and its own privacy notice governs it. See section 1.
6. How your personal data is collected
We collect personal data from you directly when you ask to sign in to a Service, use it, submit one of its public forms or write to us. We also collect it through what other people do in a Service: when a colleague invites you, for example, the invitation holds your email address. Where a Service's annex says so, we also receive reports from our email provider about the messages we have sent — that one could not be delivered to your address, for example — and use them only as that annex describes.
As part of delivering the Services we use only the cookies that signing in needs. Our Cookie Policy lists them, says what each one is for and how long it lasts.
We do not use an analytics provider, and we do not track you across other websites. Where a Service counts how its pages are used, section A2 of its annex says what it records, how, from which pages and for how long; any aggregate count a Service's error reporting sends is described in its annex too. Requests still reach our hosting provider carrying your IP address, as they do for any website.
7. How and why we use your personal data
Under data protection law, we can only use your personal data if we have a proper reason: (a) where you have given consent; (b) to comply with our legal and regulatory obligations; (c) for the performance of a contract with you, or to take steps at your request before entering into a contract; or (d) for our legitimate interests or those of a third party.
In the table, Contract or legitimate interests means: to perform our contract where you are a party to it or are taking steps to become one; and where the contract is with the organisation you act for and not with you personally — the usual case — our legitimate interests in providing the Service it has bought.
A legitimate interest is when we have a business or commercial reason to use your information, so long as this is not overridden by your own rights and interests. You can object to any use that relies on it (see section 12).
| What we use your personal data for | Our reasons |
|---|---|
| Creating and managing your sign-in account, and your membership of the organisations you belong to | Contract or legitimate interests (defined above the table) |
| Providing the Services and their functionalities to you | Contract or legitimate interests (defined above the table) (the contract being our SaaS Terms and Conditions and the relevant Service Schedule, or — for website use — our Website Terms of Use) |
| Sending you a sign-in link, and an invitation where a colleague invites you | Contract or legitimate interests (defined above the table). Where a Service signs you in by emailed link, as its annex says, there is no password, so without this you cannot use it at all |
| Handling support enquiries, and creating a support-portal account for the people a Service's Service Schedule describes | Contract or legitimate interests (defined above the table). The annex and the Service Schedule for that Service say who gets an account and exactly what is sent |
| Taking payment, raising invoices and meeting our accounting and tax obligations | To perform our contract where you are a party to it; where the contract is with the organisation you act for and not with you personally — the usual case, and always so for a billing contact — for our legitimate interests in being paid for the Service it has bought; and, for keeping the billing records afterwards, to comply with our legal obligations |
| Recording which legal documents you accepted, and at which version | For our legitimate interests in being able to show what was agreed, by whom and when, and to establish, exercise or defend legal claims. When the person contracting for an organisation accepts our SaaS Terms and Conditions, the same tick confirms that they are acting for an organisation or a business and not as a consumer. That confirmation is recorded only as their acceptance, and we collect no company or VAT number. It is evidence, not a decision: whether someone is in fact a consumer is settled by law, not by a tick box, and a consumer's statutory rights are unaffected |
| Communications not related to marketing — changes to our terms or policies, changes to the Services, and the notices our agreement with your organisation requires | Depending on the circumstances: to comply with our legal and regulatory obligations; otherwise, for our legitimate interests, i.e. giving the notices that agreement promises and keeping you informed about the Service you use |
| Protecting the security of systems and data, and diagnosing failures | Depending on the circumstances: to comply with our legal and regulatory obligations; and, where we go beyond them, for our legitimate interests, i.e. to protect systems and data and to keep the Services working |
| To enforce legal rights, or defend or undertake legal proceedings | Depending on the circumstances: to comply with our legal and regulatory obligations; otherwise, for our legitimate interests or those of a third party |
| Statistical analysis to help us manage our business, only from data for which we are the controller, and in a form that cannot identify anyone | For our legitimate interests, i.e. to run and improve the Services (see section 10) |
| Sharing your personal data with third parties in connection with a significant corporate transaction or restructuring — including a merger, acquisition, asset sale, or in the event of our insolvency. In such cases information will be anonymised where possible and only shared where necessary | Depending on the circumstances: to comply with our legal and regulatory obligations; otherwise, for our legitimate interests, i.e. to protect, realise or grow the value in our business and assets |
Section A7 of each Service's annex adds the purposes that are particular to it, with our reasons.
We send product marketing only where the Service Schedule for a Service, and its annex to this policy, say that we do, and then only to people who asked for it; we never pass anyone's details to a third party for their own marketing.
8. Who we share your personal data with
We routinely share personal data with service providers we use to help us run our business or provide the Services. We only allow service providers to handle your personal data if we are satisfied they take appropriate measures to protect it, and where they act as our processors we impose contractual obligations on them so they can only use it to provide services to us and to you. A provider that is also an independent controller for purposes of its own — a payment provider preventing fraud, for example — uses what it receives for those purposes under its own privacy notice, as its row in the annex says.
The complete list of processors and other recipients for each Service — what we use each for, what personal data each receives, where it processes it, and how any transfer out of the UK is covered — is in section A3 of that Service's annex. It is the sub-processor list for the purposes of clause 11.5 of our SaaS Terms and Conditions. If we add or replace a processor we will update the table and give the owners of each customer organisation at least 30 days' notice by email before the change takes effect; customers may object on reasonable data protection grounds within that period.
Other people in your organisation also see some of your details, such as your email address and your role; section A3 of each Service's annex says who sees what.
We, or the processors listed in the annexes, may occasionally also need to share your personal data with:
- (a) external auditors, e.g. in relation to the audit of our accounts — the recipient will be bound by confidentiality obligations;
- (b) professional advisers, such as lawyers and accountants — the recipient will be bound by confidentiality obligations;
- (c) law enforcement agencies, courts or tribunals, and regulatory bodies, to comply with legal and regulatory obligations; and
- (d) other parties in connection with a significant corporate transaction or restructuring — usually information will be anonymised, but this may not always be possible; the recipient will be bound by confidentiality obligations.
We will not share your personal data with any third party other than as described in this section and the annexes.
9. How long your personal data will be kept
How long we keep something depends on what it is. These rules apply across our Services; the rows that differ by Service are in section A4 of its annex.
| What | How long we keep it |
|---|---|
| Your sign-in account, and the email address in it | Until you ask us to delete it. Being removed from an organisation, or that organisation being deleted, does not delete your account, because you may belong to others. When we delete an account, your memberships, the access granted to you, your acceptance records and any invitations you sent go with it; the organisations you belonged to, and what they recorded, do not |
| Your membership of an organisation, and the copy of your email address held with it | Until you are removed from the organisation, your sign-in account is deleted, or the organisation is deleted, whichever comes first |
| Content in your organisation's Records | For as long as the organisation exists in that Service, including after a subscription is cancelled or lapses. Nothing deletes it on a timer; the organisation decides when it goes. The detail is in section A4 of each Service's annex, and the duration of our processing in section 11.4 of the Service Schedule. Within that, the organisation is the controller of the content |
| An organisation deleted at an owner's request | Deleted in full, in the way that Service's annex describes. Deletion is not reversible |
| The record of which legal documents you accepted | It cannot be edited or removed on its own from inside a Service, and it is deleted when your sign-in account is deleted. It holds your user identifier, the document, its version, the date and time, and a random reference for the row — and nothing else, not even the organisation |
| Support enquiries — raised in our support portal, or sent to our support address about a customer organisation — and support-portal accounts | Six years after the customer organisation closes, and then deleted in a yearly review. A portal account is deactivated and its access removed when an owner of the organisation asks — the portal has no deletion call, so deactivation is what we can offer. Deleting an organisation from a Service does not touch the portal |
| Other email to our support address, including the copies of public-form submissions sent to it | 24 months after it arrives, then deleted by a retention rule in our mailbox, unless it has become part of a support enquiry about a customer organisation, when the row above applies |
| Billing records | Six years after the last invoice, to meet accounting and tax obligations, and then removed from our billing account in a yearly review, as far as our payment provider allows |
| Anything we hold because you consented to it | As the annex for that Service states, next to the thing you consented to |
Nothing is anonymised. When a period above or in an annex ends, the data is deleted — by an automatic daily job where the annex says so, and otherwise by hand.
10. De-identified information
We may produce aggregated statistics from the personal data for which we are the controller — for example, how many organisations subscribe on each plan — and use them to operate and improve the Services. We do not derive statistics, benchmarks or product insight from the contents of an organisation's Records, which we process only on that organisation's instructions; section 11.3 of the Service Schedule says the same. We publish no benchmarks. We do not sell your personal data.
11. Transferring your personal data out of the UK
What your organisation records in a Service is stored in the United Kingdom, unless the Service Schedule for that Service says otherwise. Some of the other services we rely on process personal data elsewhere, and those transfers happen now rather than hypothetically. For each recipient, section A3 of each Service's annex says where it processes personal data and how any transfer is covered.
Under UK data protection law a transfer out of the UK normally needs one of two things, and they are alternatives rather than the same route: either the UK government has decided that the destination provides an adequate level of protection (an adequacy regulation under Article 45 of the UK GDPR), or appropriate safeguards are in place together with enforceable rights and effective remedies for you (Article 46). A limited set of specific exceptions can also apply.
- (a) The EEA. The UK currently treats the EEA as adequate under transitional provisions made by section 17A of the Data Protection Act 2018 and the DPPEC Regulations 2019.
- (b) Anywhere else. We rely on appropriate safeguards under Article 46 — in practice the International Data Transfer Agreement, or the EU Standard Contractual Clauses as amended by the UK Addendum — in the recipient's data processing terms. Write to us (see section 16) if you would like a copy of the safeguards for a particular recipient.
For the Records we process for your organisation, clause 11.3(d) of our SaaS Terms and Conditions applies the same rule: we transfer them out of the UK only under one of these mechanisms.
12. Your rights
You generally have the following rights, which you can usually exercise free of charge. For more information, see the ICO's guide to individual rights.
| Right | What it means |
|---|---|
| Access to a copy of your personal data | The right to be provided with a copy of your personal data. |
| Correction (rectification) | The right to require us to correct any mistakes in your personal data. |
| Erasure (the right to be forgotten) | The right to require us to delete your personal data, in certain situations. |
| Restriction of use | The right to require us to restrict use of your personal data in certain circumstances, e.g. if you contest its accuracy. |
| Data portability | The right to receive the personal data you provided to us in a structured, commonly used and machine-readable format, and/or to transmit it to a third party — in certain situations. |
| To object to use | The right to object: at any time, to your personal data being used for direct marketing (including profiling); and, in certain other situations, to our continued use of your personal data, e.g. where we rely on legitimate interests. |
| Not to be subject to decisions without human involvement | 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 any such decisions, and we do not use artificial intelligence to process the contents of your organisation's Records. Any automated calculation a Service performs is described in section A7 of its annex. |
You have an absolute right to object to direct marketing at any time, and if you do we will stop; section 7 says when we send any. You also have the right to withdraw your consent wherever we rely on consent, and each Service's annex says where that is. Withdrawing consent does not affect anything we did before you withdrew it.
We will respond to a request within one month. If a request is complex, or you have made several, we may extend that by up to two further months, and we will tell you if we do.
Where you should send a request
If your request is about content inside an organisation's Records — an entry someone made that mentions you, a photograph, a contact detail they recorded — the organisation is the controller of that content and you should ask it. We will help it respond, but we cannot decide on its behalf what stays in its records. If your request is about the data we hold about you as a user of the Services — your account, your sign-in, your email address — ask us.
Things we cannot undo, and why
Some records in a Service cannot be removed individually by the people using it, by design, because the Service's purpose depends on their being kept as they were written. Each Service's annex lists exactly which records these are for that Service, and why, in section A5. Where we are the controller and refuse a request to erase something, it will be because an exception in Article 17(3) of the UK GDPR applies — for example, that the data is needed to comply with a legal obligation or for the establishment, exercise or defence of legal claims — and we will tell you which. We can still restrict how the data is used, and we will always tell you what we have done and why.
Append-only binds the people using a Service, not the controller. For the contents of an organisation's Records the controller is that organisation, and it can instruct us to remove or amend an entry, or to delete the organisation and everything in it — see section A5 and section 10 of the Service Schedule. Where we are the controller — your account, your billing, the record of what you accepted — the request comes to us.
If you would like to exercise any of your rights, please email us — see section 16. When you do, please provide enough information to identify yourself — usually the email address you sign in with — and any additional identity information we may reasonably request, and tell us which right(s) you want to exercise and what your request relates to.
13. Keeping your personal data secure
We have appropriate security measures to prevent personal data from being accidentally lost, or used or accessed unlawfully. We limit access to your personal data to those who have a genuine business need for it, and we have procedures to deal with any suspected data security breach. We will notify you and any applicable regulator of a suspected breach where we are legally required to do so.
Across our Services, in practice that means:
- Separation between organisations, enforced as each Service's annex describes.
- Encryption in transit, with HTTPS enforced for every request.
- A content security policy for each Service — enforcing, or sent in report-only mode, as that Service's annex states.
- Staff access, described precisely in each Service's annex — including where it is less separated than a larger company's would be.
Cyber Essentials: not certified. We do not hold Cyber Essentials or Cyber Essentials Plus certification. The measures we do have are the ones above and those in section A6 of each Service's annex, which also says what we do not have.
If you would like general advice on protecting your own devices, the National Cyber Security Centre publishes guidance at www.ncsc.gov.uk.
14. How to complain
Please contact us if you have any queries or concerns about our use of your information (see section 16). We hope we will be able to resolve any issues you may have.
You also have the right to lodge a complaint with the Information Commissioner, who can be contacted at ico.org.uk/make-a-complaint or by telephone on 0303 123 1113.
15. Changes to this Privacy Policy
We may change this Privacy Policy from time to time by posting the updated version on our websites and giving you at least 30 days' prior notice by email to the address held for your account, in the same way as clause 19 of our SaaS Terms and Conditions. This policy is a notice, not terms you agree to: nobody is asked to accept it, and each version applies from its effective date.
16. How to contact us
Postal address: ITSM Ltd, 167-169 Great Portland Street, 5th Floor, London, W1W 5PF
Email: support@itsm-ltd.com
We are not required to appoint a data protection officer and have not appointed one. Questions about this policy, and requests about your personal data, go to the address above and are handled by ITSM Ltd's directors. We are registered with the Information Commissioner's Office and pay the data protection fee.
Annex A — Martyn's Law Evidence Kit
This annex applies to the Martyn's Law Evidence Kit — this website, and the application you reach after signing in to it. It forms part of this policy. In this annex, “this Service” means the Martyn's Law Evidence Kit. Keeping the drill, review and other records this annex describes is good practice — not required at standard tier (section 1(c) of the Service Schedule).
A1. What this Service collects, in addition to section 3
| Category | Detail |
|---|---|
| Your sign-in account | Your email address. An account is created the first time anyone asks for a sign-in link with that address, whether or not the link is then followed. Asking is what creates it, so an address typed in by someone else, or mistyped, becomes an account too. There is no password. Our authentication provider also records when the account was created and last signed in, and its active sessions. The account is kept until you ask us to delete it (section 9), including one created with your address by someone else |
| Organisations, memberships and invitations | Each organisation's name, whether it was set up for a single premises or an estate, who created it, its billing address and its countdown-digest setting; each member's role (owner or member), their access (the whole organisation, or only the groups and premises granted to them) and a copy of their email address; the names of groups; and each invitation's address, role, access, the groups or premises it grants, who sent it, and when it was sent, expires, was accepted or was revoked. Only a SHA-256 fingerprint of an invitation link is stored in our database, never the link itself. The link is in the email, which is sent through our email provider (section A3). Because the secret part of it is in the address, it also appears in the logs of requests made with it: each page request that carries it and, if the link is opened before signing in, the sign-in request passed to our authentication provider (the server and platform logs row below; section A4 says how long they are kept). It works once, within 14 days, and only for someone signed in as the address it was sent to |
| Premises profiles | For each premises your organisation records: its name, type, capacity, address, notes about its layout, its exits, its assembly points, the role, name and telephone number of each key holder or responsible person your organisation chooses to list, the tier the Service shows for it as a guide, worked out from its capacity and type, whether and when the Security Industry Authority was notified, the next review date, and the group it belongs to |
| Generated procedure packs | Evacuation, invacuation, lockdown and communication procedures generated for a premises from the profile above, kept as numbered versions and downloadable as PDF or Word documents carrying the template watermark. Each version keeps a copy of the profile as it was, key holders' names and numbers included, so a key holder removed from the profile stays in every earlier version until the premises or the organisation is deleted. Each version also records the account that generated it, until that account is deleted |
| Decision records | What was decided, by whom, with whom, what was weighed and what was rejected — free text your organisation writes, which routinely names people. The names are typed in: a decision record does not note which account entered it |
| Drill and refresher logs | The date, what kind of session it was, who took part and what happened — including incident and near-miss reviews, which describe real events. Who took part is typed in: a log does not note which account entered it |
| Photographs attached to a drill log | JPEG, PNG, WebP or HEIC images of up to 10 MB each, uploaded from your browser straight to our database provider's private store, which is not publicly addressable, and shown only through links that expire after an hour. The file is stored exactly as it was uploaded, so it keeps any details the camera or phone wrote into it — the time it was taken, the device, and sometimes the location. That store also records which account uploaded each photograph. A photograph is stored as soon as it is chosen, before the log is saved — see section A4 of Annex A to the Acceptable Use Policy. A photograph of a walkthrough may show identifiable people and the interior of the premises: a village hall, a church or a scout hut may photograph a walkthrough that a child is standing in (section 5). The evidence pack downloaded as a PDF on its own notes only that a drill has a photograph; downloaded as a ZIP file, it comes with every photograph attached to that premises' drill logs (section 10(a) of the Service Schedule) |
| Annual review records | The date of a review, who carried it out, the outcome and any notes. Who carried it out is typed in: a review does not note which account entered it |
| Tier-checker downloads | When you download a PDF of your tier-checker result we keep the email address you gave, the answers you gave, the tier the checker showed and the IP address the request came from. We keep it whether or not you also tick the box asking for an email repeating the result's headline — the address is required to produce the download at all, and the row is what enforces the limits below. Whether you ticked the box is not stored. We also count the download, without your address, as section A2 describes |
| Large-estate enquiries | Your name, your organisation's name and your email address (all three required), the number of premises if you give it, your message, and the IP address the request came from. The enquiry is also emailed to our support mailbox (section A3) |
| Waitlist registrations | Your name and your email address (both required), and optionally your organisation's name, a number of premises and a message, together with the IP address the request came from. The registration is also emailed to our support mailbox (section A3), and counted, without your name or address, as section A2 describes |
| Submission limits | The three public forms above are limited to 3 submissions per email address in 24 hours and 20 per network address in an hour, counted from the rows above. We store the IP address in full and not as a hash — that is what the code does, and we would rather say so than describe a protection we have not built. It is kept for 7 days, which is longer than either limit needs and short enough that it is not a log of who visited us; the submission itself is kept for the period in section A4. The limits depend on our administrative key being configured; without it they do not apply, which is one reason this Service does not start in production without it. Asking for a sign-in link has no limit of its own in this Service: it relies on the limits our authentication provider applies |
| A support-portal account | Where support-portal set-up is switched on, creating your organisation asks ITSM Ltd's support portal at `support.itsm-ltd.com` to create an account for it, sending your organisation's identifier and name and the email address of the person who created it. If that first attempt fails and our daily job retries it (up to six attempts in all), the retry sends the address of the organisation's longest-standing owner at that time. An organisation created before support-portal set-up was switched on is given an account in the same way, by that daily job, which sends its longest-standing owner's address. No name is sent, and nothing from your Records, then or ever. The portal then sends its own invitation to set a password there: it is a separate system, run by ITSM Ltd, and it is where your support history lives. We record whether the attempt succeeded, without the email address. Section 5(b) of the Service Schedule says what this means for you |
| Diagnostic reports | Once error reporting is configured, which it must be before this Service opens to sign-ups, a failure on a payment, premises-creation, pack-generation, evidence, evidence-export, legal-acceptance, support-provisioning, reminder, renewal-notice, access-change-notice, page-count (section A2), stop-list, retention or heartbeat path makes our servers send an error report to our error-reporting provider (section A3). It carries the error message, where in the code it happened, and identifiers for the organisation, premises, drill log, subscription, entitlement, payment or dispute involved — for a payment dispute, its amount and reason as well; for an access-change notice that could not be sent, the identifier of the account it was for; and for a page count, the kind of event. Each time our email provider's report adds addresses to the stop list (the row below), a report is sent saying how many and why, without the addresses. The message can include text another system returned to us, such as the support portal's explanation of a refusal, passed on unaltered. The incoming request's cookies, headers, body and query string, and any user details, are removed before a report is sent. A report can also carry a trail of up to 100 recent entries: outgoing requests the server made, including their query strings, and log lines. These can include account identifiers, and can include the email or network address one of the public forms above checked against its limits, or the daily visitor value described in section A2. The public forms send no reports of their own. What they record about a failure goes only to the logs in the last row of this table. Besides the paths above, an error that nothing in the server catches at all — an uncaught exception or an unhandled promise rejection — is also reported. No performance traces are collected. The error-reporting library does send our error-reporting provider aggregate counts of the requests the server handled and how many failed, which carry no personal data |
| The stop list | The addresses that are not to be sent a reminder. Each entry holds the email address, which reminders it stops (annual reviews, post-incident prompts, the countdown digest, or all three), the date, and a short note of why. An entry is made in one of four ways: when you press the button on the page that the link in a reminder opens, which stops that kind of reminder for the address it was sent to; when you press your mail app's own unsubscribe button, where it shows one, which sends us the same kind of link with a one-click request; by us, by hand, when you reply or write to us; or automatically, for all three, when our email provider reports that a message this Service sent to that address was permanently rejected by the receiving mail server, or was marked as spam by its recipient. The link carries the address it was sent to and a code that proves we issued it, and opening it changes nothing until the button is pressed. The stop list never stops a renewal notice, a notice of unpaid Fees, or any other email that section 6 of the Service Schedule says is sent regardless |
| Reports from our email provider | Our email provider (section A3) sends our servers signed reports about the messages this Service has sent through it. We act on two kinds only — a message permanently rejected by the receiving mail server, and a message its recipient marked as spam — and from those we take only the recipient's address, to add it to the stop list (the row above). We keep nothing else from any report, and reports of any other kind, such as a delivery, are received and discarded |
| Page visits and steps towards buying | What section A2 describes: the path of a public page that was visited, the website that linked to it (its address only), a visitor value that changes every day, and a record of three events — a tier-checker download, a waitlist registration, and the start of a card payment. We do not store an IP address, an email address or an account for any of them |
| Server and platform logs | Our hosting provider keeps the application's logs and a log of the requests made to this Service, and our database provider keeps logs of the requests made to it (section A3). A request log records the network address and browser each request came from and the page it asked for. For requests to our hosting provider, and for your browser's direct contact with our database provider when you upload or view a drill photograph, that is your own network address. For the requests our servers make to the database provider, it is our servers' address. The page asked for can carry identifiers, and it can carry a whole link: an invitation link, when one is opened or used to sign in; a sign-in link, when one is opened; and the link in a reminder that stops it, which carries the email address it was sent to, when one is opened. The application's own log lines normally carry identifiers rather than names or email addresses, but they can contain an email address: if a waitlist acknowledgement cannot be sent, for example, the log line names the address it was for. The database provider's logs also record the email and network addresses our public forms check against the limits above. Every diagnostic report above is also written to the application's logs |
Where sensitive data can come in (section 4). In this Service there are two realistic routes. The first is any free-text field — an incident or near-miss review above all, which describes something that happened and may therefore describe someone's health, conduct or an alleged offence. The second is a photograph attached to a drill log, which may show identifiable people and can reveal, for instance, that someone uses a wheelchair.
A2. How this Service measures use of its public pages
We count visits to this Service's public pages ourselves, without a cookie and without an analytics provider. No analytics or tracking product is loaded, no session is replayed, nothing measures how you use the application once you are in your account, and there is no advertising or cross-site tracking of any kind.
Which pages. The home page, the tier checker, the waitlist, the sign-in page, the user guides and these legal pages — whoever is reading them, signed in or not. No other page is counted: nothing in the dashboard, a premises, Settings or anywhere else behind the sign-in, and not the pages reached from links we email (sign-in confirmation, invitations and stopping a reminder).
What is recorded for a visit. When one of those pages opens, the Service's own script in the page sends our server the page's path, without any query string, and the address your browser reports as having sent you there. Our server keeps the path, the address of the website that sent you (its scheme and host only, never the full link), the time, and a visitor value. The visitor value is worked out on our server from your IP address, your browser's identification string and the date, using a one-way keyed function whose key only our servers hold, and cut short. Your IP address and your browser's identification string are not stored for this. The same browser on the same network address gets the same value for the rest of that day (UTC) and a different, unrelated value the next, so we can count how many different visitors a page had on a day, but not recognise anyone from one day to the next. A visitor value is limited to 30 recorded visits a minute.
Three steps towards buying. Our servers also record, in the same way, that one of three things has happened: a tier-checker PDF was downloaded, someone registered on the waitlist, or a card payment was started. The last happens from Settings, so it is the one thing counted from inside the application; the record says only that a card payment was started, with the visitor value, and not the account, the organisation, the plan or the amount. None of the three records holds your name or email address.
Pseudonymous, not anonymous. Because the visitor value is derived from your IP address, we treat it as personal data. It cannot be turned back into your IP address, and we do not use it to identify anyone. The records are held in our database, with our database provider (section A3), where only our servers, and our directors through the administrative access in section A6, can reach them; our database provider's request logs can also show a visitor value for 7 days. Why we keep them is in section A7, and for how long in section A4. Nothing is written to your device or read from it to do any of this — see section A2 of Annex A to the Cookie Policy. A browser that does not run the page's script sends us no page visit at all, and you can object to the rest under section 12.
Some things remain true anyway, and it would be misleading not to say them. Our hosting provider sees the requests your browser makes, including your IP address, as any host does — that is how a page is served. Our database provider sees the requests your browser sends it directly, when you upload or view a drill photograph. Both are covered by their rows in section A3. And the error reports described in section A1 are sent when something fails, which is a report about a failure rather than a record of you using the Service. And our error-reporting library sends our error-reporting provider an aggregate count of the requests the server handled and how many failed. It is a count about the server, with no personal data and nothing about who did what (section A1).
A3. Processors and other recipients for this Service
This table is the complete list of the providers that receive personal data from this Service, apart from any provider the support portal relies on, which the paragraph after the table explains. It is also the sub-processor list for clause 11.5 of our SaaS Terms and Conditions. Section 8 says how a change to it is notified.
| Recipient | What we use them for | Personal data they receive | Where they process it | Transfers out of the UK |
|---|---|---|---|---|
| Supabase | Database, authentication — including sending the sign-in link email, which Supabase's own mailer sends — and the private store holding drill photographs. Your browser also contacts it directly when you upload or view a drill photograph | All personal data stored within the application, including premises profiles, key-holder contacts, Records and photographs, the stop list, and the page-visit records described in section A2; your IP address and session token when your browser contacts it; and its platform logs, which record request details — including the email and network addresses our public forms check against their limits, and the visitor values in section A2 — and are kept for 7 days | Stored in the United Kingdom — London (eu-west-2) | The data is stored in the UK. Supabase Inc. is established in the United States, and access by its personnel to operate and support the platform is a restricted transfer, for which we rely on the EU Standard Contractual Clauses as amended by the UK Addendum in Supabase's data processing addendum |
| Vercel | Hosting platform — the servers the application runs on, and the daily scheduled job | Every request to this Service, including your IP address and browser information, and the application's logs described in section A1. No Vercel analytics or performance-measurement product is included in this Service: the page-visit count in section A2 is our own, and is kept with Supabase (above) | The servers that run the application are in London (lhr1). Requests reach Vercel's network at a location near you, and pages held in its cache may be served from there. Where its logs are held is set by Vercel | Vercel Inc. is established in the United States. For anything processed or accessed outside the UK, the safeguards described in section 11 |
| Resend | Sending the email this Service sends itself: invitations, with their join link; the notice to a member that an owner has changed or removed their access; annual review reminders, post-incident prompts and the countdown digest, each with a link to stop it; renewal notices and notices of unpaid Fees; the email repeating a tier-checker result's headline; the waitlist acknowledgement; and the full text of each large-estate enquiry and waitlist registration, sent to our support mailbox. No email is received through it, and every message's reply-to address is our support mailbox. It does send our servers reports about the messages it has sent, and we act only on the two kinds section A1 describes. It does not send sign-in links, which Supabase sends | Recipient and sender email addresses and the contents of those messages, which can include organisation, group and premises names, a member's role, review dates, amounts, invoice numbers, purchase-order references, payment links, and anything a person typed into a form. The link that stops a reminder carries the recipient's email address | May be outside the UK | UK adequacy regulations where the data is processed in the EEA; anywhere else, the safeguards described in section 11 |
| Sentry | Error reporting on the paths listed in section A1. Server-side only — no browser client is set up, so nothing is sent from your browser | The diagnostic reports described in section A1: error messages and stack traces, with identifiers for the organisation, premises, subscription, payment or account involved, and a trail of up to 100 recent entries (outgoing requests, including their query strings, and log lines), which can include account identifiers, the email or network address a public form checked against its limits, and a visitor value (section A2). The public forms send it no reports of their own. The incoming request's cookies, headers, body and query string, and any user details, are removed before sending. It also receives aggregate counts of the requests the server handled and how many failed, which carry no personal data | May be outside the UK | UK adequacy regulations where the data is processed in the EEA; anywhere else, the safeguards described in section 11 |
| Google Workspace | Our support mailbox, at the address in section 16 (support@itsm-ltd.com). It receives every email sent to that address — support enquiries, requests about your personal data, cancellations; the copy of each large-estate enquiry and waitlist registration this Service forwards to us; and every reply to an email this Service sends through Resend (the row above), because each one's reply-to address is this mailbox. Our replies are sent from it | Whatever those emails contain: names, email addresses, organisation and premises names, and anything else the sender writes | May be outside the UK | UK adequacy regulations where the data is processed in the EEA; anywhere else, the safeguards described in section 11 |
| ITSM Ltd support portal | Support accounts and ticketing at support.itsm-ltd.com, for the person described in section A1 | That person's email address, your organisation's name and an identifier for your organisation — plus whatever is written in a support enquiry afterwards. No Records are sent | United Kingdom | None by ITSM Ltd itself, which runs the portal in the United Kingdom. Any provider the portal relies on is not covered by this row; see the paragraph after the table |
| Stripe | Takes card payments for us, raises our invoices, and emails invoices against a purchase order, and any other invoice or receipt it sends for us, to the billing contact. We are the seller. For the billing details we send it and the payments it takes for us, Stripe is our processor, under its data processing agreement; for its own purposes — preventing fraud and financial loss, and meeting its own legal and regulatory obligations as a regulated financial services provider, including anti-money-laundering checks — it is an independent controller under its own privacy notice. The Stripe account is shared with ITSM Ltd's other products. Refunds and disputes are handled by us. It receives nothing from an organisation's Records | From us: the organisation's name and an identifier for it, its billing address, the email address of the person buying or of the billing contact they name, identifiers for that user and for any premises the purchase covers, the plan, interval and number of premises, and any purchase-order reference, which is printed on the invoice. Any card details you enter are provided by you directly to Stripe on its own pages and are not received by us | May be outside the UK | For what it processes for us, the safeguards described in section 11, in Stripe's data processing agreement, where a mechanism is required; for its own purposes, Stripe is responsible for its own compliance as a controller |
There is no third-party helpdesk: the support portal in the table above is run by ITSM Ltd itself, in the United Kingdom. It is a separate system from this Service, and any provider it relies on to host it or to send its own email is not listed in this table. There is no bot-protection provider; the public forms are limited by the counting described in section A1 instead. When the daily job finishes, it tells an uptime-monitoring service, where one is set up, how many reminders, notices and deletions it handled. That message carries counts only and no personal data, so the service is not listed above.
Inside your organisation. Every other person in your organisation — a member who sees only part of it included — can see your email address, your role and access, and the date you joined; section A6 of Annex A to the Acceptable Use Policy says so in full. Every owner can see every invitation the organisation has sent, whichever owner sent it and whether it is open, accepted, withdrawn or expired: the address, the role and access offered with the groups or premises it grants, which account sent it, and the dates it was sent, expires and was accepted or withdrawn. Settings lists those still open. An invitation shows the person invited the inviting owner's email address, the organisation's name, and the groups or premises it grants. Anyone else who is signed in and opens a forwarded invitation link sees the organisation's name and, while the invitation is still open, the address it was sent to, but cannot use it.
Where a region is named above it is where the data is stored; it is not on its own an answer to whether anyone outside the UK can reach it, which is why each row says so separately.
A4. Retention specifics for this Service
| What | How long |
|---|---|
| Decision records, drill and refresher logs, incident reviews and annual reviews | For the life of the premises they belong to, and never longer than the life of the organisation. Nothing in this Service can edit or delete them individually; deleting the premises removes them all at once — see section A5 |
| Versions of a generated procedure pack | For the life of the premises they belong to, key-holder details included. A copy that has already been downloaded is outside our control altogether |
| Photographs | Until the organisation is deleted, or until we remove one by hand on the organisation's instruction. Deleting a premises does not remove its photographs, and a photograph chosen but never attached to a log stays stored too (section A5) |
| Tier-checker downloads | 24 months, then deleted — enforced by the daily job, not by hand. The row is written on every download, whether or not the email repeating its headline was asked for, and is kept that long so somebody who checked a tier can come back to us about it; the IP address on it goes after 7 days, because the submission limit is all it is for. No record is kept of whether you asked for that email: it is sent once, at the moment you ask, and nothing else is sent because of it |
| Large-estate enquiries | 24 months from the day it was sent, then deleted by the daily job, with the IP address cleared after 7 days. The copy emailed to our support mailbox is kept as section 9 says for other email to our support address. If the enquiry became an account, the account holds its own copy of anything that matters and the account's retention applies to that |
| Waitlist registrations | Until this Service opens to the public and we have written to tell you, or until you ask us to remove you, whichever is sooner — both done by hand — and in any event no more than 24 months, which the daily job enforces, with the IP address cleared after 7 days. Asking to be removed withdraws your consent: we delete the registration and keep no record of the withdrawal beyond our reply to you. The copy emailed to our support mailbox is kept as section 9 says for other email to our support address |
| Invitations | The link expires after 14 days. The invitation itself — open, accepted, revoked or expired — is kept, not deleted, until the organisation is deleted or the account of the owner who sent it is deleted. An invitation addressed to you stays even if your own account is deleted |
| The sent-reminders record — which reminders and notices have gone | Kept indefinitely. By itself it identifies nobody: it holds only a premises identifier, an incident-record identifier, an organisation identifier (for the monthly digest) or the identifier of a subscription record (for a notice of unpaid Fees or a renewal notice), with the kind of reminder and the date — never a name or the recipient's address — and it has no database link to the organisation, so it is not removed with it. An entry for a notice of unpaid Fees is removed again if that notice reached nobody, so that it can be sent. An identifier in it can still be matched to other records we hold — a subscription-record identifier to our billing records for as long as we keep them (six years), any of them to a backup not yet overwritten — so for as long as that is possible we treat the entry as pseudonymous personal data, held only to stop the same notice being sent twice; after that nothing links it to anyone |
| The stop list — the addresses not to be sent a reminder | Kept until the person tells us they want the reminders again, because removing the entry would start them again; it is not removed when an organisation is deleted, for the same reason. An entry made automatically, because a message to that address was rejected or marked as spam, is kept on the same terms. Tell us and we remove it |
| Page visits and steps towards buying (section A2) | 14 months, then deleted by the daily job — long enough to compare one year with the next. No IP address or email address is stored with them, so there is no shorter clock to run alongside, as there is for the public forms above |
| Diagnostic error reports | For the retention period set for our project at our error-reporting provider. We keep no separate copy, although the same line is written to our hosting provider's logs (section A1) |
| Server and platform logs | Our database provider's platform logs are kept for 7 days. Our hosting provider keeps the application's logs for the period our hosting plan sets |
| An organisation deleted at an owner's request | Deleted in full, photographs included, within 30 days of an owner asking in writing, using the administrative access described in section A6. There is no self-service deletion in this Service — section 10(b) of the Service Schedule says so, and section 10(c) of the Service Schedule lists what deletion does not reach. Deletion is not reversible, and we confirm in writing when it is done. Backups taken before it are overwritten within 7 days — see section 7(d) of the Service Schedule |
A5. Things this Service cannot undo
| What cannot be removed | Why |
|---|---|
| A decision record, drill log, refresher log, incident review or annual review | The database grants no right to update or delete one, so nobody can edit or remove an individual record — ourselves included through the ordinary application. A log that can be tidied afterwards evidences nothing. The exception is not individual: deleting a premises deletes everything recorded against it in one act, as section 9 of the Service Schedule describes |
| A photograph attached to a drill log | The store holding it has no deletion rule for users at all, for the same reason — and, unlike the records above, a photograph is not removed even when its premises is deleted. A photograph chosen but never attached stays stored too. Only deleting the organisation, or our removing it by hand on the organisation's instruction, reaches it. If a photograph should never have been uploaded — because it shows a person the organisation had no proper basis to record — tell the organisation, and tell us (see the note below) |
| A version of a generated procedure pack | Versions are fixed so that a decision recorded on a given date can be read against the pack version that was in force then. Any version in force at some point in the last 2 years can be downloaded; older versions are kept but no longer offered for download. A new version is added rather than an old one rewritten, and key-holder details in earlier versions stay as they were. Each version records the account that generated it until that account is deleted, when the link is cleared |
| A pack or evidence export somebody has already downloaded | Once a copy has left this Service — sent to an insurer, a trustee committee or a licensing officer — it is outside our control entirely |
| The record of which legal documents you accepted | It cannot be edited or removed on its own from inside this Service. It is deleted with your sign-in account (section 9) |
| An email we have already sent | Once a message has reached a mailbox it is outside our control entirely |
A6. Security specifics for this Service
- Deny by default at the database. Every table holding customer data is protected by row-level policies, and the checks are written in the database rather than in the application, so an organisation's data is unreachable to another organisation even if the application asked for it wrongly. The policies have their own test suite, which runs against a real database on every change that touches anything a database could have an opinion about.
- Two access rules, not one. Who administers an organisation and how much of an estate a person can see are separate settings, so a colleague can be given one premises or one group of premises without being given the estate.
- A private photograph store. Drill photographs are never publicly addressable, are limited to 10 MB and to image formats, and are shown only through a link that expires after an hour and is issued only to someone whose access has already been checked. Until it expires, anyone who has that link can open the photograph.
- Backups are our database provider's daily backups, described in section 7(d) of the Service Schedule — which also says that we do not test restoring them, and that drill photographs should be treated as not backed up.
- Evidence is append-only for the people using it, as section A5 describes — with the one exception it names.
- Sign-in without a password. There is nothing to guess, reuse or leak, and a link is single-use, expires, and is cancelled by requesting a newer one. The trade is stated plainly in section 8(e) of the Service Schedule: there is no multi-factor authentication for customer sign-in, so an account is as secure as the mailbox it signs in from.
- Encryption in transit, with HTTPS enforced and HSTS set for two years including subdomains (not preloaded); protections against clickjacking (
X-Frame-Options: DENY) and MIME sniffing (nosniff), which are enforced; and a content security policy which is sent in report-only mode and has no reporting address — so it blocks nothing, and nothing it would have blocked is reported to us; a violation shows only in the visitor's own browser console. Saying otherwise would be the easiest false claim in this document to make and the easiest for a buyer to check. - Administrative access. Our database provider's administrative console and an administrative database key, both held only by ITSM Ltd's directors, can read, change or delete any record, and the key could be used to create a sign-in link for any account. The directors can also see the copies of some data held by the other recipients in section A3, through each provider's own console, as section 8(b) of the Service Schedule lists. The application uses the key automatically in the server-side code paths that section 8(b) of the Service Schedule lists; our people use the console or the key by hand for support at a customer's request, removals, deletions, erasures and incident work. Neither use is logged by the application, and there is no larger team to separate those duties between. Section 8 of the Service Schedule sets this out in full.
- Sign-in cookies are readable by the page's own scripts (not HttpOnly), carry no Secure attribute — the HSTS header keeps them on HTTPS after a first visit — and can last up to 400 days; section A1 of Annex A to the Cookie Policy lists them.
A7. Additional purposes for this Service
| What we use your personal data for | Our reasons |
|---|---|
| Annual procedure review reminders and post-incident prompts | Part of the Service, sent on your organisation's instructions under section 11 of the Service Schedule — we are its processor for them, so its lawful basis applies rather than ours. They go only to the organisation's owners. Use the link in one, or reply or write to us, and we stop sending them to you by adding you to the stop list (section A1). When we do it by hand, we tell your organisation's other owners that we have; the link tells nobody else |
| Keeping the stop list | For our legitimate interests, i.e. honouring your request, since removing the entry would start the reminders again; and, for an entry made because a message was permanently rejected or marked as spam, not sending mail that cannot be delivered or is not wanted, which also protects the delivery of the notices we have to send |
| Telling a member that an owner has changed or removed their access | Contract or legitimate interests (defined in section 7): that someone whose access to an organisation's Records has changed hears it from us rather than finding out by looking. Section 6(f) of the Service Schedule says when it is sent |
| Counting visits to the public pages, and three steps towards buying (section A2) | For our legitimate interests, i.e. knowing whether people find this Service and which of its public pages help them, so that we can improve them. The effect on you is small: no cookie is used and nothing is stored on your device, no IP address or email address is kept, the visitor value changes every day, no third party receives it for its own use, and nothing is measured inside your account beyond the fact that a card payment was started. You can object under section 12 |
| Keeping the record of which reminders and notices have been sent | For our legitimate interests, i.e. not sending anyone the same reminder or notice twice. It holds identifiers and dates only, and is kept as section A4 describes |
| The commencement countdown digest | For our legitimate interests, i.e. that an organisation preparing for the Act's commencement hears when the expected date moves. We do not rely on consent for it. The switch the digest calls an opt-in is one setting for the whole organisation in Settings, off until someone turns it on, and any member of the organisation can turn it on or off: when the digest says the organisation “opted in”, it means that setting, not a choice each recipient makes. It goes only to the owners of an organisation with a live purchase (a one-off procedure pack counts), and every digest says how to turn it off. Section 6(b) of the Service Schedule describes it. We do not consider it direct marketing — it sells nothing — but if you would rather not receive it, use the link in it, or say so and we will stop it for you personally; you do not have to give a reason |
| Emailing you the headline of a tier-checker result | On your consent, given by ticking the box asking for it. The email is sent once, at the moment you ask, and nothing else is sent to you because of it. The tick itself is not stored |
| Keeping the record of a tier-checker download | For our legitimate interests: stopping the tool being used to send mail to people who did not ask for it, letting someone who checked a tier come back to us about it, and seeing how the tier checker is used — our directors read the records in a report, run with the administrative key in section A6, listing each download's date, the tier shown, the capacity given and the address, and noting an address that downloaded more than once. The report does not show the IP address, and nothing is sent to anyone because of it. The record is kept whether or not you asked for the email (section A4). You can object to it, or ask us to erase it (section 12). We do not add the address to a mailing list, because there is no mailing list |
| Answering a large-estate enquiry | To take steps at your request before entering into a contract. A person reads the enquiry and replies; there is no automatic acknowledgement |
| Registering you on the waitlist, acknowledging it, and telling you when this Service opens | On your consent, which you can withdraw at any time by asking to be removed. You receive one acknowledgement when you register and one email when this Service opens to sign-ups |
| Limiting how often a public form can be submitted from one email address or one network address | For our legitimate interests, i.e. keeping the public forms usable and stopping this Service being used to send mail to people who did not ask for it |
No product marketing. We send no product marketing to Users of this Service (section 6(e) of the Service Schedule). The one promotional email we send is the single email telling someone who joined the waitlist, on their consent, that this Service has opened.
The one automated assessment. The only automated element in this Service that assesses anything is the tier calculation. The tier checker applies it to the answers you give, and the Service applies it to each saved premises from its capacity and type. It is a calculation about a premises, not a decision about a person, and its result is a plain-English guide, not a legal determination — see section A1.3 of Annex A to the Website Terms of Use.