This policy explains what Nikita Cherevko ("Wardentry", "we", "us") does with
personal data. It covers our website at wardentry.com, the organizer console at
app.wardentry.com, the scanner at scan.wardentry.com, and the service behind
them.
It is written to be read. Where a section says something you would rather it did not, that is deliberate - we would rather be plain than reassuring.
1. The two roles we play, and why it matters to you
There are two kinds of personal data in this service, and we stand in a different relationship to each.
Data about our customers - we are the controller. If you sign up, run an organization, or are invited as staff, we decide why and how your account data is processed. Sections 3 to 14 of this policy are our notice to you.
Data about your attendees - we are the processor. When an organizer uploads a guest list, issues passes, or scans people at a gate, the organizer decides what is collected, from whom, for what and for how long. We only hold it and enforce the rules we are told to enforce. Our obligations there are contractual, set out in our Data Processing Agreement, and we act only on the organizer's documented instructions.
If you attended someone's event and want to know why they have your data, see section 11 - the short answer is that you need to ask them, not us, and we will help them answer you.
2. Who to contact
| Controller | Nikita Cherevko |
| Privacy contact | privacy@wardentry.com |
| Security reports | security@wardentry.com |
We have not appointed a Data Protection Officer. Our processing does not meet the Art. 37 thresholds - we are not a public authority, our core activity is not large-scale monitoring, and we do not process special categories of data at scale. If that changes, so does this line.
3. What we collect about our own users
3.1 Account and organization data
When you create an organization or accept a staff invitation:
- your email address, and the password you set - the password is held by Firebase Authentication (Google) and never reaches our servers or our database;
- your role in the organization (administrator, event manager, or scanner operator) and which organization you belong to;
- an identifier issued by Firebase Authentication that links the two;
- the name of your organization, its default language, and when it was created.
3.2 Data you create while using the service
Events, gates, access rules, device links and their labels - a device link's label is whatever you typed, and organizers typically type a person's name ("Ana's phone"). That makes it personal data, so we say so.
3.3 Technical data
- Server logs. Requests to our API produce structured log entries containing a timestamp, the endpoint, the response status, timing, and the organization the request belonged to. Where a request is authenticated, the acting user's identifier appears with it. Logs are held in Google Cloud Logging.
- IP addresses. Our rate limiter counts requests per IP address in memory, on the instance handling the request. It is not written to our database. IP addresses do appear in Google Cloud's own request logs and in Firebase Authentication's sign-in records.
- Email delivery data. Our email provider records whether a message was accepted, delivered, bounced, or opened.
3.4 Website and waitlist
wardentry.comis hosted by Vercel and uses Vercel Analytics, which measures page views and a small number of product events without cookies and without building a profile of you across sites. We set no advertising or tracking cookies, and there is no consent banner because there is nothing to consent to.- The feedback form collects an email address, if you give one, and your message.
3.5 What we do not collect
We do not ask for payment card details - there is no checkout in this product. We do not buy personal data from third parties, we do not run advertising, and we do not sell or share personal data for advertising purposes under any definition of those words.
4. Attendee data, in outline
We describe this here for transparency, not because we decide any of it. Acting on an organizer's instructions, the service stores: an attendee's name, and optionally an email address, phone number and language; the passes issued to them and each pass's validity, entry allowance and entries used; and a scan record for each time a credential is presented at a gate - the time, the gate, whether it was admitted or denied, why it was denied, which device scanned it, and whether the credential was scanned or typed in by hand.
Details, including retention and how erasure works, are in Annex I of the DPA.
5. Why we process it, and on what legal basis
| Purpose | Data | Legal basis (GDPR Art. 6) |
|---|---|---|
| Providing the service to your organization | Account, organization, and service data | Performance of a contract, Art. 6(1)(b) |
| Authenticating you and keeping accounts secure | Email, credentials held by Firebase, sign-in records | Contract, Art. 6(1)(b); legitimate interests in security, Art. 6(1)(f) |
| Sending service email - verification, password reset, staff invitations | Email address | Contract, Art. 6(1)(b) |
| Keeping the service up, debugging, and preventing abuse | Server logs, IP addresses, rate-limit counters | Legitimate interests in running a reliable and un-abused service, Art. 6(1)(f) |
| Responding when you contact us | Whatever you send us | Legitimate interests in answering, Art. 6(1)(f) |
| Understanding how the website is used | Cookieless analytics | Legitimate interests in improving a website, Art. 6(1)(f) |
| Processing attendee data | See section 4 | We process on the organizer's instructions; the legal basis is the organizer's to establish and to tell attendees about |
6. Who else sees it
We use a small, fixed set of service providers. Each processes personal data only to provide its service to us, under a contract that requires it.
| Provider | What it does | Where it processes |
|---|---|---|
| Google Cloud Platform (Google Ireland Ltd / Google LLC) | Runs the API, holds secrets, stores logs and metrics | europe-west1, Belgium |
| Firebase Authentication (Google) | Holds organizer and staff sign-in credentials | Google infrastructure; see section 8 |
| Firebase Hosting (Google) | Serves the console and scanner | Global content delivery network |
| Neon (Neon Inc.) | The product database - everything in sections 3 and 4 | aws-eu-central-1, Frankfurt |
| Brevo (Sendinblue SAS) | Sends service and pass email | France / EU |
| Vercel (Vercel Inc.) | Hosts wardentry.com, its analytics, and the feedback-form database | See section 8 |
We will also disclose personal data where we are legally required to, and to professional advisers under confidentiality. If the business is incorporated as a company, sold or merged, data moves with it - we will say so before it does, and whoever receives it takes on this policy as it stands.
There is no other category of recipient. We do not have an advertising network, a data broker, or a customer-data platform in this list because we do not have one at all.
7. Cookies and local storage
We use no cookies for advertising, and no third-party tracking cookies.
What the applications do keep on your device:
- A sign-in session. The console stores a Firebase Authentication token in your browser's local storage so you are not asked to sign in on every page. Signing out removes it.
- A scanner session. The scanner keeps the device secret from the link an organizer gave you in the browser tab's session storage, so the phone at the gate does not need to be re-linked between scans. It arrives in the URL's fragment, which browsers never send to a server, and it is discarded when the tab is closed.
Both are strictly necessary for the service to work and neither is used to track you anywhere else.
8. Where data goes
Our primary processing is in the European Union - Frankfurt for the database, Belgium for the application. Three exceptions are worth naming:
- Firebase Authentication stores account records on Google infrastructure that may be located outside the EEA. Transfers rely on Google's Standard Contractual Clauses and, where applicable, the EU-US Data Privacy Framework.
- Firebase Hosting serves static files from a global network, which means the console and scanner may be delivered from a server near you rather than from Europe. Attendee data is not stored there; it is fetched from the EU-hosted API.
- Vercel, which hosts the marketing website, is a US company. The
feedback-form database is currently hosted in the United States
(
us-east-2). It holds only what section 3.4 describes - the email address, if given, and message of someone who used the feedback form - and no attendee data has ever been in it. We intend to move it to the EU; until we have, this sentence is here so that you know.
Where personal data leaves the EEA, we rely on the European Commission's Standard Contractual Clauses, supplemented by the EU-US Data Privacy Framework where the recipient is certified under it.
9. How long we keep things
| Data | Kept for |
|---|---|
| Account and organization data | While your organization is active, and for 30 days after it is closed |
| Events, gates, rules, device links | Same as above, or until you delete them |
| Attendee records and passes | Until the organizer deletes them, or 30 days after the organization is closed. There is no automatic expiry, and that is the organizer's decision to make, not ours |
| Scan history | 90 days. A scheduled job deletes every scan record older than that, every day, for every organization. There is no per-customer override - a retention window is a promise about the product, not a setting |
| Erasure records | Kept as long as the organization exists. They record that an attendee was erased, by whom and when, and contain no personal data of the erased attendee |
| Server logs and metrics | Per Google Cloud Logging's retention, currently 30 days for the default log bucket |
| Email delivery records | Per our email provider's retention |
| Waitlist and feedback submissions | Until you ask us to delete them, or 24 months after our last exchange |
| Backups | Our database provider's point-in-time restore window. Data deleted from the live database persists in backups until it falls out of that window |
10. Your rights
If you are in the EEA or the UK, you have the right to access your data, to have it corrected, to have it erased, to restrict or object to processing, to portability, and to withdraw consent where we rely on it - withdrawal does not affect what we did before you withdrew.
Write to privacy@wardentry.com. We answer within one month. We do not charge for this, and we will ask you for enough information to be sure you are who you say you are
- which is a smaller ask than it sounds, since for account data your email address is the identifier.
If you think we have got it wrong, you can complain to a supervisory authority in the country you live or work in. Ours is the Polish President of the Personal Data Protection Office (Prezes Urzędu Ochrony Danych Osobowych), Warsaw.
11. If you are an attendee at someone's event
You are probably here because you received a pass, or you scanned a QR code, or someone told you their door runs on Wardentry.
The organizer is the controller of your data, not us. They decided to collect your name and email address, they decided to issue you a pass, and they decide how long to keep the record. Your rights under the GDPR run against them, and they are the ones who can answer why they have your details.
So: ask the organizer first. If you cannot reach them, or you do not know who they are, write to privacy@wardentry.com with whatever you have - the email you received, the event name - and we will identify the organizer and pass your request to them. What we cannot do is delete or hand over data on your behalf without their instruction; that is not us being unhelpful, it is the same rule that stops anyone else doing it to your data either.
Two things we can tell you directly, because they are true of the product rather than of any one organizer: scan records are deleted after 90 days automatically, and when an organizer erases an attendee, that attendee's passes and scan history go with them in the same operation.
12. Security
The measures we take are listed in full in Annex II of the DPA
- it is a customer-facing document, but the measures are the same ones protecting your account. In summary: everything is encrypted in transit and at rest; credentials are stored hashed or derived, never in a form that could be replayed; each organization's data is separated at the database level and not merely by application code; access to production is limited to people who need it; and secrets live in a managed secret store rather than in configuration.
No system is perfectly secure, and anyone who tells you otherwise is selling something. If you find a vulnerability, please write to security@wardentry.com. We will not pursue anyone who reports a genuine issue in good faith.
13. Children
The service is not directed at children and we do not knowingly collect data from anyone under 16 in the course of running our own accounts. Whether an organizer's attendee list includes minors is the organizer's decision and the organizer's responsibility, and our terms require them to have a basis for it.
14. Changes
We will update this policy when the service changes. Material changes are announced by email to organization administrators at least 30 days before they take effect. Every version is dated, and the history is below.
15. Version history
| Version | Date | Change |
|---|---|---|
| 1.1 | 2026-09-15 | Early-access form discontinued; removed its data-collection description and legal-basis row. No change to what we do with data we still collect |
| 1.0 | 2026-08-19 | First published |