Privacy

Who is responsible for what

Not important B.V. is the controller for the data of the people who hold a Kadrenta account: your name, your email address, and how you use the product.

For everything a studio puts into Kadrenta (its projects, its shots, its files, and the contact details of its clients and freelancers) the studio is the controller and Not important B.V. is the processor. The studio decides what goes in, who may see it, and how long it stays. If you are a client or a contact of a studio and you want your details changed or removed, the studio is who to ask; we will help them do it, and the tools for it are described below.

The data processing agreement is at /processing-agreement, and a studio agrees to it when it is created. It sets out what Not important B.V. does with the personal data a studio puts in, on whose instructions, and which sub-processors are involved. Like this page it is a draft that no lawyer has reviewed, and the studios that were already here before it existed have not been asked to agree to it; they are being spoken to in person.

What is collected

Two kinds of thing, and it is worth keeping them apart.

• From you, because you signed up: your name, your email address, whether you have confirmed that address, and your password, stored only as a hash, never as the password. If you upload a profile photo, that too.
• From your browser, because a session has to work: a session record with the address you connected from and the browser you used. It expires after thirty days and is deleted when you sign out or reset your password.
• What your studio puts in: projects, shots, tasks, files, comments, review versions, and an address book of the people the studio works with. Some of those people have no account here and never will, a client who leaves a comment on a review link is recorded by the name they gave.
• What a client leaves behind, if your studio asks them to. On a shared canvas, a client holding a personal link can record a walk-through: their voice, and their picture as well if they switch the camera on. It is off unless the studio turns it on for that canvas, it is stored with the studio's other files, and the lead on that job or a studio manager can throw it away.
• What you connect yourself: if you link a Discord account, your Discord id and display name are stored so notifications can reach you. No Discord token is kept. If you connect your own Claude, the calls it makes are logged by name of the tool and nothing else, never the question and never the answer.
• An email address you leave on the front page, if you do, and whether you have confirmed it. Nothing else, and see below for what happens to it.

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 anywhere that follows you between pages or between sites. There is nothing to opt out of, which is also why there is no cookie banner.

One script does come from somewhere else, and it is named here rather than left for you to find in the page source. Three forms that anybody on the internet can reach, signing up, asking for a password reset, and the address field on the front page, load Cloudflare's Turnstile, which is the check that tells a person from a script without asking you to pick out traffic lights. It is a security measure and nothing else: it sees the address you are connecting from, it can set a cookie of Cloudflare's own on those three pages, and it is 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 of which emails were sent stores a one-way hash of the address rather than the address, and never the subject or the body. The counter that stops password guessing stores a hash of the connecting address rather than the address. The log of what your own Claude asked for stores the name of the tool and nothing about the request.

Cookies

All set by this site itself, all strictly necessary, and none of them used to follow anybody anywhere. These are the ones that stay on your machine. Signing in with a second step sets one more, which lasts ten minutes and is only there while you finish the step, and the security check described above can set one of Cloudflare's own, on the three pages it runs on.

• A session cookie, so you stay signed in. Thirty days.
• A share link cookie, remembering which review links this browser has already typed the passphrase for. A day. It is not what grants access, the link is checked against the database on every request, so revoking one takes effect immediately.
• A review visitor cookie, so a client's comments on a review link stay attached to them. A day.
• A view-as cookie, used by a studio administrator checking what somebody else can see. One hour.
• A shell-memo cookie, holding a copy of what the last page already knew so the next one can draw instantly instead of waiting on a database round trip. Thirty seconds, and every write of your own throws it away.

Where it is stored

In the European Union, by choice and not by accident. There is one exception, it is a copy and never your own file, and it has its own row below rather than a footnote.

Who else is involved

These are the only companies that touch anything. Each of them is here because the product cannot work without it, and each is named so the list can be checked against reality.

• Cloudflare: hosting, file storage, the network in front of it, and the check on the sign-up and password-reset forms that tells a person from a script.
• Neon, the database.
• Resend: outgoing email: confirmations, password resets, invitations, notification digests.
• Zoho, the mailbox that receives mail sent to the support address.
• Stripe, payments, and only if your studio takes a paid plan. You are sent to Stripe's own page to pay, so a card number or a bank account number never passes through this product and is never stored here. What we hold is the identifier Stripe gives your studio and what your subscription is; what Stripe holds is between you and them.
• Google, only if you choose to sign in with a Google account. Google then tells us your address and your name, and knows you signed in here. Sign in with an address and a password instead and Google is not involved at all.
• Discord, only for a studio or a person who connects it, and only for the notifications they asked to receive there.
• Anthropic, only if you connect your own Claude to your studio. The connection runs the other way from what people expect: your Claude asks this product for things, using your own Anthropic subscription. Nothing is sent to Anthropic by this product on its own, and there is no AI feature in it.

Connecting your own Claude

A studio can let the people in it reach it from their own Claude. It is off until an administrator switches it on, and then off per person until they are named, nobody is connected by default and nothing happens to a studio that leaves it alone.

What crosses when it is on: whatever that person can already open here. That includes client companies, contact details and deal values if their switches reach those, and it means the text of that answer sits in their own Claude conversation, under their own agreement with Anthropic rather than under this one. A connection can be ended at any moment from the profile page, and ending it takes the key and the standing permission together.

Writing is a second switch, off on its own, and it comes with a paid plan. With it on, that person's Claude can do a handful of things they could already do themselves by hand: add a task or adjust one, start a job, add a deal, move it along or write a note on it, and put a finished file from a job's dock under a shot or up as a review round for the team to look at. It can never publish anything, send anything to a client, or delete. Every change is recorded on the project's activity with “via Claude” beside it, and the last batch can be undone from the profile page.

How long it is kept

A studio's work is kept for as long as the studio keeps it. While a studio is being used, nothing in it is deleted on a schedule, because a deletion schedule for somebody's production archive would be a surprise and not a service.

There are three clocks that do eventually remove something, and none of them can run without you having been written to first. All three are described in full on the terms page; in short: six months after a studio stops paying, whatever sits over what the free plan has room for is removed, oldest first, after three letters. Two years after anybody last used an account, that account is closed, after three letters. And the record of who signed in and who downloaded an export is kept for a week, or a year on Pro, while the rest of a studio's history is not swept at all.

A deleted file is a fourth: its bytes are held for five days so an administrator can put it back, and destroyed after that. A canvas you throw away is the same five days.

• Sessions: thirty days, and gone at once when you sign out or reset your password.
• The counters that stop password guessing: one day after the window they belong to has closed.
• Half-finished uploads: a day, cleared as soon as a later upload notices them.
• An address left on the front page that nobody ever confirmed: thirty days. A confirmed one stays until it is taken off.
• The record that an email was sent: ninety days. It holds a one-way hash of the address rather than the address, and never the subject or the body.
• The log of what your own Claude asked for: ninety days for the list of tool names, fourteen days for the trail that lets the last batch of changes be undone.

The email address on the front page

If you leave an address on the front page, one message is sent to it: the one asking whether it really was you. Nothing else is sent to an address that has not answered that, and nothing is sent to the list at all today, Kadrenta has no newsletter and no campaigns, and both are deliberately out of the first version.

Every message to that list carries a link to a page with a button that takes the address off, and taking it off deletes the row rather than marking it. The list is not shown anywhere in the product and cannot be listed from it.

Your rights, and what the product can actually do

You can ask for a copy of your data, for it to be corrected, or for it to be deleted. The honest description of what happens then is below, because this product distinguishes two things that most describe as one.

• A copy of everything a studio has typed is a button. It is on *Export* under Admin, it is the owner's to press, and it hands back one zip: everyone the studio knows, every job, shot, task, remark and review round, as plain JSON with a README that explains every file. Your own files are described in there rather than carried: put any set of them on a delivery and press *Download all*, which hands you the originals in one go, as often as you like. Nobody has to ask us for either.
• Removing somebody takes them out of a studio's address book and ends their memberships. The history keeps their name: who made a shot, who approved a version, who was assigned a task.
• Erasing somebody does all of that and overwrites the name in the history as well. What is left reads as *Erased person*, and the email address, phone number and notes are cleared. This is what a real request under the GDPR gets.
• Erasing is a best effort on old activity records. Where a name was written into a log line as text before ids were used everywhere, it is matched and overwritten as a whole value. It is described here as best effort because that is what it is.
• Erasing is refused while somebody still owns a project. That is not a refusal of the request, it is a step in it. The projects are named on screen so they can be handed over first, which is a thing that can be done in minutes, rather than a project silently left with no owner.

What is not there yet

This section exists because a privacy policy that only lists what works is not a description of anything.

• Deleting your own account is a button, and deleting somebody else is not. *Delete your account* is on your profile page; it names, studio by studio, what will happen before you press it: a studio that is yours alone goes with you and everything in it, a studio you share carries on with somebody else as owner, and one you were only a member of simply loses you. It cannot be undone, and where a studio carries on without you it is refused while you still own a project there, so those are handed over first. Removing or erasing somebody else is an administrator's, on a page built for it; if that is what you want and you are not one, ask the studio, or write to support@kadrenta.com.
• A studio can export itself; one person cannot yet export themselves. The button described above hands a *studio* everything it has typed. Somebody who wants a copy of only their own rows (a freelancer who worked on two jobs, a client contact who left remarks) has no screen for that, so it is gathered by hand when you ask at support@kadrenta.com. And the export leaves one thing out on purpose: private tasks, which belong to the person who wrote them and are not the studio's to take.
• The database can be wound back; your files have no second copy. Where the database is hosted it can be put back to any moment in the last seven days, and that was used in earnest on 5 September to recover rows that had been overwritten. Your files have nothing of the sort: no versions, no bin behind the five days described above, and no copy anywhere else. A copy held at a different supplier is written and not yet running, so nothing here protects you against that supplier itself failing. Do not treat this product as the only copy of anything you cannot lose.
• Nobody outside has reviewed the security of this. Everything described in the next section was built and checked by the same people who wrote it.
• No lawyer has read the data processing agreement, and there is no formal breach procedure. The agreement is published and a studio agrees to it when it is created; it was written alongside the product rather than by counsel, and it has not been reviewed by anyone qualified. Studios that were already here before 8 September 2026 have not been asked to agree to it, and are being spoken to in person instead. If your studio needs anything more than that, write to support@kadrenta.com and you will get a straight answer about where it stands. If something goes wrong you will be told, and that is a commitment rather than a process.

How it is protected

Concretely, and only things that are actually in place:

• Every studio's data is fenced at the database itself, not only in the application. The connection the application uses cannot bypass that fence, it is a database role without the permission to.
• Passwords are stored as hashes and never in readable form. A password reset ends every existing session.
• Review links carry a token long enough not to be guessed: 24 characters out of an alphabet of 31, about 118 bits, and that is where the safety of such a link sits. A link can also have a passphrase, can expire, and can be revoked with immediate effect. The passphrase is stored salted and hashed with PBKDF2-SHA-256 and never in readable form, and what keeps it from being guessed is not the cost of that hash but a limit on how often it may be tried, counted per address and per link.
• Files never travel through the application. A browser uploads to and downloads from storage directly, using an address that is signed and expires in minutes, one minute for anything reached through a share link.
• Sign-in, password reset, share-link passphrases and the front-page form all have limits on how often they can be tried, counted per address and per account.
• Everything is served over TLS, with a strict content security policy, and with no third-party script beyond the Turnstile check described under Cookies, which is on three forms and on no page once you are signed in.

Getting in touch

Write to support@kadrenta.com. That address reaches a person.

If you are in the EU and you are not satisfied with the answer, you can complain to your national data protection authority. In the Netherlands that is the Autoriteit Persoonsgegevens.