Privacy policy

Who is the data controller

For your own account (the person who signs up, their name, work email, role, and our billing records) Flavoureak UK LTD T/A Estimark is the data controller. Our privacy policy governs that relationship.

For the data you put into Estimark about other people (your staff, your workers and subcontractors, your clients, and the residents and tenants of properties you maintain) you are the data controller and we are your processor. You decide what goes in and how long it stays; we process it on your documented instructions in order to provide the service. Our data processing agreement governs that relationship, and it is the written contract UK GDPR Article 28(3) requires.

These are two different roles over two different sets of people. Read the privacy policy for what we do with your account; read the data processing agreement for what we do with the personal data you enter about everybody else.

Our data processing agreement sets out the Article 28 terms on which we process personal data on your behalf. It forms part of your subscription terms and is accepted in the application, where the version, the exact text and the time of acceptance are recorded. A copy is available at any time from Settings, and we will provide a counter-signed copy on request to privacy@estimark.co.uk. The sub-processor table below is the same table that agreement uses.

What we collect

We collect only what the service needs to work:

• Account data: name, work email, company name, role, and a hashed password. Passwords are stored as bcrypt hashes and are never recoverable, by us or anyone else.
• Billing data: your plan, subscription status and payment method reference. Card details are handled by Stripe and never reach our servers.
• Content you create: clients, jobs, quotes, invoices, timesheets, photographs, documents and any other records you enter. This is the data you are the controller of.
• Location data: when an operative scans a site QR code to clock in, or takes a site photograph, we record where it happened. This is used to confirm attendance and to evidence site records. It is captured only at the moment of the scan or photograph, never continuously, and never in the background.
• Technical data: IP address, browser and device type, and pages visited, used for security, rate limiting and diagnosing faults. Your IP address and browser are also recorded against a cookie choice, an electronic signature and a sign-in session, so that each can be evidenced later.
• Calls to our sales and support line. Every call is recorded and transcribed, and we tell you so at the start of the call before you say anything. We keep recordings for twelve months and then delete the audio and the transcript together; the fact that a call happened, and the number it came from, is kept as an ordinary business record. Voicemail becomes a support ticket so that a message left out of hours is answered rather than missed. If you would rather not be recorded, say so and we will take the details another way, or write to us at privacy@estimark.co.uk.
• Email we have sent you, and whether it was opened: when we email you about your account — an invoice, a quote, a payment reminder — we record that it was sent, to which address, and the subject. Those emails carry a single invisible image, and when your mail program loads it we record that you opened the message once, the first time. We do this so that a question about an invoice can be answered accurately, and so we do not chase somebody who never received something. We do not record what you clicked inside the message, we do not build a profile from it, and it is never used for advertising. If you would rather not be counted, most mail programs can be set to stop loading remote images, and the email itself is unaffected.
• Special category and criminal records data, where you put it in. The HR, health and safety and housing features are designed to hold sickness absence, accident and injury records, right-to-work and passport documents, criminal records certificates, and, in the housing modules, notes about a resident’s health or vulnerability, including a child’s. You are the controller of all of it and you need your own lawful basis under Articles 9 and 10 to hold it.

Why we are allowed to hold it

Account, billing and content data are processed to perform our contract with you. Technical and security data are processed under our legitimate interest in keeping the service available and secure, and in preventing abuse. Where we rely on consent, as we do for optional analytics cookies, you can withdraw it at any time without affecting the service.

A record of the account email we have sent you, and whether it was opened, is kept under our legitimate interest in administering your account accurately: if you ask us whether an invoice reached you, we can answer instead of guessing. These are service messages about your own account rather than marketing, so we do not ask for consent to send them, and you can object to the open recording at any time by writing to privacy@estimark.co.uk.

Who else sees it

We do not sell personal data, and we do not share it for advertising. The table below is generated from the service’s own configuration rather than maintained by hand, so it lists every third party the software actually contacts and cannot quietly fall behind what the software does.

"Always" means every customer on every deployment. "Only if you accept analytics" means the script is not fetched at all until you agree, so with no decision or a refusal nothing reaches that provider. "When enabled by us" means a feature or credential we control, and the register says where that stands today. "Only if you connect it" means nothing is sent until you authorise the connection yourself.

Recipients that are not our sub-processors

Two recipients receive personal data as controllers in their own right rather than on our instructions, so they are not sub-processors and we have not treated them as such. Where the product sends data to one of them, you need your own lawful basis for that disclosure.

• Structural warranty providers (Premier Guarantee, Build-Zone, LABC, NHBC): EstiWarranty submits a project for a structural warranty quotation.
• Google (AdSense, on EstiJob only): Contextual advertising on the public EstiJob site, and an advertising controller in its own right rather than our processor. It loads only if a visitor accepts advertising cookies, and only where a publisher ID is configured. None is configured today, so EstiJob currently makes no request to Google whatever a visitor chooses.

Where it is stored, and what leaves the UK

Your data is hosted in the United Kingdom, in Amazon Web Services' London region, and backups, of the database and of the files you upload alike, are held in the United Kingdom too. Some processing happens outside the UK and we would rather name it than average it out. Our AI features run on Amazon Bedrock using EU inference, so a request issued from London may be served from another Amazon European region; the EEA is covered by UK adequacy regulations, so no additional safeguard is needed for that. Analytics, card payments and SMS involve transfers to the United States under those providers' own approved transfer terms. If you connect an accounting system, a CRM or a cloud drive of your own, data goes to your account with that provider wherever it is. Every recipient and its location is listed in the sub-processor table.

How long we keep it

While your account is active we keep your data so the service works, and you control how long the records inside it live. You can set your own retention periods for most record types, from 30 days to ten years, and for timesheets, attendance records and audit entries you can choose anonymisation instead of deletion, which keeps the hours, the attendance and the sequence of events and removes the person, including the clock-in coordinates. For record types where removing every identifier would leave nothing meaningful, the product deletes and tells you so rather than performing a rename and calling it anonymisation. Where you set no period, records are kept until you delete them or close the account. Some records have their own fixed period: a data export you request is deleted after seven days, and a recorded screening video is deleted after 183 days. One record is ours rather than yours, so we set its period rather than you: the security log that records failed sign-ins, password and two-factor changes and administrator sign-ins, together with the IP address and browser each came from. Most of the addresses in it belong to people who are not customers, because an attempt to guess somebody's password is recorded against whoever made it. Those entries are deleted after 180 days. The one exception is the receipt an account erasure leaves behind, which records how many rows and files were deleted and names nobody; it is kept, because it is the only durable evidence that the erasure was carried out. After you cancel, your data is kept for 90 days and then erased, and the export stays available for the whole of that window. Two kinds of record are not yours or ours to delete on a timer, because the law fixes a minimum period for them, and the product enforces those minimums over both your own retention settings and a request to close the account. Financial and tax records are kept for at least 6 years (invoices, credit notes, payments received and recorded, expense claims and the receipts attached to them, and CIS returns and deductions) because of the VAT Regulations 1995 reg 31(1), which requires records of supplies made and received to be preserved for six years, and the Finance Act 1998 sch 18 para 21, which requires company tax records to be kept for six years. The period runs six years from the date of the record itself. Stated plainly because it is not quite the statutory clock: the instruments run from the end of the VAT period or accounting period the record falls in, which is later, and the product does not hold your accounting period. Accident records are kept for at least 3 years (accident and incident reports, including the RIDDOR particulars recorded on them) because of RIDDOR 2013 reg 12(2), which requires a record of a reportable incident to be kept for at least three years from the date on which it was made, and the Social Security (Claims and Payments) Regulations 1979 reg 25(3), which requires accident book entries to be kept for three years from the date of the last entry. The period runs three years from the date the record was made. That is what reg 12(2) says, and it is not always the date of the accident. A retention period you set shorter than one of those is refused when you set it, naming the rule; a record still inside one of those periods is not removed by a retention sweep, and an account closure that would remove one is held until the period has run, with the rule that held it recorded. Apart from those two, we apply no blanket period of our own to your business records, because deleting a customer's records on a timer we chose would be worse than keeping them.

What happens if you close your account

Your account owner can ask us to delete the account from inside the product. The request is held for 90 days so it can be cancelled, and is then carried out by a scheduled job. That job deletes the files you have uploaded first and the database rows second, in that order on purpose: a row without its file is untidy, but a file without its row is an unkept promise and an unfindable one, because nothing is left to say the file is there. It removes your company record and everything the database links to it, the fifteen tables a foreign key would otherwise have stranded, and the accounts of users who belonged to no other company. It cancels your Stripe subscription and deletes the Stripe customer record. If storage refuses a deletion the whole erasure is abandoned rather than committed, so we never record an account as erased while its files are still in the bucket. Every run produces a report listing what was deleted and what was left, and the report outlives the account it describes. Where the account still holds a record the law requires to be kept (a financial record inside its six years, an accident record inside its three), the closure does not run at all. It is held until the last of those periods has expired, the owner is told which rule held it and until when, and nothing is deleted in the meantime; a partial erasure that left the ledger behind and reported success would be a worse answer than a delay we can explain. Three things we cannot reach, and we would rather name them than let the sentence above imply otherwise. Stripe keeps issued invoices and payment records, as its own legal obligations require. Anything we previously pushed into your own accounting system stays in your ledger, where you are the controller and we have no standing to delete it, though our stored credentials for it are destroyed. Erasure does not reach backups. Backups are taken nightly and cover both the database and the files you have uploaded; they are kept 14 days on the host and 35 days off-site, both enforced automatically rather than by hand. Personal data that has been erased from the live service therefore persists in those backups for at most 36 days after erasure, after which no copy remains. Backups are not searched, edited or restored selectively to honour an erasure: production holds write-only credentials for the backup store and cannot read or delete from it, which is the correct security position and the reason the residual exists. The files you upload (photographs, scanned documents, signed PDFs) are inside that residual and not outside it: an erased photograph or scanned certificate survives in a backup for the same bounded window as an erased database row, and is then gone. The same nightly archive is what allows those files to be restored if the server holding them is lost. That is the reason it is taken. We are telling you the first half as plainly as the second. Finally, a user account that belongs to another company as well as yours is kept, because deleting it would lock somebody out of an account that is nothing to do with you.

Your rights

Under UK GDPR you can ask us for a copy of your data, ask us to correct it, ask us to delete it, object to processing, or ask us to restrict it. In the product you can export your company's data and request deletion of the account. Anything else, such as correcting or erasing one individual's records across the system, restricting processing, or objecting, is handled by us on request rather than by a button, and there is no per-person erasure function yet. Email privacy@estimark.co.uk and we will respond within one month. If we are your processor rather than your controller (that is, if the request is about your employee, client or tenant) we will pass it to you rather than answer it, because it is yours to answer. If you are unhappy with how we have handled your data you can complain to the Information Commissioner's Office at ico.org.uk, though we would rather you came to us first so we can put it right.

Security

Traffic is encrypted in transit with TLS and HTTP Strict Transport Security is enforced. Passwords are stored as bcrypt hashes and are never recoverable, by us or anyone else. Employees' National Insurance numbers and bank details, and the credentials for any system you connect, are encrypted in the database with a key held outside it. Access is role-based, two-factor authentication is available, uploaded files are reachable only through short-lived signed links, and every significant action is written to an audit log you can read. Database backups are taken nightly, verified, and copied off-site encrypted, and the production servers hold write-only credentials for them so a compromise of the application cannot destroy historic backups. Uploaded files are not part of that: the backup covers the database only, so a file you upload exists in one place, and we would rather say so plainly than let a general word about backups be read as covering it. We hold no security certification of any kind: no ISO 27001, no SOC 2, no Cyber Essentials. We would rather tell you that than let a badge imply one. No system is perfectly secure.

If we suffer a personal data breach affecting data we hold as your processor, we will tell you without undue delay and in any event within 24 hours of becoming aware of it, and help you make any report you have to make. Where we are the controller, we will report to the Information Commissioner's Office within 72 hours where the law requires it, and tell the people affected where the law requires that. Those are the timescales we are bound by, and we will not dress them up as a rehearsed procedure: the platform records security events and flags anomalies such as repeated failed sign-ins, but the alerting, the on-call rota and the written incident plan that would make those timescales dependable are being built rather than already in place. Until they are, a breach would be handled by the people who run the service. We would rather you knew that than assumed otherwise.

Changes

If we change this policy materially we will tell account holders by email before the change takes effect. The date at the top always reflects the current version.