Data Processing Addendum

What this is, and when it applies

This addendum is between Nidrosoft (“we”, the processor) and the customer that holds the Octana account (“you”, the controller). It applies to personal data we process on your behalf through Octana, and it applies from the moment you start using the product for that purpose — it does not need to be signed separately to be the terms we operate under.

It does not change how we handle data where we are the controller in our own right — your account details, your billing records, the operational logs that keep the service running. Those are covered by the Privacy Policy.

Who is the controller

For the content you put into Octana and everything made from it, you decide the purpose and the means, and we act on your instructions. You are the controller; we are the processor.

You are also the one who must have the right to the material you upload. That matters most for biometric data: if you clone a voice or train a presenter avatar from someone who is not you, you are the party who needed their permission. Octana requires a consent record naming the subject and the rights-holder before a clone can exist, and the term recorded on it is enforced — but the software recording a consent is not the same as the consent being validly given, and it is you who has to answer for the second.

Subject matter, duration and purpose

Subject matter

Processing personal data contained in the material you submit to Octana and in the videos, audio, images and records the service produces from it.

Duration

For as long as you have an account, plus the completion of the deletion described in the last section. Individual categories have their own retention periods, set out below and enforced by scheduled jobs rather than by intention.

Nature and purpose

Producing video. Concretely, that means: storing what you upload; sending text, images and audio to model vendors to have scripts, voiceovers, images and video generated; synthesising speech, including from a voice clone you have consent for; assembling and rendering a finished file; publishing it to a channel you connect, when you choose to; reading that channel’s own analytics; and keeping the account, billing and audit records that make the service operable and reviewable.

We process personal data only on your documented instructions. Your configuration and use of the product is that instruction. We will not process it for our own purposes, we do not sell it, and we do not train models on it — we train no models at all.

Data and data subjects

Categories of data subject

• Your personnel who hold or use the account.
• People whose voice, likeness or personal details appear in material you upload or in a script you generate.
• Subjects and rights-holders named on a consent record — who may be neither you nor your staff.
• Viewers of a published video, to the extent their aggregate figures reach us.

Categories of personal data

• Identity and contact: name, email address, profile image URL, an opaque identity-provider user id.
• Content: anything in the text, images, audio and video you submit, and in what the service generates from it.
• Biometric data: voice recordings, voice replicas held at a speech vendor, reference likeness footage, trained avatars, and liveness recordings.
• Consent records: subject name, rights-holder name, permitted uses, term in months, a hash of the exact text agreed to, the time it was accepted, the IP address and browser that accepted it, and any signed release document.
• Connection data: OAuth tokens and channel identifiers for platforms you connect.
• Usage and operational records: job history, credit ledger entries, audit log entries, error reports, and a coarsened network address recorded against API key use.

Special category data. The biometric data above is special category data under GDPR Art. 9 and is subject to BIPA and AB 2602 in the United States. It is the only special category data Octana is built to process, and the product is not designed for health, financial account, or criminal offence data. If you put such data into a prompt, it will be processed as content and we will have no way to know.

Retention

What we undertake as processor

• To process personal data only on your instructions, and to tell you if we think an instruction breaks data protection law rather than carrying it out quietly.
• To keep it confidential, and to give access only to people who need it for the service. Administrative access is checked on the server and every administrative action is written to an audit log.
• To apply the security measures set out below, and not to weaken them silently.
• To engage sub-processors only under the terms in the next section.
• To help you meet your obligations to data subjects and to regulators, as described further down.
• To return or delete personal data at the end, subject to the one stated exception.

Sub-processors

You authorise the sub-processors below. This is the same list the Privacy Policy publishes, rendered from the same source, so the two documents cannot drift apart. Adding a vendor to the product without adding it here fails our build.

Each sub-processor is engaged under terms that impose data protection obligations no weaker than these, and we remain responsible to you for their performance. Where a vendor is marked as accepting your own key and you have supplied one, that leg of the processing runs under your contract with them instead, and our responsibility for it ends where your agreement begins.

We will give you reasonable notice before adding or replacing a sub-processor, and you may object on reasonable data protection grounds; if we cannot resolve the objection, you may stop using the affected feature or terminate. Stated honestly: there is no subscription list for these notices yet. Until there is, notice means an update to this page and an email to account holders, and you can ask to be told directly at legal@octana.one.

International transfers

Our sub-processors are largely United States companies, so using Octana involves transferring personal data to the United States and to other regions those services operate in. Where data leaves the UK, the EEA or Switzerland, we rely on the transfer mechanisms each sub-processor offers in its own data processing terms — Standard Contractual Clauses and the UK addendum, principally.

What we do not yet have, and will not imply we do: a completed vendor-by-vendor record of the mechanism relied on for each transfer, and the transfer impact assessments behind them. That work is not finished. If your own compliance requires it before you can adopt the product, ask at legal@octana.one and we will tell you exactly where it stands.

Security measures

These are measures implemented in the software today, not a catalogue of intentions.

Encryption at rest

Secrets are encrypted with AES-256-GCM before they are written to the database, using a fresh random 96-bit initialisation vector for each value and storing the GCM authentication tag alongside it, so a tampered value fails to decrypt rather than decrypting to something wrong. The stored format is versioned, which is what makes a future key rotation detectable rather than a guess. The master key is held as a deployment environment secret and derived to 32 bytes with SHA-256. This protects:

• Provider API keys you supply for your own vendor accounts.
• Google OAuth access and refresh tokens, including every refreshed token.
• The OAuth client secret, where you bring your own Google Cloud project.
• Outbound webhook destination URLs and their signing secrets.

Decryption happens only inside the server-side action that is about to make the vendor call. A regression test asserts that a refreshed OAuth token is never written back in the clear.

Hashing

API keys are stored as a SHA-256 hash and nothing else, alongside a short display prefix so you can tell keys apart in the interface. After the one moment a new key is shown to you, no copy exists in our systems — we cannot recover it, only revoke it. Verification is an indexed point lookup on the hash. Tokens issued for the MCP integration are stored the same way. Where a key’s last use is recorded, the network address is coarsened first: IPv4 to its first three octets, IPv6 to its first 48 bits.

Access control and isolation

Every record carries exactly one owning account, and every read and write resolves the caller’s identity and checks ownership on the server before touching it. Indexes are per-owner, so a query cannot accidentally range over another account’s rows. Administrative capability is a role checked in the backend, deliberately not in the interface — hiding a link is cosmetic.

Precisely: isolation is per account. Octana has no organisation or workspace concept today — there is one owner per record and no shared ownership. If your procurement requires tenant-level segregation with multiple named users inside a tenant, that does not exist yet and you should not read this section as describing it.

Transport

Traffic to and from the application, the database and object storage is encrypted in transit by our hosting platforms. Outbound webhooks are restricted in application code to HTTPS on port 443, with credentials-in-URL rejected. Customer-supplied URLs that the product fetches are checked against private address ranges before the request is made.

Not yet in place: we do not send an HTTP Strict-Transport-Security header. Transport security therefore rests on platform defaults rather than on a browser-enforced policy of ours. It is a small gap and it is being closed, but it is a gap today.

Application hardening and logging

• Response headers set content-type sniffing off, framing to deny, a restrictive referrer policy, and a content security policy that forbids being framed and restricts form submission and object embedding.
• Error reports pass a scrubber before they leave. It redacts by value — the actual contents of every credential in the environment — rather than by guessing at the shape of a key, and a contract test re-derives that list from the credential loader so a newly added vendor fails the build until it is covered. The backend that holds and decrypts credentials has no error-reporting integration at all, so nothing from it can reach a report in the first place.
• An audit log records administrative and consent events — actor, action, target and context. The version of it shown in the product allow-lists which context fields may reach a browser at all, so a future addition cannot leak a token into the interface.
• Inputs are validated against schemas at every boundary, including the public API.

What we do not have

No SOC 2 report, no ISO 27001 certification, and no third-party penetration test. If your procurement process requires any of those, we do not meet it today and we would rather you learned that here than three weeks into a questionnaire.

Personal data breaches

If we become aware of a personal data breach affecting personal data we process for you, we will tell you without undue delay and in any event within 72 hours of becoming aware. We will describe what happened, the categories and approximate number of people and records involved, the likely consequences, what we have done, and what we recommend you do — and where we do not yet know something, we will say that rather than delay the notification until we do.

We will not notify a supervisory authority or your data subjects on your behalf unless you ask us to; that is the controller’s call and it is yours to make.

Helping you meet your own duties

Where a data subject comes to you with a request, the product can do most of the work without us being in the loop: a full export of an account’s data, correction through the interface, revocation of a voice clone or a presenter avatar, and account deletion are all self-service. If a request needs more than the product offers, tell us at privacy@octana.one and we will help within the time you need to answer.

If a data subject contacts us directly about data we hold for you, we will not answer on your behalf. We will pass it to you, unless legally required to do otherwise. The exception is a report that a voice or likeness was used without permission: we act on those ourselves, because a person whose voice was cloned should not have to wait on a routing decision. Those come in through the reporting form, which needs no account.

We will give you the information you reasonably need for a data protection impact assessment or a prior consultation with a regulator. Given the biometric processing, you should expect to need one.

Audit and information rights

You may ask us to demonstrate that we are meeting this addendum. In practice that means: we answer a reasonable security questionnaire, we explain how a specific control works, and — because we are small enough that this is a real offer rather than a deflection — we will walk you through the actual code for a control if that is what would satisfy you.

You may audit us on reasonable notice, no more than once a year unless a breach or a regulator’s instruction makes another necessary, at your cost, during business hours, and without disrupting the service or exposing another customer’s data.

We have no audit report to hand you. There is no SOC 2 and no ISO certification to send instead of an audit, so this right is not the formality it usually is in a document like this.

Return and deletion

You can take your data out at any time, not only at the end: the export at Settings → Export or delete produces a JSON file of the account’s records, and rendered media can be downloaded from the product while the account is live.

On termination, deleting the account runs the deletion sequence: connections revoked, voice replicas purged at their vendors, the subscription cancelled, stored files removed, content and configuration deleted, retained records anonymised, and the identity removed at the identity provider. It is scheduled seven days out and can be cancelled during that window. A step that fails leaves the run marked failed rather than complete, so a partial deletion does not report itself as a finished one.

There is one thing this sequence cannot do, and you should plan around it: a presenter avatar trained at HeyGen is not deleted at HeyGen, because no avatar-deletion endpoint we have been able to read is published. Removing a trained likeness there is a manual step at the vendor, and we will tell you so at the time rather than report an erasure we did not perform.

Precedence, changes and contact

Where this addendum conflicts with our general terms on the processing of personal data, this addendum wins. Everything else in those terms stands.

We may update this document as the software changes — that is the point of it. The effective date at the top moves when the substance does. Where a change reduces a protection you rely on, we will tell account holders rather than let the page change under you.

Contact for anything in this addendum, including a signed counterpart if your process requires one: legal@octana.one. Data subject requests and privacy questions: privacy@octana.one.