Skip to content

Legal

Data Retention

How long each kind of record is kept, and what expiry and deletion actually do.

Last updated 28 July 2026

1. How to read this

1.1 The principle, in one sentence. We keep an analysis of a named company or a named person for a bounded period and then destroy it, because holding a scored assessment of somebody indefinitely is a risk we are not willing to carry and a cost the person carrying it did not agree to.

1.2 Two readers. If you bought a report, this tells you how long you have it and what we keep afterwards. If a report names you, section 8 is for you, and If a Report Names You sets out your rights in full. A report about a person other than the buyer is produced only after that person has confirmed to us, by email, that they agree to it, so if a report names you then either you bought it or we wrote to you first. Clause 2.8 sets out what we keep about that exchange.

1.3 What is true today. Most of what is described here is not built. There is no checkout, no account, no report, no file and no email, and there is no retention sweep, so no period in the table below is being enforced by anything today. What this service holds about anyone at present is the web server request logs in that table and whatever you have sent to our mailbox, which the correspondence row covers. What this site stores on your own device is a different question and the Cookie Policy is the document that answers it.

Read every rule in this schedule as the rule that will apply from the first sale. Where a control that a clause depends on does not exist yet, that clause says so in its own words rather than leaving it to this paragraph.

1.4 One place for a period, and what this document does not override. This schedule is the complete list of the maximum periods we apply, and it is the one we will be held to on the length of a period. Where any other document of ours states a period that differs from the one here, this schedule governs the length and the other document is a defect we will correct; where the other document states a shorter maximum for a class, the shorter one governs, because we will not rely on our own inconsistency to hold something longer. Two figures are restated elsewhere because they are part of what those documents promise: the ninety-day report window, and the backup cycle in If a Report Names You. No other period of ours is meant to appear in more than one place, and one that does is a defect that the rule above decides.

This schedule is not a source of your contractual entitlement and does not cut one down. Where the Terms of Service or the Refund Policy gives you a longer period of access, suspends or extends the ninety-day window, or gives you a remedy that outlasts it, that document governs and nothing here shortens it. Clause 16.3 of the Terms, which extends your window by the length of any interruption, is the clearest case: where it applies, the ninety days in the table below runs from the end of the extended window rather than from the moment the report became ready, and the retention of the report and the evidence behind it extends with it. That is the division clause 2.6 of the Terms already draws, and this clause states our side of it.

If you find a period of ours stated two different ways, tell us at [email protected] and we will correct it and say when.

1.5 One period per class, and each copy has its own life. Where the same information exists in two places for two purposes, both are listed. That is why a single ninety-day figure is not the whole answer.

2. Retention by class

2.1 The schedule.

ClassWhat it holdsHow longNames a report subject?
Report contentFindings, section text, the six dimension scores, the narrative90 days from the moment the report is ready, extended by any interruption under clause 16.3 of the Terms of Service – see 1.4Yes
Evidence behind a reportPages fetched, text taken from them, search results, content hashes, the stored copy of what was read, and for a company subject the answers given by AI assistants90 days, destroyed with the report. Subject to 2.7, which is a prohibition and not a periodYes
Report files on our serversThe evidence bundle, the preview image, and any rendered file of the report that we hold90 days, with the report. A file already downloaded is not on our servers, no row in this table governs it, and 4.3 says what doesYes
The report subject's own recordName, matching key, the profile address supplied, a short role descriptor, countryDestroyed with the report it was created for. A later report about the same person creates its own record and does not extend an existing one – see 2.6Yes
The consent record for a report about somebody other than the buyerThe address we wrote to, the wording of the request as sent, the time, whether it was confirmed, declined or left unanswered, and the confirmation itselfWhere the request was confirmed, with the order, for the same period as the access records below. Where it was declined or left unanswered, 12 months – see 2.8Yes
The briefWhat the buyer typed: subject name, address, up to 600 characters of contextThe copy held with the report, 90 days. The copy held with the order is reduced to a record that a brief existed at the expiry of the report, its deletion, or a request from the person named in it, whichever comes first – see 7.3Yes
Prompt and model-call logsWhich model was called, when, with what token counts, the text sent, what came back, and any error90 days, destroyed with the report – see 2.5Yes
Share linksA digest of the link, never the link itself; the name and email address of the reader it was issued to; the record that the reader confirmed that address before the first view; the permission the buyer gave when the link was created; the link's own expiry; and whether it was revokedWith the report, and never longer. A link's life is fixed when it is created and clamped to the report's window, so no link outlives the report it points at. The reader's name and address live in this class and nowhere else, and are destroyed with the reportYes, and it names its reader as well
Access records for a purchased reportThat a sign-in code was issued and used, that a report was opened, that a share link was created, that a reader confirmed their address, that a view was served under that link, and that the report was downloaded as a file; and for each the time, the order reference, the account identifier, the IP address, the user agent and the digest of the report served. A download is its own event and is never folded into an opening. This class holds the event and not the reader: a reader's name and address sit in the Share links class above and die with the report, so what outlives the report here is that a link existed and was followed, never who followed it18 months from the event, or until any payment dispute about that order is finally resolved if that is later – see 2.9Indirectly, by reference to an order
Delivery record for a purchased reportThe order reference, the product, how many sections the delivered report carried, how many sources it recorded, the headline figure, the digest and byte size of the report delivered, and the times the report became ready and was first opened. No name, no finding, no section text, no evidence, no contextThe same period as the access records – see 2.9 and 3.5No
Account recordEmail address, optional display name, timestamps30 days after closure where nothing was bought. Where an order exists, reduced to a marker carrying no name and kept with that orderNo
Sign-in sessions and single-use codesHashed token, hashed IP, user agent, attempt counts. The code a share-link reader confirms their address with sits here on the same terms as a buyer's, because it is the same mechanismDeleted 24 hours after they expire. A session lasts 30 days at most and 14 idle daysNo
Order, payment, refund and dispute recordsThe order and what it was for; the amount, currency and tax charged and the tax calculation; the invoice, its number and our copy of it; the receipt; our payment provider's identifiers for the customer, session, payment, charge, refund and dispute; card brand, last four digits, country of issue and method type; every refund with its ground, its amount and who or what authorised it; every payment dispute with the evidence we submitted, when, and how it was determined; and the payment-fraud signals our provider returned on the order and the decision taken7 years – see 7.1No, once the order copy of the brief is reduced under 7.3
What you were shown and agreed to at checkoutFor each separate confirmation actioned: the rendered wording exactly as it appeared on screen, a digest of that wording, the version identifier of the document it came from, the time it was actioned, whether the control was presented unticked and separately, and the identifier and delivery status of the message in which the same wording was confirmed back to the buyer7 years, with the order – see 2.10No. Where a confirmation would otherwise name the person a report is about, the stored wording refers to the brief instead – see 2.10
Location evidence for EU consumer salesBilling country and postal code, hashed IP, card country, tax identifier and its validation stateSee 7.2No
Orders we refused, cancelled or did not completeThat an order was refused or cancelled, when, on which ground, what was refunded, and the identifiers needed to apply the same decision to a repeat attempt. Where a name was screened against a designated-party list, which lists, the result and the time7 years with the order record where money was taken; 24 months where it was not. The brief that prompted it is reduced at the same time as the order copy under 7.3 – see 2.8 and 5.7Yes, until the brief is reduced
Email delivery recordsRecipient address, which message, the subject line, delivery status2 years for the record. A report subject's name will be removed from it when that report expires or is deleted, on the same sweep as everything else in this table – see 2.11Yes, until removed
Addresses that bounced or asked us to stopThe address onlyUntil we are asked to remove it – see 5.4No
The do-not-report listThe identifiers needed to refuse a future orderFor as long as the request stands – see 5.2Yes. It is the request
CorrespondenceA message you send us and our reply, and whatever you chose to put in either24 months. A message that is a rights request or a correction is kept under the row below insteadWhere you name one
Rights requests and correctionsWhat was asked, how we checked who was asking, what we did, when3 yearsYes
System audit logWhich operator or process did what, to which record, when. Append-only7 years – see 2.4No – see 2.4
Deletion and expiry markersThat a report identifier was used, which product it was, the order it belonged to, and when it expired or was deleted. No name, no content, no score, no evidence24 months – see 5.5No
Material preserved at your own requestAny class above that the person it is about has asked us to restrict and preserveUntil the matter ends, then destroyed at once if its period has passed – see 8.6Follows the class
Web server request logsIP address, user agent, path30 daysNo
Payment provider event recordsOur provider's notifications to us. At 90 days the personal data in the stored payload is removed: the buyer's email address, name and address, and any reference to a brief. What remains is the event type, the provider's identifiers, the amount, the currency, the status, the sequence of state changes and the timesThe personal data in the payload, 90 days. The event record, 7 years with the order – see 2.12No – see 2.12
Product analyticsCounts and events against an opaque identifier. Separately, daily totals per product that identify no person, no account and no report12 months for the counts and events. The daily totals identify nobody and are kept as an ordinary business record. Nothing is collected todayNo
Error reportsStack traces against an opaque identifier, with email addresses, codes and tokens stripped before anything is sentOur error-monitoring provider's own period, stated on the Sub-processors page. We set no period of our own for this class and we publish no number we do not control. Nothing is collected todayNo
Short-lived operational recordsRequest de-duplication keys, which may briefly contain a brief24 hoursBriefly
Backups of the databaseEvery class above that the database holdsRolling, no more than 35 days – see section 9Follows the class

2.2 Three classes a reader would not expect, named because they are the ones that matter. The record of the automated model calls made while a report was produced sits in the table above and is destroyed with the report, for the reason in 2.5. The location evidence that a cross-border consumer sale obliges us to keep is the longest retention in this schedule and is dealt with in 7.2. And a copy of the buyer's brief sits with the accounting record, which is the one place a report subject's name could otherwise survive the report by years; clause 7.3 states what happens to that copy and when. A schedule that lists only the periods a reader would guess is not a schedule.

2.3 These are ceilings, not targets. Where a class is no longer needed for its purpose before its period ends, it goes then. No period in this table restarts because somebody placed another order.

2.4 The audit log is designed to record actions and not names, and that constraint is not yet enforced. It records that an action of a given type happened, which record it touched, and who or what did it. It must not record the name of a report subject, because entries in it cannot afterwards be edited or removed and anything written there could never be erased. Today that is a rule for whoever writes to it rather than a control that refuses the write, and the field it would land in accepts arbitrary content. Two things follow, and both are conditions of the first sale rather than later improvements: the write path must refuse a value capable of identifying a report subject, and there must be a route to remove one if it ever appears, even in a store that is otherwise append-only. Until both exist, no report about a named individual will be produced, so nothing in this store can name one. If a name is ever found there we will tell the person, treat it as an incident, and say what we did about it. The seven-year period in the table is the period for a log of actions and is not a period for anybody's name.

2.5 What the evidence is for, what it is not used for, and why the model-call records sit inside the same ninety days. The stored copy of a source is the record of what that source said when we read it, kept so that a finding can show its evidence. It is not reused to build a general corpus, it is not sold, and we do not use it to train models. It is destroyed with the report.

The prompt and model-call records exist so that a report can be explained after the fact: which model produced which part of it, whether a call failed and was retried, and what it cost. That purpose is served for as long as the report exists and ends when the report does, so they are destroyed with it. An earlier internal figure of 180 days was carried over from operational debugging, and we could not state a purpose that needed a further ninety days over material carrying the name of a person who did not seek the report. Where a particular record has to be kept longer for a specific matter, that is a hold under section 6 and everything in that section applies to it.

What our providers may do with what we send them is in the Sub-processors list; what may be quoted from a source, and at what length, is in the Intellectual Property notice.

2.6 A second order does not extend the first record. A subject record is what lets a report resolve to one identifiable person rather than to somebody with the same name. It would be cheaper for us to hold one record per person and reuse it whenever a second buyer asks about them, but the ninety-day clock would then restart with every new order, and a person asked about twice a year would be held by us indefinitely under a schedule that promises a bounded period. So the record is scoped to the report that created it and is destroyed with it. A second report about the same person creates a new record from that buyer's own brief and from that person's own confirmation, and gives us no reason to keep the earlier one for a day longer.

Two consequences, stated because they are ours to carry. We cannot match a new order against an old one or reuse work, so a repeat subject costs full production every time. And we cannot tell anybody how many reports about a person have ever been produced once they have expired, which is the same limit already stated in 5.5 and in section 14 of If a Report Names You. The do-not-report list in 5.2 is keyed separately and is not affected, so asking us in advance to produce nothing about you does not depend on a subject record existing.

2.7 Material we refuse rather than keep. The special categories listed in the Privacy Policy – health, political opinions, religious or philosophical belief, trade union membership, sex life, sexual orientation, biometric or genetic data, racial or ethnic origin – have no retention period here, because they must not be held at all. We hold no condition that would permit us to keep that material, so the answer cannot be to keep it for a shorter time.

Three rules follow. The classifier that refuses such material will run at the point evidence is written to storage rather than at the point a report is composed, so that prohibited material is discarded before it is stored rather than after. Where such material is nevertheless found in storage it is destroyed on discovery rather than at the end of its class period, and what we record of the destruction is a count and never the content. The prompt and model-call records are covered by the same rule, so a discovery reaches them too. Separately, we will not put identity questions about a natural person to AI assistants at all, so the assistant answers described in the evidence row will exist only for a company subject.

None of these three controls is running today, and the first report about a named individual will not be produced until the first two are. ``

2.8 The consent record, and what happens when nobody confirms. A report about a person other than the buyer will be produced only after we have written to that person, described what the report is and who asked for it, and received their confirmation. What we keep of that exchange is in the table above. We keep it because consent has to be demonstrable by us, and a buyer's assurance that permission exists is not a demonstration that it does.

Where the request is not confirmed inside the window, the order is cancelled and refunded in full automatically, the brief and any subject record created for it are destroyed, and what survives is the order record and a record that we asked and did not proceed. We keep that record for 12 months so that a repeat order cannot be used to send the same person the same request again and again, and it is used for nothing else. It is never a basis for producing a report.

The address a person gives us at that step is used for that request, for anything they ask us about it afterwards, and for nothing else. It is not added to any mailing list and is not used to market to them.

None of this exists today. The consent request, the store that holds the record of it, the window in which it can be answered, and the automatic cancellation and refund where nobody answers are four conditions of the first sale of a report about a person other than the buyer, and no such report will be produced before all four are running. ``

2.9 The access and delivery records: what they are for, and the basis for keeping them. They do two jobs. They show a buyer their own activity, and they are the evidence that what somebody bought was made available and opened. Without them a payment dispute is decided on an assertion, so being able to produce them is an obligation rather than a convenience. The lawful basis is our legitimate interest in answering a payment dispute and in preventing payment fraud, and the Privacy Policy records it as a processing activity in its own right. They are not used to build a picture of what anybody reads, are not enriched from any other source, and are not shared for marketing.

The IP address in these records is held in a form we can read and produce, because a record we cannot read is not evidence. It is held apart from the tax evidence in 7.2, is used for nothing else, and is destroyed with this class. Eighteen months is the outer limit we hold ourselves to; where the payment for a report can no longer be disputed before that, the records for it go then. ``

2.10 The checkout record is written at the payment step, and checkout will not open without it. Each confirmation actioned at checkout will be stored as the string that was on the screen, not as a flag recording that a control was ticked, because a flag is not evidence of what somebody was shown.

One of those confirmations is the buyer's statement that the person the report is about has given their permission. That wording is drafted to refer to the person named in the buyer's brief rather than to reproduce the name, so that a record we keep for seven years carries no third party's name and the reduction in 7.3 has nothing left to reach in this class. That is a condition on the wording we use rather than a description of a form that exists. It does not stand in place of the confirmation in 2.8: the buyer's statement is evidence and carries the buyer's own responsibility for it, and the report is still produced only after the person named has confirmed to us directly.

The message reproducing that wording will be sent from the payment step rather than from the report pipeline, and its delivery status stored with the order, so that a failure to produce a report cannot also destroy the record of what was agreed. Where this record is missing or incomplete for an order, the Refund Policy resolves the question in the buyer's favour. ``

2.11 The email records, stated fully. The subject line of a message about a report contains the name of the person that report is about. Our own record of what we sent, to whom and whether it arrived is kept for two years, for delivery problems and complaints. Removing a report subject's name from it at ninety days belongs to the same sweep as every other period in this table. That sweep is not running, and our database is currently configured to refuse the deletion of a report subject rather than carry it through to the records that refer to them, so a request under section 8 would fail outright rather than partly succeed. Both are conditions of the first report about a named individual being sold. Our email provider keeps its own delivery record for its own period, which is stated on the Sub-processors page and is not the period stated here.

2.12 Why our provider's payload is cleared and the record is not. Our provider's notifications are the authoritative account of what was authorised, captured, refunded and disputed on an order, and a payment can be disputed long after ninety days. Deleting them at ninety days would delete the account of the payment while the payment is still in question, so what we remove at ninety days is the part of the payload that identifies a person, which is not the part that evidences the payment. The answer in the last column is "No" for a stated reason rather than by assertion: only an opaque reference to a brief crosses to our provider, never the subject's name, and the invoice line description must not carry it either. That is a condition of the first sale, and the Payment Terms say the same thing.

3. What expiry does

3.1 Expiry is a change of state, not a deletion of your purchase. Ninety days after a report is ready it expires. Online access ends, every share link for it stops on its next request, and the content, the evidence and the files behind it on our servers are destroyed.

A file you downloaded before expiry does not stop, does not expire and is not reached by this schedule at all; 4.3 says what governs it instead. Where clause 16.3 of the Terms of Service has extended your window, expiry follows the extended window.

3.2 What survives is the record that you bought it: the order, the product, the date and the headline figure, together with the delivery record described in 3.5. That record is linked to the subject record described in 2.1 for as long as that record exists, and under 2.6 the subject record is destroyed with the report, so from expiry the surviving row carries no name and no identifier that resolves to one. That is a condition of the surviving row being built at all. Nothing about it is public and nothing is indexed. The product consequence, stated because it is not obvious: the page for an expired report will not show the subject's name. A control to run a fresh report at the price then advertised will be offered instead.

3.3 What expiry does to your remedies, stated exactly rather than reassuringly. Expiry is the end of hosting. It does not end this contract, and it does not end a right you have under consumer law, which we could not limit by agreement and do not attempt to.

(a) If you tell us before expiry that a report does not match its description, we will place that report, the evidence behind it and the files generated from it under the hold in section 6 until your complaint is closed, so that the material needed to put the report right still exists when we answer you. Telling us does not extend your ninety days of access, and it does not need to, because the material is preserved on our side.

(b) If you tell us after expiry, the content, the evidence and the files will already have been destroyed on the schedule in 2.1. We will not be able to correct or regenerate the report, and we will not ask you to accept repair as your remedy in a situation we created. Your remedy is then a price reduction or the end of the contract with your money back, at your election. We will not put you to proof of non-conformity from material we destroyed, and we will not treat the absence of that material as an answer to your complaint.

(c) Expiry does not shorten the period in which you may raise a non-conformity. Neither does this schedule, and neither does the destruction of the material. The remedies in the Refund Policy and in section 10 of the Terms of Service are otherwise unaffected by expiry; the only one expiry can reach is repair, for the reason in (b).

``

3.4 The reminders, with the days in them, and what happens if we fail to send them. We will email the address used for the order 14 days, 3 days and one day before a report expires, and we will show a notice inside the report itself in its final fortnight. We will send them however much of the report you have already read, and we will use the address given at checkout rather than an account address, because you may never have signed in. They matter for a different reason than when this clause was first drafted. Then there was no export, and the end of the window was simply the end of your access. Now it is also the last moment at which you can download a copy, so a reminder we fail to send costs you the file and not only the reading time. The remedy in the next paragraph is set against that.

Expiry on the stated date is not a fault and gives rise to no refund on that ground alone, where the report was available to you throughout the window and those reminders were sent. It is not treated that way, and a refund may be due, where the report was unavailable to you for a material part of the window, where the reminders were not sent, where the window turned out to be shorter than the ninety days stated to you, or where the report did not match its description. If we fail to send the reminders and your report expires, tell us at [email protected] and we will either restore access for 14 days or refund you in full, whichever you prefer. That is an entitlement under this schedule and not a goodwill gesture, and it is the reason we are willing to say that expiry, once the reminders have been sent, is not a fault.

No email of any kind is sent by us today. The reminder ladder is a condition of the first sale rather than an improvement to be made afterwards.

3.5 One record survives expiry, so that a payment can still be answered. A card payment can be disputed for longer than a report exists. Expiry destroys the report, the evidence and the files, and leaves behind the delivery record listed in 2.1: what was delivered, how much of it, and when it was read, in a form that carries no name, no finding and no section text. The digest lets us show that a file somebody still holds is the file we delivered, and that the report carried what we said it would, without our holding the report. It is kept on the basis in 2.9 and for no other purpose. It is not kept on the tax basis in section 7, and clause 7.4 continues to mean exactly what it says.

4. What deletion does

4.1 Deletion is destruction, with one limit stated here rather than left to section 9. Content, evidence, generated files and share links go together and at once. There will be no recycle bin and no soft-delete window in the running system, and nothing in the product will bring a deleted report back, which is why the confirmation will ask you to type the subject's name before it proceeds. The limit is backups: a copy of the database taken before your deletion still holds the material until that copy rolls off, which is within 35 days. We do not edit backups, for the reason in 9.2, and if one is ever restored the deletions recorded since it was taken are re-applied before the system is used again. Report files, report content and the evidence bundle will not be held in the database, so for those classes there is no backup tail and deletion is final at once. So the honest statement is this: deletion is immediate in the live system, no route in the product brings it back, and it is complete everywhere within 35 days. None of it is running today, because there is no report to delete and no sweep to delete it.

4.2 Three things trigger deletion, and a payment dispute is not one of them. You delete the report. We refund it in full, in which case access ends with the money. Or the person the report is about withdraws the agreement they gave us or objects, and we withdraw the report and refund the buyer under section 7 of the Refund Policy.

A disputed payment has the opposite effect. Where a charge is disputed, whether or not the amount has already been debited from us, access to that report is suspended and the material behind it is placed under a hold under section 6: the content, the evidence, the generated files, both copies of the brief, and the access and delivery records. Nothing relating to that order expires or is deleted while the dispute is open, or while any further presentment, escalation or arbitration remains available to either side. That is what clause 7.7 of the Terms of Service and the Refund Policy already say, and this schedule agrees with them. When the dispute is finally determined the hold is released. Where it is determined against us, the position is the same as a full refund: access ends and the material is deleted. Where it is determined in our favour, access resumes for the remainder of the ninety days, extended by the length of the suspension.

``

4.3 There is now a file our deletion cannot reach, and that cuts both ways too. A report can be downloaded as a file while it is live, and that file is yours. Two things follow, and the second is the one sellers leave out.

In your favour: when the ninety days end you are not left with nothing. A report you downloaded in time is a report you still have, and expiry does not touch it.

Against you, and against the person the report is about: our deletion is no longer the end of the document. When we delete, when you ask us to, or when a report's subject exercises a right, we destroy our copy, the evidence, the files we hold, and every share link for it. The link part is complete, because we serve every view of a link ourselves and every reader confirmed their address with us before their first one: no reader holds a storage address and nothing is cached anywhere else, so from the next request onwards a revoked link serves nothing, whoever has it. The file part is not complete and cannot be made complete. We will not tell you we destroyed every copy of a file we never held, because that is the single statement in this schedule nobody could check.

What we do instead is end your licence to use the file, require you to destroy it and to recall what you sent, and tell the person the report is about how many times it was downloaded and when.

What you can still be holding is the file you downloaded, and whatever you wrote down, screenshotted or retyped while reading. Your licence to use either is granted by section 8 of the Terms of Service, and it ends in the cases named in clause 10.7 of those terms: where we withdraw a report because its subject withdrew their agreement, objected, or exercised a right, or because the law required it; where you have breached section 8 or section 9 of the terms; and where a court orders it. Where the withdrawal was not caused by anything you did, we refund you in full under section 7 of the Refund Policy. In every one of those cases we will tell you, and you must destroy the file and anything you copied out, and ask everyone you gave either of them to do the same. Clause 8.6 of the Refund Policy is the single statement of what such a copy is and governs if this page and that clause can be read differently.

4.4 Revocation and deletion do different things, and only one of them is complete. Revoking a share link stops that link, whoever is holding it, from its next request onwards. That is complete rather than nearly complete, and the reason is worth stating: we serve every view of a link ourselves. No reader holds a storage address, nothing about a shared report is cached outside our own machine, and a link is checked on every single request rather than once. So when we say no, there is nothing left that could still serve that link.

It does not stop a file downloaded while the link worked, and it never stopped a passage somebody copied out. What protects a subject there is not a retention period. It is the licence in section 8 of the Terms of Service, the recall obligation in clause 10.7 of those terms, the report version and confidentiality notice printed on every page of the file, and our record of every download and every link view, which is what lets us tell a subject the size of what is still outside instead of guessing at it.

5. What survives, and why

5.1 The transaction record, because tax and accounting law requires it. It must not carry the name of the person a report was about, and 7.3 says how that is achieved.

5.2 The do-not-report list, because deleting a request not to produce reports about somebody would let the next order about them through. It is never published, and we do not confirm to anyone that a particular person is on it. Since a report about anybody other than the buyer is produced only on that person's own confirmation, this list is not the only thing standing between an order and a report about you. What it adds is that we do not write to ask.

5.3 The record that a request was made and answered. A rights request that leaves no trace is indistinguishable from one that was ignored. The register records the request, what we did and when. Separately, once the append-only administrative log is in service it will record that a request of a given type occurred and will not record who made it. That log is written and not yet running, and we will not rely on it in an answer to you until it is.

5.4 The list of addresses that bounced or asked us to stop mailing, because deleting that list is how somebody who asked us to stop starts hearing from us again. An address on it is used for nothing else. Ask and we will remove it.

5.5 A marker that a report identifier was used, so that an identifier is never reissued. It carries no name, no content, no score and no evidence, it is listed in 2.1 with its own period, and it is not kept indefinitely.

It is not there to let us tell anybody whether a report existed. An unauthenticated question about a deleted report and an unauthenticated question about an identifier that never existed get the same answer, so nobody can use us to confirm that a report about a named person was produced. That property comes from answering identically in both cases and not from anything we looked up, which is why clause 14.2 of If a Report Names You can say the same thing.

5.6 What a deletion leaves behind. Once a deletion has propagated, nothing we hold will contain report content, analysis, evidence, or what the buyer wrote in the context field, other than the delivery record described in 3.5, which contains none of those things. Propagation is not instantaneous and we will not pretend otherwise: a database backup taken before the deletion still holds that material until it rolls off, within 35 days, and section 9 sets out what we do and do not do with it in the meantime. Expiry is the less thorough of the two: what it leaves behind is listed in 3.2 and 3.5 and nothing else. Both were checked class by class against 2.1, and the backup qualification applies to every class in it that the database holds.

5.7 A refusal we cannot evidence is indistinguishable from one we never made. Where we refuse or cancel an order, the record that we did so and why survives the order, because the same order will otherwise be accepted next week and because a decision nobody can show is not a control. Those records carry a subject's name no longer than the order copy of the brief does. We do not tell anyone whether a particular name was screened or what the result was. ``

6.1 What it is, and the fact that it does not exist yet. No hold mechanism is in service. No report and no order can be placed under one, and a deletion currently runs inside the request that asks for it, which means a deletion arriving during a live complaint would destroy the material the complaint is about. Building the hold is a condition of the first sale rather than an improvement to be made afterwards, and no report will be sold before it exists. This section describes how it will work.

Once it is in service, where a report, a finding or an order is the subject of a payment dispute, a regulatory enquiry, a claim, or a complaint made by someone other than the person the material is about, we will place a hold on the material relevant to that matter.

6.2 What it will do. It will suspend expiry, the retention sweep and deletion for that material, including where the buyer has asked for the report to be deleted, and it must take effect ahead of expiry, ahead of the sweep, ahead of the purge of stored files and ahead of a deletion running inside somebody's own request, or it is not a hold. It will reach only what is relevant to that matter, never a class or an account wholesale. Every hold will name the matter it belongs to, the date it was placed and who placed it. It will not be placed to prepare a defence to a claim we expect but have not received.

6.3 A hold will disclose nothing to the complainant. It is a stop on destruction, not a use and not a permission. Held material will not be read for any other purpose, will not be shared with the person who complained, and the fact that something is held will tell that person nothing about anybody else.

6.4 It will end. When the matter ends the hold is released, and the material is destroyed at once if its period has passed or on its normal schedule if it has not. Every live hold will be reviewed at least quarterly, and no hold will run beyond 24 months without being placed again on a recorded decision naming the matter it preserves and the material it reaches.

6.5 A hold cannot be placed because of something you asked us for. Where the matter arises from something the person the material is about told us – a correction request, an objection, a withdrawal of the agreement they gave us, an erasure request, or a complaint about a report that names them – we do not place a hold on that basis, and we do not treat somebody's exercise of a right as a reason to keep material about them for longer. The request is carried out on the timescales in If a Report Names You, and the fact that we are examining it extends nothing. There is one exception and it runs only in your favour: where you ask us under 8.6 to preserve material about you rather than let it expire, we do, for as long as you ask and no longer.

Where a hold already exists for a different matter and it stops us acting on your request, we will tell you that material is held, which matter it belongs to in general terms, what will end it, when we will look at it again, and that nothing held is read or used for any purpose except answering that matter. If we ever conclude that we must keep something about you in order to answer a claim brought against us, we will say so, say exactly what we are keeping and for how long, and tell you that you may complain to the Estonian Data Protection Inspectorate about that decision specifically. A hold is not a way of keeping something after you have asked us to erase it.

``

7. Tax and accounting records

7.1 Seven years for the accounting record. The order, the payment, any refund and any dispute are kept for seven years. This is a legal obligation and is not affected by deletion of the report, closure of an account or an erasure request, save that the identity of a report subject is removed from it under 7.3. ``

7.2 Location evidence on cross-border consumer sales. A cross-border sale of a digital service to a consumer in the EU requires us to hold two non-conflicting pieces of evidence of where the customer was. We will hold the billing country and postal code, a one-way hash of the IP address rather than the address itself, the card country, and the tax identifier and its validation state. No sale has been made and no such evidence is held today.

We will keep that evidence for the period the applicable tax rule requires and no longer. Where the supply is declared under the One-Stop-Shop, that period is ten years from the end of the year of the transaction, under Article 63c of Council Implementing Regulation (EU) No 282/2011. Where a supply of ours is not declared under that scheme, we keep the evidence for the same period as the accounting record in 7.1 and no longer, because the ten-year period attaches to the scheme rather than to us.

The address is hashed so that a readable one is not kept for a decade. The hash is sufficient for the tax purpose, which is to show two non-conflicting indications of country, and it is evidence of nothing else. Where a readable address is needed to answer a payment dispute it is the access record in 2.9 that holds it, for the period stated there and no longer. The two are kept apart on purpose. ``

7.3 A tax record does not name a report subject. The brief carries the name of the person or company a report was about, and it exists in two places: with the report, where it is destroyed ninety days after the report is ready, and with the order.

The order copy is reduced to a record that a brief existed, carrying no name, no profile address and no context text. That reduction happens automatically, without anybody asking for it, at whichever of these comes first: the expiry of the report, its deletion, or an erasure, objection or withdrawal request from the person named in it. What remains with the order is the order line, the product, the amount, the currency and the date.

The accounting obligation reaches the fact and the value of the sale between us and the buyer. It does not reach the identity of a third party who is not a party to that sale, and we do not rely on it to keep one. Nothing in 7.1 or 7.2 keeps a report subject's name, and an erasure request under section 8 reaches this copy. If a report has named you and you believe an order record of ours still carries your name, write to [email protected] and we will check and tell you what we found. ``

7.4 Tax is not a reason to keep everything. The obligation reaches the transaction. It does not reach the analysis, the evidence or the scores, and none of those is kept on that basis.

7.5 What appears on an invoice, and what our payment processor holds independently of us, is in the Payment Terms.

8. If a report names you

8.1 You need no account, no fee and no particular form of words for anything in this section. Write to [email protected]. If a Report Names You is the notice written for you. If you are reading this because we wrote asking whether you agree to a report, clause 2.8 sets out what we keep about that request whichever way you answer.

8.2 The classes above that concern you are the report content, the evidence behind it, the files generated from it, your own record, the consent record, both copies of the brief, the prompt and model-call logs, the record of every share link issued for the report and of each view we served under it, the record of each time the report was downloaded as a file, our email records until your name is removed from them, the do-not-report list if you are on it, the record of any request you make, and any correspondence between us. The rest of the table is about a buyer, a visitor or a transaction.

8.3 The ninety-day rule is a default, not the answer to a request. If you ask us to erase what we hold about you we do not wait for the ninety days to run. The request reaches the report, the evidence behind it, the files generated from it that we hold, your own record, both copies of what the buyer typed including the copy that would otherwise sit with an order, the prompt and model-call records, the share-link records including the name and address of every reader a link was issued to, and any copy of your name in our email records. It takes effect in the live system at once and in backups as they roll off, within 35 days.

It also stops every share link for that report from its next request onwards, because we serve every view of a link ourselves rather than handing anyone an address. It cannot reach a file downloaded while the report was live: 8.5 lists that first, and 4.3 explains why we will not claim otherwise.

Five things do not go, and we would rather name them now than refuse you on the day.

(a) The accounting record of the sale, for the period in section 7. Your name is removed from it under 7.3, so what remains is a transaction and not a person.

(b) Your entry on the do-not-report list, if you are on it, because deleting it is how the next order about you gets through. Tell us you want that gone as well and we will remove it, and we will tell you plainly what you lose by doing so.

(c) The record that you made a request and what we did about it, for the period in 2.1, because a request that leaves no trace cannot afterwards be shown to have been answered.

(d) Material under a hold, on the terms in section 6, which include that a hold cannot be placed because of a request you made.

(e) The record of the agreement you gave us, described in 2.8, for the period stated there. It holds the address we wrote to, what we asked, what you answered and when, and nothing else. It is the only thing we have that shows a report about you was one you had agreed to, so destroying it on request would leave us unable to show that what we did was lawful. Ask and we will tell you exactly what it contains and the date it goes, and the question of whether it must survive your request at all is one we have put to counsel in 2.8 rather than answered ourselves.

Two limits on the rest, stated in advance rather than discovered when you ask. A database backup taken before we act still holds the material until it rolls off, and we do not edit backups. And our system log cannot be edited or deleted at all, which is why 2.4 forbids your name from reaching it and why a name that reaches it is handled as an incident we report to you rather than as a period we serve. Beyond (a) to (e) we hold nothing about you afterwards, and we will tell you in writing what was deleted, what was kept, under which head, and the date it goes.

The routine that reaches every store, the constraint on the system log and the automatic reduction of the order copy of the brief are conditions of the first sale of a report about a named individual. None of them exists today, and until they do no such report will be sold.

8.4 We will not treat somebody's purchase as a reason to keep material about you. Where you withdraw the agreement you gave us, object, or make an erasure request we act on, we withdraw the report from the buyer, delete it, and refund the buyer in full. That is a cost we carry rather than an argument we make, and it does not depend on how long ago the purchase was made. Withdrawal and deletion happen when we decide the request; they do not wait for the refund to complete, and how the buyer is repaid is a mechanical question dealt with in the Refund Policy rather than a limit on this clause.

One consequence of 2.6 is ours to state rather than yours to discover. Because we keep no standing register of the people we have been asked about, a request from you reaches the reports that are live when you make it. A report that has already expired has been destroyed, and there is nothing left to withdraw. ``

8.5 Six things can outlive a report about you, and we would rather number them accurately than round the number down. A file downloaded while the report was live, which is the whole report and not an extract, which no period on this page governs, and which we can neither see nor reach; 4.3 sets out the cases in which the buyer must destroy it and recall what they sent, and we will tell you how many times the report was downloaded and when. Whatever the buyer copied out by hand while reading, which we also cannot see. Our own record of the emails we sent about the report, kept up to two years, from which your name is removed when the report expires or is deleted, and 2.11 is honest about the fact that the removal is not yet running. The consent record described in 2.8. The transaction record, which is kept for the period in section 7 and from which your name is removed under 7.3. And anything under a hold, which section 6 explains, which cannot be placed because of a request you made, and which we will tell you about.

Two more can outlive it, and both exist only because you asked us for something: your entry on the do-not-report list, if you are on it, and our record that you made a request and what we did about it. They are limbs (b) and (c) of 8.3, each has its own period in 2.1, and either goes if you tell us to let it go. Nothing else in the table above outlives a report about you.

8.6 If you want us to keep something rather than destroy it, ask, and ask early. Everything else on this page is about material going. One request runs the other way. You can ask us to restrict what we do with material about you and to preserve it while a dispute, a correction or a complaint is looked at, instead of letting it expire on day ninety. Where you do, we place that material under the hold described in section 6, we stop using it for anything except answering the matter, we give it to nobody, and we tell you when the hold is placed and when it is released. The material is destroyed when the matter ends and not before. A restriction you ask for is not a reason for us to keep anything for our own benefit, and we will not treat it as permission for any other use. You can withdraw it at any time, in which case the ordinary period resumes and may already have passed, and we will tell you if it has. Ask as early as you can: once a period has run and material has been destroyed we cannot bring it back, and after 35 days it is not in a backup either. Nothing in this clause is running today, because the hold it depends on does not exist yet.

9. Backups

9.1 Backups of the database will be held on a rolling cycle of no more than 35 days. The exact figure will be the one our database provider's configuration actually delivers, and it will be stated here before the first sale rather than assumed now. Everything in the table above that the database holds exists in them until the backup holding it rolls off. A report's composed content is held in the database, so it is in those backups and rolls off with them; the backups are encrypted to a key whose private half is not kept on the machine that writes them. The evidence bundle, the preview image and any rendered file sit in object storage with versioning switched off, so for those there is no second copy and no backup tail and their deletion is final at once. The Security statement must be corrected to this in the same release, and the Sub-processors list now names the backup bucket as a class of its own.

9.2 Deletion propagates as backups expire rather than instantly. We do not reach into a backup to edit it. A backup that can be edited is not a backup, and a system that can edit its own history cannot show what it did.

9.3 A restore is not a route back. We will not restore a backup in order to recover a deleted report. If a backup is ever restored for any other reason, deletions and erasures recorded since it was taken are re-applied before the system is used again.

10. Changes

10.1 Material changes are dated in this section and published before they take effect. We keep earlier versions and will send you one on request.

10.2 Which direction a change may run. Where we shorten a period, the shorter one takes effect on publication and material we already hold is brought inside it, because holding less about somebody can never require their agreement and never disadvantages them. Where we lengthen one, it applies only to material collected after the change takes effect; material we already hold keeps the period that applied when we collected it, whether it is about a buyer or about a person a report names.

There is one exception and it is narrow: where a period is fixed by a legal obligation and that obligation changes. If that happens we will publish which obligation changed, which class it reaches, the old period, the new one and the date, we will apply it to nothing else, and we will make no other change to this schedule in the same release.

A change to this schedule does not shorten the period for which a report you have already bought stays available to you, does not shorten the period in which you may raise a non-conformity, and does not otherwise apply to your disadvantage to a purchase already made. Section 17 of the Terms of Service governs changes that affect you as a buyer, and where that section and this one differ on a right of yours, that section governs. A material change to this schedule takes effect no earlier than thirty days after publication, and the only exception is a shortening, which may take effect at once because it can only reduce what we hold.

10.3 Which version applies to a purchase. The version of this schedule in force when you buy will govern your order for the life of that report. Before checkout opens, every published version will carry a content-hash identifier, and the identifier of the version shown to you will be recorded against your order, so that which version applies can be checked rather than asserted. That record does not exist today. Until it does we keep a dated archive of every version and will send you any earlier one on request, and where the version applicable to an order is disputed we resolve the dispute in the buyer's favour.

10.4 How a report subject learns of a change. Where we have written to somebody to ask whether they agree to a report about them, we hold an address for them, and we use it for that request and for what they ask us about it afterwards rather than for anything else. So publication before a change takes effect remains the mechanism, and we will not turn a consent address into a mailing list in order to improve our notice position.

10.5 A sale of the business does not reset these periods. Under section 18.3 of the Terms of Service, information about a report subject is transferred only to a successor that agrees in writing to be bound by the same periods, the same commitment not to publish reports, and the same correction, objection and do-not-report routes. Where a successor will not accept them, the information is deleted before the transfer.


This Data Retention schedule is part of the LeMans Labs legal set and should be read with the Privacy Policy, If a Report Names You, the Terms of Service, the Refund Policy, the Payment Terms, the Sub-processors list and the Security statement.