Privacy policy

This notice covers VillageWatch, the community safety reporting service at villagewatch.app.

Every village has a data controller — the person or body that decides what VillageWatch is used for there and answers for it. Which one depends on how your village is run. Where a parish or town council has taken the village on, the council is the controller. Otherwise — and this is the ordinary case for a neighbourhood group — your village coordinator is the controller, and they have signed an agreement setting out what that obliges them to do. Either way, VillageWatchitself provides the software and processes data on the controller’s instructions.

Ask your coordinator which applies to your village if you are not sure; they are also who to ask for the contact details of a council that has taken it on.

When you create an account

• Your name and email address.
• Your village, and a join code if your coordinator gave you one.
• Optionally, your telephone number and street or address. The address is used by your coordinator to confirm you actually live in the village. It is never shown to other residents.
• Optionally, an approximate home location that you pin on a map. We shift the point you drop by up to 100 metres before saving it, and we never ask for your exact address on the map. It is used for one thing only: deciding whether an incident is close enough to be worth alerting you about.

When you ask for VillageWatch in a village we do not cover yet

The sign-up screen lets you say your village is not listed. This does not create an account — nothing is reported, nothing is shown to anybody, and you cannot sign in. What we keep is only what you typed on that form:

• Your name and email address.
• The village or town and the county you gave us.
• Whether you would be willing to coordinate the village, and — only if you said yes, and only if you chose to write one — a sentence about why you are interested.

We use it to tell you when your village goes live, and to work out where to set one up next. We do not use it for anything else and we do not pass it to anybody. Because there is no account, there is no screen where you can delete this yourself — so write to info@yakasista.com and we will remove it, or reply to the confirmation email, which goes to the same place. We keep it until your village launches or you ask us to remove it. See section 7.

When you file a report

• What you wrote, in your own words. This is kept separately from the version other residents see, and it is restricted to you, your village coordinators and moderators. Every single time one of them opens it, that is recorded with their name and the time.
• The anonymised version. A rewrite with names, registration plates, addresses and other identifying details removed. This is what appears on the map, in the incident list and in alerts.
• An approximate location. Every pin is moved by a random offset of up to 100 metres before it is saved. The exact point you tapped is never written to our database, so it cannot leak later.
• Photos and video, after redaction. See the next section — the originals stay on your device.
• The category, how serious you judged it, when it happened, any landmark you typed, and whether you have reported it to the police. Where the AI suggests a different level from yours and you accept it, both answers are kept, so your coordinator can see that the two differed.

While you use the service

• Your notification preferences: whether you want push alerts, the minimum severity worth disturbing you for, and how close an incident has to be.
• A record of privileged actions — publishing, rejecting, editing, exporting, confirming that a resident lives in the village, and every read of an original report — including who did it, when, and from what IP address and browser. This is the accountability trail. It cannot be edited or deleted, by anyone, including us.
• If you turn on push notifications, an anonymous device identifier held by our notification provider so that a message can reach your phone.
• Your votes on published reports.Every published report carries a thumbs up and a thumbs down, meaning “more serious than it looks” and “less”. We record which way you voted so that pressing the button again can take it back — so the record is linked to your account, not anonymous to us. Your neighbours only ever see the totals. See section 6.

We also do not collect any of the following:

• Your exact location, at any point. Not when you file, not in the background, not ever.
• Your precise home address on a map.
• Analytics, advertising identifiers, or any behavioural tracking. We run no third-party analytics and no advertising.
• Payment details. VillageWatch is free for residents and takes no payments.
• Special category data, deliberately. Reports sometimes touch on things like someone's health or ethnicity because a resident described what they saw — the anonymisation pass exists to take that out, and coordinators are asked to reject anything that survives it.

Running your account — contract, Article 6(1)(b)

We need your name, email and village to give you an account, put your reports in the right place and let you sign in.

Community safety reporting — legitimate interests, Article 6(1)(f)

Keeping the people who live somewhere informed about local safety is a legitimate interest, shared by the residents, the controller and the local policing team. This covers publishing anonymised reports, showing them on the map and alerting nearby residents. We have carried out and documented the balancing test this basis requires, and the mitigations it turns on are the ones described on this page: your original wording is never published, map positions are shifted, and faces are covered before a photograph leaves your device. This is the basis in the ordinary case, where your village coordinator is the controller.

Where a council runs your village — public task, Article 6(1)(e)

A parish or town council keeping its residents informed about local safety is also exercising a function in the public interest, and a council that has taken your village on may rely on that instead for the same processing. It changes nothing about what is collected, who sees it, how long it is kept, or your right to object to it — see “Objection” in section 8, which covers both bases.

Push notifications — consent, Article 6(1)(a)

Alerts only go to residents who have switched them on and granted their browser permission. You can withdraw that at any time in Settings, or in your browser, without affecting anything else.

Telling you when your village launches — legitimate interests, Article 6(1)(f)

If you registered interest in a village we do not cover, we keep your details to tell you when it goes live and to decide where to set one up next. You asked us to get in touch, it is the only thing we use it for, and one email address is the least we could keep and still do it. Who is responsible for this is not your village’s data controller — there is no village yet, so it is Yakasista Ltd, the company that runs VillageWatch, and section 13 is where to write. Asking to be removed takes one email and we will not ask you why.

Moderation and the audit trail — legal obligation and legitimate interests, Article 6(1)(c) and (f)

Reviewing reports before publication is what stops personal details reaching a few hundred neighbours. Logging who read an original report is what makes that promise checkable.

Reports frequently describe suspected criminal offences. Personal data about criminal offences has extra protection under Article 10 of the UK GDPR and Schedule 1 of the Data Protection Act 2018. This is precisely why the original wording of a report is restricted to coordinators, audited on every read, and never published — what residents see is the version with the identifying details taken out.

When you file a report, the text you wrote — and a still frame from a photo, if you attached one and its faces have already been covered — is sent to Anthropic, the company behind the Claude AI models, and processed on their servers. Claude rewrites the report with identifying details removed, suggests a category and a severity — with one sentence saying why it chose that level — and pulls out a few keywords.

• You see the result before anyone else does. The rewrite comes back to your screen for you to read, edit or reject. Nothing is saved until you press publish.
• It is not a decision about you.There is no automated decision-making with legal or similarly significant effects, in the sense of Article 22. The rewrite is shown to you before anything is saved, and nothing is published unless you accept it — the AI's judgement is advice, never the last word.
• Whether a coordinator reads it first is your village's choice.By default every report waits in a moderation queue until a coordinator approves it, and that is what the screens tell you as you file. A village's coordinators can switch that off, in which case reports are published the moment you press publish and you are told so on the screen before you do. Either way the anonymised text is what other residents see, and your original wording stays restricted to you, your coordinators and moderators.
• If it is unavailable, nothing breaks. Reports filed when the AI cannot be reached use your own wording, and the screen says so — including a warning that they will be published as written if your village has turned review off.
• Anthropic processes this data as a processor on our behalf, under their commercial terms, and does not use it to train their models.

The AI is a filter, not a guarantee. Assume a coordinator will read your original words, and write your report as though the person you are describing might one day read the published version.

We do not sell your data and we do not share it for marketing. It is shared only with the following:

Other residents of your village

The anonymised report, its category, severity, approximate location and any redacted photos. Never your name— there is no screen a resident can open that puts the person who filed a report against it, whether or not you filed anonymously. Never your original wording, your address, your email or your home location.

Your village coordinators and moderators

Everything above, plus your original wording — recorded each time — and your name against the report, including one you filed anonymously. Filing anonymously keeps your name from other residents; it does not keep it from the person who decides whether your report is published, because somebody has to be able to account for what the village is shown. They also see the village’s membership list: your name, when you joined, how many of your reports are on the map, and your email address — which is shown partly hidden, as “j***@example.com”, until they ask for it. That is how a coordinator confirms the people on the map are the neighbours they think they are; confirming you, or withdrawing that, is recorded in the trail above.

Anyone, if your coordinator posts an alert somewhere public

Once a report is published, your village coordinator can post an alert about it to your village’s WhatsApp Channel — public to anyone holding the invite link, in or out of the village — or share it to Facebook, where a post is public. Nothing is posted automatically. Neither service gives an app a way to write on somebody’s behalf, so a coordinator copies the alert and posts it themselves, which means a person makes the decision each time. An alert carries a headline, an approximate area, how long ago it happened, a short extract of the same report your neighbours see, and a link back to this app. Never your name, never the coordinates, and never a photograph. A WhatsApp Channel is switched off unless your coordinator sets one up; sharing to Facebook needs no setting, so on a published report it is always one of the options in front of them.

Anyone, if your coordinator posts the village's week

Your coordinator can also copy a weekly summary of the village and post it wherever the village already talks to itself, which for most villages is a Facebook page or group and is public. It lists each report published that week as three things: how serious it was, what kind of thing it was, and the approximate area — the landmark you named, not an address. It carries no description at all— not even the anonymised one your neighbours read — and no link to any individual report. Alongside the list it carries the week’s count, how that compares with the week before, and a link for joining the village. Nothing is posted automatically, and a report only appears in it if it was already published on the village map.

Anyone given a link to a published report

Every published report has a preview page that opens without an account, so that a link shared with your village actually shows something to a neighbour who has not joined yet. It carries the category, how serious it was, roughly when it happened, which village, and the first line or so of the same anonymised description your neighbours see — about a hundred characters, cut off mid-sentence. Never the rest of it, never the landmark or the map location, never a photograph, and never your name. Reading the report itself still needs an account in your village. The page is not listed in search engines and its address cannot be guessed, so in practice it is visible to whoever was handed the link — which, for a report your coordinator has shared publicly, is the same audience as the alert above, and a shorter extract than the alert carries.

Your local police officer, in a summary from a coordinator

Your village coordinator can produce a written summary — of one report, or of everything published over a period — and send it to your PCSO, or to a parish or town council where one runs your village, or keep it for the group’s own records. This is what a neighbourhood watch scheme is for, and it is the same information your neighbours already see: the anonymised description, the category, how serious it was, when it happened and the landmark the reporter named. Never your original wording, never your name or contact details, never the map coordinates, and never a photograph. A summary covering a period is recorded in your village’s audit trail. A single report’s summary is the same text already on the village map, so it is not recorded separately.

Nobody, in the case of how you voted on a report

The totals are shown to everyone in your village and to your coordinator — “four residents rated this more serious than it looks” — and they can appear in a summary a coordinator sends to your PCSO. Who voted which way is shown to nobody: there is no screen in this service, for a resident or a coordinator, that puts a name against a vote. Your coordinator can reach the underlying records, in the same way they can already read original report wording, and nothing displays them. Your vote goes when you take it back, when you close your account, and when the report itself is deleted.

The police, on request

Separately from the above: where there is a lawful basis to disclose, such as a formal request in the investigation of a crime. That can include your original wording. Your village’s data controller decides this, not VillageWatch, and the disclosure is logged.

The people who run this service

We keep an internal staff channel on Slack that is told when somebody registers, when a report is published, and when somebody applies to become a coordinator. It carries your name, and on registration your email address, so that the people running VillageWatch can see the service is working and spot abuse. For a published report it carries the same headline, severity and approximate area your neighbours see — never your original wording, never your address, never coordinates, and never a photograph. The same channel also receives alerts about the service itself — whether a scheduled job ran, and a note when a page or a request fails. Those carry nothing about you: a count, the name of the job or the address of the page that failed, and a reference number for the engineer. Never your data, and never anything that would identify you.

Our processors

Supabase (database, authentication and file storage, in the UK or EU), Vercel (hosting), Anthropic (the AI pass described above), OneSignal (push notification delivery), Resend (email delivery — see below), Sentry (fault reporting — see below), and Slack (the staff channel above). Each acts only on our instructions, under a written data processing agreement in every case but Slack — see below.

Resend, which delivers our email

Your email address, your first name and your village’s name, so that the message can be addressed and sent. Four kinds of email go out. The sign-up confirmation and password reset links, which are sent when you ask for them. A welcome message when you join a village, which explains what happens to a report once you file one. An alert when a report is published in your village, if you have asked for those — it carries the published description, which is the same anonymised text your neighbours can already read on the map, and never the reporter’s original wording, never an address, never coordinates and never a photograph. And, for coordinators only, a weekly summary of what their village published. We send no marketing.

Sentry, which records faults in the software

When something in VillageWatch goes wrong — a page that fails to load, a report that will not save — a description of the fault is sent to Sentry so that it can be found and fixed. That description is the error the software produced, the part of the code it happened in, which page or request was involved, and your browser and operating system. It does not include your sign-in cookie, anything you typed into a form, anything in the address bar after a question mark, or any reference to your account.

One thing we would rather tell you than have you find. An error message is written by the software at the moment something breaks, and it can quote whatever it was working on at the time — so if a report fails to save, part of what you typed may appear in the fault report. We cannot prevent that and still record faults usefully. These reports are visible only to the people maintaining VillageWatch, they are deleted after 90 days, and they are never used to look at what anybody reported.

Sentry stores this in Frankfurt, Germany, not in the United Kingdom. The UK recognises the European Economic Area as giving personal data the same protection it has here, so no extra safeguards are required for it — and we chose Sentry’s European service over its American one for that reason.

The one image in an email

Every email we send carries our logo, and your email program fetches it from villagewatch.appwhen it opens the message. That request tells our server your internet address and the fact that the message was opened. It is our own address, not a third party’s, and it is the only thing an email loads — there is no tracking pixel, no link that reports back, and nothing anywhere that reads those requests to work out who opened what. Most email programs block remote images until you allow them, and the message reads correctly either way.

Choosing whether we email you

Village alerts by email are a setting, sitting beside the one for notifications on your phone. The two are independent — you can have either, both or neither — and the same choices about how serious an incident has to be, and how close to your home, apply to both. Turn either off at any time in your settings. Two kinds of message are not covered by that switch and will still reach you: the confirmation and password links you ask for, and messages about something you did yourself — joining a village, or a decision on an application you made.

Slack (Salesforce), and why it is listed separately

Administrative notifications only, to a private channel that only the people who run VillageWatchcan read. It is never used to deliver anything to a resident and no part of this service depends on it. What a message carries is an anonymised incident summary — the same headline, severity and approximate area published to your village — or the fact that somebody has registered, applied to coordinate, or been given coordinator access. Never your original wording, never your address, never coordinates, and never a photograph. It does carry your name, and on registration your email address, so that abuse can be spotted; nothing else about you is sent. We have no separate data processing agreement with Salesforce beyond Slack’s standard terms, which is why this is set out here rather than left inside the list above. If you would rather this disclosure did not happen at all, tell us using the contact details in section 13 and we will act on it.

Map tiles come from OpenStreetMap and are fetched by your browser directly, so their servers see your IP address as they would for any website you visit. No report data is sent with those requests.

VillageWatchalso shows the official recorded-crime figures the Home Office publishes for your area, so that your village’s own reports can be read against an independent number. Those figures are fetched by our servers from data.police.uk, and nothing about you is sent to get them — the request carries your village’s map centre and a calendar month, and nothing else. No report, no account, no location of yours and not your IP address. What comes back is open data published under the Open Government Licence, in which every crime has already been anonymised by the police to a point “on or near” a street rather than an address.

If your village has turned them on, VillageWatchalso shows the public bulletins your police force and local watch schemes publish through Neighbourhood Alert — scam warnings, appeals for information, notices of local meetings. Those are fetched by our servers, and nothing about you is sent to get them: the request carries a single number identifying your force’s alert website and nothing else. No report, no account, no location of yours and not your IP address. What comes back is a bulletin already published to anyone who subscribes to that force’s alerts, and we store a short extract of it with a link to the original. These are published for a whole force or scheme area rather than for your village, and they are not reports made by anyone here.

Some of our processors operate outside the UK. Where data is transferred, it is protected by the UK International Data Transfer Addendum or an adequacy decision.

Interest in a village we do not cover — until it launches

If you asked us to bring VillageWatch to your village, we keep your name, email address and the village you named until that village launches, or until you ask us to remove them — whichever comes first. There is no account behind this and so no screen to delete it from: write to info@yakasista.com, or reply to the confirmation email we sent you.

Photos and video — 6 months

Deleted from storage entirely, redacted copies included. A photo is the most identifying thing in a report and the least useful once the incident is old.

Reports — archived at 12 months

Archived reports leave the map and the incident list. They are not deleted: the record is kept for the pattern history a village needs to see year-on-year trends.

Original report wording — deleted at 12 months

Your original wording is deleted twelve months after you file it, in the same overnight step that archives the report and takes it off the map. That is twelve months from filing however the report got there — if a coordinator archives it sooner, the wording still goes at twelve months and not before. Until then it stays with the report, restricted to your coordinators, and every single read of it is recorded in the audit trail. You do not have to wait: delete the report, or close your account, and it goes immediately, along with the photos. One thing to know — if the rewrite described in section 4 did not run on your report, the published description is your own wording, and that is the report itself rather than a restricted copy of it, so it stays with the archived record.

Votes on reports — until the report goes

How you voted is kept while the report is. It goes when you take the vote back, when the report is deleted by the person who filed it, and when you close your own account — in that last case, every vote you have ever cast, on every report.

Audit records — 24 months

Kept longer than the reports they describe, because their whole purpose is to show, afterwards, who looked at what.

Inactive accounts — 24 months

An account with no sign-in for two years is closed and its personal details removed. Reports already published stay up, detached from the account.

Accounts you close yourself — immediately

Closing your own account from Settings does not wait for any of the periods above. Every report you filed is deleted there and then, the photos are removed from storage, and your name, address, phone number and approximate home location are erased from your profile. Your email address is kept, because it is what stops the closed account being signed into again.

Under the UK GDPR you have the following rights. To use any of them, contact your village’s data controller — your coordinator, or the council if one has taken the village on; section 1 explains which — using the details in section 13. They must respond within one month, and it is free.

Access

Ask for a copy of the personal data we hold about you, including your reports in their original wording and the record of who has read them.

Rectification

Have inaccurate details corrected. You can edit your own report yourself, in the app, at any point before a coordinator has reviewed it.

Erasure

Ask for your data to be deleted — and you do not have to ask us. Any report you have filed has a Delete button on its own page, whatever stage it has reached, published included; and Settings has a Delete my account option that does the same to every report you have ever filed and closes the account. Both act immediately. Deleting a report removes its wording, its location and any photos or video, and takes it off the map; the photos are deleted from our storage, not merely hidden. What is left is the reference, the category, how serious it was and the date — a report the village can still count without a word of what you wrote. Audit records cannot be deleted: they are the accountability trail, and a trail that can be erased on request is not one. They record what a coordinator decided about a report, not what the report said.

Portability

Receive the data you gave us in a structured, machine-readable format, or have it sent to another controller.

Objection

Object to processing carried out under our public task or legitimate interests. Tell us why it affects you, and we will stop unless we can show compelling grounds that override your interests.

Restriction

Ask us to hold your data but stop using it, for example while a complaint about its accuracy is being resolved.

Withdraw consent

Turn push notifications off in Settings at any time. Withdrawing does not affect anything done before you withdrew.

You must be at least 16 to hold a VillageWatchaccount. We do not knowingly create accounts for anyone younger, and we do not ask for anyone's date of birth beyond that confirmation.

Reports frequently mention young people — a group causing a nuisance, a missing teenager, someone seen near a shed. That is legitimate and the service is built for it, with three safeguards:

• The anonymisation pass removes names, schools, and descriptions distinctive enough to identify one particular child.
• Faces are covered before any photo is uploaded, at every setting a village can choose, so a photograph of a child cannot be published even by mistake.
• Coordinators are asked to reject any report that names or clearly identifies a child, and to route safeguarding concerns to the police or to children's services rather than onto a village map.

If you believe a published report identifies a child, contact your coordinator and it will be removed while it is reviewed. If a parent or guardian asks us to remove data about their child, we will do so.

• Everything is served over HTTPS, and the browser is instructed never to use anything else.
• Your village is a hard boundary. Every query for reports, residents and alerts is scoped to it, and that scope comes from your session on our servers — never from anything a browser sends.
• Original report wording sits behind a deliberate action that records who read it, rather than being loaded onto a page where a glance leaves no trace.
• Passwords are handled by Supabase Auth and are never stored by us in any form we can read.
• The database enforces access rules of its own, underneath the application, so a bug in one screen cannot expose another village's reports.

If a breach occurs that is likely to risk your rights and freedoms, we will report it to the ICO within 72 hours and tell you directly where the risk is high.

VillageWatch sets only strictly necessary cookies: the ones that keep you signed in and protect the sign-in form. There are no analytics cookies, no advertising cookies, and nothing that follows you to other sites — which is why you have not been asked to accept anything.

We will update this page when what we do changes, and the date at the top will change with it. Where a change materially affects you — a new processor, a new purpose, a shorter or longer retention period — we will tell you in the app before it takes effect.

For anything in this policy, including a request to exercise your rights, contact your village’s data controller. If your coordinator is the controller — the ordinary case — they are who to ask. Where no village-specific controller has been named, write to info@yakasista.com or to the address in section 1, and Yakasista Ltd will identify the controller for your village and pass your request to them.

If you are not satisfied with the response, you can complain to the Information Commissioner's Office, the UK's data protection regulator, at ico.org.uk/make-a-complaint or on 0303 123 1113. We would rather you came to us first, but you do not have to.

See also our terms of use, which cover what may and may not be posted.