Data processing addendum

Status of This Document

This was written by the engineering team and has not been reviewed by a lawyer. The technical parts — who the subprocessors are and what each one receives — are rendered straight from one register, so Annex II below cannot drift from the subprocessors page — a test holds both of them to that register. Keeping the register itself in step with the code is a check a person does rather than one the build enforces, and it has lagged the code three times since 20 August 2026. The security measures in Annex III are written by hand. The contractual parts need review before signature, and four things they assume are not in place: the transfer impact assessment that the Standard Contractual Clauses in clause 7 require has not been done, we hold no Data Privacy Framework certification, the sub-processors run on their own published terms rather than on terms we have imposed, and there is no SOC 2 report. Each is said again where it belongs, below.

1. The Parties

This addendum is between the customer named in the order or account (“the Customer”) and CRALIO LLC, a single-member limited liability company formed in the State of Wyoming, United States, under filing ID 2026-002065886, of 5830 E 2nd St, Ste 7000 #38271, Casper, WY 82609, United States (“Cralio”). It forms part of the terms of service and, where they conflict on the processing of personal data, this addendum governs.

2. Scope and Roles

This addendum applies where Cralio processes personal data on the Customer’s behalf. The two roles are not symmetrical, and which is which decides who answers for what:

• The material you upload — video containing faces and voices, static creatives, fonts, audio — and the free text you write into a job, which reaches a provider and can therefore carry whatever personal data you chose to type: you are the controller, we are the processor. We do not decide why that material is processed. You do, by submitting a job.
• Your own account, billing and usage data — who signed up, what was bought, what was charged: we are a controller in our own right, and process it under the privacy policy, not under this addendum.

“Personal data”, “processing”, “controller”, “processor”, “sub-processor”, “data subject” and “personal data breach” have the meanings given in the GDPR. “Data Protection Law” means the GDPR, the UK GDPR, the Data Protection Act 2018, and any other data protection law applying to a party.

3. Your Instructions and Warranties

We process personal data only on your documented instructions, except where the law requires otherwise: when we open a safety incident, the material an operator names is copied to a held location that no deletion sweep and no storage rule reaches, and it stays there until a person removes it by hand. Clause 10 says what that means for deletion. Otherwise those instructions are this addendum, the agreement, the jobs you submit through the application — which are the operative instruction for each act of processing — and anything further we agree in writing. If we think an instruction breaches Data Protection Law we will tell you, and may suspend the affected processing until it is resolved.

You warrant that you have a lawful basis for the processing you instruct, and specifically that you hold the informed permission — recorded, not assumed — of every identifiable person whose face, voice or name is in what you send and of anybody you describe in what you send— in a file you upload or in the text of a job alike; Annex I names both as categories of data subject, a person can be brought into a result by words alone, and a file carries a person without carrying their face when the narration speaks their name or the copy on a creative prints it — covering reproduction of their likeness or voice by an AI model, the languages the result will speak, where it may be published, how long the data will be kept, which companies will process it, named or as a class that includes them, and that a provider may use the material to improve its own models where its terms allow that. What that has to cover is set out in full in the biometric notice. This mirrors Terms §3 and is not diluted here. You are responsible for the accuracy, quality and legality of what you upload, and for how you obtained it.

4. Confidentiality

Everyone on our side who is authorised to process your personal data — our own people and anyone working under our direction — is bound by an obligation of confidentiality, and access is limited to those who need it to provide, support or secure the service. The sub-processors in Annex II are not among them: they process under their own published terms rather than under terms we have imposed, and clause 6 says so and says why.

5. Security

We implement appropriate technical and organisational measures under Article 32. The ones actually in place are on the security page, together — deliberately — with the ones that are not. We may update them, but not in a way that materially reduces the level of protection.

6. Sub-processors

You give general authorisation for us to appoint the sub-processors listed below, and we remain fully liable to you for what they do. Each of them processes under its own published terms rather than under terms we have imposed. Annex II below records, per provider, what it receives, whether it may use that to improve its own models and how long it keeps it, under a single date — printed above the table rather than per row — on which a person last read every provider’s terms. For the dubbing provider the answer is that it may, by default; an opt-out exists on request and we have not asked for one. Clause 7 names the absence of terms of our own among the three things still outstanding, because Module Three’s Clause 9 contemplates terms we impose; the un-requested opt-out is one consequence of not having them.

Notice of change. When we add or replace a sub-processor that a job chooses — one your material is sent to because of the work you asked for — we post it on the subprocessors page and the new row appears in Annex II below with the day it was announced, and nothing of yours reaches it until you have accepted our register of subprocessors with that company on it. Four of the eleven rows in Annex II are of that kind and carry the mark; the other seven are the infrastructure your account itself runs on, and the end of this clause says what authorises those instead. A row that needs your authorisation says so in Annex II in a column of its own, and the first job you submit after such a change stops at the submit button: the screen names the documents that have moved, the register among them as a link to the page that names each company, says what it receives, where it is and how long it keeps it, and links to that company’s own terms — and it refuses the submission before anything is priced, before any credit is reserved, and before any file of yours leaves our storage.It is one acceptance for the register, not one per company, and that is a limit worth your knowing: if you would rather not accept a company we have added, you cannot decline it and keep the rest — what you have instead is the notice, the refusal before anything moves, and the 14 days to object and the refund below. What you accept is the register’s exact words, identified by a SHA-256 of the page, recorded against your account with the date and kept for as long as the account is; if we add a company, widen what one receives, change where it is or how long it keeps material, the acceptance you gave stops counting and we ask again before the next job runs. You can read back the exact text you accepted at any time.Between 11 and 14 September 2026 this was a permission per company, with a checkbox of its own for each, and you could decline one and go on using every tool that did not reach it. That was withdrawn in favour of the single acceptance above. Permissions recorded in that window stay on your account and stay readable at the words they were given at.This replaced a period of notice on 11 September 2026. Until then this clause promised the posting would state a start date at least 30 days after it, and a customer who never read the posting was taken to have agreed once the days ran out. The new rule is the stronger of the two and is elected as such in §7 below: no material of yours moves to a new company on the strength of your silence. Every row in Annex II published before that date says in its own Since column that no advance period ran for it, because none of them had one. You have 14 days from the posting to object on reasonable data protection grounds; if we cannot resolve the objection, you may terminate the affected part of the service and have back any prepaid fees for the unused period — a refund we make by hand in Stripe, since nothing in the system computes one, and an exception to the rule in Terms §4A that plan fees are not refundable. It is announced by e-mail as well as here, and that changed on 14 September 2026 when the register became a document in its own right: it is one of the entries in workers/legal_versions.json, and the notice that goes out for a changed document goes out for this one. That message cannot be unsubscribed from. It carries no waiting period for this document, because there is none to carry: a change to the register binds when it is posted, and the tick at the submit door is what makes sure you have seen it. The build enforces this. A check that runs on every push — tests/test_subprocessor_notice.py — fails the build when any code path names a provider that no door asks your permission for, whether the provider is named by a mode a customer can submit or by a credential this repository holds. It fails a build; it is not a gate on the server. Our releases are run by hand from a working tree, so what stands between an unasked-for provider and this clause is this check going red and a person heeding it — and, at run time, the refusal at the submit door described above, which is not a build check and does stop the job. Three limits, stated because a control described wider than it is, is worse than none: the check does not fire when we widen what a provider already in Annex II receives; it cannot see a recipient that needs no credential from us; and it knows a credential by the shape of its environment-variable name, read by that literal name in our own source, so a credential named outside that shape or reached indirectly would be invisible to it. Before 7 September 2026 nothing in the build checked this at all, and this register lagged the code three times from 20 August 2026, each lag corrected on the subprocessors page rather than hidden. One case sits outside the authorisation and only one: where a sub-processor stops being available and we cannot deliver the service without a replacement, we may appoint one at once and post it the same day, and your 14 days to object and the way out above run from that posting. A new product or a new feature is not that case.

The seven rows that carry no mark, and what authorises them. The tick above is for a company a job chooses. Seven rows in Annex II are not of that kind: the host, the object store, the account database, the payment processor, the mail relay and the two channels our own alerts go to. Two of them do receive your material and their rows say so — a file you upload passes through the host in transit, and the object store is where your files live. What the seven have in common is that no submission selects them, none avoids them, and nothing keeps working if one is declined: your file is in the bucket before any provider is chosen, and the database is where the permission itself would have to be recorded. So they are authorised by the terms you accept — clause 3 names where your files and your words are kept, in those words, and your acceptance of the terms is recorded, digested and refused on at all five submit doors like any other document. Replacing one of them is a change to that clause and to Annex II, not a silent substitution.

A job already accepted runs to completion. An authorisation is given for a submission. A job you submitted under the words in force at the time is finished under them, and a row that moves afterwards is asked about at your next submission rather than applied to work already under way — refusing a job already paid for, to somebody who is not at a screen, would strand it.

The current list is the subprocessors page, and both it and Annex II below render from one register in this repository rather than from a copy typed into either page. A build check fails when a provider’s terms have not been re-read within 120 days, so it is not reviewed annually either. A human last read every provider’s terms on 2026-08-30.

7. International transfers

Start with where we are. Cralio is a company in the United States. If you are in the EEA or the UK, the company deciding what happens to your personal data is in the United States from the moment you open an account, even though the account itself is stored in Ireland — so the first transfer is sign-up and not the first job, and it is ours rather than a supplier’s. Beneath it, the parts sit in different places:

Several of the sub-processors below operate in the United States, and instructing a job that uses one transfers the relevant content there.

It is not uniform, and your own risk assessment turns on which:

The mechanism, and the elections it requires. The transfers described above are made under the European Commission’s Standard Contractual Clauses (Decision 2021/914), which are incorporated into this addendum by reference. This addendum forms part of the terms of service and takes effect when the agreement does — clause 12 below says so — and the Clauses take effect with it, so they are in force for every customer from that moment rather than waiting on a signature. A signed copy is available on request and changes nothing about when they began:

• Module Two (controller to processor) governs the transfer from you to us, you being the controller of the material you upload and we your processor.
• Module Three (processor to processor) governs each onward transfer from us to a sub-processor named in Annex II.
• Clause 7 (docking) applies, so a further controller may accede. Clause 9, Option 1 (specific prior authorisation) applies, on the terms in clause 6 above: we engage a new sub-processor for your material only with your specific prior authorisation of that sub-processor, given before anything of yours is transferred to it — and that authorisation is your acceptance of our register of subprocessors with the company’s row on it, one acceptance for the register and not one per company. The period Option 1 leaves blank is filled: the option asks the parties to say how long before the engagement the request for authorisation must be submitted, and this addendum answers before the engagement, with no fixed minimum and no deadline on your decision. The request is our register of subprocessors, which carries for each company what Clause 9(a) calls the information necessary to decide — what it does, where it is, what it receives, whether its own terms let it train on that, how long it keeps it, and a link to those terms — named as a link on the screen you submit from, before the first submission that would reach the new company is accepted; that submission is refused until you have accepted the register, and you may take as long as you like over it. A fixed minimum would add nothing: under Option 2 the period is the protection, because the company is engaged when it expires whether you read the posting or not, and under Option 1 the engagement is conditioned on your authorisation, so the interval only has to be long enough for the request to reach you first. Annex III of the Clauses is Annex II of this addendum, which is the list Option 1 points at; it is generated from one register on every build, so it cannot fall out of step with the subprocessors page.This replaced Option 2 on 11 September 2026. Until that day this clause elected Option 2 — general written authorisation, with 30 days of advance notice and a right to object — and the change is a strengthening of your position rather than a relaxation of ours: under Option 2 a customer who never read a posting was authorised by the calendar, and under Option 1 nothing moves until you say so. Your 14 days and the way out in clause 6 are unchanged and run from the posting. Clause 6 says what stands behind the authorisation: a refusal at the submit door, above the price and above any transfer, and a check that fails our build on every push where code names a provider that no door asks your permission for. Clause 6 also names the three cases that check cannot see. Clause 11’s optional independent redress-body paragraph does not apply.
• Clause 17: the Clauses are governed by the law of Ireland. Clause 18(b): disputes are for the courts of Ireland. Chosen because Ireland is where your account data is held and because Clause 17 requires the law of an EU member state that allows third-party beneficiary rights.
• The Annexes of the Clauses are the three Annexes of this addendum, and the second and third are the other way round, because the Clauses order them differently from this document. The Clauses’ Annex I is the parties and the description of the transfer, which is this addendum’s Annex I; the Clauses’ Annex II is the technical and organisational measures, which is this addendum’s Annex III; and the Clauses’ Annex III is the list of sub-processors, which is this addendum’s Annex II. It is written out rather than left to the order of the headings because Clause 9(a) Option 1 refers to Annex III by name.
• Where you are in the United Kingdom, the Information Commissioner’s International Data Transfer Addendum (version B1.0) applies to the Clauses, with this addendum as its Tables 1 to 4 and no additional protections selected.

Three things are still outstanding, and none of them is a drafting matter. We are not certified under the EU–US Data Privacy Framework; the Clauses above stand alone rather than beside it. The transfer impact assessment those Clauses require has not been completed: until it is, the Clauses are in force and the assessment behind them is not, which is a real gap and one you should weigh before signing. And the sub-processors named in Annex II process under their own published terms rather than under back-to-back terms we have imposed, which is what Module Three’s Clause 9 contemplates and we have not done; clause 6 above says the same thing from the other side. The privacy policy states the first two in the same terms.

8. Assistance With Data Subject Requests

If someone contacts us directly about your data, we will not answer substantively — we will pass it to you without undue delay and help you respond. Where the product already does the job, it does it: you can delete a job and its files from the dashboard as soon as that job is not running — a running job has to be stopped first, which is a button on the same page, and Delete appears once it has stopped — and you can read your job records for as long as their files are stored, on the dashboard and the gallery, and every credit movement on the billing page, permanently. Since 12 September 2026 a row leaves the dashboard and the gallery when its files are deleted; what the job was, what it was asked for and what it cost stays on the billing page, which is where a record of past work is read. There is no export or download of either yet; ask us and we will send them.

We will give reasonable assistance with data protection impact assessments and prior consultations, in proportion to what we actually know about the processing. Where what you ask for goes materially beyond what the product provides, we may charge our reasonable costs, agreed in advance.

9. Personal Data Breach

We will notify you without undue delay and in any event within 72 hours of becoming aware of a personal data breach affecting your personal data. The notice will describe, so far as it is known at the time: what happened and when; the categories and approximate number of people and records affected; the likely consequences; what we have done or propose to do; and a contact point. Where the full picture is not available at once we will send what we have and follow up, rather than delay the first notice.

We will not make a public statement identifying you without your consent unless the law requires it. Tell us where to send the notice when you sign. Reports to us go to info@cralio.app.

10. Deletion

While the agreement is running you can delete a job and its files at any time once that job is no longer running, and files are otherwise deleted automatically on your workspace’s retention window — your plan’s number unless we have agreed a different one with you. There is one window, and nothing is exempt from it by anything you can press or ask us for. No control, no flag and no request of yours takes a delivered result off it: every result is removed on that schedule, and what you want to have afterwards you download before the window closes. One case outlives it and it is not yours to invoke — where the law requires material to be preserved it is copied where no deletion sweep and no storage rule reaches, and 10.3 and 10.4 below set that out; the Annex I retention table carries the same row. The flat 30-day rule the storage service enforces on everything we deliver sits underneath as the outer bound — it cannot read a job record, so where a window we agreed with you is longer than 30 days that rule ends the file first. The plan numbers are on the security page and the window on each job is on the job.

Erasing the whole account is one operation, not a ticket somebody works through. It runs end to end once you confirm by typing the address on the account. There is no button for it in the dashboard yet — it is a DELETE request to /account, and if you would rather not call an API you ask us and we run the same erasure for you. It empties the stores holding the person’s personal data and content: profile, email settings and the log of what we sent them, consent records, invitations, uploads, workspace membership and the sign-in itself — and, in the workspaces that person OWNS, the jobs and delivered files behind them, typefaces, glossary and saved subtitle styles. Work done inside a workspace somebody else owns is that controller’s, not the person’s: a request from one member is not consent to destroy an organisation’s files, so those rows stay and the person’s identifier is removed from each of them. Since 19 September 2026 it also reaches the prompts saved in Generate: those rows hang on the workspace rather than on the person, and the erasure — which empties and unnames the workspace instead of deleting it — used to leave them behind. It now deletes them for every workspace the person owns. The credit ledger is not deleted but stripped — the rows recording money stay, with the identifiers, file names and operator notes taken out of them — because the balance of a workspace is our record of money that moved rather than your personal data. It is refused while a subscription is live, while jobs are still running, while other people remain in your workspace, or while a safety case on the account is still live — open, or reported to the authorities and not yet closed; each refusal names what has to change first, except the last, which we do not explain. Closing that case makes the account deletable again and releases nothing: the preserved copy stays where no sweep and no storage rule reaches it. Every step is safe to repeat, and an erasure that could not be finished is reported as unfinished rather than as done. What survives it is described in the privacy policy.

On termination we delete your personal data within 30 days. Nothing in the build starts that clock: there is no closed-account sweep among the scheduled tasks, and cancelling a subscription is a precondition of erasing an account rather than an erasure of one. It is the same erasure described above, run by a person on termination, and until it is run your files go on expiring on their own retention windows. The exceptions are: data we must keep by law — invoices and the transactions behind them, which contain no media; the audit log of administrative actions, which is append-only by design; database backups already taken, being the last 30 daily copies, so a deleted row can survive in one for about a month — and for longer if the daily job stops, because the pruner keeps a count of copies rather than an age and prunes only after a successful one, while the storage service’s own rule removes a backup older than 90 days whatever happens; one tombstone row per erased account, written before anything else is removed and never deleted afterwards, holding a one-way hash of the address, the account and workspace ids, who ran the erasure and when, and any reason you typed when you asked — no address in clear — and kept for one purpose only, so that deleting an account and creating it again cannot re-mint the welcome credit grant; our pointer to your Stripe customer record, which stays because Stripe is a separate controller with its own duty over the payment record, and deleting the Stripe customer itself is a step we take by hand; and material we are required to preserve after a child-safety report, which is copied to a location no deletion sweep and no storage rule reaches and stays there until a person removes it by hand.

That last exception is not ours to waive, and it overrides everything else on this page. Where United States law requires material to be preserved — a report under 18 U.S.C. § 2258A is the case that arises here — the copy survives your retention window, your deletion of the job, the account being closed, and this clause; and while the incident behind it is open, or reported and not yet closed, an erasure request is refused rather than performed in part. The obligation runs for at least 90 days from the report and we keep the material for at least that long. The acceptable use policy sets out when this arises. We will certify deletion in writing on request.

Media is never in a backup. So an expired retention window is a real deletion from our own systems, not a deletion from the live system with a copy still sitting in a backup of ours. Two things can outlive it: material preserved under the obligation above, and a provider’s own copy. The generation provider logs prompts and outputs for up to 55 days for abuse monitoring, the transcription provider for up to 30, and the dubbing provider’s backups hold a deleted account’s data for about 60. The provider that recuts a video is the one with no published answer: its API terms name no period, and its enterprise terms give thirty days after an agreement ends to take back what was sent and no undertaking to hold it after that. We have not asked it for a shorter one, and nothing of yours has reached it — that row is inside its notice period. The register in Annex II carries each answer under the provider it belongs to.

11. Audits

We will make available the information reasonably necessary to show we are complying with this addendum. You may audit no more than once in any 12 months, on 30 days’ written notice, during business hours, subject to confidentiality, and without access to other customers’ data or to our production systems. A regulator may audit on whatever notice the law requires.

There is no SOC 2 report and no third-party penetration test. A buyer of a certain size will ask for one instead of an audit, and there is nothing to send them. That is the honest position today rather than a date we have not committed to.

12. Liability and term

Liability under this addendum is governed by the limits in the terms of service. This addendum takes effect when the agreement does and lasts as long as we process personal data on your behalf.

Annex I — what is processed

Annex II — sub-processors

Rendered from the register, not typed here. Terms last read 2026-08-30. The fuller version, with the note behind each training answer, is the subprocessors page.

Annex III — technical and organisational measures

These are the measures in place today. Clause 5 points at the security page, which describes them at greater length and is kept current; this annex is the part that forms part of the agreement.

Encryption. Files are encrypted in transit, and at rest by the storage service’s own default server-side encryption — AES-256, with keys the storage service holds. That default is a setting in the provider’s console rather than anything in our code, so no file of ours sets it and no build check asserts it; it was read off the bucket on 25 August 2026 and it is a setting a person would have to re-read to be sure of again.

Separation and access control. What you upload, and every typeface you add, is stored under a prefix belonging to your account; what a job produces is stored under a prefix carrying that job’s own id. Either way, every request that names an object is checked against the account making it. Download links are minted on request and expire an hour later; there is no public URL for any customer file. Row-level security is switched on for the database’s tables and is not what separates you from another customer: our own code reaches the database with a service credential that bypasses it, so the check named above is the thing doing that work, and the database is a second line behind it.

Accountability. Administrative actions — granting credits, retrying a job, changing a role — are written to an append-only record naming the person, the account, the time and the numbers involved. Nothing in that module deletes. Two platform-level switches are the exception: the face gate leaves only a server log line, and a safety hold is written to its own incident record instead. Reads are not recorded, and we would rather state the limit than overstate the control.

Availability. The database is dumped daily and the last 30 copies are kept. No customer media is ever in a backup, which is why an expired retention window is a real deletion from our own systems rather than a deletion from the live system with a copy still sitting in a backup of ours. Two things outlive it, both set out in clause 10 and neither of them a backup: material copied to a preservation hold, which sits under a separate prefix of the same live store that no sweep walks and no lifecycle rule matches, and a provider’s own copy.

Abuse and rate control. The requests that cost money are rate limited per caller: job submissions, price quotes, upload preparations, billing calls, the confirmation that erases an account and waiting-list sign-ups each have their own ceiling. Signing in and creating an account are not ours to limit: both happen at our identity provider rather than at our own interface, so no ceiling of ours applies to them.

Our own alerting. Alerts to our operators pass through a gate that admits fields by name and otherwise only values shaped like a number, an amount, a duration or an id; anything else is withheld and named rather than transmitted. Free text cannot travel in one, with a single exception: the reason our own operator types when they grant credits by hand, capped at 120 characters with any email address removed. A file, a filename or a prompt of yours never leaves this way.

What is not in place. There is no SOC 2 report, no ISO certification and no third-party penetration test. Our staff read customer account data through ordinary administration screens and those reads are not logged. The key our own servers run on can read and write the whole media store rather than one customer’s prefix — the same process has to sweep every account’s expired files — and what is narrowed on that key is deletion, which reaches only the working prefixes and can touch neither the spend ledger nor preserved material; the AWS role the rendering worker runs under is not narrowed the same way and may delete anywhere in the store. There is also no multi-factor authentication on customer accounts, no customer-managed encryption keys, and no choice of the region your files are stored in — they are where clause 7 says they are. No full restore of the database has been rehearsed end to end: one table was restored as a drill on 28 August 2026 and a build check holds every backed-up table to being restorable or named as a refusal on purpose, but the whole database has never been brought back. And there is no independent alerting for the alerting — the channel that would report a stalled queue is the same code path that would be stalled.

How to sign it

Write to info@cralio.app with your company’s details and where breach notices should go. There is no counter-signed copy waiting. This text has not been through a lawyer, so what comes back is this addendum and its annexes, and the signature happens on paper one of us prepares for it. Signing changes nothing about when this addendum began or when the Standard Contractual Clauses in clause 7 came into force: both run from the moment the agreement does, and the paper records that rather than causing it. If your own paper is required instead, send it — we would rather read yours than argue about ours, and the three annexes above are the part we cannot take from a template.