Data processing agreement

Version 1, in effect since Oct 24, 2026.

About this agreement

This agreement is between the organization that uses ORG-APP ("you"), as controller, and VantageTech Apps Limited ("we", "us" and "our"), as processor. VantageTech Apps Limited is a federal corporation incorporated under the laws of Canada and registered in Ontario, corporation number 1827120-8.

It forms part of our Terms of service, and applies whenever we process personal data for you in providing ORG-APP. You accept it with the terms, by checking the box that names both, and we keep a record of which version you accepted. If you need a signed copy, email legal@org-app.com.

It is meant to meet the rules that data protection laws set for an organization that has another process personal data for it, such as Article 28 of the EU and UK General Data Protection Regulation, the accountability principle of Canada's Personal Information Protection and Electronic Documents Act, and the rules of the other laws listed in clause 1.

If it conflicts with the terms, this agreement comes first for anything about personal data. If standard contractual clauses, or similar clauses, apply between us, they come first.

1. Meanings

Data protection law means the laws on personal data that apply to the processing. Depending on where you and your people are, they include Canada's Personal Information Protection and Electronic Documents Act; Singapore's Personal Data Protection Act 2012; India's Digital Personal Data Protection Act 2023 and its rules, and the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules 2011, as each applies; Nepal's Individual Privacy Act 2018; the data protection laws of the United States and of its states; and the EU and UK General Data Protection Regulation.
Personal data, processing, controller, processor, data subject and personal data breach mean what data protection law says they mean.
Your personal data means the personal data we process for you in providing ORG-APP, as Annex 1 describes.
Sub-processor means another company we engage to process your personal data.
Owner means a person who holds the Owner role in your organization on ORG-APP.

2. Our roles

2.1 You are the controller of your personal data, and we are your processor.

2.2 If you process some of it as a processor for someone else, we are your sub-processor for it, and you are responsible for passing that controller's instructions on to us.

2.3 For the data we use for our own purposes, we are a controller and not your processor: your organization's account, its billing and support, the record of its agreement to our terms, what it sends us to be verified, and the records we keep to secure ORG-APP. Our Privacy policy covers that data.

3. Your instructions

3.1 We process your personal data only on your documented instructions. Your instructions are the terms and this agreement, the way you set up and use ORG-APP, and anything else you ask of us in writing, for example in a support request.

3.2 We will tell you if we believe an instruction breaks data protection law, and we need not follow it until you confirm or change it.

3.3 If a law requires us to process your personal data in some other way, we will tell you before we do, unless that law forbids it.

3.4 We do not use your personal data for our own purposes, we do not sell it, and we do not share it for advertising.

4. Confidentiality and staff access

4.1 Only our staff who need to, in order to provide, support or secure ORG-APP, can reach your personal data, and each of them is bound to keep it confidential.

4.2 Our staff look at your organization's records only:

on a support visit you ask for; or
where we must, to restore lost data, carry out a request you make under data law, or deal with a security incident.

4.3 A support visit needs a written reason, the reference of your request and a fresh code from the staff member's authenticator app. It is read-only and lasts at most 30 minutes. It cannot see pay, safeguarding or confidential board business. Every page of your organization shows a banner while it lasts, and its start and end are recorded in your organization's audit trail.

5. Security

5.1 We keep in place the technical and organizational measures in Annex 2, to protect your personal data against accidental or unlawful destruction, loss, change, disclosure or access.

5.2 We may change these measures over time, but never so that they protect your personal data less.

5.3 You are responsible for how you use ORG-APP's own controls: who you give accounts and roles to, two-step sign-in, withholding names between units, document sensitivity, and your own storage bucket if you use one.

6. Sub-processors

6.1 You authorize us to use the sub-processors listed in Annex 3.

6.2 The current list is on our Sub-processors page, which we keep up to date.

6.3 Before we use a new sub-processor, we tell every Owner of your organization by email at least 30 days ahead, and show it on that page as coming.

6.4 You may object to a new sub-processor, on reasonable grounds about data protection, within those 30 days, by writing to legal@org-app.com or through Help & support. We will discuss your concern and try to find a solution. If we cannot resolve it, you may end the agreement before we start using the new sub-processor, and we refund any fees you paid in advance for the time after that.

6.5 We make each sub-processor agree in writing to data protection obligations no weaker than those in this agreement.

6.6 We remain responsible to you for how our sub-processors process your personal data.

6.7 When we stop using a sub-processor, we take it off the list straight away.

6.8 Services that you or your people choose to use with ORG-APP are not our sub-processors, and their own terms apply. They are: your own Stripe account for payments for bookings and classes, Sign in with Google, a video service of your own, a payment page you link to and the company that runs it, your own storage bucket, the push services of your people's browsers, and the calendar apps your people subscribe with. When a booking is paid by card through your Stripe account, we give Stripe the event's title, the booking code and the booker's email address, and never an attendee's name or date of birth. When a place on a class is paid by card, we give it the course's and the class's names, the place's reference and the learner's own email address, and never the learner's name or date of birth. ORG-APP sends a payment page nothing; when you import a file of payments downloaded from one, ORG-APP reads it to record the payments it matches to your bookings and class places, and keeps neither the file, nor the names in it, nor the rows it did not match.

6.9 ORG-APP's own video rooms run on our own video server, meet.org-app.com, which Hetzner Online hosts for us in Helsinki, Finland, as Annex 3 lists. A call's audio and video, and the names people join with, pass through it while the call lasts, and it does not record them. If you prefer, hold your calls on a video service you control and add its link to the meeting: ORG-APP then sends nothing about that call to our video server.

7. Transfers between countries

7.1 We are in Canada. ORG-APP's database and servers are in Singapore. Our sub-processors process your personal data in the places Annex 3 lists, and our staff reach it from Canada.

7.2 We transfer your personal data to another country only as this agreement allows, and with the safeguards data protection law requires. We protect it by contract with each sub-processor, so that it keeps a level of protection comparable to the one this agreement gives it. Where a law requires a particular safeguard for data leaving a country, such as the European Union's standard contractual clauses, we put it in place, with you and with our sub-processors.

7.3 While your personal data is held in another country, the courts, law enforcement and national security authorities of that country may be able to reach it under that country's laws. If one of them asks us for it, we act as clause 3.3 says.

8. Helping you with people's requests

8.1 ORG-APP lets you answer most requests from the people in your records yourselves:

people can correct many of their own details, including their contact details and emergency contacts;
each person can download a copy of their own data from Your account;
your Owners and Organization admins can download one person's data as a file, including what that person's own copy leaves out, as far as their own keys allow, and also for a person whose account is suspended; each download is recorded;
your administrators can correct records, download lists from their pages, and close accounts;
your Owners and Organization admins can erase a person: their identity is replaced by a mark saying that someone was erased, their personal details are deleted, and their files are deleted from storage, while the records your organization must keep, such as its books and its audit trail, stay whole;
an administrator of your whole organization can download an archive of your records in Settings › Your data.

8.2 For anything ORG-APP cannot yet do for you, your Owner, or another administrator of your whole organization, can ask us in Help & support, choosing "A request under data law". We act on it within 30 days, and sooner if you tell us the law requires it. We can erase a person from your records for you, on such a request.

8.3 If someone sends us a request about your personal data, we pass it to you without undue delay, and we do not answer it ourselves unless you ask us to.

8.4 We also give you reasonable help to meet your obligations about security, breach notices, data protection impact assessments and consulting a data protection authority, taking into account what we know about the processing. We charge nothing for this help unless a request is unreasonable or repeated, and we tell you first.

9. Personal data breaches

9.1 If we become aware of a personal data breach affecting your personal data, we tell your Owners without undue delay, and in any case within 48 hours.

9.2 We tell you what we know, and what we do not know yet: what happened, the kinds of data and roughly how many people are affected, the likely consequences, what we have done and will do about it, and who you can talk to. We send more as we learn it.

9.3 We take reasonable steps to contain the breach and limit its harm, and we keep a record of it.

9.4 You decide whether to tell the people affected and any authority, and we help you do so.

9.5 Telling you about a breach is not an admission of fault by us.

9.6 If you notice a possible breach, tell us in Help & support, choosing "A suspected data breach", or at legal@org-app.com.

10. When the agreement ends

10.1 While your organization is open, an administrator of your whole organization can download its archive, each of your people can download their own data, and we will help you export any records the archive does not hold. Do this before your organization is closed: a closed organization is read-only, and you may not be able to download from it.

10.2 When your organization leaves, we close it: it becomes read-only, so your people can still sign in and see their records, but nothing can be changed, and nothing is deleted.

10.3 When your Owner asks us to erase your organization, in Help & support ("A request under data law", then "Close and erase"), we agree a day with your Owner, at least 7 and at most 90 days ahead, so that your organization can download its archive first. A second member of our team must approve the erasure before it runs, and we tell your Owners the day once it is approved; your Owner can ask us to cancel it until then. On that day we delete every record of your organization that we hold: every person's account and details, bookings, checks, pay records, messages, reports and files, your organization's audit trail, its pages and its web address, which is retired and never given to anybody else. We keep your organization's name, its invoices and payments to us, and our own record that the erasure was done, with counts and nothing else. We then tell your Owners that it is done. Until the erasure, your personal data stays protected by this agreement, and we use it for nothing; ORG-APP's own removals of old data go on as before. On your Owner's request, we also erase any one person from your organization at any time.

10.4 Copies in our backups remain for as long as those backups are kept, which our database host's plan sets. Until then they stay protected by this agreement, and we do not use them.

10.5 We keep any of your personal data for longer only where the law requires us to, only for as long as it requires, and still protected by this agreement.

10.6 Files in your own storage bucket stay there under your control, and deleting them is up to you.

11. Information and audits

11.1 We make available the information you need to check that we meet this agreement: this agreement, Annex 2, the sub-processor list, and answers to your reasonable questions.

11.2 When you ask, we give you extracts of your organization's audit trail, including the record of every support visit.

11.3 You, or an independent auditor you appoint who is bound to confidentiality, may audit our compliance with this agreement. You give us 30 days' notice, and audits take place no more than once a year, unless there has been a personal data breach or an authority requires one. Each of us pays its own costs, unless the audit finds that we have materially broken this agreement.

11.4 An audit must not put other organizations' data at risk, or disrupt ORG-APP.

12. Your responsibilities

12.1 You have a lawful basis for the processing you instruct, and you give people the notices, and get the consents, that the law requires. That includes consent from a parent or guardian where a child is concerned, and the care the law asks for with health information, background checks and other sensitive data. Your own privacy notice can be linked from every public form you run on ORG-APP, in Settings › Your data › Your privacy notice.

12.2 Your instructions to us comply with data protection law.

12.3 You put into ORG-APP only the personal data you need for your purposes.

13. Liability, term and changes

13.1 Each party's liability under this agreement is subject to the limits in the terms.

13.2 This agreement lasts for as long as we process your personal data.

13.3 When we change this agreement, we tell every organization's Owner by email at least 30 days before the new version takes effect, and keep a record of whom we told; a "What changes" page shows exactly what changes, line by line.

Annex 1: Details of the processing

Subject matter and duration

The processing of your personal data to provide ORG-APP to you, for as long as the terms apply and until your personal data is erased as clause 10 describes.

Nature and purpose

Storing, organizing, finding, showing, changing and deleting your records as your people use ORG-APP.
Sending the emails and notifications ORG-APP sends for you, such as invitations, reminders, booking confirmations, thank-yous to donors and broadcasts.
Hosting your website, public booking pages, Give pages and certificate checks.
Translating a message for its reader, where Translate is switched on and they ask for it.
Making the archives and downloads you ask for.
Backing up and restoring.
Supporting you, and keeping ORG-APP secure.

The people whose data is processed

Your staff, volunteers, contractors, interns and members.
Your board and committee members.
Trainees and course participants, including people from outside your organization who join your classes that allow guests.
People from outside your organization whom you ask to teach a class.
The emergency contacts your people give you.
Donors, and people who give or promise to give through your Give pages.
Suppliers, and the people you deal with at them.
Outside contacts, such as speakers and trainers.
People who book your events, and the attendees they book for, who may include children.
People who pay you, by card, by bank transfer or through a payment page.
People who sign up on your website, or join or are invited to your groups.
Anyone else named in your records, messages or documents.

Kinds of personal data

Names, including preferred names and names in another script, pronouns, photos and staff numbers.
Contact details: email addresses, phone numbers and home addresses.
Date of birth, gender where a booking asks for it, nationality and languages.
Emergency contacts.
Roles, units and positions, with start and end dates and reasons for leaving.
Hours: clock-ins and clock-outs, including card scans at a door kiosk, timesheets, corrections and reasons for absence, and, if a person's browser shares it, their device's location when they clocked in or out.
Leave: requests, types, dates, reasons and balances.
Training, courses and classes: the courses and classes a person is on, and their answers to a class's joining questions; attendance at each session, which the register can suggest from whether the person was in the session's video call for at least half of it; work handed in, quiz answers, marks, feedback and reviews by classmates; which lessons of a self-paced course they marked as read, and their progress along a learning path, worked out from their courses; completions, renewals and certificates; and, for a paid class, what is owed and paid for a place.
Checks: background checks, references, right-to-work checks and qualifications, with outcomes, dates and reference numbers, and copies of identity and right-to-work documents.
Pay details: pay rate, bank account, tax reference and pension enrollment.
Bookings: the booker's name and contact details, attendees' names and, where asked, dates of birth and gender, answers to booking questions, waivers agreed to, check-ins, rooms and payment records; and a program's checklist: travel details such as a passport's number and expiry, an emergency contact, agreements, and photos or PDFs of documents such as a passport, a visa, insurance or a medical form.
Giving: donors' names, contact details and addresses, their contact preferences, notes about them, and their gifts, pledges, promises, thank-yous and statements, with the links those emails carry to the donor's own page, kept only as a hash.
Money: ledgers, budgets, levies, expense claims and receipts, bills, suppliers' contact and payment details, and bank statements with their lines; the bank accounts, QR codes, payment pages and Stripe accounts your units are paid through; and the payments recorded for bookings and places on classes, posted to the unit's books, with the reference Stripe or a payment page gave each.
Governance: meetings and attendance, minutes, votes, declarations of interest and resolutions.
Messages and their attachments, reports of messages, posts, comments and who has read them, reports and their notes and photos, and documents with their versions and who opened them.
Video calls: who joined and when, who asked to share their screen and who was let, who recorded a call to their own computer and when, and answers about recording.
Follow-up records about people who signed up on your website or at an event.
Your Participants directory: for each person who registered for or attended your programs, or was on your courses, with an account or without one, their first, middle and last name, email address, mobile number, WhatsApp number where it differs, gender and date of birth, and the programs, courses, groups and follow-ups they took part in, read from your own records. Nothing else a program asks goes into it.
Audit records: who did what and when, and for some actions the IP address and browser used.
Device records: the push subscriptions of people who allow notifications.
Guest accounts, where you let people who book or are invited sign in with an emailed code: the email address each signs in with, the name it gives, when it was made and last signed in, and the devices it is signed in on. For an outside speaker you book from Resources, also the answer links in the emails sent to them, kept only as a hash, what those emails last told them, and the push subscriptions of the devices they turn phone notifications on for.
People from outside your organization who join or teach your classes: the name and email address each signs in with, and when the address was proved.
People outside your organization who checked "Stay in touch" after a program or a call: the email address, the name given, where and when they asked, which words they agreed to, and, once withdrawn, a coded form of the address with when and how.

Special categories and other sensitive data

Depending on how you use ORG-APP, your personal data may include:

health information, in answers to booking questions and to a class's joining questions, in medical forms sent for a program's checklist, and in reasons for leave or absence;
information about criminal records, in background checks;
identity documents and right-to-work status;
financial information, such as bank accounts, pay, tax references and gifts;
data about children;
the location of a person's device when they clock in or out;
information that reveals beliefs, or another special category, where belonging or giving to your organization reveals it.

You decide whether to put such data into ORG-APP. ORG-APP gives you ways to limit who sees it, which Annex 2 describes.

How often

Continuously, while you use ORG-APP.

Where

Singapore, and the places Annex 3 lists.

Annex 2: Security measures

Keeping organizations apart

Every organization's records are held apart by row-level security in the database, enforced by the database itself.
ORG-APP's servers connect to the database with a role that cannot bypass that security, and we check this against the live database.
Public pages, such as booking pages, Give pages and certificate checks, are held to one organization in the same way.

Access within your organization

Each person's powers come from their roles in each unit, and are read from the database on every request, so a role taken away stops working at once.
Personal details, pay details and safeguarding checks each need their own permission, and every read of a person's pay details is recorded.
A unit can withhold its members' names from the levels above it, and lists, messages and downloads respect that.
A document is seen only by its owner and the people and units it is shared with, and shares can expire.
Reads of sensitive and restricted documents by anyone but their owner are recorded, and restricted documents are left out of archives.
Confidential board business is kept from people who may see only ordinary board business.
Every download of records is recorded: who took it, what it held and how many rows. A download of the whole organization, or of 25 or more people's contact, pay, giving or safeguarding details, is emailed to every Owner and administrator as it happens.
Where a unit is paid, such as its bank account, QR code, payment page or Stripe account, is changed only by an Owner or Organization admin who has confirmed it's them; each change is recorded and told at once to every Owner and Organization admin, in the app and by email, with the account shown only in part. A Unit coordinator or Finance officer can only propose a change, which another Owner or Organization admin approves.
A class's joining answers marked sensitive are shown only to the people from your organization who run the class, one person's at a time and only when they choose to look, and each look is recorded.
A person from outside your organization whom you ask to teach a class reaches that class alone: its sessions and the register; its learners' names, and their work and marks; their answers to its joining questions, except any marked sensitive; and its materials, which they can add to; and they can set work, mark it and give feedback, and send messages to the class. They never reach your other classes, your directory of your people, contact details beyond any a learner gives in answer to the class's joining questions, answers marked sensitive, or the course's own page or its settings. Their access is checked on every request, and ends 30 days after the class's last session, at once if the class is canceled, or sooner if you end it.

Signing in

Passwords are hashed with bcrypt.
The codes in emailed links, sign-in codes, booking links, donors' links and invitations are stored only as SHA-256 hashes, and expire.
Two-step sign-in with an authenticator app is available to everyone, and is required by default for anyone with an organization-wide role, and for anyone who can see pay or safeguarding checks or post to the books.
Signing in, and public forms, are rate-limited by account and by network address, and sign-in locks after repeated failures.
Public forms can require Cloudflare Turnstile's check that a person is sending them.
A sign-in lasts 12 hours, unless the person chooses to have their device remembered: then it lasts as long as they chose, up to 90 days, and ends after 14 days unused. You set the longest allowed in Settings › Organization, one for administrators, never more than 30 days, and one for everybody else, or turn remembering off. A remembered device is not asked for the authenticator code again until the remembering ends; the password always is.
Each sign-in is recorded with the device's description, when it was signed in to and last used, and until when it is remembered, and is checked on every request: a device signed out, past its time, or belonging to a person whose password was changed or who was suspended is refused at once. People see their devices, and can sign out of them, under Account › Where you're signed in, and are told when a device becomes remembered.
The most sensitive changes, such as where payments go or downloading the whole organization, need the person to confirm it's them within the last 15 minutes: their password, and their authenticator's code if they use one.
An Owner or administrator who signs in from a browser new to their account is told by email.
Signing in with Google never creates an account, and a person who uses two-step sign-in still has to give their code.
Guest accounts, which you can turn off in Settings › Organization, sign in with a 6-digit code emailed to the address, which works for 10 minutes and five tries and is kept only as an HMAC. A code is sent only to an address that has a booking, a place on a booking, an invitation or a guest account with you, and the screen says the same whatever the address; an address that belongs to one of your members gets no code. A guest account holds no role and opens only the guest's own bookings, places, calls and receipts, read from your records at the time; it is signed in on a device for 90 days, its holder can sign out of any device and delete it, and turning guest accounts off signs every one of them out at once.
Somebody from outside your organization who joins a class that allows guests passes the check that a person is sending the form, proves their email address with an emailed code, and confirms that they are 18 or older; they then sign in with an emailed code, hold no role, and reach only their own learning. A person from outside whom you ask to teach a class signs in with an emailed code, and an address that already belongs to one of your members cannot be asked.
An outside speaker you book from Resources sees, from a guest account, only their own part of the program — its days and place, their own lines and their times, and their answer — never anybody else's name, nor the title of anybody else's line. Their emails' answer links answer that one booking and nothing else, are kept only as a hash, work only while the email address is still the one they were sent to and until the program ends, stop when the booking is called off, and change nothing until a button is pressed. Their phone notifications say only that their part changed, was called off or is tomorrow, and go only to devices they turned on and are still signed in on, which signing the device out or deleting the account turns off; an address that becomes one of your members gets none.

Encryption

All traffic to ORG-APP uses HTTPS, with HTTP Strict Transport Security.
The connection between ORG-APP's servers and its database is encrypted, and the database's certificate is checked against a pinned root.
Files are kept in a private bucket, and each is reached through a signed link that expires within 15 minutes, apart from the download links an administrator asks for in an archive, which last one day, or seven if the organization chooses.
The credentials of an organization's own storage bucket, and the secrets of people's authenticator apps, are encrypted with AES-256-GCM.
Stored data is encrypted by our providers: Supabase encrypts the database, and Cloudflare encrypts the files in R2, with AES-256, as each states in its own security documentation.

Records and monitoring

An audit trail records changes: who made them and when and, for some actions such as activating an account, resetting a password or agreeing to our terms, from which IP address and browser, which are blanked after 12 months.
Each audit entry is hashed when it is written, the entries are sealed into a chain every 15 minutes, and the chain is checked every night.
A separate register records reads of sensitive data: answers about medical, dietary and accessibility needs on bookings, a class's joining answers marked sensitive, a person's private details, message attachments, program files and reports, and certificates.
Our staff's actions in our own console are recorded in a platform audit trail.
Failed pages and scheduled jobs are reported to our team by email: a failed page by where it failed and the kind of error, never the error's own words; a failed job by its errors, with any email address in them taken out.

Our staff

Our console needs a password and a code from an authenticator app at every sign-in.
Each console role has only the powers its job needs.
Support visits are limited as clause 4.3 describes.
Everyone who can reach organizations' data is bound by written confidentiality obligations and is trained in data protection before they are given access.

Keeping data to a minimum

Card payments for bookings and classes give Stripe no attendee's or learner's name or date of birth, and ORG-APP keeps nothing of the card.
A file of payments imported from a payment page is read to record the payments it matches, and is not kept, nor are the names in it or the rows it did not match.
Push notifications carry only a title and a link.
Pages seen while signed in are kept on a device only where its person chose to have it remembered and you have not turned this off in Settings › Organization: the installed app's main pages, never a browser tab's, and the person's recent messages (the 40 newest conversations in their inbox, and the last 50 messages of each of the 20 they opened most recently), as they were last shown to that person, so the app and Messages open at once, even with no signal. They are removed when the person signs out; once the device has not connected while they were signed in for 72 hours they are never shown again, and are deleted the next time ORG-APP is opened on it; and they are never kept for a device signed in for this time only or during a support visit. A device keeps one person's copy at a time, under a key that names nobody, and never a message's attachments or a draft.
Apart from those, what a phone keeps for use without a connection names nobody, apart from what the person themselves is waiting to send.
Location is recorded only at the moment a person clocks in or out, and only if their browser shares it.
A booking asks for a date of birth or gender only where the organization asks for it, or where a ticket or a room needs it.
Translate sends one message, only when its reader asks, and stores neither the message's text nor the translation.
An organization's verification certificate is deleted from storage as soon as we decide on it.
Deleted files are removed from storage 30 days after they are deleted, and unfinished uploads after 24 hours.
The copy of each email kept for sending is deleted 30 days after it is sent, and notifications that have been dealt with are deleted after 90 days.
Sign-in codes, with the address and network they were asked from, are deleted after 30 days.
The record of where somebody is signed in is deleted 30 days after the device was last used; it holds no network address.
A guest account is deleted 12 months after its last sign-in, once nothing is coming up for it, with the devices it was signed in on; and where a guest account is signed in is deleted 30 days after it was signed out, or its 90 days ended. Deleting a guest account leaves your bookings as they are.
The answer link in an outside speaker's email, kept only as a hash with the address it was sent to, is deleted the day after it stops working, when the program ends or the link is withdrawn, and at once when the booking is called off or the contact is removed.
A guest account made for a class — a learner who joined a class as a guest, or a facilitator from outside your organization — is erased 12 months after the last class it was on ended, or after it was made or last signed in, if later, as Erase this person erases: its name, address and every way in go, and the class's register, work and marks then read "Erased person". It is kept longer while it holds a place or a request on a class, money owed for a place, a group, or a certificate still in force, while its own record in the Participants directory has had activity in the last 3 years, or while its address is on a booking, a donor's record, a promise, a follow-up, a request for news or a guest account you keep.
The link in a donor's thank-you or statement email, kept only as a hash with the donor it opens, is deleted 30 days after it stops working; until then, a link that has run out can still ask for a fresh one to be emailed to the donor.
"Stay in touch" is never checked for anybody, and nobody can be added to the list by hand: an address you invited, or a guest account signs in with, is added when its holder checks the box, with an email saying how to stop, and a booking's address, or one somebody typed, only once its holder confirms from a link, kept only as a hash, that works once and for 7 days. Every news email carries a one-click way to stop, which works at once, as deleting the guest account or erasing the person does. Asking for news is kept until it is stopped; once withdrawn, only a coded form of the address, when and how are kept, for 2 years, and then deleted. An email address typed to ask for news and never confirmed is deleted 7 days later, when its link runs out.
Outside contacts nobody has booked for two years are deleted.
The answers to a booking's questions are deleted 12 months after the event ends, apart from a signed waiver, which stays with the booking.
The answers a person gave to a class's joining questions are deleted when they leave the class or are taken off it, and otherwise 12 months after the class finished or was canceled, apart from a signed waiver, which stays with the place; answers sent with a request to join a class are deleted if it is declined or withdrawn, and otherwise at the same time.
An attendee's date of birth, gender, middle name and own email and phone are blanked 12 months after the event ends; the booking itself, each attendee's name, payments and check-ins are kept.
A person's record in the Participants directory (their first, middle and last name, email, mobile, WhatsApp, gender and date of birth, and the programs, courses and follow-ups they took part in) is deleted 3 years after their last activity, unless they have an account; the yearly blanking of a booking's details does not empty it.
A traveler's files for a program's checklist (a passport's photo page, a visa, insurance, a medical form) and the checklist details marked sensitive, a passport's always, are deleted 90 days after the program ends, or 30 or 365 days, as its organizers choose; that each thing was done, and checked, stays with the booking.
Where, and on which device, somebody clocked in or out is blanked 90 days after the punch; the time and the unit stay.
The network address and browser on the audit trail, and the network address on the register of sensitive reads, are blanked after 12 months, and the audit trail is sealed again.
An email that was never delivered is deleted 90 days after it was queued.
A notification not read, or not dealt with, is deleted after 12 months.
The mail provider's reports of bounces and complaints are deleted after 7 days; the list of addresses mail no longer goes to is kept, because it is what stops mail to them.
A photo taken for a report's notes and never sent with it is removed a year after the report was sent.
The record that somebody read a post in a group is deleted 30 days after they read it.
Safeguarding checks and identity documents are kept as long as the organization's own policy says, and deleted by the organization from the person's page.
Everything else is kept while the organization uses ORG-APP, until it leaves and asks for it to be erased; the schedule is shown to every organization in Settings › Your data.

Backups, recovery and incidents

Backups: ORG-APP's database is backed up as our database host provides backups for our plan.
We have written procedures to restore data, and to roll back a faulty release without touching data.
We have a written procedure for incidents: notice it, record it, work out what it touched, contain it, tell those affected, recover, and review it within a week.

Annex 3: Sub-processors

The current list is on our Sub-processors page, and it is the one that applies. When this version of the agreement was published, it was:

Supabase: hosts ORG-APP's database, which holds every organization's records. In Singapore.
Vercel: hosts ORG-APP and runs the servers that process every request, and keeps their logs. The servers are in Singapore; requests reach them through Vercel's network, which spans many countries; the logs are kept in the locations Vercel's own terms describe, which may include the United States.
Cloudflare: stores uploaded files, such as documents, photos, receipts and attachments, in its R2 storage, in the locations Cloudflare's own terms describe for it, which may include the United States. Runs Turnstile, the check that a person is sending a public form, which receives information from the browser and the IP address, on its global network.
Resend: delivers the emails ORG-APP sends, including invitations, reminders, booking confirmations, thank-yous and broadcasts. In the locations Resend's own terms describe, which may include the United States.
Google: runs VantageTech's own email (Google Workspace), so it holds what you send to an org-app.com address, such as a support request by email. In the locations Google's own terms describe, which may include the United States.
Anthropic: translates one message into its reader's language when they ask, where Translate is switched on. It receives that message's text. In the United States.
Stripe: takes card payments for ORG-APP plans when online payment is switched on. It receives the email address of the Owner or administrator who pays, and your organization's reference. In the locations Stripe's own terms describe, which may include the United States.
Hetzner Online: hosts ORG-APP's video server, meet.org-app.com, which carries the audio and video of ORG-APP's video rooms, and the names people join with, while a call lasts, and records none of it. In Helsinki, Finland.

Our own operations console, which we use to support and bill organizations, reads your organization's registry entry: its name, plan and status, how many people and units it has, and the names, email addresses and roles of its administrators. The console is our own software, and only our staff use it. It reads this from ORG-APP when one of them opens it, through a connection that ORG-APP checks on every request: each call must be signed with a key that only the console and ORG-APP hold, and a call that is unsigned, altered, out of date or repeated is refused. It keeps no copy of what it reads: its own record of what our staff did there names your organization only by ORG-APP's reference for it. The console is hosted only by companies on this list; before any other company hosts it, we add that company to the list, as clause 6.3 describes.