Privacy Policy

1. How this handbook is arranged

Sections 5 to 8 walk the four stations in the order a working day meets them. Everything before those sections tells you who we are and which hat we wear; everything after them covers the housekeeping that applies across all four — sensitive notes, keys, distance, shelf life, lock-up, mishaps and the things you are entitled to ask of us.

The handbook covers the pages at venuebooker.co, the demo requests and enquiries that arrive through them, the VenueBooker booking and operations service, the operator apps for iOS and Android, and the ordinary business correspondence that surrounds all of it.

Five sorts of reader will find themselves in here. Venue teams — hall committees, club secretaries, community-centre managers, duty managers at function rooms — will want section 6 and section 8. Anyone who has written to us or asked for a demo wants section 5. Anyone who simply hired a room from a venue that runs on our software should turn to section 4 first. Suppliers and business contacts are covered at section 8. And anyone doing procurement diligence should read the whole thing and then write to us with the gaps.

Read it beside our Terms of Service, whose Part C carries the processor obligations in contract form, and our Cookie Policy. Where a venue has signed an order form or a separate data processing agreement with us, that paperwork governs its own hirers’ records and takes precedence over anything general said here.

2. The name above the door

2.1 Who is answerable

• VENUEBOOKER SOLUTIONS LTD, a company incorporated in Northern Ireland under number NI737741
• Correspondence: bookings@venuebooker.co

VenueBooker is the trading name that company operates under. No parent, subsidiary or sister company shares in what we hold. Accountability for data protection rests with the directors, who have not handed it to a committee or a consultancy. Anything to do with privacy — a question, a request to see or correct a record, a complaint, a report that something has leaked, a written instruction from a venue — should be addressed to the mailbox above, which is read on working days and reaches a director. Post can be sent to the registered office and marked for the attention of Data Protection.

2.2 A Data Protection Officer

Article 37 of the UK GDPR reserves the mandatory appointment of a Data Protection Officer for three situations: public authorities, organisations whose core work involves monitoring people regularly and systematically on a large scale, and organisations processing special category or criminal offence records on a large scale. Selling booking software to venue businesses is none of those, so the role is not mandatory for us and the directors carry the responsibility directly. Should the shape of the business change enough to bring us inside Article 37, the appointment will be named on this page.

2.3 The register, and where we are established

Under the Data Protection (Charges and Information) Regulations 2018 most controllers owe the Information Commissioner an annual fee and an entry on the public register. We pay it where the Regulations apply that duty to us, and the entry number goes on this page as soon as it can be looked up publicly at ico.org.uk; ask us by email if a supplier form needs it sooner. The company is established in the United Kingdom, answers to the UK GDPR and the Data Protection Act 2018, and has no processing footprint requiring a representative under Article 27.

3. Two sets of keys

3.1 The distinction, in plain terms

A controller is whoever decides that a record should exist and what it is for. That decision brings duties: pick a lawful basis, tell people what is happening, answer to them, answer to the regulator. A processor is whoever handles the record on the controller’s written say-so and may not repurpose it. A processor still owes obligations of its own on security, on who it brings in behind it, and on reporting trouble upward — but it does not get to decide what the record is for. A single company can hold both roles over different piles of data. Ours does, and nearly every paragraph below traces back to which key is in the lock.

3.2 Where the decisions are ours

We are the controller for: the details of the people who administer a venue workspace; demo requests; enquiries and support threads; what the web server sees of a visit; billing and accounting records; product telemetry and crash diagnostics; supplier and business contacts; and any product email somebody has asked to receive. Security and audit logging is ours as controller too, even when the events being logged sit around a venue’s own bookings.

3.3 Where the decisions are the venue’s

We are the processor for everything a venue records about the people who hire from it — who booked, how to reach them, what the event is, what has been paid, and the operational notes attached to the run sheet, including any access or catering requirement written into it. Section 6 itemises the lot. Those records exist to run that venue’s bookings and nothing else: we do not trade them, we do not mine them for our own ends, and we never market to a venue’s hirers.

3.4 What that means for a venue team

Your hirers’ records are yours to answer for. In practice that means settling on your own lawful basis — normally Article 6(1)(b) because you are performing the hire agreement, or Article 6(1)(f) for enquiries that never turn into a booking; publishing a privacy notice of your own that names you, describes what you do with a hirer’s details, and mentions that a software supplier holds them for you; dealing with requests from your hirers, with whatever help from us the request needs (16.10); keeping run-sheet notes to what the evening genuinely requires; and holding an Article 9 condition wherever you write down something about somebody’s health, mobility or diet. Your bookings are your business and we will not second-guess them. We will, however, decline an instruction we believe would put us or you on the wrong side of the law, and we will explain our reasoning rather than simply refusing.

4. If you hired a room and ended up here

4.1 We built the software, not the venue

If you have found this page after booking a hall, a pitch, a studio or a function room, the important thing to know is that we are the supplier standing behind the venue’s diary. We did not take your booking, we do not set the hire fee or the cancellation window, we hold none of your money, and we cannot let you into the building. The venue is answerable for your details; we merely keep them for the venue.

4.2 What the entry usually contains

Expect a name, one way of reaching you, the space and the hours booked, roughly what the occasion is, how many people are coming, whether a deposit has cleared, and whatever the venue has typed into the notes — a reminder that somebody needs a step-free route in, perhaps, or that one of your party cannot go near nuts. What goes into that entry is the venue’s call; our software stores it and puts it in front of the staff working that evening. It is not sold, it does not feed advertising, it is not matched up across venues, and it produces no marketing from us. Any message you receive about the booking is the venue writing to you, carried by our software.

4.3 Where to take a question

Start with the venue. Being the controller, they can show you the entry, put a mistake right, remove it where removal is allowed, and tell you their own timescales. Should you write to us instead, we will not hand over or wipe a customer’s record on the word of somebody who is not that customer — doing so would be reckless and would break the contract we hold with them. What we will do is reply, tell the venue you have been in touch, and support them in getting you an answer. If you have already tried the venue and got nowhere, the Information Commissioner will hear a complaint about the venue (section 17). If you think the fault lies with the software rather than with how the venue behaved, tell us and we will look into it as a supplier matter.

4.4 Youth activities

A great many of the buildings we serve give their evenings over to scouts, junior teams, dance schools and toddler groups, so children turn up in booking records as a matter of course. Section 10 deals with that squarely.

5. The door — enquiries, demo requests, visitors

The first station is arrival: somebody writes in, somebody asks to be shown the software, somebody loads a page. Wherever the table below leans on legitimate interests, we name the interest and confirm that a balancing exercise was written down — a considered weighing of what we want against what the person would reasonably expect and be comfortable with.

Nothing at this station is bought in. We purchase no contact lists, append nothing from third-party datasets, and draw no inferences about anybody’s income, household or interests.

6. The diary — bookings we hold for a venue

The second station is the book itself. Everything in this section belongs to a venue, which is its controller; our role throughout is processor. A venue’s own notice, not this handbook, is what its hirers are entitled to be given. We publish the detail so that venues can complete their Article 30 records without having to interrogate us for it.

6.1 What we undertake as processor

• To act on the venue’s documented instructions and nothing else, transfers included, unless UK law compels us otherwise — in which case the venue hears from us first, unless telling them is itself forbidden.
• To place everybody with access under a duty of confidence, and to run the measures described at section 14.
• To bring in a sub-processor only under a written contract carrying obligations equivalent to ours, with the notice described at 11.3.
• To help with requests from hirers, with security duties, with reporting a mishap, and with impact assessments.
• To hand back or destroy the records when the relationship ends, per 13.3, and to supply whatever a venue needs in order to show a regulator that its house is in order.

7. The till — deposits, balances and the ledger

7.1 Whose money is whose

We are not a payment institution and no client money passes through us. What a venue pays us: a subscription bought inside one of our apps is billed by Apple or by Google under their own store arrangements and settled onward to us; a subscription arranged directly with us is collected by a third-party payment provider. What a hirer pays a venue: deposits and balances are handled by a payment provider and land in the venue’s own bank account, under the venue’s own agreement with that provider. The money never sits with us in between.

7.2 The card never reaches this side of the counter

7.3 The provider, and the metadata that stays behind

A payment provider authorised by the Financial Conduct Authority is engaged before online payment is offered, named in section 11, and everyone we correspond with hears from us before anybody can be charged through us. What follows is the record kept once money moves.

7.4 Why six years, and a word on fraud

Section 388 of the Companies Act 2006, together with HMRC’s record-keeping rules, requires adequate accounting records to be preserved. Six years from the close of the relevant financial year is the line we work to, and it happens to sit alongside the ordinary limitation period for a contract claim in Northern Ireland. That duty arrives under Article 6(1)(c), and it outlives both account closure and a request for erasure — a lawful accounting entry cannot be struck out because somebody asks, and we will say as much rather than pretend otherwise. Separately, transaction data may be examined by us and by the payment provider to head off fraud, an interest Recital 47 acknowledges in terms, resting on Article 6(1)(f). Nothing in that involves an automated decision carrying legal or comparably serious consequences (16.8).

7.5 What the numbers are turned into

A venue can look at its own trading: hours filled by day and by space, income per room, how many deposits convert, how often a booking falls through, who comes back. Every one of those figures is built from that venue’s own book, shown to that venue’s own people, and processed by us as processor — and a report that names a hirer is still a record about a person. Across customers we work only from aggregate counts: free text is excluded, so are names and contact details, and so is every access or dietary note; minimum group sizes are applied so no figure can be walked back to a single venue or a single evening; and nothing venue-identifiable is published, sold or used for benchmarking.

Aggregate figures that are genuinely anonymous may be kept without a time limit. Booking records, hirer details and run-sheet content are not sent to third-party artificial-intelligence services for model training, and no provider we use is permitted to train on them. Should we build a feature that leans on such a service, it will be described here, with a clear statement of what leaves our infrastructure, before it goes anywhere near a live venue.

8. The office — accounts, logins and correspondence

The fourth station is the back room: who has a login, who signed what, what the servers noticed, and which suppliers we deal with. All of it is ours as controller.

9. The locked drawer — sensitive notes

9.1 On our own account, we do not go looking

For accounts, enquiries, billing, support and the website we have no use for the categories Article 9 protects — racial or ethnic origin, political opinion, religious or philosophical belief, trade union membership, genetic or biometric identifiers, health, sex life, sexual orientation — nor for the criminal offence material Article 10 covers, and we never ask for any of it. Should you mention something of that kind unprompted, perhaps explaining a health problem in a support email, it is used to deal with the message in front of us, it joins no profile, and it is taken out again wherever we sensibly can. It is better not to put sensitive detail into a support thread at all unless the issue genuinely turns on it.

9.2 On a venue’s account, it turns up and must be handled properly

Here the position is different, because run sheets exist precisely so that an evening goes safely. “Wheelchair user — bring them in by the side door” and “severe nut allergy in this group” are both statements about somebody’s health. The venue is the controller and must settle on an Article 9(2) condition, which in practice means Art. 9(2)(a) — explicit consent given to the venue — or, in a narrow emergency, Art. 9(2)(c) vital interests. Where the condition chosen requires it, the venue also needs a matching provision in Schedule 1 to the Data Protection Act 2018: usually the health and social care paragraphs of Part 2, or paragraph 5 of Part 2 where an access requirement is recorded to secure equality of opportunity or treatment. Relying on a Schedule 1 condition brings with it the appropriate policy document required by paragraph 1 of Part 4 of that Schedule. On our side these fields are encrypted where they rest, confined to the staff a venue has authorised, kept out of every cross-customer figure and out of any support export unless somebody expressly asks for them; they are optional fields, and the interface is written to invite a short operational note rather than a medical history.

9.3 Convictions, and sensitive material sent in error

Article 10 material may only be handled under official authority, or where the law authorises it with proper safeguards — for most organisations that means a condition in Parts 1 to 3 of Schedule 1, most often paragraph 18, which covers safeguarding children and individuals at risk. There is no vetting or DBS module in VenueBooker, and we ask venues not to press free-text fields into service as a store of criminal record information. Where a venue does need to note that an AccessNI or DBS check has been sighted, note the fact and the date and leave the content out of it. If sensitive material lands with us by accident, write to bookings@venuebooker.co: we will shut access down, remove it wherever the law lets us, tell you what was done, and log the episode so we can see whether our own interface invited the error.

10. Children through the door

10.1 The tool is for adults; the buildings are full of children

VenueBooker is business software. Logins belong to venue teams, the website and the apps are not aimed at children, they carry nothing designed to attract a child, and they carry no advertising whatsoever. That said, the halls we serve are exactly where childhood happens — scout huts, junior football and GAA, dance classes, toddler mornings, Sunday school, birthday parties. Most of the time the involvement is at one remove: an adult hires the hall for a children’s activity and no child is named anywhere. Occasionally it is direct — a child’s name on a party booking, a named junior squad, an access requirement written down for a particular child. Saying so plainly seems better than pretending a venue diary never touches a child’s life.

10.2 The venue is in charge of it

Where a booking record concerns a child, the venue needs a lawful basis; where it relies on consent for an information society service offered directly to a child under thirteen, that consent must come from somebody holding parental responsibility, under section 9 of the Data Protection Act 2018. The venue should also write a notice a parent or an older child can actually follow, apply the Information Commissioner’s Age Appropriate Design Code to any online service of its own likely to be reached by children, hold no more than the activity calls for — a first name and an emergency number, not a biography — and clear the record out once the activity finishes.

10.3 Our part in it

A child’s details sit behind exactly the same technical controls as every other booking record, and are excluded from every cross-customer figure. Booking data is never turned to marketing, profiling or advertising, and there is no advertising SDK anywhere in what we ship. We do not process a child’s details for any purpose of our own, and a venue request concerning a child goes to the front of the queue. Should you believe a child has given personal details directly to VenueBooker, tell us: it will be removed promptly and we will write back to confirm, without putting you through a formal request or asking you to prove who you are.

11. Who else holds a key

11.1 The rule, and the list

A key goes only to an organisation that needs one to keep the service running, that has signed a written contract carrying what Article 28(3) requires, and that has come through our own checks. Advertisers and data brokers get nothing. Personal data is not for sale here, and that will not change.

11.2 Other occasions we hand something over

Records leave us where the law compels it — to a court, a regulator, a law enforcement body or HMRC on a valid legal requirement, once we have satisfied ourselves the demand is lawful and proportionate, releasing only what is actually required, and telling the affected customer unless we are forbidden to. They also go to insurers and advisers where a legal claim has to be brought or defended. And on a sale of the business or its assets, diligence disclosure would be kept narrow and covered by confidentiality, this handbook or something no less protective would continue to apply afterwards, and affected customers would hear from us.

11.3 Telling venues before a key changes hands

No new category of recipient is added without this page being amended first. Where we hold the processor role we go further and commit to at least thirty days’ written notice before a sub-processor is appointed or swapped, sent by email to the workspace’s administrative contact and posted here at the same time; to hearing an objection made on reasonable data protection grounds inside that window; and, where an objection cannot be worked through, to letting the affected part of the service be terminated without penalty, with an export taken first. Ask at bookings@venuebooker.co to be added to that notification list. Before any provider is appointed we look at the security measures it can evidence, its certifications, where data would live, which transfer route it relies on, what it promises about reporting a breach, who it uses behind itself and how it deletes; that assessment is written down and revisited whenever terms change materially.

12. Keys that travel abroad

12.1 Our preference, and the routes open to us

Left to ourselves we keep records in the United Kingdom or the EEA, and we pin storage to UK or EU regions whenever a provider offers the choice. Several providers are nonetheless global businesses with United States parents, so some movement across borders cannot be designed away. Chapter V of the UK GDPR allows a transfer only along a defined route, and these are the ones that bear on us:

• Adequacy regulations made for the UK under Article 45 — covering the EEA and the other listed countries, and covering United States organisations certified under the UK Extension to the EU–US Data Privacy Framework, to the extent their certification reaches the data in question.
• The UK International Data Transfer Agreement under Article 46 — the Information Commissioner’s own standalone instrument, which we use where we contract directly with the importer and no adequacy route is available.
• The UK Addendum to the EU Standard Contractual Clauses, also Article 46 — used where a provider’s processing addendum is already built on the EU clauses, which is the usual position with the larger suppliers.
• The Article 49 derogations — for an occasional, non-repeating transfer needed to perform a contract or to pursue a legal claim. These are for the exception, never a way of running something routine.

12.2 Which route covers what

12.3 Risk assessments, and transfers made as processor

Neither the IDTA nor the Addendum does the job on its own. Before leaning on either we work through a transfer risk assessment: how sensitive the records are; what the destination’s law says about state access and about what redress an individual could actually obtain there; whether that law would hollow out the contractual protection; and which supplementary measures would bring the risk back down — in our case chiefly encryption in flight and at rest, sending as little across the border as the function permits, and the provider’s own record of resisting government demands. Each assessment is documented, revisited when the picture changes, and a transfer will be halted if the protection cannot be held up. Acting as processor, customer records move only through the recipients listed at section 11; this handbook and our processor terms together constitute the customer’s documented instruction for those movements. Ask us about the safeguards behind a particular transfer and you will get them, redacted only where commercial confidence genuinely requires it.

13. Retention — how long the book stays on the shelf

Nothing is held for longer than its purpose lasts, unless a statute says otherwise. The retention periods below are the ones we actually work to, station by station. Where the table reads “the venue decides”, we are holding the record as processor and the choice is not ours to make.

13.1 The retention schedule

13.2 What deletion actually does

Deleting a record takes it out of the live systems and puts it beyond reach through the product. Encrypted backups run on a rotation and are not edited selectively, because picking items out of a backup destroys the integrity of the thing; a deleted record can therefore survive inside a backup for up to thirty-five days, at which point that backup expires. Through that window the record is not reachable in the ordinary course and would surface again only if we had to restore from disaster, after which outstanding deletions are re-applied.

13.3 When a venue leaves

On termination the workspace goes read-only and the venue has thirty days to take its data out as a structured file in a common, machine-readable format. We then remove the workspace from live systems within a further thirty days. A venue can ask us to move faster, or to return the data and then destroy it; either way we confirm in writing once it is done. What stays behind is only what a statute requires — in practice the accounting record — plus the slimmest possible suppression entry. This retention schedule is reviewed at least once a year.

14. Lock-up

The standard Article 32 sets is security proportionate to the risk. What follows is the state of the building, not a prospectus.

14.1 Encryption, and keeping venues apart

• On the wire: TLS at version 1.2 or better with current cipher suites, plain HTTP redirected upward, and Strict Transport Security so that a browser will not accept a downgrade.
• Where it rests: platform-managed AES-256 across databases, object storage and every backup we take.
• Credentials: passwords survive only as salted hashes produced by a modern memory-hard algorithm, which is why nobody here can read yours back to you. Keys and secrets live in a secrets store rather than in source code, and are rotated whenever somebody with access moves on.
• Separation: every row carries the identifier of the workspace it belongs to, and every query is narrowed to the signed-in user’s workspace down at the data-access layer — so a request cannot surface another venue’s diary even when a layer above it has a bug. Automated tests exercise that boundary on every change.

14.2 Who gets in, what gets logged, and backups

Production access is held by the smallest number of people who genuinely need it, granted by role, reviewed at least twice a year and immediately when somebody changes role or leaves; administrative access requires a second factor. Customer content is not ours to read. Reaching into a workspace for support requires that customer to ask, is time-boxed, and is written to a log the customer can request. Inside a workspace it is the venue’s administrators who decide which of their staff can see contact details, payment status or run-sheet notes. We record authentication, permission changes, exports and administrative actions for twelve months, written deliberately so that they hold no credentials, no card data and no run-sheet content, and we alert on error-rate spikes and on patterns of failed sign-ins. Backups are automatic and encrypted, and restores are rehearsed rather than assumed.

14.3 How the software is built, and who builds it

• Changes are reviewed by a second pair of eyes, and nothing reaches production straight off a laptop. Production, staging and development are kept apart, and live personal data is never copied down into development — test fixtures are invented.
• Dependencies are watched for known vulnerabilities and patched quickly, and that work goes ahead of new features rather than behind them.
• The defensive basics are simply standard: parameterised queries, encoded output, a content security policy, secure and HTTP-only cookies, rate limits on authentication, and security headers on every response.
• Any feature that touches personal data is assessed for privacy impact before it is built, with a full data protection impact assessment wherever Article 35 calls for one.
• Everybody working on VenueBooker is held to confidentiality undertakings that continue well after the work does, is told in plain words that a customer’s content is not there to be browsed, and loses access on the day the engagement ends. Every supplier that handles personal data goes through the checks at 11.3 and signs an Article 28(3) contract.

14.4 No promises we cannot keep, and reporting a hole

Nothing connected to the internet is perfectly safe, and we are not going to claim otherwise. What we will promise is that these measures are taken seriously, that you will hear from us quickly and straightforwardly when something goes wrong, and that we chase causes rather than symptoms. Found a vulnerability? Write to bookings@venuebooker.co under the subject “Security vulnerability report”. You will hear back inside two working days, and nobody who reports a genuine issue in good faith, stops at the point of demonstrating it, and gives us a fair chance to close it before going public will face legal action from us.

15. When something goes missing

15.1 What counts, and what happens first

A personal data breach means any failure of security that leads to records being destroyed, lost or altered accidentally or unlawfully, or being disclosed to or reached by somebody who should not have them. It is a much wider idea than a break-in: a mislaid laptop, an email sent to the wrong venue, a permission set the wrong way round, or data lost past recovery all count. Anybody here who suspects one must tell a director straight away, without waiting to be sure — the Article 33 clock starts running from awareness, so the first two moves are always to contain it and to write down the time. From there we establish what happened and when, which categories of people and roughly how many records are caught up in it, whether we stand as controller or as processor, what the likely consequences are, and what has already been done to limit the damage. Every incident is entered in a register whether or not it needs reporting, because Article 33(5) requires that documentation; the register is kept for six years.

15.2 Reporting upward when the records are ours

Where we are the controller and the breach is likely to put people’s rights and freedoms at risk, the Information Commissioner hears from us without undue delay, and no later than 72 hours after we become aware. Where the full picture is not yet available, we report in instalments rather than sit on it, and we explain why the rest is still coming. Where we conclude a breach is unlikely to put anyone at risk, the reasoning behind that conclusion is written down instead. And where the risk to individuals is high, those individuals hear from us too, without undue delay and in language anybody can follow: what happened, what it may mean for them, what we have done, what they can usefully do themselves, and who to speak to.

15.3 Reporting sideways when the records are a venue’s

Where the affected records belong to a venue, our Article 33(2) duty runs to that customer rather than to the regulator. We contact the affected venue without undue delay, working to make first contact inside 24 hours. Being the controller, the venue then decides whether the Commissioner and the individuals need telling; we give them what they need in order to decide and to notify, and we will not make any public statement about their data without squaring it with them first. Every incident ends with a written review of what actually caused it and what changes as a result.

16. What you can ask us for

These entitlements bite where we are the controller. Where we hold a venue’s records as processor, the request belongs with the venue (see section 4) and our part is to help them answer it.

16.1 Being told

You are entitled to know what becomes of your details before it becomes of them, which is what this handbook is for. If a passage here is opaque, say so and we will explain it in different words.

16.2 Seeing what we hold

You may ask us to confirm that we hold anything about you, to give you a copy, and to supply the further information Article 15 lists — the purposes, the categories, who receives it, how long it stays, where it came from and what you can do about it. The copy comes electronically unless you would rather it did not, and where a record also describes somebody else we redact only what has to go and tell you that we have done so.

16.3 Putting it right

Anything inaccurate can be corrected on your say-so, and anything incomplete can be completed, including by adding a statement of your own. Where we have already passed the record on, we tell the recipient unless that proves impossible or wildly disproportionate, and we will name the recipients if you ask. Most profile details can be edited by an account holder directly.

16.4 Having it removed

You can ask us to erase records where the purpose has run out; where you have withdrawn consent and nothing else supports keeping them; where you have objected under 16.6 and we have no overriding ground; where the processing was unlawful to begin with; or where a statute requires deletion. Erasure is not unconditional, though. We may have to refuse where a legal duty binds our hands — the six-year accounting record being far and away the most common instance — or where the records are needed for a legal claim. When we refuse, we name the exemption and explain how it applies to you.

16.5 Pausing, and taking it with you

You can require us to hold everything still — keeping the records but doing nothing further with them — while a dispute about accuracy or an objection is worked out, or in place of erasure where you need the material preserved for a claim. You will hear from us before any such pause is lifted. Where processing rests on consent or on a contract and is carried out by automated means, you can also have the details you gave us handed back in a structured, common, machine-readable file, and sent on to another controller where that is technically workable. Venue teams can export a whole workspace whenever they like.

16.6 Objecting where we rely on legitimate interests

Wherever this handbook cites legitimate interests, you may object on grounds particular to your own situation. We then stop, unless we can show compelling grounds that override your interests, rights and freedoms, or unless the records are needed for a legal claim. Tell us how the processing actually affects you and the balancing exercise gets worked through again on your facts, rather than the generic version being read back at you.

16.7 Objecting to marketing, and taking consent back

An objection to direct marketing has to be honoured at once and in full — there is no weighing up to be done and no discretion for us to exercise. Every marketing email carries a link that ends it, and a one-word reply does just as well (see section 19). Separately, wherever we rely on consent — product updates, push notifications, any non-essential cookie we might one day introduce — you can take it back whenever you like and with no more effort than giving it took. Withdrawing does not unpick what was lawfully done while the consent stood.

16.8 Decisions made by machine

Article 22 gives you the right not to have a decision with legal or comparably serious consequences taken about you purely by automated means. No decision of that kind is made anywhere in VenueBooker. Nobody is scored, ranked or profiled, and nothing here approves or refuses a person automatically; the availability rules that determine whether a slot can be taken are the venue’s own settings applied to a diary, not a judgement about the person asking. Were we ever to build something that fell inside Article 22, it would be described on this page before it went anywhere near a live venue, along with the logic and its consequences, and it would come with human review, a route to put your side of it, and a route to challenge the outcome.

16.9 How to make a request

• Where to send it: to bookings@venuebooker.co. A letter works equally well; address it to the registered office and mark the envelope Data Protection. There is no form and no particular wording — ask us for your data and you have made a request.
• Proving who you are: where we have genuine doubt we ask for enough to settle it, which is normally a reply sent from the address on the account. We ask for the least that will do and do not routinely want identity documents; the clock pauses only for as long as it takes you to send what we reasonably need. Where somebody acts for you, we need your written authority before we start.
• How quickly: a valid request is answered within one month. That can be extended by up to two further months where a request is complex or where several have arrived together, in which case we tell you inside the first month and give the reason.
• What it costs: nothing. A reasonable administrative charge, or a refusal, is possible only where a request is manifestly unfounded or excessive, and we would set out our reasoning and how to push back on it.
• If we say no: you get the reason, together with your right to take it to the Information Commissioner and your right to a judicial remedy.

16.10 Requests that really belong to a venue

Send us a request about records a venue controls and we will reply, explain that we hold them as processor, and pass it to the venue — normally inside two working days — unless you would rather we did not. From there we support the venue in meeting its own deadline. A customer’s records are never deleted or disclosed on the instruction of somebody who is not that customer.

17. If we get it wrong, and the ICO

Unhappy with how we have handled your records or your request? Tell us at bookings@venuebooker.co. You will hear back inside two working days, we will look into it, and a written answer to the substance follows within thirty days. None of that is a precondition, though — the United Kingdom’s supervisory authority will hear from you whenever you choose to go to it:

• Information Commissioner’s Office
• Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF
• Telephone: 0303 123 1113
• Website: ico.org.uk

Taking a complaint there costs nothing and closes off no other remedy. Separately, where a breach of data protection law has caused you damage — distress counts as damage — a claim for compensation can be brought in court.

18. The app in your pocket

18.1 What this covers

This section covers the VenueBooker operator application for iOS and iPadOS and for Android, distributed through the Apple App Store and Google Play. Should any of what follows change, this page is corrected first and the store listings are brought into line with it. The apps are a window onto the service: what they display is the material at sections 6 and 8, and the same division of keys applies. Anything a store reviewer or a tester sees is invented data, never a real venue’s bookings.

18.2 What the apps ask for

Nothing else is requested — no location of any precision, foreground or background, no contacts, no microphone, no health data, no messages and no call logs. Each permission is asked for in context, at the moment you first reach the feature that needs it and with the reason on screen, rather than as a wall of prompts on first launch.

18.3 What lives on the handset, and what lives with us

On the device: a sign-in token held in the platform keychain or keystore; a cached copy of recent bookings and diary entries so the app is usable on a weak signal; your display preferences; and a queue of changes made while offline. On our servers: the authoritative version of everything at sections 6 and 8. The local cache sits inside the app’s private container, is encrypted by the operating system’s own file protection, and is wiped on sign-out and on account deletion; uninstalling takes the container with it.

18.4 Measurement, crashes and identifiers

Measurement inside the apps runs no further than feature-use counts and technical performance, exactly as described at section 8. A crash report carries the stack trace, the app and operating-system version, the device model, its memory and storage state, and the screens visited beforehand. No booking content, hirer name, contact detail or run-sheet note appears in a crash report; identifying values are stripped on the device before the report is sent, and on iOS the platform’s own analytics sharing is governed by Apple’s “Share iPhone Analytics” switch rather than by us. Two identifiers exist: a push token issued by Apple or Google, which is what allows a notification to arrive and which is dropped when notifications go off or you sign out, and an installation identifier generated by the app itself, reset on reinstall and used for nothing beyond grouping crash reports together. Advertising identifiers play no part whatsoever: Apple’s IDFA goes unread, so does Android’s Advertising ID, and nothing resembling an advertising or third-party tracking SDK is compiled into what we ship.

18.5 App Tracking Transparency on iOS

Apple’s definition of “tracking” is specific: linking what an app collects with data from other companies’ apps, websites or offline records in order to target advertising or measure it, or passing that data to a data broker. None of those describes VenueBooker. Because no tracking in Apple’s sense takes place and no advertising identifier is read, the App Tracking Transparency prompt is not presented — the prompt exists to authorise a practice we have no use for. Were our practices ever to fall inside Apple’s definition, permission would be sought through that prompt first and this page would be revised beforehand.

18.6 Data Safety on Google Play

Where Google Play calls for a Data Safety declaration, ours says what this page says: which categories are collected — account information, app activity, app performance and diagnostics, and the content a user types in; what they are collected for — running the app, managing an account, measurement and crash diagnostics; that everything is encrypted while in transit; that nothing is sold and nothing is shared for advertising or with a data broker; that deletion can be requested; and the deletion route set out at 18.8. Should the listing and this page ever diverge, this page is the one that governs and the listing gets corrected.

18.7 Buying a subscription inside an app

A subscription bought inside an app is billed by Apple through App Store billing or by Google through Play Billing. The purchase completes inside the platform’s own sheet, which is why your card, your bank details and your store password are never visible to us. What comes back to us is a transaction or purchase token, the product identifier, the purchase and expiry dates and the renewal status, and we use those for one thing only: unlocking the right plan and keeping the entitlement accurate. We also receive status messages covering renewal, lapse, refund and billing retry. For the payment itself Apple and Google act as controllers in their own right under their own policies, and managing or cancelling a store subscription happens in your store settings rather than in our app — see our Terms of Service.

18.8 Closing an account and deleting the data

• Inside the app: open Settings, go into Account, and choose Delete account. Confirm it and the account is deactivated on the spot, sign-in stops working, and the local cache is cleared.
• By email: write to bookings@venuebooker.co from the address on the account, under the subject “Account deletion request”. This route covers enquiry and demo records as well as accounts.
• On the web: the same option, in account settings.

Deletion finishes within thirty days and we write to confirm it; backups age out as described at 13.2. Two things are worth flagging. Deleting your own login is not the same as deleting your venue’s workspace: if you are one of several people on a team, deleting yourself removes you and leaves the venue’s records standing, because they belong to the venue — an owner has to ask for the workspace itself, and should take an export first. And removing the app does not close the account: uninstalling clears the local copy and nothing more. Afterwards what remains is the statutory accounting record for six years (7.4), the slimmest suppression entry, and the incident or request records the law obliges us to keep. The steps are written out again on our Support page.

19. Letters you asked for

Two kinds of message leave here and no others. Service messages cannot be switched off while you hold an account, because they are the account talking to you: security alerts, password resets, billing notices, material changes to this handbook or to our terms, and notice of scheduled maintenance. Product updates go only to people who asked for them.

Email marketing answers to the Privacy and Electronic Communications Regulations 2003 as well as to the UK GDPR. For an individual subscriber we rely on consent, given by asking for our updates or ticking a box that was not already ticked. For an existing customer we may instead rely on the PECR soft opt-in for a similar product, having offered a way out when the address was collected and in every message since. A corporate subscriber — a role address at a limited company or an LLP — may be written to on Article 6(1)(f), the interest being bringing a business product to the attention of businesses that would plausibly want it; a balancing exercise was recorded, and the unqualified right to object at 16.7 is untouched by it.

To stop it: follow the link in any message, reply with the word “unsubscribe”, or write to bookings@venuebooker.co. It is actioned within 48 hours at the outside, and a minimal suppression entry is kept so that a later import cannot quietly undo your decision. Coming off the marketing list does not stop service messages about an account you still hold. Marketing lists are never bought in, a venue’s hirers are never marketed to by us, and nobody is given your details for their own marketing. No telephone marketing goes out from here; were that ever to change, the Telephone Preference Service would be screened first.

20. Amendments to this handbook

This page is revised whenever what we do with personal data changes, and it is kept level with the product as the product grows.

• Any revision at all: the version number and the date at the top move, and the new text is published here.
• A material revision — a fresh purpose, a different lawful basis, a new category of recipient, a longer shelf life, or anything that narrows your rights — is emailed to account holders and to everyone on our updates list at least thirty days before it takes effect, with a short account of what moved and why.
• A new sub-processor follows the notice and objection procedure at 11.3.
• Where a change needs consent, we ask for it. Continuing to use the product is not agreement to a new purpose, and it will never be read as one.

Earlier versions are kept and any of them will be sent to you on request. Version 3.0 rebuilds the handbook around the four working stations, restates every section in our own words, and sets out the payment, transfer and mobile sections in the same voice.

21. Where to find us

• Email: bookings@venuebooker.co — read on working days, with an answer normally back inside one.
• Company: VENUEBOOKER SOLUTIONS LTD, incorporated in Northern Ireland, number NI737741.
• Regulator: Information Commissioner’s Office, Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF · 0303 123 1113 · ico.org.uk.

Venue managers working through a supplier assessment often need something this page does not carry — a signed data processing agreement, a summary of a transfer risk assessment, a place on the sub-processor notification list, or a security questionnaire filled in. Write to us and we will work through the form with you rather than sending back a link.

Version 3.0 · Effective 15 August 2026 · Last updated 15 August 2026 · Supersedes version 2.0 of 5 August 2026.