Privacy Policy
Last updated 26 August 2026
The short version
DockLedger stores your delivery bookings, your staff logins, the paperwork your checkers photograph, and — if you switch it on — where your carriers' vehicles are. All of it lives in a database in London and is walled off so that one customer's data can never be read by another.
We never sell it, never use it to train anything, and never look at it except when you ask us to help with a problem. Card numbers never reach us at all — Stripe handles those.
You can have a copy of everything, or have it all deleted, by emailing hello@dockledger.co.uk.
1. Who we are
DockLedger is a trading name of Angelo Guedes, a sole trader established in England and Wales, at Office 1899, 60 Tottenham Court Road, Fitzrovia, London W1T 2EW, United Kingdom.
That named individual is the data controller for the personal data described in this policy. Being a sole trader changes nothing about your rights under UK GDPR: the same obligations, the same deadlines, the same right to complain to the regulator.
For anything in this policy, write to hello@dockledger.co.uk. We aim to answer within five working days and are required to answer formal data protection requests within one month.
We are registered with the Information Commissioner's Office as a data controller and the data protection fee is paid. Our entry on the ICO's public register of fee payers is under registration number ZC231614, registered 26 August 2026 and renewed annually. You can check it yourself on the ICO's public register.
2. Controller or processor — and why it matters
UK data protection law splits responsibility in two, and DockLedger sits on both sides of that line depending on which data you mean.
Where you are the controller and we are the processor
Everything you put into the product about your operation — your bookings, your drivers and hauliers, your staff accounts, your paperwork, your vehicle positions. You decide what goes in, why, and how long it stays. We only act on your instructions, which in practice means: we store it, we show it back to the people you have given logins to, and we do nothing else with it.
Where we are the controller
The much smaller set of data about your relationship with us: the name and work email of whoever signs up, billing records, support emails, and the security logs we keep to spot break-in attempts. We decide how that is handled, because it is our business records rather than yours.
3. What we actually store
| Category | What it includes | Why |
|---|---|---|
| Account | Name, work email address, job title, role, and a one-way hash of the password. We never store a password we could read. | So people can sign in and so the product knows what each of them is allowed to do. |
| Bookings | Haulier name, driver name and mobile number, vehicle registration, trailer number, expected and actual times, notes your staff type in. | It is the delivery record. It is the product. |
| Contacts | Names, email addresses and phone numbers of hauliers and suppliers you deal with. | So bookings can be raised against a known carrier rather than retyped each time. |
| Paperwork | Photographs your checkers take of delivery notes and CMRs. These often contain printed names and handwritten signatures. | Proof of what arrived, including any signature already on the paper your checker photographed. DockLedger itself captures no electronic signature. |
| Vehicle location | Position, heading and timestamp for vehicles and trailers, taken from the telematics system a carrier connects, plus the arrival times we calculate from them. | To tell your gatehouse when a lorry will actually turn up. See section 5 — this one deserves its own explanation. |
| Billing | Your plan, subscription status, renewal date, and an identifier that points at your record in Stripe. | To know what you have paid for. Card numbers never reach our servers — payment pages are hosted by Stripe. |
| Technical | Sign-in timestamps, IP addresses, and error logs. | To spot someone trying to break into your account, and to fix faults. |
4. Our lawful bases
- Contract. We cannot provide the service you are paying for without storing your bookings, your logins and your billing state.
- Legitimate interests. Keeping security logs, preventing fraud and abuse, and contacting an existing customer about their own account. We have weighed these against the rights of the people involved and consider them proportionate and expected.
- Legal obligation. Keeping financial records for the period UK tax law requires.
Where DockLedger is the processor, the lawful basis for the underlying data is yours to establish, not ours — see the next section.
5. Vehicle tracking, plainly
Vehicle location data deserves singling out because it is the part of DockLedger most likely to affect someone who has never heard of us: a driver.
Location is only ever collected when a carrier connects their own telematics account through the haulier portal, using their own credentials, having ticked a consent statement. It is never collected from a driver's phone without that, and DockLedger has no way to switch tracking on for a carrier who has not connected one.
We store positions for the period around a booked delivery and discard older readings. We do not build journey histories, driver league tables, or behaviour scores, and we do not make the raw position trail available for performance management.
What you and your carriers must do. A vehicle's location can identify what a named driver was doing and where. If you or your carriers use DockLedger to track vehicles, that is your processing and you are responsible for having a lawful basis for it and for telling drivers it is happening. We strongly recommend the carrier informs its drivers in writing before connecting. We can supply wording if it helps — email us.
6. Who else touches it (sub-processors)
We use a small number of specialist suppliers. Each is bound by a written contract to process data only on our instructions and to protect it properly.
| Supplier | What for | Where |
|---|---|---|
| Supabase | Database, logins, and storage of paperwork photographs | London, United Kingdom (region eu-west-2) |
| Netlify | Serving the web pages themselves | Global content network. The pages contain no customer data. |
| Stripe | Taking payment, hosting the checkout and billing portal, and acting as merchant of record — Stripe issues the VAT invoice and holds the payment relationship | UK and USA |
| TomTom | Maps, routing and traffic, to work out arrival times | Netherlands |
| Cloudflare | Turnstile, the challenge that tells people from bots on every sign-in page. It sees the visitor's IP address; it does not see anything you type. | Global content network |
| Google (Fonts) | The typefaces used by the console and the floor apps. Requesting a font tells Google the visitor's IP address. | Global content network |
| jsDelivr and cdnjs | Public code libraries the apps load in the browser (the Supabase client, the map, the barcode reader). They see the visitor's IP address. | Global content network |
| Anthropic | Reading a photographed delivery note into proposed lines, when you use that feature. The image and the text on it are sent, held only for the length of the request, and never used to train a model. | USA (with UK/EU processing where available) |
We will tell you before adding a new sub-processor that handles your data.
Sending data outside the UK
Your operational data stays in the UK. Some of the suppliers above operate internationally, and where data reaches a country without a UK adequacy decision, the transfer is covered by the UK International Data Transfer Addendum to the EU Standard Contractual Clauses.
7. How it is kept apart and kept safe
- Separation is enforced by the database, not the screen. Every table carries row-level security rules, so a request for another company's records returns nothing even if someone bypasses the app entirely and calls the API directly. Hiding a button is not a security control and we do not treat it as one.
- Encrypted in transit and at rest. HTTPS everywhere; the database and the file storage are encrypted on disk.
- Passwords are hashed, never stored in a form anyone could read. Third-party credentials, such as a carrier's telematics API key, are held in an encrypted vault that even an account administrator cannot read back.
- Least privilege by role. Checkers can record deliveries but cannot delete records or see billing. Office staff cannot see billing. Only the account owner can.
- Paperwork photographs are private by default and served only through short-lived links to people signed in to that same workspace.
No system is perfect. If we ever discover a breach that puts people at risk, we will tell you without undue delay and report it to the ICO within 72 hours as the law requires.
8. How long we keep it
- While you are a customer — your operational data stays as long as your workspace is open, because deleting your delivery history is not ours to decide.
- After you cancel — we keep it for 90 days so you can change your mind or ask for an export, then delete it. Ask us sooner and we will delete it sooner.
- Vehicle positions — kept only around the relevant delivery window; older readings are discarded automatically.
- Billing records — kept for six years, because UK tax law requires it.
9. Your rights
Anyone whose personal data we hold can ask to see it, correct it, have it deleted, restrict what we do with it, receive it in a portable format, or object to processing based on legitimate interests. There is no charge, and we will respond within one month.
If you are an employee, driver or contact of one of our customers, your request is usually best directed at them, since they decide what is stored about you. Write to us anyway if you are not sure who to ask — we will point you the right way and help them answer.
If you think we have got it wrong, you can complain to the Information Commissioner's Office at ico.org.uk or on 0303 123 1113. We would rather you told us first so we can put it right.
11. Changes
If we change this policy in a way that materially affects you, we will email the account owner before it takes effect. The date at the top always reflects the current version.