Data Processing Agreement

1. Roles

You are the controller: you decide what personal data goes into the apps and why. We are the processor: we act on your instructions and for no other purpose. Where we decide something for ourselves — who may hold an account with us, for instance — we are a controller for that, and the privacy notice covers it.

2. Our obligations

• We process only on your documented instructions. Using the apps is the instruction. We will tell you if we believe an instruction breaches data protection law.
• Confidentiality. Everybody with access is bound by it.
• Security. The measures in Annex C, which are technical facts about how the product is built rather than aspirations.
• Sub-processors. Listed at nexcubator.com/subprocessors. We will tell you in advance of adding one and you may object.
• Assistance. We will help you answer a data subject's request, and help with a data protection impact assessment or a consultation with a supervisory authority.
• Breach notification. Without undue delay, and in any event within 48 hours of becoming aware, with what we know at the time rather than waiting until we know everything.
• Deletion. On request or when the account ends — see Annex B.
• Audit. We will provide the information needed to demonstrate compliance and will accommodate an audit by you or an auditor you appoint, on reasonable notice.

3. Your obligations

You confirm that you have a lawful basis for the personal data you put into the apps, that the people it concerns have been told what you are doing with it, and that any address you invite or send a reminder to is one you are entitled to contact.

4. International transfers

There are none. Every service processing customer data runs in AWS European regions — Ireland, and Frankfurt for one control interface. No Standard Contractual Clauses or transfer impact assessment are required. If that ever changes, we will put the mechanism in place and say so here before the change takes effect.

Annex A — what is processed

	Detail
Subject matter	Providing scheduling, video meetings and reminders.
Duration	For as long as the account exists, plus the retention periods in Annex B.
Nature and purpose	Storing, organising, transmitting and deleting personal data so that meetings can be arranged, held and remembered.
Categories of data subject	Your staff who hold accounts; the people they invite or who book time with them.
Categories of personal data	Name, email address, timezone, anything typed into a note or a meeting subject, and the record of who attended what and when.
Special category data	None is required by the apps. If your use involves it — a note describing a medical matter, for instance — you remain responsible for the lawful basis, and the security measures in Annex C apply to it identically.
What is never processed	Meeting audio and video are carried, not stored — there is no recording feature. Messages sent during a meeting travel between participants and never reach our servers. We hold no passwords and no payment card data.

Annex B — retention and deletion

Each record carries its own expiry, set when it is written, and the database deletes it when that time passes. This is a property of the data rather than a job somebody runs.

Record	Deleted
Meeting, its participants and invitations	30 days after the meeting
Booking, and the person's details on it	90 days after the meeting
The cancellation link in a confirmation	120 days
Reminder, and the record of its attempts	30 days after it is sent or abandoned
Application logs	30 days. They record what happened, not what was said
Account holder's name and address	When the account is closed

On the end of the account, or on request, everything not already expired is deleted within 30 days, and backups holding it age out within a further 30. We will confirm in writing when it is done.

Annex C — security measures

Article 32 requires appropriate technical and organisational measures. These are ours, stated as facts about the system:

• Encryption in transit for everything, over TLS, including meeting media.
• Encryption at rest for every stored record, by the managed service holding it.
• No passwords exist. Sign-in is a one-time code to an address already held, so there is no password store to breach. Service credentials between our own apps are stored hashed and are held in a managed secrets store, never in configuration or source.
• Tenant separation is structural. Every database key begins with the customer's identifier and there is no way in the code to construct a read that does not name one.
• Least privilege. Each app runs under its own role, with permissions for the specific operations it performs.
• Access control inside a meeting. Nobody joins without being admitted by the organiser. Somebody waiting is given no means of connecting to the room and is told nothing about it — not its subject, not who is in it.
• Meeting passcodes in addition to the invitation link, which itself carries 256 bits of randomness.
• Rate limiting on every public route.
• Data minimisation by default. No recording, no transcripts, no stored messages, no analytics inside the apps, and no third-party request from any app page.
• Deletion by expiry as set out in Annex B.
• Change control. Every change is version-controlled and reviewed, and every deployment moves a version number that the running service reports, so what is live can always be identified.

We hold no third-party certification today. When we do, it will be named here with its scope and date rather than described in general terms.