Data processing addendum

This page describes how Instroc handles the personal data that ends up in an app you build with it. It is written to be read alongside our Privacy Policy, which covers your own Instroc account, and our Subprocessors page, which lists every vendor involved.

It is a description of how the product works, not legal advice. If you need this as a signed agreement, or you need terms that differ from what is below, write to [email protected].

1. Parties and roles

You are the controller of the personal data your app collects. You decide what it asks people for, what it stores, and what it is used for. Your app's users are your users, not ours.

Instroc is the processor. We store and process that data to run your app, on your instructions, and we do not use it for anything else. The engineers who can reach a customer app's database are the ones who operate the platform.

2. What is processed

Everything your app puts in its own database and storage:

• Rows in your app's tables. Whatever you designed them to hold, from bookings to orders to messages.
• Files your users upload. The file itself, plus its name, size, type and who uploaded it.
• End-user accounts. Email address, display name, avatar, whatever profile fields your app adds, sign-in method, and the times they last signed in. Passwords are stored as a hash, never as the password.
• Organisations, where your app groups its users into them: which organisation someone belongs to and their role in it.
• Application logs your app writes, and the delivery records of any webhooks it receives.

Separately from your app, we hold your own Instroc account and billing details. Those are covered by the Privacy Policy.

3. Why it is processed

To run your app and nothing else: to serve requests, keep it online, take backups you asked for, meter what it uses so it can be billed, and investigate a fault when one is reported. We do not sell it, we do not use it for advertising, and we do not use it to train AI models.

4. How long it is kept

For as long as your app holds it. When you delete a project, its database and stored files are deleted with it after a 30-day window during which you can still restore it.

• Backups are kept for 30 days and then deleted automatically.
• Save points, which let you roll an app back to an earlier state, are kept for 30 days.
• When one of your users deletes their account through your app, their data goes immediately. See section 7.
• Cloudflare, who run the databases, keep a rolling 30-day point-in-time history of every database so one can be restored after a mistake. A deleted row is gone from the live database at once and ages out of that history within 30 days.

5. Subprocessors

We use third-party providers to run the platform. Every one of them, what it is for and which region it operates in, is listed on the Subprocessors page. We post changes to that list at least 30 days before a new provider begins processing personal data, so you have time to review it.

6. Where the data is kept

When you create an app you can choose to keep its data in the European Union. That choice is made once, at creation, and cannot be changed afterwards, because moving a live database between regions is not something we can do without taking your app down and risking its data. The settings page shows which one your app has.

• European Union. The app's database is created in Cloudflare's Western Europe region, and files your users upload are stored in a bucket under EU jurisdiction. Backups of that app are stored there too. EU residency always means Western Europe, whatever database location is set for the workspace or the app.
• No residency requirement. The default. A new app's database is created in Cloudflare's Western Europe region unless another location is chosen: by the workspace owner as the workspace default, by the person creating the app, or by Roc when the app's description says where its users are. Apps created before database locations were introduced keep their database where it was first created. Files your users upload are stored in our standard bucket, which is not tied to one region.

Two things are the same either way. Your own Instroc account and billing records live in Supabase, in the European Union, as listed on the Subprocessors page. And your app's code, as opposed to its data, is served from Cloudflare's global network so that it loads quickly wherever a visitor is; it is your app, not anybody's personal data.

Where a provider operates outside the European Economic Area, transfers rely on Standard Contractual Clauses or an equivalent safeguard. The Subprocessors page says more.

7. Export and deletion

Your app can offer its own users both, and you can do either on their behalf from the Users tab when a request reaches you by email instead.

• Download my data. A JSON file with their account, every row in your app's tables that belongs to them, their organisation memberships, and a download link for each file they uploaded. It never contains another user's rows, a password hash, or a sign-in token.
• Delete my account. Removes their account and sessions, their rows, their uploaded files and the files themselves, and their organisation memberships. You can mark individual tables to keep their rows instead, for records you have to retain such as invoices; a kept row has its link to the account removed, and its other columns are left as they are, so a table that also stores a name or an email in its own columns should be set to delete rather than kept. Either way, one entry is written to your app's audit log naming what was removed and who asked.
• Deleting the whole project takes everything with it, on the window in section 4.

What both of these cover is decided by your app's own table settings: a table counts as holding someone's records when you have told us which of its columns identifies them. A table you never set that on is neither exported nor deleted, and the Users tab lists any it had to skip so you can see which.

Two things are deliberately kept. If an address has unsubscribed from your app's email, that record stays: it is a do-not-contact list, and erasing it would start the mail again. And the audit entry keeps the deleted account's email address, because a record of a deletion that cannot say who it was about is not a record anyone can rely on.

These two rights are not only European. The access and deletion rights in United States state privacy laws, California's CCPA and CPRA and the states that followed them, are the same two actions, so an app that offers Download my data and Delete my account answers those requests as well. Sector rules such as HIPAA call for agreements this addendum does not provide.

8. Security

The measures that apply to every app on the platform:

• A separate database per app. Your app's data is not in a shared table with another customer's.
• Access rules on every table. You choose who can reach each table's rows, and the rule is applied by the server on every request rather than by the app's own code.
• Secrets are encrypted before they are stored. The API keys and tokens you add to an app are encrypted at rest.
• Passwords are hashed, and sign-in sessions are held in cookies that scripts on the page cannot read.
• An audit log in your app records account deletions: who was deleted, what it removed, and who asked.
• Rate limits on sign-in, sign-up, password reset, data export and account deletion.

9. If something goes wrong

If we become aware of a personal data breach affecting your app's data, we will tell you without undue delay, and in any case within the time the law requires, with what we know at the time and what we are doing about it. We will keep you updated as we learn more, and we will help you with any notification you have to make to your own users or to a supervisory authority.

10. Your users' requests

Requests from your app's users come to you, because you are their controller. The tools in section 7 are how you answer them. If one reaches us instead, we will point the person at you rather than act on their data ourselves.

A starting point for your own customers

If your customers ask you for the same thing, the text below is a starting point. Fill in the parts in square brackets and check it against what your app actually does. It is not a finished agreement and it is not legal advice.