Security

1. What this statement is, and what it is not

1.1 This page describes what we do, and you may rely on it. Every sentence on it is a statement of fact about our own practice, meant to be falsifiable by showing that we do not do the thing described, and true as at the date recorded for it in section 13. We do not ask you to agree that it has no effect, and we do not present it as marketing. What it is not is a prediction. No set of controls prevents every incident, and nothing here is a promise that this service will not be attacked, will not be interrupted or will contain no error; clause 7.6 of the Terms of Service governs availability. Nothing in this clause excludes or limits our responsibility for a statement on this page that was untrue when it was made, and nothing in it affects a right you have as a consumer that cannot be excluded by agreement. If a statement here is wrong, tell us and we will correct it and record the correction in section 14.

1.2 It is not a certification. We hold none. Section 2 names what we do not hold.

1.3 It is dated. Section 13 is an inventory of the controls this page relies on, each with the date it was verified and what it was verified against. A control that is not in place carries no date and is listed as not in place. We publish nothing as operating unless its row is dated.

1.4 Most of this product does not exist yet. The website is live. There is no checkout, no account, no sign-in, no database in service, no report pipeline and no email. Sections 3 to 9 therefore describe two different things and label which is which: what is in place on the site as it stands, and what will be in place before the first report is sold. We do not describe a planned control in the present tense. Where an earlier version of this page did so, section 14 records it.

1.5 Nothing here reduces any right. This statement does not vary the Terms of Service, with one exception stated in the clause that makes it: clause 12.4 grants a permission to security researchers and is intended to prevail over any inconsistent term. Subject to that, this statement does not affect any right you have as a consumer that cannot be excluded by agreement, and does not affect anyone's rights under data protection law. That last point includes the rights of a person a report is about, who has no contract with us and cannot be bound by anything a buyer accepted.

1.6 This page limits nothing. Where our liability is limited, it is limited by section 12 of the Terms of Service and by nothing written here. Clause 1.1 says what this page is; it is not an exclusion and is not to be read as one.

2. Certifications and cover we do not hold

2.1 We are not SOC 2 certified and hold no SOC 2 report of any type.

2.2 We are not ISO 27001 certified.

2.3 No independent penetration test has been carried out against this service.

2.4 No payment-card self-assessment questionnaire has been completed. Section 8 explains the position we expect to qualify for, why that is a different thing, and the one questionnaire we will always complete.

2.5 We hold no third-party security attestation of any kind. Nobody outside this company has audited, assessed or reviewed our security.

2.6 We do not describe ourselves as compliant with any standard, framework or regulation, here or anywhere else. Where there is a practice, we describe the practice instead.

2.7 We carry no insurance against any of this. There is no cyber policy, no professional indemnity policy and no other cover behind the service. That is a decision taken with the risk stated rather than an oversight, and it is recorded here so that nothing on this site can be read as implying that a policy stands behind a claim. Nobody should rely on the existence of cover, and no sentence in this suite offers any.

2.8 If any of that changes, this section changes with it, the change is dated in section 13 and recorded in section 14.

3. Hosting and architecture

3.1 What runs today is a website. Cloudflare hosts it, serves it and runs its server-side functions, on Cloudflare Pages, and provides the domain's DNS and the network layer in front of it, so one company carries every request and holds the platform request log of it. It is named on the Sub-processor list, which is the page to read for what it sees and where it runs, and which governs if this page and that one ever describe recipients differently. Nothing else is switched on: no analytics, no error monitoring, no advertising or measurement tag, no third-party script of any kind. Beyond what those two platforms log, described in the Privacy Policy, we store nothing about a visitor ourselves. One item is stored on your own device, recording your storage choice; it is described in the Cookie Policy and carries its own row in section 13.

3.2 What will run when the product does. On one machine rented from Hetzner in Helsinki, and administered by us: a Postgres database, the application that serves this site, and a worker container that runs the scheduled tasks. Off it: collected evidence and report preview images in Cloudflare R2; payments by Stripe; search results from Serper; model access routed through OpenRouter; transactional email through Resend, delivered through Amazon SES. Product analytics with PostHog and error monitoring with Sentry are configured for but not switched on, and receive nothing. Each is named on the Sub-processor list with what it sees and where it is. That list is longer than this sentence and it is the authoritative one: if a company appears there and not here, the omission is a defect on this page.

3.3 Browser-side protections: what our configuration sets. Our configuration sets a content security policy that names an explicit allow-list of origins rather than permitting any. Framing is denied. Content-type sniffing is off. The referrer policy stops a full page address being passed to another site, which is the control that will keep report identifiers and share tokens out of third-party logs once there are any. The camera, microphone, location, payment, USB and topic interfaces are switched off. Cross-origin opener and resource policies are set to this origin. Production responses are configured to carry strict transport security with a two-year maximum age and subdomains included. No third-party script is included in this site's own code, and typefaces are served from our own domain, so reading a page is not intended to disclose your address to a font provider.

3.4 The script part of that policy is not in its strictest form, and we would rather write that than publish a claim stronger than the header we send. Inline script is permitted, because the framework streams its own inline script and the per-request mechanism that would allow only ours has not shipped. Section 13 records it and what closes it. Do not read 3.3 as a statement that inline script is blocked.

3.5 Database access controls, and the one class they will not initially cover. When the database goes into service, the tables holding customer data will be separated at the database level, so one account's records cannot be read in another account's context even by application code with full command execution.

The register of the people who have been analysed will not initially sit inside those controls, because it is shared between reports by design. We record that as a defect and not as a design decision, and we offer no justification for it. In particular, the fact that the register holds no buyer data is not a reason: every field in it belongs to the person the report is about, who is the person the control exists to protect. We claim no uniform protection, here, in the Privacy Policy or in an answer to a questionnaire, and clause 15.4 of the Privacy Policy carries the same exception so that a person a report names is not told otherwise in a document written with them in mind.

Until the row in section 13 is dated, the only things between that register and an application fault are the application layer itself and the constraint on the administrative role in 6.2. The bound we intend for the register is its short life: the design destroys the record ninety days after the last report referring to that person. That destruction depends on the job described in 9.6, which does not run, and clause 7.2 of the Data Retention notice records that a second order about the same person restarts the ninety days rather than adding to them. So the register's short life is a rule we have adopted and not yet a mechanism we operate, and it is not an outer limit. Bringing the register inside the same database-level controls, and exercising the deletion path end to end against the database constraints as built, are both conditions of the first sale of a report about a named individual, and neither is a condition we will treat as met by intention rather than by a passing check.

3.6 What we have not confirmed, and why we say so. Everything in 3.3 describes our own configuration. A network layer sits in front of this site and can add to or alter what our configuration sets, and our own records already contain one instance where the policy served and the policy configured differ. We have not yet captured the response a visitor actually receives and compared it, line by line, against 3.3. Until that capture exists and is filed, the header rows in section 13 carry no date and this page makes no claim about what the response on the wire contains. You can settle it yourself in one request, and we would rather you did than take our word for it. Where the response and the configuration ever differ, the response is what this page must describe and the configuration is a defect we record.

4. Encryption

4.1 In transit. Every connection to this site uses TLS. Strict transport security is configured on production responses, so a browser that has seen the site once will not connect to it unencrypted afterwards, subject to 3.6. Both statements are covered by the first row of section 13 and neither carries a date until the capture described in 3.6 exists.

4.2 At rest, stated the way it is actually true. We will not operate our own storage and will hold no encryption key of our own for data at rest. What stands behind an at-rest claim in this product is therefore the encryption our database and storage providers apply to what they hold, with keys they manage. We do not audit those providers and are not in a position to, as clause 10.3 says, so we do not present their practice as a finding of ours. What we will do instead is keep a record, for each provider and with a date, of the encryption term in that provider's own published documentation and of the corresponding term in the agreement we execute with it, and give that record to anyone who asks for it. No provider is engaged today, no agreement is executed and no such record exists, so today this clause describes an arrangement we intend rather than a protection anyone has. When a company says its data is encrypted at rest, provider-managed encryption is usually what stands behind it, and we would rather say which of us is standing behind it.

4.3 We do not encrypt individual fields inside the database, and here is the honest reason. The analysis needs the brief and the collected evidence in readable form to run, so the key would live in the same place as the data and would add little to what the provider's encryption already covers. That reasoning belongs to a buyer, who chose to hand us their inputs. It carries less weight for the person a report is about, who agreed to the report but did not choose how we hold it.

For that person the protection we rely on instead is a short life for the material, and the honest version of that is not one figure. The report, the evidence behind it and the files generated from it are designed to be destroyed at ninety days. Three classes are scheduled to outlive them: the logs of the automated calls made while the report was produced, the record of the email we sent, and the copy of the brief held with the accounting record. Every period is in the Data Retention notice, which governs if anything we publish disagrees with it. All of them depend on the job described in 9.6, which does not exist, so none of them is enforced by a mechanism today. Before the first report about a named individual is sold, each of the three longer classes is either brought inside ninety days or stripped of the subject's name, and the schedule states which was done. We will record the field-encryption decision, and revisit it specifically for reports about named individuals, with that person named as the interested party rather than the buyer.

4.4 Credentials. Sign-in codes and session tokens will be stored only as cryptographic digests, so a copy of the database will contain nothing anyone can sign in with. This is written and not in service.

5. Signing in

5.1 There is no sign-in today, because there is no account to sign in to. This section describes the design that will be in place before the first sale.

5.2 There will be no password. Signing in will be by a single-use six-digit code sent to the email address on the order and exchanged for a session. There is no password to reuse across sites, none to leak and none to reset, and a copy of our database will contain no password of yours because there will never be one.

5.3 The sign-in email will carry a code and no link. A sign-in link in a message can be relayed by whoever receives it, and it trains people to click authentication links in mail, which is the habit we most want a customer not to have. One message we send does carry a link, and it is not this one: the consent request described in 9.9, which confirms a permission and grants access to nothing.

5.4 What that design costs, and the limits we put on it. A code sent to a mailbox is easy to forward, and anyone who controls the mailbox on the order will be able to reach the reports bought with it. A password would not have prevented sharing either. Clause 7.5 of the Terms of Service places responsibility for that mailbox on the account holder and clause 9.5 prohibits sharing a code or reselling access, and those are the obligations we rely on. They are obligations on a buyer, not controls, and we do not read clause 7.5 as putting on a consumer the cost of an authentication design we chose. We will not rely on it for that purpose. Where a report is reached by somebody who obtained a code without the buyer's knowledge, we will treat that as our incident: we will investigate it, tell the buyer, and where the report is about a named individual we will act on it under section 11 as well.

Three controls are designed to bound the weakness rather than to describe it. A session will be bound to the browser that redeemed the code and will not be transferable to another. Opening a report whose subject is a natural person from a session we have not seen before will require a fresh code, so a forwarded code opens one reading rather than a standing entitlement. Every sign-in, every new session and every opening of such a report will be recorded under 7.5, and the account holder will be told when a session starts from somewhere we have not seen before. That recognition will use the sign-in cookie already listed in the Cookie Policy and the request data we already hold; it will not use any fingerprinting technique, and if it ever needs one it will not be built. None of this runs today. Each is a condition of the first sale and each carries a row in section 13, and until those rows carry dates we make no claim that a report reaches only the buyer, and no other page of ours should be read as making one.

5.5 We will never ask you for a sign-in code. Not by email, not by telephone, not in a chat, not in any circumstances. Anyone who does is not us.

6. Access to production systems

6.1 One person holds the production credentials. LeMans Labs is a company of one. At that size there is no separation of duties and no second pair of hands, and we would rather write that sentence than describe a department that does not exist.

6.2 The administrative database role will bypass the controls in 3.5 by design, because it is the role that applies changes to the database structure and runs the expiry job. It is specified never to be present in the environment the website runs in, and verifying that in the build rather than by intention is a condition of the first sale.

6.3 What compensates for 6.1. Administrative actions will be written to a log that the application can add to and cannot alter or delete, with each entry chained by hash to the one before it and a daily job verifying the chain. That detects an alteration after the fact; it does not prevent access. It is the strongest control available to a team of this size, and unrun it is worth nothing. It does not run today.

6.4 A gap we would rather name than have found, and what it costs us. The list of actions that log will record covers state changes, shares, sign-ins, and the delivery and view events described in 7.5. It will not record an operator reading the contents of a report, and clause 7.3 keeps report content out of the log altogether. Two things follow, and the second is against our own interest.

First, a person a report is about, who is not our customer, has no way to take our word for it that nobody read the analysis written about them.

Second, we would be unable to evidence our own statement that no person reads, approves, edits or alters a report before or after delivery, which is what clause 3.4 of the Terms of Service and clause 3.1 of If a Report Names You say. A statement we cannot evidence is worth less than one we can, to us as much as to the person relying on it.

So two things are conditions of selling the first report about a named individual, and each is its own row in section 13: recording an operator read of report content as an action in its own right, and recording any change to the text of a generated report with the identity of the operator or process that made it and the time. Until both rows carry a date, clause 3.4 of the Terms and clause 3.1 of If a Report Names You are statements of our practice that we ask you to take on trust, and we say so rather than let them read as evidenced.

6.5 Support access to an account, with the customer's agreement, is a designed capability. Both its start and its end will be recorded in that log as actions in their own right.

7. Logging and monitoring

7.1 What runs today. The platform request logs of the two companies named in 3.1, holding the network address, user agent and path of a request, on retention periods those platforms set and we do not. That is the whole of it.

7.2 What does not run today. The tamper-evident action log in 6.3, the order event record in 7.5, error monitoring, product analytics, alerting of any kind, and any on-call arrangement beyond one person reading mail. None of it is switched on, and nothing is sent to an analytics or error-monitoring provider.

One qualification, because 3.3 invites you to read the policy we serve and you will find something in it that does not match this clause. That policy still permits browser connections to the origins of the analytics provider named on the Sub-processor list, left over from a configuration written before the decision to ship without analytics. Permitting a connection is not making one and nothing has ever been sent, so this clause is true; but we record it as a defect rather than as a decision, because while those origins stand in the allow-list, switching analytics on would need no change to a header, to this page or to that list. Removing them, so that turning analytics on requires a change to all three, carries its own row in section 13. Standing up the monitoring named in this clause is a condition of the first sale, for the reason in 11.5.

7.3 What will be written, what is held in readable form, and what never will be. The action log will record who did what to which record, and never the content: never a brief, never a finding, never the body of a report. Sign-in codes, session tokens, share tokens, keys and card details will be written to no log at any time. Email addresses will be removed from error reports before they leave our systems, by code that is already written and that has nothing to scrub because nothing is sent.

Network addresses are handled in three ways, and we would rather set out all three than state one rule that is untrue of two of them. First, the platform request logs in 7.1 hold the full address of a request, for periods those platforms set; we do not truncate them and cannot. Second, in logs and error reports we generate ourselves, an address is truncated or stored as a one-way digest, and no readable address is retained. Third, against an order we will keep a separate and deliberately narrow record: the country derived from the address the order was placed from, the country of the payment method, the billing country given at checkout, a one-way digest of the address that country was derived from, and the times in 7.5. That record exists because the same facts answer a payment dispute and evidence where a cross-border sale took place. It holds a country and a digest rather than a readable address, and its period is in the Data Retention notice.

``

7.4 How long logs are kept is in the Data Retention notice, not here, so the two cannot say different things.

7.5 The record kept so that a payment dispute can be answered. Against each order we will record, as separate events with the time of each: the order and the total charged; the wording of every control the buyer actioned at checkout, as it was displayed to them; the consent request sent under 9.9 and the reply to it; the confirmation email we sent and what our email provider reported about its delivery; the moment the finished report was made available; each sign-in to the address the order was placed from; and each time the report was opened, and from which session. That record carries no report content, no brief, no finding and no card data.

It is the only evidence we will have that what was bought was delivered and used, so it is kept for the period stated in the Data Retention notice rather than for the ninety days the report itself lives, because a payment can be disputed after a report has expired. Clause 10.3 of the Refund Policy, clause 6.7 of the Payment Terms and clause 11.5 of If a Report Names You each promise something out of this record: a dispute answered on delivery and use, and an honest answer to a report subject about who reached the report about them and when. None of those promises can be kept until this record exists. It does not exist in any form today, and section 13 carries its rows.

One item in that list carries more weight than the rest and we would rather say so here than let it pass as one line among the others. The Refund Policy states that a report is not refundable as of right once it has been delivered. That position stands or falls on our being able to produce, for the individual order, the wording the buyer was actually shown when they asked us to begin at once and acknowledged what asking for that costs them, together with the confirmation we sent afterwards. Storing the rendered wording rather than a reference to a template, and storing it against the order, is what makes that producible, and it has its own row in section 13. Until that row carries a date, the position in the Refund Policy is one we assert and cannot evidence for any order, and nothing on this page should be read as saying otherwise.

``

8. Payment data

8.1 There is no checkout today. Nothing on this site can take a payment.

8.2 When there is one, card details will be entered on a page served by Stripe. Card numbers, security codes and expiry dates will not reach our systems, our logs, our database or our backups. We will store the card brand, the last four digits, the issuing country and the payment method type, so a payment can be identified in a support conversation and a dispute can be answered. The name of a person a report is about is not part of what goes to the payment provider and must not appear on an invoice line; clause 4.5 of the Payment Terms is the commitment and the configuration that carries it is a condition of opening checkout.

8.3 Why it works that way, and what holds it there. Checkout will be a redirect to the payment provider rather than a card field embedded in our page, which keeps our involvement with card data as narrow as a seller can make it. That arrangement can be undone by a single change to the checkout, so it will be held in place by a test that fails our build if any part of this site reads a card field, and by the policy already in force that restricts where our forms may submit. Clause 4.2 of the Payment Terms states the outcome without qualification; this clause names the control that has to exist for it to stay true, and section 13 says that control is not built.

8.4 What we do not claim, and the one questionnaire we will always complete. We are not "PCI compliant" and we are not "PCI DSS certified". Neither phrase will appear on this site, in our marketing, on an invoice or in an answer to a buyer's security questionnaire. The arrangement in 8.2 is the basis on which we expect to qualify for the shortest merchant self-assessment available to a fully redirected checkout. No self-assessment has been completed, because no payment can be taken yet. A position is not an attestation and we will not print one as the other.

That is a statement about what we advertise. It is not a refusal to answer anyone. Where our payment provider, our acquirer or a card scheme requires a self-assessment questionnaire, an attestation or a written description of our card-data environment, we will complete it accurately, on the form specified, by the date required, and keep it current for as long as we take payments. Completing it before the first charge is a condition of opening checkout and is a row in section 13. Where a buyer's own procurement asks the same question, we will answer it in writing with the true position.

8.5 Payment Terms covers what we hold about a payment and how it appears on a statement.

8.6 Screening, and what it is not. Clause 14.3 of the Terms of Service reserves the right to refuse or cancel an order on sanctions grounds and states that screening by our payment provider does not discharge that obligation. It is therefore an obligation we owe ourselves, and the controls that would carry it – a screen of the buyer and the payment at checkout, and a screen of the subject named in a brief before any search runs and before money is taken, each with the lists used, their version and the decision recorded against the order – do not exist. Until their rows in section 13 carry dates, clause 14.3 is a rule we apply by hand to the orders we happen to see, and we would rather write that than let two of our documents imply a control between them that neither of them operates.

``

9. Reports, the consent record and share links

9.1 The three most sensitive things this product will hold are not about a customer. The first is a complete, scored analysis of a named person who bought nothing. The second is the consent record described in 9.9: the address we wrote to, and whether that person agreed or refused, which discloses that a named individual was the target of a diligence request and what they said about it. The third is the list of people who have asked us not to produce reports about them, which is more sensitive per record than any report, because membership discloses that a named person took a step to protect themselves and we have promised elsewhere never to confirm or deny that anyone is on it. This section starts there deliberately, because the usual way of writing it – we protect your data – describes the wrong person.

9.2 Report storage is not public, and no report is served from it. The bucket holds the collected evidence and the sample preview images – not the report, which is in the database, and not the file a buyer exports, which is produced by the application that already holds the report and streamed straight to the reader.

That is a rule and not an accident. Writing a report or a file into the bucket would mean the company that runs the bucket holds a complete analysis of a named person, and handing a reader a storage address would mean handing out access we could not afterwards revoke. Every view and every download is served by us, on a request we check first. Clause 2.7 of the Sub-processor list carries the same condition from the other side, and section 13 carries its row. It will have no public access and no address of its own, and no browser will fetch from it, so there is no cross-origin rule left to state. Object versioning will be off deliberately, so deleting an object in that bucket does not leave an earlier version of the same object behind it. That is a statement about that bucket, and it is not a statement about backups, which are 9.8.

9.3 A shared report is checked on every request. A shared view is served through a route that validates the link and the reader each time, rather than a signed address that keeps working until it expires. So revoking a share takes effect on the next request, and a link never outlives the report's ninety-day window. Nothing about a shared report is cached.

That check is the whole of what revocation means here, and it is why we say a link can be ended and never say the same of an exported file (9.7). What we do not yet have is the search-engine work: robots entries for the report and share routes, directives instructing search engines not to index or follow them, exclusion from our sitemap, and a link preview carrying our name and nothing else. None of it is built, it has its own row in section 13, and clause 12.6 of the Intellectual Property notice states it. What stands in its place is that nothing anonymous reaches a shared report at all: a crawler, a preview fetcher or a platform unfurling a pasted address is not the named recipient and has no code.

9.4 A link names the person it was issued to, and that person proves the address before the first view. It is not a key that works for whoever holds it. The buyer names the recipient and gives us their address, we send the link, and before the first view the recipient confirms that address with a code – the same mechanism a buyer signs in with. Every view after that is recorded against the link.

So forwarding the address carries no access with it, there is no anonymous shareable link in this product, and no address in storage serves a report directly. Every view is served by us, which is the fact 9.3 depends on. The trade we made is on the buyer's side rather than the reader's: the buyer has to say who is reading, and the reader has to open one message from us before they open the report.

9.5 Where a company report turns out to be about one living person. A report about a named person is sold only to that person. The buyer attests at checkout, in a separate box that starts unticked, that the subject is themselves, and checkout refuses a Founder X-Ray or an Executive Package without that attestation. A file or a link for such a report is therefore the subject's own decision about their own document.

A company report takes no such attestation, and a company can be one living person – a sole trader, a one-person company, a named partnership. Our pipeline detects that case and the report is written under stricter rules because of it. It does not close the export or the link. A check that would have done so was considered and deferred; it is not built, it has no row in section 13, and no sentence on this page or anywhere else in our published set says it exists.

What that leaves is stated rather than smoothed over. Where such a report is exported or shared, the person it is about is not our customer and has agreed to nothing, and what makes the processing lawful is our own legitimate interest rather than a contract with them. The weighing that supports it, what it concludes and the condition that conclusion depends on are written down and dated before this release, and a person a report names can ask us for it.

9.6 The bound that is meant to do most of the work, and what state it is in. The design is that a report, the evidence collected to produce it and the files generated from it are destroyed ninety days after the report is ready, and that this short life, rather than the storage arrangement, is the main protection for a person the report is about. The destruction is carried out by a scheduled job rather than by anyone remembering.

That job is not built, it is not scheduled and it has never run. Nothing on this service expires today. No report has been produced, so nothing is yet overdue for destruction, and we would rather write that than leave a period on a page with no mechanism behind it. Until the row for it in section 13 carries a date, every ninety-day period in this statement, in the Data Retention notice, in the Privacy Policy and in If a Report Names You is a rule we have adopted and not yet a mechanism we operate, and nothing on this site should be read as saying that material about a person a report names has been or will be destroyed on schedule. Building the job, running it against real records and recording the date it was observed to work is a condition of the first sale. Two protections elsewhere on this page depend on it and say so: clause 3.5, for the register of people who have been analysed, and clause 4.3, for the decision not to encrypt individual fields.

One exception will apply once it does run. Where a report, an order or a finding is the subject of a payment dispute, a complaint we are examining, a regulatory enquiry or a claim, section 6 of the Data Retention notice places a hold that suspends destruction of that material and of nothing else, for as long as the matter runs. That is why clause 7.7 of the Terms of Service can undertake not to delete a report while a dispute is open. A hold is a stop on destruction and is not a permission to use the material for anything, and it means a buyer's dispute can extend the life of a third party's report past ninety days. The hold does not exist either, and it has its own row.

9.7 What we cannot undo. A link we can end, because every view of a shared report is served by us and checked first: revoking one stops the next request, wherever the address has travelled and whoever is holding it.

A file we cannot. When a buyer exports a report, that file sits on their machine and outside every control on this page. Deleting our copy does not reach it, revoking anything does not reach it, and no scheduled job expires it. The same is true of what a buyer transcribed, screenshotted or retyped. We can require them to stop using such a copy and to destroy it, and the Terms do, but we cannot see that they made one and we cannot confirm that it is gone. A company that told you it had destroyed every copy would be telling you the one thing about this it could not check, so we tell you the shape of it instead: every export is recorded as an event of its own, so we can say that a file was made and when – which is a different thing from being able to reach it.

9.8 Backups, because deletion is not instant everywhere. The database will be backed up on a rolling cycle, and the period is in the Data Retention notice rather than here, so the two cannot say different things. Anything we destroy still exists in a backup taken before the destruction until that backup rolls off. We do not edit backups, because a backup that can be edited cannot show what the system held, and if one is ever restored, the deletions and erasures recorded since it was taken are re-applied before the system is used again. So when we tell you something has been destroyed, the accurate statement is that it is gone from the running system at once and gone everywhere within the backup cycle. That applies equally to a report a buyer deleted, to a report we withdrew, and to an erasure carried out for a person a report was about. Clause 9.2 is about one bucket and this clause is about backups; neither is a statement about the other.

9.9 The consent record, which is the store this section exists for. A Founder X-Ray may only be about the buyer, who attests at checkout that the subject is themselves. The route that let somebody else buy a report about a third party, on that person's emailed confirmation, was withdrawn on 9 August 2026, and no such report is offered at any price. The store described below belongs to that route: it is built, it sends nothing, and the rest of this clause states the terms it would be held on if the route ever returns. Where the subject is anyone other than the buyer, we send that person a message describing what the report is, who asked for it and what happens next, and production starts only if they confirm. The message carries a link that does one thing, records a decision and gives access to nothing. It is the one message from us that carries a link, and 5.3 says why the sign-in email does not.

What that creates is a store holding, for each request: the name and email address we wrote to, who asked, when, and whether the person agreed, refused or did not reply. It is more sensitive than it looks. A refusal, or an unanswered request, records that a named individual was the subject of a diligence enquiry by an identified person and did not agree to it, and the same record read from the other side tells the buyer more about the subject's response than the buyer is entitled to know. So it is held on the following terms. It is never shown to a buyer beyond the fact that the order proceeded or was cancelled, and never with a reason. It is read by the production pipeline and by nobody else in the ordinary course, and every read of it by a person is recorded as an action in its own right under 6.4. Where consent is not confirmed within the window, the order is cancelled and refunded automatically, and the address we wrote to is destroyed on the period in the Data Retention notice rather than kept against a future order. It is never used to market anything, never added to any list, and never used to contact that person for any purpose other than the request itself and, where it applies, a notice under section 11.

None of this exists. The consent gate, the automatic cancellation and refund, the retention of the address and its destruction each carry rows in section 13, and no report about a third party may be sold before all of them are dated.

``

9.10 The list of people who asked not to be reported on. It holds the least a refusal needs: the identifiers required to recognise a future order, and the date. No correspondence, no reason, no report. It is read by the production pipeline when an order is submitted and at each stage afterwards, and by nobody else in the ordinary course. Every read of it by a person rather than by the pipeline is recorded as an action in its own right under 6.4, and that recording is a condition of the list being used at all, because our promise in clause 4.4 of the Acceptable Use Policy and in If a Report Names You never to confirm whether someone is on it is worth nothing if a read leaves no trace. It is never exported and never included in an answer to any question from anyone. It does not exist today, it carries its own row in section 13, and building it is a condition of publishing the route that invites people to use it.

10. Sub-processors

10.1 We build on other companies' infrastructure, and every one of them that handles personal data is named on the Sub-processor list, with what it sees, where it is, the transfer mechanism relied on, and the date each row was checked.

10.2 Which agreements exist, and which do not. At the date of this version, and subject to the qualification about our payment provider at the end of this clause, no data processing agreement is executed with any provider named on that list. Two of them handle personal data today: our host and our network provider, because they carry every request to this website and see its network address, user agent and path. Their agreements are being put in place before the product launches rather than after, and that list records the date each is signed. No other provider has received anything about a buyer, a report or a report subject, and none will in production before its agreement is executed, its transfer basis is recorded and its row on that list is dated. Our payment provider is a separate case in one respect: it is also a controller in its own right for its own fraud, risk and regulatory purposes, its row says so, and the terms accepted when a payment account is opened may themselves carry the data protection terms for what we route through it. If they do, an agreement exists for that provider from the day the account is opened, the first sentence of this clause is qualified accordingly from that day, and this clause and that list are corrected in the same release rather than left to be read as an absolute that has stopped being true.

``

10.3 Something worth knowing before you ask. A provider list is not an assurance about a provider's security. We do not audit them and are not in a position to. What we can tell you is which ones there are, what each one sees, and that we have kept the list as short as the product allows. Clause 4.2 depends on this and says so.

10.4 A correction we have made, and its scope. An earlier version of the privacy page on this site said that every recipient of personal data was already bound by a data processing agreement. That was wrong when it was written. It was published from [date first published] until [date corrected], and it was replaced on [date of withdrawal]. While it stood, no report had been produced and no information about a person a report names had been sent to any provider; the recipients in that period were the two companies in 10.2, which carry website traffic. The superseded wording is retained and we will send it, with its dates, to anyone who asks. We record the scope rather than the fact alone, because an undated admission invites a wider reading than the truth supports and a narrower one than we can prove.

11. If something goes wrong

11.1 What we commit to is a process, not a deadline we cannot yet meet.

11.2 The order of work on becoming aware. Contain first. Then establish what was affected and whose information it was. Then notify. We assess the affected population starting with report subjects rather than buyers, because a breach of report material harms the person the report is about first, and that is the opposite of the instinct.

11.3 Notification to the supervisory authority and to affected people. We will notify the Estonian Data Protection Inspectorate of a qualifying personal data breach within the period the law requires, and we will tell affected people directly where the law requires it and we hold a way to reach them.

11.4 Report subjects, and what we can now reach them with. This has changed, and an earlier version of this page said the opposite. For a report about the buyer, the address on the order is the subject's own. For a report about anyone else, we hold the address we sent the consent request to under 9.9, because there is no other way to obtain a permission that is demonstrable by us. So in most cases we can tell a report subject directly, and where we can, we will, on the same footing as a buyer and before them where 11.2 applies.

Where we cannot – where the address has been destroyed, where mail to it fails, or where the affected set cannot be resolved to addresses we hold – we will publish a dated notice in three places at once and leave it in all three for as long as it is current: at the head of If a Report Names You, which is the page written for the people affected and is linked from every page footer; on this page; and on the home page of this site. We will not place it only here, because this page is not where a person a report names would look for it. Clause 15.6 of the Privacy Policy and clause 8.6 of If a Report Names You must name the same three placements, in the same words, in the same deploy. Not being able to send an email is not a reason not to tell people, and putting a notice where nobody affected would find it is a way of not telling them.

11.5 The honest weakness in all of that. A duty that runs from the moment we become aware is worth exactly what our ability to become aware is worth, and today that ability is one person reading provider bulletins and customer mail. The monitoring in 7.2 is a condition of the first sale for this reason and not for a tidier one.

11.6 Our payment provider. Where an incident affects, or where we cannot yet rule out that it affects, any system involved in taking a payment, any record described in 8.2, or the integrity of our checkout, we will notify our payment provider through the channel its terms specify, without waiting for the assessment in 11.2 to be complete, and we will tell it what we know and what we do not yet know. We will do that whether or not the incident is a notifiable personal data breach and whether or not any card data appears to be involved, because whether card data is involved is one of the things we would not yet know. We will do the same where we learn of a compromise from that provider, from a card scheme or from a customer rather than from our own systems, and we will say which it was. This notification is separate from 11.3 and neither replaces the other.

11.7 If you think a report about you has been exposed, this is how you reach us. Write to [email protected], or to [email protected] if you would rather; either reaches us. Tell us what you saw and where. You need no account, no fee and no particular form of words, and you do not need to prove anything before we look. We will not ask you for identity documents in order to take a report of an exposure seriously. We will tell you what we found and what we did about it. Where the exposure is confirmed, clause 11.2 means you come first and our buyers second. Your rights, and the other routes to us, are in If a Report Names You and in the Privacy Policy.

``

12. Reporting a vulnerability

12.1 Where to send it. [email protected], with "security" in the subject line. That mailbox exists, is monitored and is routed to a named person, whose name we will give you on request. We publish no separate security address, because a published address nobody has created is worse than none, and this is the one we can stand behind.

12.2 What we commit to on timing, and why it is not shorter. We will acknowledge your report within three business days of it arriving. We are one person, we have no alerting and no on-call arrangement, and clauses 7.2 and 11.5 say so, so we publish a period we can meet in a bad week rather than one that reads better. If you have had no acknowledgement after five business days, write again. A second message going unanswered is a fault on our side and never on yours.

12.3 What else we commit to. An assessment, and the decision that follows it, communicated to you; and being kept informed until the matter is closed. We publish no fix deadline, because a company of this size that publishes one and misses it has handed the reporter a document. We ask that you do not disclose publicly for 90 days, or until a fix is released, whichever is sooner. That is a request and not a term of any agreement. If you decline it, we will not treat that as a breach of 12.5 and it does not affect the safe harbour in 12.4.

12.4 The safe harbour, and where it sits in relation to everything else we publish. This section is our vulnerability disclosure policy. It is given as a binding undertaking by LeMans Labs OÜ, it is intended to be relied on by you, and it prevails over any statement elsewhere on this site that no disclosure policy is published or that no safe harbour is offered, and over any inconsistent term of the Terms of Service or the Acceptable Use Policy. Clause 1.5 of this page does not apply to it.

Where you report a vulnerability to us and your research kept within 12.5 throughout, then in respect of that research: we will not bring or support a civil claim against you; we will not make or support a criminal complaint, or a complaint to your employer or to a provider, about you; we will not treat it as a breach of the Terms of Service or of the Acceptable Use Policy; and, as against you and for that research only, we treat the access to our own systems that it required as authorised by us rather than as access we did not permit.

This clause reaches research on systems we operate. It gives no protection in respect of anything done through the payment path, which is dealt with in the second paragraph of 12.5, and it reaches nothing listed as out of scope in 12.6. It binds nobody else, and it is not permission to touch any system that is not ours.

12.5 The conditions, all of them. Test only against material you supplied yourself, and only against orders, records or accounts you created yourself. Where the service offers no account, that means testing only against what you submitted. Do not access, alter, download or retain anyone else's brief, order or report. If you reach someone else's information by accident, stop at once, do not keep or share it, and say so in your report. Do not degrade or interrupt the service for anyone else. Keep automated testing to a low rate. No social engineering of our people, our customers or our providers, and no physical testing of anything. Do not send a consent request under 9.9 to anyone who has not agreed with you in advance to receive one, because the person on the other end of that message is not a test subject.

The payment path is outside this permission in every respect, and this is not a formality. Do not attempt a payment except to buy a report you actually want, with a payment method that is your own. Do not submit a card, account or credential belonging to anyone else. Do not attempt a payment you expect to be declined, do not repeat authorisation attempts, and do not use generated, published or provider-issued test numbers against our live checkout. Do not test our payment provider's pages, which are not ours to give permission over. If you believe you have found a weakness in the payment path, describe it to us in writing and stop there; we will reproduce it ourselves in a test environment. Conduct of that kind remains a breach of these conditions and of clause 15.2 of the Terms of Service whatever the motive behind it, because it puts our ability to take payment at all at risk, which is why it is excluded rather than rate-limited.

12.6 Out of scope. Findings from automated scanners with no demonstrated impact; missing headers with no exploit path; anything reachable only through the payment path described in 12.5; and anything concerning the providers named in section 3, hosting, DNS and our payment provider included. Nothing in this section is permission to test a third party. We cannot give permission we do not hold, and a researcher testing one of our providers on our invitation is a problem we would have created.

12.7 We pay no bounty. This clause says so rather than implying one. Public acknowledgement is offered instead, if you want it.

12.8 If we disagree about whether your testing stayed inside 12.5, we will tell you why in writing before taking any step against you.

``

13. What is not in place yet

13.1 Below is every control this statement relies on, and the list is closed: if a sentence on this page depends on a control, that control has a row here, and adding such a sentence means adding its row in the same change. If you find a protection described anywhere in this statement with no row here, the row is missing and the protection is not one you should rely on; tell us and we will correct the table and record the correction in section 14.

A row carries a date only if the control is in place and was verified on that date, and verified means one thing and nothing looser: a named person observed the control behaving as described on the running production system, or an automated check that observes it passed, and a written record of that observation exists, names the person or the check, and is retained for as long as this page is published. Reading a configuration file, a specification, a ticket or a code comment is not verification, because what a configuration file says and what a deployment serves can differ, and in this deployment they have. The second column names what each dated row was verified against, so the date can be checked rather than taken on trust. A control we believe we have but cannot evidence on the day of publication is published undated, on the same terms as one we know we do not have. A row without a date is not in place, whatever else this page or any other says. Where a row is not in place, the third column says what closes it.

This is an inventory of what this statement relies on. It is not a register of every obligation the company has: the sanctions duty in clause 14.3 of the Terms, the eligibility rules in section 4 of the Terms and the conduct rules in the Acceptable Use Policy are obligations whose controls appear here only where a sentence on this page depends on them.

13.2 Two rows are conditions of publishing this page rather than of selling anything: the served-response capture that the first two rows depend on, and the retention of superseded versions in 14.2. If this page is live and either is missing, this page is wrong and should come down until they exist.

13.3 How this section is maintained. It is re-checked on every release that touches a row, and the date moves only when the control is verified again on the terms in 13.1. A dated inventory nobody maintains is worse than no inventory, because it is a claim with a date on it.

13.4 The record behind a date. The verification record behind every dated row is retained and will be produced on request to a customer, to a person a report names, or to a supervisory authority. If a record cannot be produced, the row loses its date in the next release and section 14 says so.

14. Changes to this statement

14.1 Every version of this page is identified. Each published version carries the date it took effect and a content-hash identifier printed at the foot of the page, in the same way as the Data Retention notice.

14.2 We keep every superseded version. Anyone may ask for any earlier version, with no account, no fee and no particular form of words, and we will send it. We do this because the value of this page is that it is dated, and a dated statement that can be rewritten without trace is worth nothing to the person relying on it.

14.3 A withdrawal of a claim is recorded, not quietly made. Where a control this page described stops being in place, its row loses its date in the same release and the change is listed here with the date. Where a sentence is removed because it was wrong, we say here that it was removed and why. We do not delete a claim silently.

14.4 Which version applies to you. For a buyer, the version in force on the date of the order. For a person a report is about, the version in force on the date the report about them was produced. We record both against those records, so that neither has to be argued about later.

14.5 Changes to date. None. This is the first version. Two statements that appeared in earlier drafts of this page and never in a published one are recorded here so the correction is on the face of the document rather than in a file nobody reads: that report material expires at ninety days, stated in the present tense when no mechanism to expire anything existed; and that we hold no contact details for the people reports are about, which ceased to be true when the consent step in 9.9 was adopted.

---

This Security statement is part of the LeMans Labs legal set and should be read together with the Privacy Policy, which governs what we do with personal data and carries our provider identification and contact details; the Sub-processor list, which names every provider that handles it and governs where this page and that one differ; the Data Retention notice, which holds the periods and governs where this page states one; If a Report Names You, written for the person a report is about; the Acceptable Use Policy, which governs testing and misuse; and the Terms of Service, which is the contract and which carries the limits on our liability.