Just Granted
Log in

Privacy notice — customers

Privacy notice — customers (APPROVED 2026-08-27, was v1)

APPROVED BY DAN, 27 August 2026 (869eqx27v): "I have read the complete GDPR pack, I approve all of it." The draft banner is lifted on every document in this pack at once, which is what he asked for. What his approval is not: it is not legal advice, no solicitor has read any of it (his decision of 2026-08-19, 869ef85a2), and it did not create the DPIA that §12.6 of the LIA says is needed before the first bulk-file sale — that DPIA was written on 2026-08-29 at his instruction (869eqy933 Q2) and is at docs/gdpr/DPIA-BULK-DATA-FILE.md; it is drafted and awaiting his sign-off, which is a different thing from approved. The history below is kept as written.

History — status was: DRAFT v1 (2026-08-24). Written by Claude for ticket 869enj3v8. Not legal advice, and not approved. No solicitor has read it: on 2026-08-19 (ticket 869ef85a2) Dan decided not to commission a formal review at this stage, having discussed the business model and this documentation with a solicitor in detail. Dan reviews, amends and approves before this binds anyone; until he sets KESTREL_LEGAL_APPROVED=1 every page on this site carries a draft banner saying so.

Why it exists. Everything published before it was written for planning applicants — the people whose details we take from public registers. Nothing covered the people who subscribe. This notice is that half, and it was written by reading the database models rather than from memory: every category below is a real column in a real table, and the sections say which part of the service creates it.

The contact address is now hello@justgranted.co.uk, on Dan's instruction (869ee2apd, 2026-08-27). The trading name changed from Plan & Post to Just Granted on 2026-08-20 (869em1n5x), the website moved on 2026-08-24 (869em1nqu) and the mailbox followed on 2026-08-25 (869em1ny7), proved by a real message delivered each way. hello@planandpost.co.uk is an alias on the same mailbox and is kept receiving indefinitely, so an email sent to the address this notice used to print still reaches us.

Who we are

Just Granted is a trading name of Blueworkz Ltd (company number 13258077), registered at 39 Crispin Field, Pitstone, Leighton Buzzard, LU7 9BG, United Kingdom. Blueworkz Ltd is the data controller for the personal data described here.

Contact us at hello@justgranted.co.uk, or by post at the registered address above. We have not appointed a data protection officer; we are not required to.

Who this notice is for

This one is about you, our customer — the people at a subscribing business. That means:

It is not about the planning applicants our subscribers write to. They have their own notice, because the two relationships have different lawful bases, different rights and different retention, and one page covering both is a page nobody reads. The applicant notice is at justgranted.co.uk/legal/privacy/.

Most of what we hold about you is business-contact information about a person acting for a business. Some of it is not so tidy: a sole trader's business address is often a home address, and a one-person company's records are records about one person. We treat it all as personal data.

What we do not do, first

It is shorter than the list of what we do, and it is the part people usually want to know.

What we hold, why, and on what basis

Your login

Email address, first and last name, your role on the account (admin or subscriber), the date you joined, the time you last logged in, and the time of your current and previous visit — the last pair is what makes the "new since your last visit" list on the applications screen work.

Your password is never stored. What is stored is a one-way hash (PBKDF2-SHA256 with a per-password salt), which cannot be turned back into your password by us or by anybody who steals the file. Nobody at Just Granted can tell you what your password is, only reset it.

Email verification links, invitation links and unsubscribe links are signed rather than stored — the link proves itself, so there is no table of live tokens to leak.

Lawful basis: contract (UK GDPR Article 6(1)(b)) — we cannot give you an account without them.

Your business

Company name, address, town, postcode, phone number and logo; the plan you are on and the date it is paid until; which councils you subscribe to and which are your defaults; whether you hide applications with no published applicant name; and how you want letters addressed when a council publishes no name.

Some of this is printed on paper and posted to strangers. Your business name, address, phone number and logo appear on the letters you send, because a letter has to say who it is from. Once posted, that is out of our hands and in a recipient's letterbox. Everything else in this section stays inside the service.

Lawful basis: contract.

Colleagues you invite

An invitation stores the email address you typed, the role you chose, who sent it, when it was sent and accepted, and which account it was for. We email that person because you asked us to. If they do not accept, the invitation stays as an unaccepted row until the account is deleted; tell us and we will delete it sooner.

Lawful basis: contract with the subscribing business, and our legitimate interests in letting a business run a team account.

How you use the service

Lawful basis: contract for the features themselves; legal obligation and our legitimate interests in accountability for the export audit log (Article 5(2)).

The letters you send

Templates you write, including the body text, images, watermark, fonts, QR link and who created them. Batches, including who built them, when they were dispatched, and how many recipients were skipped and why. Individual letters, including the delivery status, the printer's own reference, what it cost, what you were charged, any error, and a snapshot of the body as it was actually sent.

Alongside those, an append-only send audit: every attempt to spend your money, whether it succeeded or was refused, the reason, who authorised it, and whether it was a test. It is written whether the attempt worked or not, and it cannot be edited afterwards. If you use automated workflows, we also keep each run: what it matched, what it skipped, what it would cost, and who approved it or whether it was approved automatically when the window closed.

Lawful basis: contract for sending at all; legal obligation for keeping records of what was sent; and our legitimate interests in being able to answer a complaint about a letter, and in stopping money being spent that nobody authorised.

Money

Your Stripe customer and subscription identifiers, your subscription status, and whether the account is live or test. Paid invoices as Stripe reports them: the invoice number and identifier, the date, the currency, what was charged for subscription and for postage, and the processing fee. Movements of prepaid letter credit, including any note and who recorded it. Your monthly spend cap and who set it, the threshold at which spend alerts go out, the email addresses those alerts go to, and a record of each alert actually sent.

We hold no card number, no expiry date and no security code. Payment is taken on Stripe's own hosted pages, and cancellation happens in Stripe's own customer portal.

Lawful basis: contract, and legal obligation for the accounting records — which is why they outlive the account. See retention, below.

Emails we send you

Two different things, and the difference matters.

Transactional email — email verification, invitations, password resets, receipts, dispatch confirmations, spend-cap warnings — is part of the service. It cannot be switched off while you have an account, because it is not marketing and there is nothing to consent to. Lawful basis: contract.

Optional email — the weekly lead alert, a newsletter, and tips and how-tos — is sent only if you have said yes. Lawful basis: consent (Article 6(1)(a)), and you can withdraw it at any time from your email preferences or from the unsubscribe link in any of them. Three details worth stating, because they are properties of the code rather than intentions:

The funnel — five rows, and this is all of them

We record whether the money we spend on marketing actually produces customers. It is the smallest measurement that answers the question, and it is worth writing out in full because it is the section people expect to be the worst.

We record five milestones per account, once each, ever: signed up, first search, first letter drafted, first letter posted, first payment. Each row carries the account, which of the five it is, the campaign and source that won the account, and the time. A uniqueness rule in the database makes "first" mean first, so the table grows with customers rather than with traffic — five rows per account is the maximum, not an average.

What a row does not carry: not your name, not your email address, not your IP address, not your user agent, not the URL you were on, not your search terms, not a session identifier, not a cookie, and never a planning applicant's name, address or postcode. Nothing about it makes a request to anybody outside our own server. It is not analytics and it is not permitted to become analytics.

Alongside it, your account carries the campaign and source it arrived with — for example a utm_source on a link, or the referring site, or "direct" — captured once at signup. An account created before 22 August 2026 carries "unattributed", because we never asked.

Lawful basis: our legitimate interests in knowing whether our marketing works before spending more on it. The impact on you is minimal by construction: five rows, about a business rather than a person, never combined with anything else.

The waiting list

If you asked to be told when we open, we hold your email address, which box on the site you used, which campaign brought you, and when. Nothing else — no name, no IP address, no cookie.

Lawful basis: consent. We use it for one email when we open, and you can tell us to delete it at any time.

When our staff look at your account

Our support staff can, when there is a reason to, open the service as your account in order to see what you are seeing. Every start and every stop is recorded: who did it, whose account, the reason given, the time, and the operator's own IP address. The audit row is written before the switch happens, so a failure halfway leaves evidence rather than silence. The IP address recorded is our operator's, not yours.

Lawful basis: our legitimate interests in supporting the service and in being able to account for staff access to customer data.

If you use the AI letter drafter

Drafting a letter with AI sends the brief you typed and your company name to Anthropic, our processor for that feature, and sends back letter text. We do not send your customer list, your applicant data, or anything else about your account.

We keep a log of each attempt: which account and which user, the provider and model, how many tokens went in and out, what it cost, and whether it succeeded or was refused and why. We do not store the brief and we do not store the prompt. Because the brief goes to a third party, do not type other people's personal details into it.

Lawful basis: contract for the feature; legitimate interests for the usage log, which exists to enforce a fair-use quota and to know what the feature costs.

Cookies

Two, both strictly necessary, both first-party:

Both are marked HttpOnly or SameSite as appropriate and are sent only over HTTPS in production. Strictly necessary cookies do not need your consent, and these two are the only cookies there are today: no analytics cookies, no advertising cookies, no third-party cookies. That is why you have not been asked to agree to anything — there is nothing to ask about — and an anonymous visitor is not given a session at all.

If that changes, the banner arrives with the cookie, not after it. We intend to add website analytics (see "What we do not do, first"). A non-essential cookie may only be set with consent under the Privacy and Electronic Communications Regulations, so on the day analytics is switched on there will be a consent banner that lets you refuse as easily as accept, refusing will leave the site fully usable, and this section will be rewritten to name the cookies, who sets them and how long they last — before they are set, not afterwards.

Our server logs, and the free preview

Our web server and application logs may contain IP addresses and requested URLs, as every web server's do. They are used for security and diagnosis and nothing else, and they are kept for 90 days.

The postcode you type into the free preview is inside one of those URLs. The preview asks our own server a question of the form /preview/nearby/?postcode=...&radius=..., so for those ninety days the access log holds the postcode you asked about next to the network address it came from. We say that out loud rather than leave it inside the words "requested URLs", because the postcode is the one thing on that page a visitor might mind.

One other organisation is sent the postcode, and only sometimes. To put your area on the map we need that postcode's coordinates. We keep our own lookup table of them, and if yours is not already in it our server asks postcodes.io — a free, key-less public service built on Ordnance Survey's open Code-Point data — for it. What is sent is the postcode on its own, from our server: never your name, never your network address, never anything about who asked or why, and nothing at all if the postcode is already in our table, which most are because they came from the planning registers. The answer is then kept for good, because a postcode's coordinates do not move and asking a free service the same question twice would be rude. That row is a place rather than a person — a postcode, two numbers and the date we asked, with nothing recording who wanted to know — which is also why we have not treated the lookup as a transfer of your personal data under "Where it goes" below.

The preview is also rate-limited without identifying anybody. It stores a salted, irreversible hash of the caller's address — never the address itself — and rows older than two days are deleted. Salting with our own deployment secret means the table cannot be worked backwards into a list of visitors.

Lawful basis: our legitimate interests in keeping the service available and free from abuse, and in answering a visitor who has asked us what we hold near them.

The map, and why OpenStreetMap never sees you

The map on the public site is drawn on OpenStreetMap imagery, and the ordinary way to do that would send your browser to tile.openstreetmap.org — twenty or so requests every time the map moves, each one carrying your IP address and the coordinates of what you are looking at, to an organisation you have no relationship with.

We do not do it that way. Your browser only ever talks to us. Our own server fetches each square of the map once, keeps a copy, and serves that copy to everyone afterwards. What OpenStreetMap sees is our server asking for a picture of a place; it is never told who asked, and after the first time it is not asked again for a month. Nothing about you — not your address, not your postcode, not the fact that you looked — reaches them, which is why they are not in the list of processors below. The postcode itself is a different question with a different answer, and it is answered above: that does go to postcodes.io, which is in the list.

The map imagery is © OpenStreetMap contributors and the credit is on the page beside it, as their licence requires.

The lawful bases, in one place

We do not process special category data about customers (Article 9), and we do not knowingly hold data about children.

Who else sees it

Everyone on this list, and nobody else. Each is a processor acting on our instructions unless it says otherwise.

We are a small company, and the people with access to customer data are few. Staff access to an account is audited as described above.

Where it goes

Our database is on a server in the United Kingdom, in London, and the service reads and writes it there.

Three flows leave the UK. Our mail passes through a European data centre, so every email between us crosses it. Our second backup copy is held in a European (Amsterdam) data centre by Backblaze — the first copy stays in London. For both of those the UK recognises the EEA as providing an adequate level of protection. The AI drafting feature, if you use it, sends the brief to a provider in the United States. That transfer is made under the safeguards UK data protection law requires — an adequacy decision, or the ICO's International Data Transfer Agreement or Addendum.

Payment data is held by Stripe, which operates internationally under its own arrangements.

How long we keep it

The published retention policy at justgranted.co.uk/legal/retention/ is the approved timetable, and it is now the only one: the periods below were approved on 29 August 2026 and are in that policy, so what you read here and what you read there are the same thing said twice rather than two schedules that could drift apart. They are repeated here because a customer reading their own notice should not have to click through to find out how long we keep their invoices.

One honest caveat. Enforcement of the timetable is currently manual — no scheduled job prunes customer data on these dates yet, and the retention policy says the same about applicant data. When we delete, deletion is destruction rather than archival.

Your rights

You can:

Requests to hello@justgranted.co.uk. We respond within one month. There is no charge, and we do not ask for a reason.

You can also complain to the Information Commissioner's Office (ico.org.uk, 0303 123 1113). We would rather you told us first, but the route is yours and you do not have to come to us first.

Keeping it safe

The service is served only over HTTPS. Passwords are stored as salted one-way hashes. Session and CSRF cookies are marked HttpOnly and SameSite and are restricted to HTTPS in production. Access to customer data by our staff is limited to the people who need it, and acting as a customer's account is audited every time. Payment card data never reaches us at all.

Backups. The database and the files you upload are backed up every night, kept for a rolling fortnight, and copied to the two storage providers named above so that no single failure loses your record. The copies travel over HTTPS and are held in private buckets that only our server's keys can read. They are also encrypted by us, with our own keys, before they leave our server, so a copy taken out of either provider's storage is unreadable without a key neither provider holds. Backups are restored into a scratch copy and checked, so that "we have a backup" is something we have tested rather than something we assume.

No system is perfectly secure. If a breach ever puts your rights at risk, we will tell the ICO within 72 hours and tell you without undue delay.

Changes to this notice

We will change this notice when what we do changes — a new processor, a new category of data, a new purpose. Material changes are notified by email to account admins at least 14 days before they take effect. The date at the top of this document is the version you are reading.