What we store and for how long

Who is responsible

• The data controller is Secordit Intelligence Ltd, 13-17 Whitby Street, Hartlepool, TS24 7AD.
• To ask about your data, for example to see, correct or delete it, email intel@secordit.co.uk. This is the address our privacy policy gives for data requests.
• Our lawful basis for your email, sign-in records and check counts is that we need them to provide your Ordit account (performing our contract with you). Our lawful basis for the visitor count and the short-lived request record is our legitimate interest in keeping the service secure and stopping abuse.
• Cloudflare hosts Ordit and holds this data on our behalf, as our processor. Our account database currently runs in Western Europe. We haven't restricted it, or the short-lived request record, to any region or country, so we can't promise where either is held. Cloudflare may also handle technical request data outside the UK, as our privacy policy explains.

When you check a message

• We don't store the message you paste. It is scored and shown back to you.
• We don't store the score or the warning signs found. Outside business accounts, we don't keep a history of your checks, only the counts described below. For a business account, we keep a record of when each check was used and which team member used it, as described below.
• We don't store your IP address in our database.
• Our code doesn't log the text you paste.
• Cloudflare, our hosting provider, handles normal technical request data such as your IP address.
• For most checks, an AI model, Llama 3.3 70B, run by Cloudflare, our hosting provider and processor, also reads the text to help with the score. We send at most the first 1,500 characters, with email addresses and phone numbers masked. Cloudflare says that for this kind of request it does not keep the text after the request is processed. Cloudflare may keep data where the law requires it. Cloudflare also says it does not use that text to train AI models. We don't store the model's answer or the text. If that step can't run, the rules alone decide the score.

If you haven't signed in

• Without an account you can run 3 checks a month per connection. We count them against a keyed hash of your IP address. The address itself isn't stored.
• The hash uses a secret key, so it can't be turned back into your address without that key.
• The month follows UK time. Counts from earlier months are deleted the first time any visitor uses a check in a new month.
• Separately, a short-lived record keeps the times of your recent requests against a keyed hash of your IP address. The hash uses a secret key, so it can't be turned back into your address without that key. It slows down heavy repeat use (20 requests in 10 minutes). It is cleared about 10 minutes after your last request.

If you sign in

• Your email address, saved in lower case. We keep it until you delete your account.
• When you ask for a sign-in link, we keep a keyed hash made from the link and a random value held in your browser. We also keep a keyed hash made from the 8-digit email code, your email address and that same random value. We don't keep the link, the code or that value themselves in the sign-in records. We also keep your email address, when each record was made, when it expires and whether it has been used. The link and the code each work once and expire after 15 minutes. Using either the link or the code ends both. Used or expired records are removed once they are 24 hours past expiry, the next time anyone asks for a sign-in link.
• Your sign-in session. We keep a hash of the session code. It lasts 30 days. It ends when you sign out or delete your account. Expired sessions are removed the next time anyone signs in.
• Your session cookie is called __Host-ordit_sid. It is set when you finish signing in, lasts 30 days, and ends when you sign out or delete your account. When you ask for a sign-in link, Ordit also sets a short-lived cookie called __Host-ordit_login. It lasts 15 minutes and is used so the link, or the email code, works in that browser. We clear it when you finish signing in.
• A count of checks used. For Free, one row for each month, UK time, starting on the 1st (5 checks a month). Free monthly counts are kept until you delete your account, and they're deleted with it. For Personal, the count is kept in a separate store. There is one counter for each billing month, starting on your billing date. That counter holds only a number and a keyed hash of your account ID. It doesn't hold your email address. It is deleted about 40 days after the last check it counted. Your Personal daily check counter, one for each UK day, is kept in the same store, holds the same, and is deleted about 42 hours after the last check it counted. When you delete your account, the counts kept with your account are deleted with it, along with your sign-in details and the plan record on your account. We keep a billing copy of that plan record for 6 years from the date you delete your account.
• Your plan, Free or Personal. Personal is £6 a month or £66 a year. Business check packs are 1,000 checks for £10, 5,000 for £40, 20,000 for £120 or 50,000 for £250, and unused checks expire 12 months after the pack is bought. Payments for Personal and for check packs are taken by Stripe, our payment provider. We never see or store your card details. We don't store your Stripe customer number. When you open Manage billing, we look it up from your subscription.
• Sign-in emails. We send your sign-in link and 8-digit code by email through Resend, our email provider, from no-reply@secordit.co.uk. We don't keep a copy of the email in our database. Resend keeps the email and the details of sending it for 30 days on the plan we use, and its backups can hold a copy for up to 7 days after that.
• Business accounts. If you use a business account, we keep the business account record, who the account owner is, and each team member's account and role. For each check pack we keep its size, checks left, purchase and expiry dates and the amount paid. We also keep our payment provider's reference and your confirmation that you're buying for a business. For each check used from a pack we keep the time and the team member. We don't keep the message.

  To add a team member, the account owner enters the email address of someone who already has an Ordit account. Adding them doesn't create a new account.

  We delete the record of each check used 12 months after the check. We keep pack purchases and check balances for 6 years, to meet UK tax and company record rules. If a team member deletes their account, we remove their details from these records. See our Privacy page for more.

If you delete your account

• Use Delete my account at the top of the page. You need to be signed in and to confirm.
• This deletes your account record and email, your sessions, your check counts, the plan record on your account (we keep a billing copy of it for 6 years from the date you delete your account) and any sign-in links for your email, from our database. Your Personal check counter is kept in a separate store, so it isn't deleted with your account. It holds only a number and a keyed hash of your account ID, and it is deleted about 40 days after the last check it counted. Your Personal daily check counter, one for each UK day, is kept in the same store, holds the same, and is deleted about 42 hours after the last check it counted. The copy of your latest Personal check figures, shown on your account page, is deleted with your account. The billing and business records described below stay for the periods given there. If you have a paid plan, we cancel it with our payment provider first. You won't be able to get the account back.
• Backups. Our database host keeps point-in-time backups (Cloudflare D1 Time Travel). A deleted record can stay in those backups for a limited time, up to 30 days, and then it ages out.
• The visitor count for your IP hash is not linked to your email, so deleting your account doesn't change it. It is removed with the other old months, as above.

What we never store

• The text of any message you check.
• Scores, warning signs or the results of your checks. For a business account, we do keep a record of when each check was used and which team member used it, as described above.
• Your IP address in our database. Only the hashes described above.
• Passwords. Ordit doesn't use them.
• Card numbers or bank details.

The fields in our database

These are the tables and columns in the Ordit accounts database. On the live service we leave one table out of this list: a test mailbox that only our test version of Ordit uses, and that the live service's code never writes to.

users

One row per account.

• id: random account ID
• email: your email address, lower case
• created_at: when the account was made

login_tokens

Sign-in links and email codes.

• hash: keyed hash made from the link, or from the 8-digit email code and your email address, and a random value held in your browser
• email: the address the link was for
• created_at: when it was made
• expires_at: 15 minutes after it was made
• used_at: when it was used, if it was

sessions

Signed-in browsers.

• id_hash: hash of the session code
• user_id: which account
• created_at: when it started
• expires_at: 30 days after it started

subscriptions

Plan record. It holds your plan status and payment references. If you delete your account, we remove the account. We keep a billing copy of this plan record for 6 years from the date you delete your account. It isn't your card details.

• user_id: which account
• plan: free or personal
• status: plan status
• period_end: end of the paid period
• Plan-ending setting: whether your plan is set to end at the end of the period you've paid for
• past_due_since: when a payment first failed
• updated_at: last change
• provider_subscription_id: reference number for your subscription at our payment provider, if you have one. We use it to cancel your plan if you delete your account. It isn't your card details.
• last_payment_at: The date of your latest payment. We keep it so we can tell whether that payment was within the last 14 days if you cancel your paid plan or delete your account. It isn't your card details.
• last_payment_amount_pence: The amount of your latest payment, in pence. We keep it so we can refund the right amount if you cancel your paid plan or delete your account. It isn't your card details.
• last_payment_currency: The currency of your latest payment, kept with the amount. It isn't your card details.
• last_payment_ref: Our payment provider's reference for your latest payment. We keep it so we can refund the right payment if you cancel your paid plan or delete your account. It isn't your card details.
• refund_owed_payment_id: Our payment provider's reference for a payment we owe you a refund for. We set it when you cancel your paid plan or delete your account within 14 days of that payment, before we try the refund. A later retry can still refund it. We clear this once everything we owe you has been refunded. If you delete your account, we remove the account. We keep the billing and refund record, including this payment reference, for 6 years from the date you delete your account. It isn't your card details.
• refund_owed_amount_pence: The amount of that refund, in pence.
• refund_owed_at: When we recorded that a refund is owed.

usage

Checks used by signed-in accounts.

• user_id: which account
• month: the month, UK time, for Free (like 2026-11)
• n: number of checks used

anon_usage

Checks used by visitors who haven't signed in. This table also holds the short-lived sign-in counts, partial-result counters and, when payments are on, the payment bookkeeping records. A partial-result counter is for each connection (IP address) and UK day. Its month field is a day label starting fb:, and its key is a keyed hash of the IP address and that label. It holds a count and no message text. They count partial results, so that the first 3 each day without an account or on Free don't count as checks. These counters belong to the test version's local checker path, which the live service doesn't use. Our housekeeping task deletes counters for UK days more than 48 hours before the day it runs. If it fails or hasn't run, they stay until it runs again. It also holds a daily count of how many checks were read by the AI model, and how each of those uses ended. Those counts don't include the message text.

• key_hash: either a keyed hash or a plain label, depending on the record. Keyed hashes: IP address and month for visitor checks; IP address and UK day for partial-result counters; other keyed hashes for short-lived sign-in counts; the subscription reference for the cancellation marker. Plain labels, which hold references as they are, without scrambling: a date label for AI-reader counts; our payment provider's reference for each payment event, and for the running refund total on a payment; and, for payment bookkeeping, a label with your account ID and, where there is one, a payment, subscription or checkout reference (checkout, extra subscriptions, checkout lock, Personal and pack start requests, billing date, the subscriptions an account has had, the copy of the latest Personal check figures, and a refund already paid). Pending cancellation and pack refund records use the subscription, payment or refund reference; a pending cancellation may also hold the account ID. Pack start records also hold which wording was shown
• month: the month, UK time, for visitor checks, or a UK-day label starting fb: for partial-result counters, a 15-minute window for short-lived sign-in counts, a billing label for payment bookkeeping records, or a label for AI-reader counts
• n: the check count, partial-result count, AI-reader count or short-lived sign-in count, or for the Personal figures copy, checks used, the allowance, checks left, a reset time, or a flag showing the copy is out of date. For payment bookkeeping: a timestamp, a pending/done flag, a billing day, or a refund amount in pence, depending on the record

businesses

One row per business account.

• id: random business account ID
• owner_user_id: which account is the account owner
• created_at: when the business account was set up
• refund_used_at: when the business had its pack refund, if it has

business_members

Who is on each team.

• business_id: which business account
• user_id: which account
• role: owner or member
• added_at: when they were added

credit_lots

One row per check pack bought.

• id: random pack ID
• business_id: which business account
• pack: Starter, Team, Business or Scale
• credits: checks in the pack
• remaining: checks left
• purchased_at: when it was bought
• expires_at: 12 months after it was bought
• stripe_ref: our payment provider's reference for the payment. It isn't your card details.
• amount_pence: the amount paid, in pence
• business_confirmed: whether the buyer confirmed they were buying for a business
• business_confirmed_at: when they confirmed it

credit_ledger

Checks added to and used from packs, and pack refunds. Rows for checks used are deleted 12 months after the check. Rows for purchases and refunds are kept for 6 years, then deleted.

• id: row number
• business_id: which business account
• lot_id: which pack
• delta: checks added or used
• reason: why, such as a purchase or a check
• user_id: which team member used the check
• ref: a reference so each entry is counted once: a random one for checks used, or our payment provider's reference for the purchase or the refund
• at: when it happened

pack_checkouts

Started pack payments.

• session_id: our payment provider's reference for the checkout
• business_id: which business account
• user_id: who started it
• pack: which pack
• business_confirmed: the buying-for-a-business confirmation, which must be ticked
• business_confirmed_at: when it was ticked
• created_at: when the checkout started

Not in the database: the short-lived request record described above lives in a separate store. That store keeps only a keyed hash of your IP address and the times of recent requests.

We also keep short-lived counts of sign-in requests and code attempts, in the same table as the visitor check counts. These use keyed hashes of your IP address and, for code attempts, your email address. The hashes use a secret key, so they can't be turned back into your address without that key. We also keep a keyed mark of each email address used for a sign-in request from that connection in the same window. Sign-in requests from one connection are limited in each 15-minute window. Code attempts are limited to 5 per connection and 5 per email address in each 15-minute window, including attempts that work. Counts from earlier windows are removed the next time a sign-in request or code attempt is counted.

The 8-digit sign-in code is in the sign-in email, with the link. We don't keep the code itself in the sign-in records, only the keyed hash described above. The link and the code each work once and expire after 15 minutes.

When payments are on, we also keep bookkeeping records in the same table as the visitor check counts. These are references for checkout, and for extra subscriptions we need to cancel and refund. We also keep a flag when that refund is done, and a keyed marker that a subscription was cancelled. The marker is a keyed hash of the subscription reference. It holds no card details. Checkout and extra-subscription records for your account are removed when you delete your account. The cancellation marker also holds the time of the cancellation. It is kept while you have an account and for 6 years after you delete it, so an old payment event can't open the plan again. Then it is deleted. If a cancelled subscription was never linked to an account, its marker is deleted 30 days after the cancellation. If the account it came from is deleted first, the 6-year period applies instead. We also keep the reference of each payment event Stripe sends us, so the same event isn't counted twice. References older than 35 days are deleted each time we finish handling a new payment event of a kind we use. Repeats of events we've already handled, and events we don't use, don't start that clean-up. If the clean-up fails, it waits for the next such event, so a reference can be kept for longer than 35 days. When you start Personal, we keep the time you ticked the box asking us to start it during the 14-day cancellation period. That record's label is your account ID itself, so it isn't scrambled. It is deleted when you delete your account. Stripe also keeps that time with the payment. When you start a check pack, we keep the time you ticked the start box and which wording you saw, in a record labelled with your account ID and the checkout reference. We delete it when you delete your account. The billing-date record is deleted with your account. We keep the billing and refund record for 6 years after you delete your account. Pending cancellations are removed after they've been applied to the plan, or with the account if they're labelled with its ID. The separate links to the subscriptions your account has had, and the copy of your latest Personal check figures, are also deleted with your account. The billing copy of your plan record keeps your current subscription reference for 6 years from the date you delete your account. Pending pack refund records are removed once the refund is matched to a pack. A pending cancellation or pack refund that can't be matched has no set end date: we keep it while money may still be owed, check it by hand at least once a month, and delete it only once we've confirmed nothing is owed or we've paid what is. The running total refunded on each payment, if it's linked to your account, is kept for 6 years after you delete your account, then deleted. Before sending a plan or pack confirmation, we keep its purchase details, recipient address, purchase time and start request time in a queue. The queue entry stays until the email is sent and the plan or pack is supplied. If the purchase is dealt with by hand, our team deletes the queue entry once that work is resolved. When we send the confirmation email, we keep its subject and text, wording version, terms version, start wording and sent time. We also keep a fingerprint (a hash) of its subject and text. We keep these while you have an account and for 6 years after you delete it, then delete them. For each refund we make, we keep our payment provider's refund reference, the amount and when we first recorded it, so the same refund isn't paid twice. If the refund is linked to your account, we keep that for 6 years after you delete your account, then delete it. A refund record or running total without an account link is kept for 6 years from its first recorded time. For older totals without that time, the 6 years start when our scheduled review first finds them without a link. A separate refund link containing your account ID and refund reference is given the date you delete your account. We delete it 6 years from that date, together with the refund record. If a pack is paid for without a start request, we don't add its checks. We keep a record of that payment (the checkout and payment references, the amount, the pack and the account) and a note for our team to deal with it. If you ask us to start the pack, we send its confirmation before adding checks and deleting that record. Otherwise we keep the record for 6 years from when we made it, even if you delete your account, so we can still refund you. Notes our team makes on a billing or refund case, such as the reason an account was suspended, are kept for 6 years from the last time they were changed, even if you delete your account. Other notes our team makes on an account are deleted with the account. While an account is suspended, a marker labelled with its account ID blocks sign-in, checks and purchases, and we keep a total of the time it has been suspended. We delete the active marker when the suspension is lifted, and that marker and suspended time when the account is deleted. When a suspension is lifted, we keep a record of your account ID and when that suspension started. We delete that suspension record when you delete your account. If we close a business account by hand, we keep its closure progress, amounts owed, payment references and refund results. We keep these while money remains owed or the closure is unfinished. We delete them 6 years after the closure is finished. Our scheduled review checks when these records are due for deletion.