This Data Processing Agreement ("DPA") forms part of the Terms of Service between Nikita Cherevko ("Wardentry", "Processor") and the customer organization identified in the account ("Customer", "Controller"), together the "parties".
It is accepted electronically when an organization is created. Article 28(9) GDPR permits an agreement in electronic form, and Article 28(3) requires it to be in place before processing begins - which is why it is presented at signup rather than sent afterwards. A record of the version accepted, by whom, and when, is retained by Wardentry and available to the Customer on request.
Where this DPA and the Terms of Service conflict on a data protection matter, this DPA prevails.
1. Definitions
"Data Protection Law" means, as applicable to the processing: Regulation (EU) 2016/679 ("GDPR"); the GDPR as retained in UK law together with the Data Protection Act 2018 ("UK GDPR"); the Swiss Federal Act on Data Protection; and the state privacy laws of the United States, including the California Consumer Privacy Act as amended ("CCPA").
"Customer Personal Data" means personal data contained in Customer Data, as defined in the Terms of Service, that Wardentry processes on the Customer's behalf. It is described in Annex I.
"Controller", "processor", "data subject", "personal data", "processing", "personal data breach" and "supervisory authority" have the meanings given in the GDPR. "Sub-processor" means a processor engaged by Wardentry to process Customer Personal Data.
"SCCs" means the standard contractual clauses annexed to Commission Implementing Decision (EU) 2021/914.
2. Roles of the parties
The Customer is the controller of Customer Personal Data and Wardentry is the processor. Each party complies with the obligations Data Protection Law places on it in that role.
The Customer is responsible for the lawfulness of the collection of Customer Personal Data, for having a legal basis for its processing, and for providing data subjects with the information Articles 13 and 14 require - including that a third-party access-control system processes their data on the Customer's behalf. Wardentry does not have, and does not seek, a direct relationship with the Customer's attendees.
Wardentry is an independent controller of the account data of the Customer's own users - the people who sign in to the console - and of technical data about its service. That processing is outside this DPA and is described in the Privacy Policy.
3. Processing instructions
Wardentry processes Customer Personal Data only on the Customer's documented instructions, including as to transfers to a third country, unless required to do otherwise by Union or Member State law - in which case Wardentry will inform the Customer of that requirement before processing, unless the law prohibits it on important grounds of public interest.
The following constitute the Customer's documented instructions:
- this DPA and the Terms of Service;
- the Customer's configuration of, and use of, the features of the service - including creating members, issuing and sending passes, defining access rules, linking scanner devices, admitting or denying at a gate, exporting logs, and erasing members; and
- any further written instruction the parties agree.
Wardentry will inform the Customer if, in its opinion, an instruction infringes Data Protection Law, and may suspend the affected processing until the instruction is withdrawn or amended. Wardentry may refuse an instruction that would require a change to the service, or charge for it, unless it is required by Data Protection Law.
Wardentry does not sell Customer Personal Data, does not share it for behavioural advertising, does not use it to train machine-learning models, and does not use it for its own purposes. Wardentry may generate aggregated statistics about the operation of the service which do not identify the Customer, any data subject, or any individual event.
4. Confidentiality
Wardentry ensures that persons authorised to process Customer Personal Data are subject to an appropriate obligation of confidentiality, whether contractual or statutory, that survives the end of their engagement. Access is limited to personnel who need it to provide, secure or support the service.
5. Security
Wardentry implements appropriate technical and organisational measures under Article 32 GDPR, described in Annex II. The Customer confirms that, considering the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing, those measures are appropriate to the risk.
Wardentry may update the measures over time provided the level of protection is not reduced.
6. Sub-processors
The Customer gives a general authorisation for Wardentry to engage sub-processors. Those engaged at the effective date are listed in Annex III.
Wardentry will give the Customer at least 30 days' notice before adding or replacing a sub-processor, by email to the organization's administrators and by updating Annex III. The Customer may object on reasonable data protection grounds within that period. If the parties cannot resolve the objection, the Customer may terminate the affected part of the service - or the agreement - without penalty, and Section 9 applies to the data.
Wardentry imposes on each sub-processor, by written contract, data protection obligations no less protective than those in this DPA, and remains fully liable to the Customer for a sub-processor's performance.
7. Assistance with data subject rights
Taking into account the nature of the processing, Wardentry assists the Customer by appropriate technical and organisational measures, insofar as possible, in fulfilling the Customer's obligation to respond to requests to exercise data subject rights under Chapter III GDPR.
The service itself provides most of what is needed, and the Customer can act without contacting Wardentry:
| Right | How it is exercised in the service |
|---|---|
| Access, rectification | The Customer reads and edits member records directly in the console |
| Erasure | A dedicated erase operation removes the member together with the passes issued to them and their scan history, in a single transaction, and records that it happened |
| Portability | Member data is the Customer's own list; scan history exports as CSV |
| Restriction, objection | The Customer revokes the pass or removes the member |
If a data subject contacts Wardentry directly, Wardentry will not respond to the substance of the request, will tell the data subject to contact the Customer, and
- where the data subject can be identified with a Customer - will forward the request to the Customer without undue delay.
8. Personal data breaches
Wardentry notifies the Customer without undue delay, and in any event within 48 hours, after becoming aware of a personal data breach affecting Customer Personal Data.
The notification will describe, so far as known at the time: the nature of the breach and the categories and approximate number of data subjects and records concerned; the likely consequences; and the measures taken or proposed. Where the information cannot be provided at once, it will be provided in phases without undue further delay. Wardentry will assist the Customer with its own obligations under Articles 33 and 34.
Notification is not an admission of fault or liability.
9. Assistance with Articles 32 to 36
Taking into account the nature of processing and the information available to it, Wardentry assists the Customer in ensuring compliance with its obligations under Articles 32 to 36 GDPR - security, breach notification, data protection impact assessment, and prior consultation. Annex II and this DPA are intended to supply what a data protection impact assessment of this service would need.
10. Deletion and return
On termination or expiry of the agreement, Wardentry will, at the Customer's choice, delete or return Customer Personal Data.
Unless the Customer asks for return, Wardentry deletes it within 30 days of termination, after the export window described in the Terms of Service. Deletion of an organization removes its members, passes, events, gates, rules, device links and scan history. Backups are not individually erased; Customer Personal Data persists in them until they expire from the provider's restore window, and is not restored to live service in the meantime.
Wardentry may retain Customer Personal Data to the extent required by Union or Member State law, for as long as that law requires, and will protect it under this DPA for that period.
11. Audits and information
Wardentry makes available to the Customer the information necessary to demonstrate compliance with Article 28 and allows for and contributes to audits, including inspections, conducted by the Customer or an auditor it mandates.
In practice:
- Wardentry responds to a reasonable written information request - including a security questionnaire - within 30 days, at no charge, no more than once a year unless a personal data breach or a supervisory authority's requirement makes a further request necessary.
- An on-site or remote inspection may be conducted once in any 12-month period, on at least 30 days' written notice, during business hours, without unreasonably disrupting the service, and subject to confidentiality. The auditor must not be a competitor of Wardentry. The Customer bears its own costs and reimburses Wardentry's reasonable costs for inspections beyond the first in any period.
- Nothing in this section requires Wardentry to disclose information that would compromise the security of the service or of another customer's data.
12. International transfers
Wardentry's primary processing of Customer Personal Data takes place in the European Union - the database in Frankfurt (Germany), the application in Belgium. Annex III identifies each sub-processor's location and the transfer mechanism relied on where personal data leaves the EEA.
Where Wardentry transfers Customer Personal Data to a third country that is not the subject of an adequacy decision, it does so on the basis of the SCCs or another mechanism recognised under Chapter V GDPR, together with any supplementary measures required.
Between the parties. Where the transfer of Customer Personal Data from the Customer to Wardentry, or from Wardentry back to the Customer, requires a transfer mechanism, the SCCs are incorporated into this DPA by reference and apply as follows:
- Module Two (controller to processor) where the Customer is the controller and is established in the EEA, or is subject to GDPR under Article 3(2), and Wardentry is outside the EEA. This does not arise while Wardentry is established in Poland.
- Module Three (processor to processor) where the Customer is itself acting as a processor for a third-party controller.
- Module Four (processor to controller) where the Customer is a controller outside the EEA and Wardentry makes Customer Personal Data available to it - the ordinary case for an organizer signing up from outside the EEA, since returning an attendee list or a scan export to a controller in a third country is itself a transfer. Where the Customer's own processing is already subject to GDPR under Article 3(2), the SCCs are not the appropriate instrument (Recital 7 of Commission Decision 2021/914) and the parties will put in place the mechanism the law then requires.
- Clause 7 (docking) applies. Clause 9: option 2, general written authorisation, with the 30-day notice period in Section 6. Clause 11: the optional independent dispute resolution body does not apply. Clause 17: governed by the law of Poland. Clause 18(b): the courts of Poland. Annexes I, II and III of the SCCs are populated by Annex I, Annex II and Annex III of this DPA.
United Kingdom. Where UK GDPR applies, the SCCs apply as amended by the ICO's International Data Transfer Addendum (version B1.0), with Tables 1 to 3 completed by the corresponding parts of this DPA and Table 4 selecting "neither party".
Switzerland. Where the Swiss FADP applies, references in the SCCs to the GDPR are read as references to the FADP, the Federal Data Protection and Information Commissioner is the competent authority, and the term "member state" does not prevent a data subject in Switzerland from suing in Switzerland.
13. United States - service provider terms
This Section applies where the Customer is subject to the CCPA or a comparable US state privacy law, and controls over any conflicting term in this DPA for that processing.
Wardentry is a service provider (or processor, under the equivalent laws of other states) and processes personal information only for the business purpose of providing the service under the Terms of Service. Wardentry does not: sell or share personal information as those terms are defined; retain, use or disclose it for any purpose other than that business purpose or as otherwise permitted by the CCPA; retain, use or disclose it outside the direct business relationship between the parties; or combine it with personal information received from another source, except as the CCPA permits a service provider to do.
Wardentry will notify the Customer if it determines it can no longer meet these obligations, and will grant the Customer the right to take reasonable steps to stop and remediate unauthorised use. The parties' obligations regarding sub-processors, security, deletion, and assistance are those set out elsewhere in this DPA.
14. Liability
Each party's liability under this DPA is subject to the limitations and exclusions of liability in the Terms of Service, except where Data Protection Law does not permit it - in particular Article 82 GDPR, which governs a data subject's claim for compensation, and which the parties cannot contract out of.
15. Term
This DPA takes effect on acceptance and continues for as long as Wardentry processes Customer Personal Data. Sections 4, 10, 11, 13 and 14 survive its termination.
16. Changes
Wardentry may update this DPA where necessary to reflect a change in the service, in its sub-processors, or in Data Protection Law, provided the change does not reduce the protection given to Customer Personal Data. Material changes take effect 30 days after notice to the organization's administrators, except changes required by law, which take effect as the law requires. Sub-processor changes follow Section 6.
Wardentry may transfer this DPA, together with the Terms of Service, to a successor of the business - including a company incorporated to operate the service. The successor assumes this DPA unchanged and accedes to the Standard Contractual Clauses in Section 12 as data importer, so the Customer is not asked to sign anything again and its rights are unaffected. Notice is given to the organization's administrators 30 days before the transfer takes effect. A Customer that objects may terminate under Section 15 and require deletion under Section 10, on the same footing as an objection to a new sub-processor under Section 6.
Annex I - Description of the processing
A. Parties
| Data exporter / controller | The Customer, as identified in its account: organization name, the administrator's name and email address, and the address given at signup. Activities: organising events or operating a venue at which access is controlled |
| Data importer / processor | Nikita Cherevko. Contact: privacy@wardentry.com. Activities: providing an access-control service for events and venues |
B. Description of the processing
Categories of data subjects
- Attendees - the people on the Customer's guest list, who are issued passes and admitted or denied at a gate.
- The Customer's staff - where the Customer records a staff member's name in a device link label or an access point description. (Staff accounts are processed by Wardentry as a controller and fall outside this DPA.)
Categories of personal data
| Category | Fields | Provided by |
|---|---|---|
| Attendee identity | Name (required); email address, phone number, preferred language (each optional) | The Customer, by manual entry or CSV import |
| Credentials | An identifier for each pass, the credential encoded in the QR code, a short manual entry code, and a link identifier used for the attendee's pass page | Generated by the service |
| Entitlements | Which event a pass is for, its validity window, its entry allowance and entries used, and its status | The Customer's configuration |
| Delivery records | Whether a pass email was sent, when it was last sent, and how many times | Generated by the service |
| Access records | For each presentation of a credential: the time, the gate, whether it was admitted or denied, the reason for a denial, which scanner device was used, and whether the credential was scanned or typed | Generated by the service at the gate |
| Free-text labels | Access point names and descriptions, device link labels, organization and event names - which may contain a person's name if the Customer enters one | The Customer |
Special categories of personal data - none. The service has no field for special category data and the Customer is contractually prohibited from submitting it without prior written agreement. No such agreement is in place at the effective date.
Frequency of the transfer - continuous, for as long as the service is used.
Nature and purpose of the processing - storing an access list; generating, delivering and validating access credentials; evaluating access rules at a gate; recording admissions and denials; producing reports and exports for the Customer; sending transactional email to attendees at the Customer's instruction; deleting data on schedule or on the Customer's instruction.
Duration
| Data | Retained for |
|---|---|
| Attendee records, passes, entitlements | Until the Customer deletes them, or 30 days after termination. There is no automatic expiry |
| Access records (scan history) | 90 days from the scan, deleted by a daily automated purge. There is no per-customer override |
| Erasure records | The life of the organization. They record that an erasure occurred, by which user and when, and how many access records were removed. They contain no personal data of the erased attendee |
| Backups | Until they expire from the database provider's point-in-time restore window |
Transfers to sub-processors - subject matter, nature and duration as set out in Annex III.
C. Competent supervisory authority
The Polish President of the Personal Data Protection Office (Prezes Urzędu Ochrony Danych Osobowych) - determined under Clause 13 of the SCCs where they apply, being the authority of the Member State in which the data exporter is established or, where the exporter is not established in the EEA, of the Member State in which its Article 27 representative is established or in which the data subjects are located.
Annex II - Technical and organisational measures
These are the measures in place at the effective date. They may be updated provided the level of protection is not reduced.
1. Separation of customers' data
Every record in the database carries the owning organization's identifier directly, rather than only through a chain of references, and every query the application makes is filtered on it. Cross-organization references are made impossible by the database's own constraints, not merely unlikely in application code: each parent record exposes a unique pair of its identifier and its organization, and every child record points at that pair. A pass therefore cannot be attached to another organization's event even if a defect asks for it.
At a gate, a credential is resolved with the organization as the leading condition, so another organization's credential is simply absent rather than matched and then rejected. Isolation is covered by automated tests that run against a real database on every change.
2. Credentials
- The secret in a scanner device link is stored as a SHA-256 hash; the secret itself is never persisted. A database dump cannot mint a working scanner.
- The link to an attendee's pass page is derived by HMAC from an identifier, so a database dump yields identifiers and no working links.
- No read endpoint reproduces a pass's QR credential. It is emitted once, when the pass is issued or re-sent.
- Four independent HMAC key sets are used, for QR credentials, scanner device tokens, attendee links, and staff invitations. The blast radius of rotating any one is limited to that purpose.
- QR credentials carry a key identifier, so key rotation is add-new, switch-signing, retire-old rather than a regeneration that would invalidate every pass already in an attendee's inbox. The identifier is covered by the signature, so relabelling a credential invalidates it.
- The application refuses to start if a signing key is blank or names a missing entry, rather than falling back to a default.
3. Access control
- Organizer and staff identity is provided by Firebase Authentication, with email verification required. Wardentry never receives or stores passwords.
- Three roles - administrator, event manager, scanner operator - form the authorisation model within an organization, enforced server-side on every request.
- Platform-level administration is a separate flag that no endpoint can set; it is granted only through direct database access.
- Scanner devices authenticate with short-lived signed tokens exchanged from a revocable link. Revocation takes effect at the next exchange, so a token already issued remains valid for up to 12 hours - this is stated in the Terms of Service so the Customer can act on it.
- Production infrastructure access is limited to named accounts belonging to personnel who require it, under confidentiality obligations. Deployment pipelines authenticate by workload identity federation; there are no long-lived service account keys.
4. Encryption
Personal data is encrypted in transit - HTTPS is enforced for the console, the scanner, the attendee pass page and the API, with certificates managed by the hosting provider - and at rest, by the database and cloud storage providers' platform encryption.
5. Secrets management
Application secrets are held in Google Secret Manager and injected at deploy time. They are not stored in source control, in container images, or in configuration files.
6. Availability and resilience
The application runs on managed, automatically restarted infrastructure with health checks. The database provider offers point-in-time restore. Infrastructure is defined as code and can be rebuilt from it. Deployments are verified by an automated smoke test and rolled back automatically if it fails.
7. Logging, monitoring and audit
- Every presentation of a credential at a gate is recorded - admissions and denials alike - with the time, gate, result, reason, and device.
- Every erasure of an attendee writes an audit record naming the user who performed it and the number of access records removed.
- Application logs are structured and carry the organization and acting user as fields alongside the request method, path and a trace identifier, so an investigation can be scoped to one organization. They are held in Google Cloud Logging. Alerting policies cover server error spikes, abnormal denial ratios, and rate-limit saturation.
- Logs are designed not to contain credentials, secrets, or connection strings.
8. Abuse prevention
Rate limits apply to scanning, manual code entry, signup and email sending, keyed per device link, per IP address and per organization so that one caller cannot exhaust another's capacity. Per-organization quotas bound how much data an account can create.
9. Data minimisation and deletion
- The only attendee field the service requires is a name. Email, phone and language are optional, and the Customer chooses whether to supply them.
- Scan history is purged automatically at 90 days by a scheduled job.
- Erasing an attendee removes the attendee, their passes and their access records in one transaction.
- The audit record proving an erasure happened deliberately contains no personal data of the erased person.
10. Development practices
Changes are reviewed and merged through version control with an automated test suite, including integration tests against a real database that specifically cover isolation between organizations. Schema changes are applied as versioned, forward-only migrations.
Annex III - Sub-processors
Current as of 2026-08-19. Changes are notified under Section 6.
| Sub-processor | Entity and location | Processing performed | Data processed | Location of processing | Transfer mechanism |
|---|---|---|---|---|---|
| Google Cloud Platform | Google Ireland Limited, Ireland (with Google LLC, USA) | Hosting of the application, secret storage, logging and monitoring | All Customer Personal Data in transit through the service; identifiers and technical data in logs | europe-west1 (Belgium) | Within the EEA; onward transfers under Google's SCCs and the EU-US Data Privacy Framework |
| Firebase Hosting (Google) | As above | Delivery of the console and scanner applications | No Customer Personal Data is stored; personal data is fetched from the EU-hosted API | Global content delivery network | As above |
| Neon | Neon Inc., USA | The product database | All Customer Personal Data described in Annex I | aws-eu-central-1 (Frankfurt, Germany) | Data stored in the EEA; provider SCCs for any support access from outside the EEA |
| Brevo | Sendinblue SAS, France | Delivery of transactional email - pass emails to attendees, and service email to the Customer's users | Recipient name and email address, pass link, and delivery metadata | France / EU | Within the EEA |
Firebase Authentication (Google) processes the sign-in credentials of the Customer's own users. Wardentry is a controller for that data, not a processor, so it is not a sub-processor under this DPA; it is disclosed here because customers ask, and it is covered in the Privacy Policy.
Vercel hosts wardentry.com and its feedback form. No Customer
Personal Data is processed there. It is listed in the Privacy Policy rather than
here for that reason.
Signature
This DPA is accepted electronically at organization creation. No signature is required. A Customer that requires a signed counterpart may request one from privacy@wardentry.com.
| Customer | Accepted by the person creating the organization, on its behalf. Wardentry records the acceptor's account, the version accepted, and the timestamp |
| Wardentry | Nikita Cherevko, by publication of this version |
Version history
| Version | Date | Change |
|---|---|---|
| 1.1 | 2026-09-15 | Early-access waitlist discontinued; Vercel row now names the feedback form instead. No change to Customer Personal Data handling |
| 1.0 | 2026-08-19 | First published |