Privacy Policy

This notice explains how Unnamed operator uses personal information for its website, events, bookings, tickets, gift cards, UKARA services and communications.

Controller and privacy contact

Operator

Unnamed operator

Email

info@example.com

For privacy questions or requests, contact privacy@example.com.

Where a gift purchaser gives us a recipient's name and email, we obtain that information from the purchaser. During an initial booking-system migration, an authorised administrator may also transfer an existing paid event booking from previous booking records. We limit that transfer to the player, allocation, contact, payment and optional emergency-contact details needed to administer the booking. The player is not treated as having accepted these terms, the site rules or a waiver merely because their booking was imported.

Conduct information may be supplied by marshals, event staff, other players or venue staff. Please tell another person before giving us their contact details, including a gift recipient or emergency contact.

Information we collect

We may collect the following information when it is relevant to the service:

• identity and contact details, including name, email address, telephone number, team or group name, address and optional messaging preference;
• booking, ticket, attendance, payment, refund, credit and gift-card details;
• UKARA application, eligibility and administration information where that service is requested;
• waiver, safety, emergency-contact, incident and chronograph information needed to run safe events and maintain evidence;
• conduct records, warnings, bans and security information where needed to protect people, property and the service;
• technical and security data, including essential session information, request timestamps, encrypted network evidence and device or browser information; and
• communications sent to us and messages we send about bookings, payments, events and services.

We do not store raw payment-card details. Payment providers process card or account credentials under their own terms and privacy notices.

Why we use it

We use information to administer bookings and payments, issue tickets, run events safely, provide UKARA services, communicate with players, prevent fraud and abuse, enforce rules and bans, protect the service, maintain proportionate records, and establish, exercise or defend legal claims.

Depending on the activity, our lawful bases are performance of a contract, compliance with a legal obligation, legitimate interests in safe and fair events, consent for optional communications, messaging or analytics cookies, and vital interests where information is needed to protect someone's life. Required booking details are needed to enter into and administer the event contract, confirm that the named player meets event requirements and enforce active event restrictions. If accurate details are not provided, we may be unable to accept the booking or admit the player. Next-of-kin details and messaging participation are optional unless an event clearly states a lawful safety requirement.

Capacity limits, payment-expiry rules, discounts, refund criteria, UKARA readiness and active-ban screening may be applied automatically. A possible ban match prevents the booking from completing automatically and creates a record for authorised administrator review. If the optional staff-security control is enabled, 3 failed attempts within 15 minutes to enter the restricted staff area may also create an active site ban for an authenticated player account. An IP-address match by itself is never used to create that automatic ban. You may contact us to challenge either result, provide relevant information and obtain human review.

Who may receive it

We share only what is reasonably necessary with:

• configured payment providers and card-machine operators;
• email, SMTP, hosting, database, security and technical-support providers acting for us;
• Google Analytics, when configured and accepted, for measurement of reviewed public pages;
• authorised Unnamed operator staff, marshals and event organisers according to their role;
• venue operators where needed for access, safety or incident management;
• UKARA and its authorised systems where you ask us to process a registration or renewal and the service is available;
• messaging services where a player opts in;
• emergency services where reasonably necessary to protect someone's health or safety;
• our legal counsel and other professional advisers, insurers, brokers and claims handlers where reasonably necessary to obtain advice, notify or manage a claim, or establish, exercise or defend legal rights; and
• courts, tribunals, regulators, law-enforcement bodies, public authorities, and a claimant or other party to a dispute and their advisers, where disclosure is required by law or reasonably necessary for legal proceedings; and
• a purchaser or successor if the organisation is sold or reorganised, subject to appropriate confidentiality and data-protection safeguards.

We do not sell personal information.

International transfers

Some configured payment, email, messaging, analytics or infrastructure providers may process information outside the United Kingdom. Where that happens, we will use a lawful transfer mechanism, such as UK adequacy regulations or approved contractual safeguards, and apply any additional measures that are required. Contact us for information about the safeguards relevant to your data.

How long we keep it

• Unpaid booking holds are normally cancelled after 48 hours, though a limited record may remain for security, support and financial reconciliation.
• Confirmed booking, transaction and refund records are retained for the period needed to perform the contract, handle claims and meet financial, tax and legal record-keeping duties. Where direct player identifiers are no longer needed, they may be replaced with a random reference while those accounting records remain.
• A raw CSV used for a controlled booking migration is stored temporarily outside the public website. It is removed after successful mapping or when the unfinished import expires, normally within 24 hours. The resulting individual booking, payment and audit records, including previous booking records where retained, then follow the retention periods described in this notice.
• Per-player waivers have separate validity and retention periods. Validity is fixed at 365 days from signing. Later use does not renew or extend it. The signed waiver, PDF and signing evidence are normally retained for 6 years after the end of the last attended event where the waiver was used. Attaching it to a booking is recorded but does not restart retention. Six years of retention plus one year of validity is approximately seven years. We may retain it longer for an actual or anticipated claim, a legal requirement, or reasonable insurer or legal advice.
• Ordinary conduct notes expire after the configured period, currently 90 days by default. Serious-infraction records may be kept longer; active bans are kept while needed to enforce the ban and reviewed for continued necessity. Details supplied during a refused booking attempt are encrypted and available only to authorised administrators while the match awaits review; the readable copy is removed when the outcome is recorded, or earlier if the related identity is pseudonymised or erased. Player IP history is encrypted and restricted to authorised administrators. Where ban evasion is reasonably suspected, an administrator may explicitly include known addresses in a ban using non-reversible keyed matches. Readable IP history is removed when the related player identity is pseudonymised or erased.
• When a player record is pseudonymised, a lowercase keyed match derived from the normalised email address is retained on that record so it can be recognised if the person later voluntarily supplies the same address again. If an active ban exists, keyed matches derived from normalised email, telephone, combined name and any explicitly blocked IP addresses may also remain so the ban can still be enforced. These values cannot be decrypted, but remain protected personal data because they can be used to recognise a repeated input.
• Gift cards are valid for the configured period, currently 365 days by default. Player balance is valid for the configured period, currently 730 days by default. Associated transaction records may be retained longer where legally required.
• Optional emergency-contact details, chronograph evidence, UKARA evidence and check-in records are retained only while needed for event administration, safety, audit, incident handling, a related claim or a legal requirement. Chronograph records can include weapon position, class, power or platform, an optional distinguishing marker, the pass or fail decision, any invalidation reason, and the responsible staff member and timestamp. They are retained for event safety, rule enforcement, audit and claims, pending a dedicated configured retention policy. Core v1 does not automatically delete these records.
• Rotating self-check-in codes expire within minutes. The short-lived kiosk journey records behind expired codes are automatically removed within seven days. The resulting attendance status remains part of the associated booking record.
• Google Analytics measurements and cookie identifiers are not stored in the local application database. Google retains analytics information according to the configured Google Analytics property settings and applicable account controls. Its `_ga` cookie distinguishes browsers and its `_ga_<container-id>` cookie preserves session state; each has a default expiry of up to two years that may be renewed when measurements are sent.
• UKARA applications, readiness evidence and issued-record details are kept while needed to process the request, administer renewal and expiry, answer queries, maintain an appropriate audit trail and meet financial or legal obligations. Information no longer needed for those purposes is deleted or de-identified.

You may rescind a digitally signed waiver before completing check-in for an event through the private ticket or self-check-in journey. Once rescission is recorded, we will not rely on that waiver for that check-in or any future event, and a new waiver will be required before you can use digital check-in. Rescission does not retrospectively change an event where the waiver was already used. The original signed document and the evidence of rescission remain protected for the applicable retention period so that we can establish what was agreed, when it was agreed and when it was rescinded. The evidential details are printed in the signed PDF; booking and use metadata stays in the protected audit trail.

You may ask us to erase personal information. We assess each request because the right to erasure is not absolute and some records may still be required by law, to fulfil unresolved financial obligations or to establish, exercise or defend legal claims. Where full erasure is not appropriate, we may replace direct identifiers with a random reference and retain only protected matching data needed to recognise the pseudonymised record, enforce an active ban or preserve necessary financial and legal records.

Returning after pseudonymisation

• A later booking attempt receives the same generic secure-verification response used for protected player accounts. The public page does not disclose the earlier request.
• Verifying the same email through the secure sign-in link reactivates the record and keeps secure booking enabled.
• Previously removed details are not recovered. The player must provide them again.

Full erasure is different: it cannot reconnect the earlier player record. A returning player creates a new record, subject to information we remain legally entitled or required to retain.

Security, essential cookies and analytics

We use appropriate technical and organisational safeguards designed to protect information against unauthorised access, alteration, disclosure or loss. These include access restrictions, secure transport, protection for sensitive values and monitoring of security-relevant activity. No internet service can guarantee absolute security, but access is limited to those who need it and suspected security incidents are investigated.

Staff sign-in activity is recorded in the restricted authentication audit. A currently authenticated player account is used as the primary player context. Only when no authenticated player account is available may a failed attempt be linked to a known confirmed booking previously accessed from the same IP address. Because an IP address may be shared, an IP-only link is contextual information for an administrator and does not establish who made the attempt.

The website uses an essential session cookie to keep forms secure, preserve sign-in state and deliver one-time messages. It is marked HttpOnly and SameSite=Lax and, over HTTPS, Secure. Because it is strictly necessary for the service requested, it is not used for advertising or cross-site tracking.

When Google Analytics is configured, we ask whether you agree to non-essential cookies. Essential cookies remain available because they keep the site secure and provide requested functions. Your versioned choice is stored in browser storage so that we can respect it and ask again if the consent model changes.

The Google tag is not contacted or loaded until you accept non-essential cookies. If you accept, analytics storage is enabled and Google Analytics may set the first-party `_ga` and `_ga_<container-id>` cookies to distinguish browsers and sessions. Advertising storage, advertising user data and advertising personalisation remain disabled. Analytics runs only on reviewed public information and event pages, using the approved page address without its query string and reducing a referring address to its origin. It does not run on staff, account, ticket, payment, check-in, application or other private pages.

You can reject non-essential cookies without losing access to the site. You can also reopen Cookie settings in the site footer and withdraw consent. Withdrawal changes the analytics consent state to denied and removes accessible Google Analytics cookies; Google will not be loaded on later pages unless you accept again.

Secure online bookings

• Players can require sign-in before an online booking uses their email.
• Unsigned attempts are paused and receive a generic public response.
• Where delivery is allowed, a one-time sign-in link is sent to the email address.
• The response does not explain whether the player enabled the setting or previously requested pseudonymisation.

How identity and ban matching works

When a booking is attempted, we consider relevant identity signals available for the player: email address, telephone number, first name, last name, combined full name, any address supplied and the current IP address. Unrelated information, such as next-of-kin details, incident or health information, payment-card data, gift-recipient details and messaging preference, is not used for this match.

Before comparison, email addresses and names are trimmed and converted to lowercase, repeated spacing in names is collapsed, telephone numbers are reduced to digits, and addresses are reduced to lowercase letters and numbers with consistent spacing. IP addresses are trimmed and converted to lowercase. Each value is then given a purpose label, such as email or address, so the same text used in different fields does not produce the same identity match.

We process each normalised value using HMAC-SHA-256 with a secret server-side key. This produces a 256-bit value stored as 64 lowercase hexadecimal characters. HMAC hashing is not encryption: there is no encrypted copy inside the hash and no decryption key or reverse operation that can recover the original value. To test a later booking, sign-in or ban match, the application normalises the newly supplied value, calculates a new HMAC with the same secret key and compares the two results. The retained email HMAC therefore lets the application reconnect voluntarily supplied details to a pseudonymised player, but cannot recreate those details itself. A person who obtained the secret key and already had a possible input could test that guess, so the key is protected and the resulting values remain personal data rather than anonymous data.

A match does not rely on one weak similarity. Relevant matches contribute configurable weights to a score, and the threshold must be reached with at least one strong match: email address, telephone number, address or combined full name. A first-name match by itself cannot refuse a booking. The current IP address contributes only where an administrator has explicitly associated that address with an active ban. If the threshold is reached, the booking is initially refused. The attempted event, admission, team and role are recorded with the matched categories and score. The name, contact details, address and section or friend-group name supplied for the attempted booking are held in encrypted form only while an authorised administrator reviews the match, then the readable copy is removed. The player can contact us to appeal. We do not disclose the protected values or another player's information during that process.

Your data-protection rights

Depending on the circumstances, you may have rights to be informed, access your information, correct inaccurate information, erase it, restrict its use, receive portable information and object to processing. You may also withdraw consent at any time where consent is the basis used. These rights are not absolute; for example, we may need to keep information required by law or needed to establish, exercise or defend legal claims.

Your right to object: you have the right to object to processing based on legitimate interests. Tell us your particular situation and we will stop unless we can demonstrate compelling legitimate grounds or the processing is needed for legal claims. You have an absolute right to object to direct marketing.

To exercise a right, contact privacy@example.com. We may ask for proportionate information to confirm identity and protect another person's data. We normally respond within one month. You also have the right to complain to the Information Commissioner's Office.

Players under 18

Unnamed operator events currently accept eligible players aged 13 and over, subject to event and venue requirements. Information about a player under 18 is used to administer their booking and safety arrangements. Their parent or legal guardian must sign the required waiver, remain on site and retain responsibility for supervision. The website and events are not intended for children under 13, and we do not knowingly accept their bookings.

Questions and complaints

Contact privacy@example.com first if you have a privacy question or complaint. We will investigate and explain our response. We may update this notice when the service, providers or law changes; the review date at the top shows the current version.