Data Processing Agreement

1. Parties and roles

Referred to below as we and you. This agreement is an annex to the terms of use at /terms; it governs the personal data you put into Kadrenta and nothing else.

1.1 The role reverses inside one product, and it is worth being clear about it

For everything you put into Kadrenta, you are the controller and we are the processor. Your projects, your shots, your files, your tasks, the contact details of your clients, the remarks a client leaves on a review link. You decide what goes in, who may see it and how long it stays. We carry it out.

For your own studio account, we are the controller. The name and email address of whoever signs up, whether the address is confirmed, the sign-in records, and what your studio pays. We need those in order to have you as a customer at all, and we answer for them ourselves. What we do with them is described in the privacy policy at /privacy, not here.

Both run through the same screens, which is exactly why they are pulled apart here. This agreement covers the first half only.

2. Subject matter, nature, purpose and duration

Subject matter. Providing Kadrenta: a platform on which a studio manages projects, shots, tasks, files and client contacts, sends work to clients for review, and delivers finished files.

Nature of the processing. Storing, organising, displaying, searching, transmitting and deleting, on your instructions.

Purpose. Providing the service to you, and nothing else. We do not profile, we do not advertise, we do not sell data on, and we do not train any model on what you put in. There is no AI feature in the product; where the product touches an AI assistant at all, it is yours and you connect it (see section 6.4).

Duration. For as long as you have an account, plus the clean-up periods in section 11. This agreement ends when your account ends, except for the clauses that by their nature outlive it: confidentiality, return and deletion, and liability.

3. Your instructions

We process personal data only on your documented instructions. Your use of the product is your instruction: creating a project, inviting somebody, publishing a review link and pressing delete are all instructions, and the product is built so that the ordinary way to instruct us is to use it.

Beyond that:

• Instructions outside the product go to support@kadrenta.com in writing.
• We process outside your instructions only where EU or Dutch law requires it. If that happens we tell you first, unless that same law forbids us to.
• If we think an instruction of yours breaks data protection law, we say so. We are not your legal adviser and this is not a veto; it is a duty to speak up.
• You warrant that you have a lawful basis for what you put in, and that where the people in your footage or your address book had to be told or had to consent, that was done. We cannot see that from here and we do not check it.

4. Categories of data subjects

• People at your studio who hold an account: employees, freelancers, anyone you invite.
• Contact people at your clients, whether or not they have an account.
• Guests who open a review link, a delivery or a shared canvas without an account.
• People who appear in the material you upload: in vision, in audio, or named in a filename. That last group is the one most easily forgotten and, at a film studio, the fullest of the four. Someone who is visible in a shot is a data subject, and we hold that shot.

5. Categories of personal data

See Annex A. In summary: names and email addresses, sign-in and session records, the contact details of your clients, everything you and your people type into the product, the files and video you upload and anything the people in them can be recognised by, what guests leave behind on a shared link, and the subscription details of a paying studio.

We do not ask for special categories of personal data anywhere. No health, no biometrics, no race, no politics, no union membership, and no date of birth, gender or nationality either; there is no field for any of it in the whole database.

Two ways they can arrive regardless, and both are yours to manage rather than ours. Material you upload may contain them, a face in shot being the obvious case; note that no face is ever measured, matched or indexed here, so a picture of somebody stays a picture rather than becoming biometric data. And the free-text fields will hold whatever is typed into them: notes on a person, notes on a deal, remarks on a review, a private message. If either is a routine part of your work it is worth saying so before you sign, because it changes what you need in place at your end.

6. Confidentiality and who can reach your data

Everyone who processes personal data on our side is bound to confidentiality, and here is the honest shape of “everyone”.

6.1 There is one of us. Not important B.V. has no employees today. The director is the only person with administrative access, and that access includes a database role that can read across studios, because running the product requires it. There is no support team, no offshore contractor and no third party with a login. If that changes, this clause changes with it and you will be told.

6.2 There is no impersonation feature for us. Nobody at our end can step into your studio through the product and look around as one of your people. The “view as” control belongs to your administrators, works only inside your own studio, and refuses every write while it is on, so it can show a screen and never act on one. It leaves no record of who viewed as whom, which is worth knowing if you rely on it.

6.3 Our suppliers. The companies in Annex C can technically reach data in the course of running their own service. Each is bound by its own contract with us; section 8 covers what that means.

6.4 Two doors you control, and we do not. Both send your data somewhere we have no relationship with, at your instruction:

• Outgoing webhooks. Your studio can point a webhook at any address it types, and notification content, including client names and deal values, goes there. Whatever is on the other end is your processor, not ours.
• Your own Claude. A studio can let its people reach Kadrenta from their own AI assistant. It is off by default, off again per person, and when it is on, what that person can already open here can end up in their own conversation, under their own agreement with Anthropic. Anthropic is therefore not our sub-processor: nothing is sent to them by the product on its own.

7. Security

See Annex B for the measures actually in place, and for the ones that are not. We keep those two lists in the same annex on purpose. A security annex that only says what works is not a description of anything, and the gaps are the part you need in order to decide.

We review the measures as the product changes, and we will not weaken them below what Annex B describes for the term of this agreement without telling you.

8. Sub-processors

You give us general written authorisation to use the sub-processors in Annex C. Each one is bound by data protection obligations no weaker than these, and we remain answerable to you for what they do.

Changes. We tell you at least 30 days before we add or replace one, and you have those same 30 days to object. If you object on reasonable data protection grounds and we cannot resolve it, you may terminate the part of the service that depends on that sub-processor, without penalty for the unused remainder.

9. International transfers

Kadrenta is built to keep data in the European Union, and mostly it does. The database is in Frankfurt. Files are in a storage bucket created under the European Union jurisdiction, which is a commitment at the storage layer rather than a preference. Request handling is pinned to the Frankfurt region.

There are two exceptions, and neither is hidden in a footnote.

Cloudflare Stream holds a viewing copy of a .mov or .mkv, because no browser plays those formats. Stream is the one Cloudflare product with no region to choose, per upload or per account, so that copy may sit outside the EU. The file you uploaded stays in the EU bucket and downloading gives you that file.

Stripe processes subscription and payment data and is a US company that moves data internationally under its own terms. This applies only to a studio on a paid plan.

A third is conditional on your own choice: signing in with Google, and connecting Discord, each involve a US company, and each is optional.

The mechanism. Both transfers rely on the European Commission's Standard Contractual Clauses (implementing decision 2021/914), module two, controller to processor. Cloudflare and Stripe each incorporate those clauses into their own data processing terms, which we have accepted, and we rely on them as the safeguard for the transfer rather than signing a separate set with you. Both publish their own transfer impact assessments.

Still open: whether our particular use needs an independent transfer impact assessment on top of theirs. Section 16.

10. Assisting you with data subjects' rights

If somebody asks you for access, correction, deletion, restriction, objection or portability, that request is yours to answer. We help, and much of the help is a button rather than a ticket:

• A copy of what your studio has typed is a button. Export, under Admin, pressed by the owner. It hands back one zip of plain JSON with a README explaining each file: the people you know, your jobs, shots, tasks, remarks and review rounds.
• Removing a person takes them out of your address book and ends their memberships. The history keeps their name: who made a shot, who approved a version.
• Erasing a person does all of that and overwrites the name in the history too. What is left reads as Erased person; the email address, phone number and notes are cleared. It is a screen your administrators already have.

10. Five honest limits, and you should know them before you promise anything to a data subject

• Erasing overwrites; it does not delete the record. The person's row stays, with its identifier and its links to what they did, and the identifying fields are emptied and the name replaced. In data protection terms that is thorough pseudonymisation rather than erasure. It is the right shape for a production archive, where deleting the row would take a shot's history with it, but it is not the same thing and this document will not call it the same thing.
• Erasing does not touch uploaded files. Material that person uploaded stays where it is. If a request covers footage they are in, that is a separate job, done by hand or by your own administrators deleting the files.
• It clears the name, address, phone and notes, and today it leaves three fields standing: the LinkedIn address, the Instagram handle and the name the person is filed under. That is an oversight rather than a design decision, it is written down here because it is one, and until it is fixed those three are cleared by hand on request.
• On old activity records it is a best effort. Where a name was written into a log line as text, before identifiers were used everywhere, it is matched and overwritten as a whole value, never as part of a longer one.
• It works per studio, and it is refused in two cases. Erasing in one studio leaves that person untouched in another. It is refused while they still own a project, and for whoever founded the studio. The first is a step in the request rather than a refusal of it: the projects are named on screen so they can be handed over first, which takes minutes, instead of a project being left silently ownerless.
• And two limits on the export. It carries the database rows and not the bytes of your files; the archive describes your files and you download them from a delivery instead. Fourteen tables are left out on purpose, among them private tasks, notification records and bug reports, and any table over 25,000 rows is truncated with the truncation stated in the manifest. Share-link tokens and passphrase hashes are redacted.
• Where the product has no screen for what is asked, we do it by hand at support@kadrenta.com, within a reasonable time and at no charge for a request of ordinary size. One thing there is no screen for at all: a single person asking for a copy of only their own rows. That is gathered by hand today.

11. Retention, return and deletion

Nothing about your work is deleted on a schedule while your studio is being used and paid for. A deletion schedule over somebody's production archive would be a surprise, not a service. The complete list of the times that is not so is in Annex A, section A.3, and every figure in it is read from a constant in the code.

At the end. When this agreement ends you choose: we return your data or we delete it. Either way we then delete the copies we hold, except where EU or Dutch law requires us to keep something, in which case we keep only that and only for as long as required. The export described in section 10 is available for as long as your account is.

Two things about that, stated rather than assumed.

There is no “delete this studio” button. A studio is dissolved today only as a side effect of its last remaining member deleting their own account; an owner with even one teammate hands the studio on instead. So deletion at the end of this agreement is done by us, by hand, on your written request. It works, and it is not self-service.

The database rows and the stored files go in two separate steps. They are not one transaction. If the second step fails partway, files can be left behind that nothing points at any more. We would rather write that down than describe a clean sweep we cannot demonstrate.

When. Return or deletion happens within 30 days of this agreement ending, at your choice, unless European Union or member state law requires us to keep something for longer. If that happens we tell you what is kept and why.

12. Personal data breaches

If personal data of yours is breached, we tell you without undue delay after becoming aware of it, with what we know: what happened, which categories and roughly how many people and records, the likely consequences, and what we are doing about it. If we do not have all of that at once, you get it in stages rather than late. Notifying your supervisory authority within your own 72 hours is yours to do; getting you what you need in time is ours.

We also help you, so far as it is reasonable, with any notification you have to make to the people affected.

No fixed hour count, and that is deliberate. Plenty of agreements promise 24 or 48 hours. This one does not, because a promise like that has to be keepable at three in the morning and there is nothing today that would wake anybody, see the note directly below. Without undue delay is the standard the GDPR itself sets, and it is the one we can actually meet.

This clause is a commitment and not yet a procedure, and the difference matters. There is no documented incident runbook, no on-call rotation and no security monitoring that would wake anybody at three in the morning. We are one person with an alerting-free stack. What makes this clause worth something today is that the company is small enough that “becoming aware” and “telling you” are the same afternoon; what would make it worth more is a procedure, and that is in section 16.

13. Records and demonstrating compliance

We keep a record of the categories of processing we carry out for you and make available the information you reasonably need to show that we are meeting Article 28. In practice that is this document, its annexes, and an answer to a question at support@kadrenta.com.

14. Audits

You, or an auditor you appoint, may audit our processing for you, no more than once a year unless there has been a breach or a supervisory authority requires it, on reasonable notice, during business hours, under confidentiality, and without touching another studio's data.

Two things you should not expect from us today. There is no ISO 27001 certificate, no SOC 2 report and no external penetration test to hand you instead, and nobody outside has reviewed the security of this product. Everything in Annex B was built and checked by the same person who wrote it. An audit of us today is a conversation and a look at the code and the configuration, and it is better that you know that before you plan one.

15. Liability, term, governing law

Liability. Each party is liable to the other for damage caused by its own failure to keep to this agreement. Our total liability to you under this agreement is limited to the fees you paid us for the service in the twelve months before the claim arose. That limit does not apply to fraud, to wilful misconduct, or to anything the law does not allow to be limited.

And one thing a limit cannot do. Article 82 GDPR gives a data subject a claim directly against a processor, and nothing written here takes that away. The limit above governs what the two of us owe each other; it does not shorten what either of us owes the people whose data this is.

Term. This agreement runs for as long as we process personal data on your behalf, which is as long as your studio uses the service. The obligations that are meant to outlive it do outlive it: confidentiality (section 6), and return or deletion (section 11).

Governing law and forum. Dutch law governs this agreement, and a dispute goes to the district court of Amsterdam. Neither choice affects your right to take a matter to your own supervisory authority instead.

Annex A.1: categories of personal data

Annex A.1: a word on what goes to Stripe and what stays here

When you take a paid plan we send Stripe your studio's name, the email address of whoever pressed the button, your country, your VAT number if you gave one, and the number of seats. The card, bank or iDEAL details and the billing address are typed on Stripe's own page and held by Stripe. There is no card field in this product, and no card, bank, VAT or address column in our database.

Annex A.2: what is deliberately not collected

There is no analytics on this product: no Google Analytics, no Plausible, no PostHog, no pixel, no tag, and nothing that follows anyone between pages or between sites. There is no cookie banner because there is nothing to refuse. One third-party script exists and it is named rather than left to be found in the page source: Cloudflare Turnstile, the check that tells a person from a script, on the three forms anybody on the internet can reach, and on no page once you are signed in.

Where a log is needed it is built to hold as little as it can. The record that an email was sent holds a one-way hash of the address rather than the address, and never the subject or the body. The counter that stops password guessing holds a hash of the connecting address.

Annex A.3: how long things are kept

Every figure here is a constant in the code, not a rounding.

Your work. Kept as long as you keep it. Two clocks eventually remove something, and neither can run without you having been written to first:

183 days after a studio stops paying, whatever sits over what the free plan has room for is removed, oldest first, after three letters.

731 days after anybody last used an account, that account is closed, after three letters at 90, 30 and 7 days beforehand.

Both of those refuse to run until the last letter has demonstrably gone out, not merely fallen due.

A deleted file is the third thing that goes, and its shape is worth stating exactly. Its bytes become eligible for destruction five days after you throw it away, so an administrator can put it back within those five days. A discarded canvas is the same five days. Five days is the earliest, not a deadline: the clean-up runs opportunistically when somebody in your studio completes an upload, so a studio that stops uploading can keep discarded bytes indefinitely. If you need a file gone by a date, ask us and we will do it by hand.

Records the product keeps about running itself.

Annex B.1: what is in place

Separation between studios, at the database itself. Every table that holds a studio's own work carries the studio, every query filters on it, and since migration 0057 force row level security is switched on. The word force is the point: the owner of the tables falls under the policies too, so the separation does not rest on the care of the code above it. The role the application connects with cannot bypass it, and there is a test that fails if that ever changes.

The exception, because it should be stated rather than found. About twenty-five tables carry no studio at all, and by design: they are account-level or they exist before anybody is signed in. Your account, your session, your two-step secret, your profile, your notification preferences, the record of which terms you agreed to, and on the public side the waiting list, the mail log and the password-guessing counters. One person has one account and appears in several studios through several records, so a studio column would be the wrong shape. These tables are protected by the application and by connecting as a role that does not own them, not by a tenant policy. None of them holds a studio's work.

Passwords are stored as hashes, never in readable form. A password reset ends every existing session.

A second step at sign-in, per person, on any plan. A studio on Pro can require it of its own crew.

Files never travel through the application. A browser uploads to and downloads from storage directly, over a signed address with a short life: fifteen minutes to upload, five minutes to download, and one minute for anything reached through a share link.

One way out. Everything a studio shares goes through one service: a token of 118 bits, which is not guessable, an optional passphrase stored as PBKDF2-SHA-256 over 100,000 rounds, which is the ceiling the platform allows, an expiry date, and revocation and rotation that take effect immediately, including against a browser that has the page cached. What actually stops guessing at a passphrase is the attempt counter on the link rather than the hashing cost. There is no second route that skips those rules. An expiry date is required only on a delivery link; on a review link the screen offers a set of windows with no “never” among them, and on a canvas link it can be left empty, which makes a link that does not expire. Choosing that is yours, and it is worth knowing you are choosing it.

Permissions per person and per project, with a separate layer for outside collaborators.

Rate limits on sign-in, password reset, share-link passphrases and the public forms, counted per address and per account, plus a check that tells a person from a script on the three public forms.

One front door. The application is reachable through Cloudflare's proxy and nowhere else: no workers.dev address and no preview URLs, both switched off explicitly and held there by a test.

Everything over TLS, with a strict content security policy and no third-party script.

An activity log of what happens inside a studio.

No secrets in the repository, and no customer data in it.

The database can be wound back seven days, and scheduled snapshots are kept. That is not theoretical: it was used in earnest on 5 September 2026 to recover rows a script had overwritten.

Annex B.2: what is not in place, stated plainly

• Your files have no second copy. No versioning, no bin behind the five days in Annex A.3, and no copy at another supplier. A copy held elsewhere in the EU is written and not running, because it waits on a machine that has to be bought. Nothing here protects you against the storage supplier itself failing. Do not treat Kadrenta as the only copy of anything you cannot lose.
• No external security review. No certification, no audit report, no penetration test.
• No formal incident procedure, no monitoring that alerts out of hours. See section 12.
• Nothing watches whether the backup ran. The design calls for a heartbeat that turns a screen red when a nightly copy has not landed. It is described and not built, which matters because a backup runner is the one machine whose loss you notice last: nothing breaks, the copy just quietly stops growing.
• The keys that let a connected AI assistant or the desktop tool talk to your studio are stored unencrypted in the database, which is the behaviour of the authentication library used. Clearing them and shortening their lifetimes is a known task, not a done one.

Annex C: sub-processors

Annex C: two notes on the list above

Anthropic is deliberately not on this list. Where a person connects their own AI assistant, the data lands in their own conversation under their own agreement; nothing is sent by the product on its own. See section 6.4.

Cloudflare Stream was live for four days before it reached a supplier list, and Google for ten days, and Stripe for one. Those were found and fixed on 5 and 6 September 2026. The rule this list is kept to, learned from that: a sub-processor list that names services you do not use is not a smaller error than one that omits services you do.

16. What is still open

Honestly, so that a lawyer sees the gaps rather than assuming there are none, and so you can see what you are being asked to accept.

Written 8 September 2026 against the code as it stood, and read through since by somebody who is not a lawyer. If something below stops matching what the product does, this document is wrong and the product is right: it is meant to move with it.

• 1. It has been read through, and no lawyer has read it. Both halves of that are worth having plainly. Somebody other than its author has gone through this text since it was written, which is the pass that catches a clause that has stopped matching the product, and most of what has ever been wrong here was exactly that. That person is not a lawyer. So section 15, drafted along the lines these agreements normally take (a twelve month fee limit, Dutch law, Amsterdam), and the periods in sections 8, 11 and 12, which are numbers rather than the word “reasonable”, have still not been through anyone qualified, and neither has the judgement of whether what is written here is enough. That review is worth buying before a customer arrives who runs one of their own.
• 2. Whether our use needs its own transfer impact assessment for Stripe and Cloudflare Stream, on top of the ones those two publish. Section 9.
• 3. The breach procedure itself. A commitment exists; a runbook, a contact route and any monitoring do not.
• 4. The file backup. Until the second copy is running, Annex B.2 stands as written and this agreement promises no more than that.
• 5. The MCP token storage, and the missing backup heartbeat. Annex B.2.
• 6. Erasure is pseudonymisation, and a lawyer should say whether that is enough. Section 10 describes exactly what the button does. Whether that satisfies an Article 17 request in your line of work, and what to write to a data subject about it, is not a question this draft can answer. The three related gaps are that erasing does not reach uploaded files, that it works one studio at a time, and that it leaves the LinkedIn address, the Instagram handle and the filing name standing. That last one is a bug rather than a judgement call and should simply be fixed.
• 7. Deleting a studio is a manual job, and destroying discarded file bytes has no guaranteed deadline. Sections 11 and Annex A.3. Both are the sort of thing a customer assumes is automatic, so both are named here rather than left to be discovered.
• 8. The studios that were here before this page was have not agreed to it. There is somewhere to sign this, and it is a required tick box at the moment a studio is created. It records the three things that make a ticked box an agreement: who agreed, when, and which version. So a studio created from 8 September 2026 onwards holds a dated record of the text it accepted, and can hold that record against the date at the top of this page; a studio created before then holds no such record. Those studios are being spoken to in person rather than shown a screen that asks them to tick something after the fact. Until it is agreed, there is no processing agreement, however good this draft is.
• 9. Whether this text should also be published in the product is settled, and this page is the answer. Until 8 September 2026 it was a document in the repository with no route, no link and no button anywhere in the app. It is now a page you can read, link to and keep, which is what the tick box in item 8 points at: agreeing to a document nobody outside the repository can open would not have been agreement to anything.