Skip to content
Book a demo
Menu

Legal · data processing

Data Processing Addendum

When a customer’s planning model contains personal data, the customer is the controller and Superiora is the processor. This page summarises the terms that govern that relationship so a reviewer can see the shape of them before asking for the document. It is a summary: the signed Data Processing Addendum is the instrument that binds, and it is the one to read.

Last updated · 2026-09-18 Summary · the signed DPA governs Blanks marked for owner review

How to
get it

Ask, and it is countersigned by the founding team.

Write to hello@superiora.ai with “DPA” in the subject, naming your legal entity and the jurisdictions your data subjects are in. There is no self-service portal during the pilot; the document goes back signed.

The published form of the DPA is [Owner: DPA document version and date, once counsel has settled it]. Until that exists, each pilot customer’s DPA is negotiated on their own paper or ours, one at a time.

01
Roles & subject matter

Who is what, and over which data.

Controller
The customer. They decide what personal data goes into a model and why.
Processor
[Owner: legal entity name], trading as Superiora, processing that data only on the controller’s documented instructions.
Subject matter & duration
Providing Superiora Planner for the term of the agreement, plus the export window after it ends.
Nature & purpose
Hosting, storing, computing over and making available the customer’s planning model; sending platform notifications; supporting the customer when asked.
Categories of data subject
The customer’s employees and contractors (as platform users, and as rows in a workforce plan), and any individual the customer chooses to model — a salesperson, a franchisee, a named counterparty.
Categories of personal data
Identity and contact data for platform users; whatever the controller puts in the model, typically name, role, cost centre, territory, employment cost and dates.
Special categories
None. The acceptable-use policy prohibits loading special-category data without prior written agreement.

02
Our obligations

What a processor undertakes.

  • Instructions only. We process personal data only on the controller’s documented instructions, including on international transfer, unless a law we are subject to requires otherwise — in which case we tell the controller first, where that is lawful.
  • Confidentiality. Everyone with access is bound to confidentiality.
  • Security. Appropriate technical and organisational measures, described in section 03 and in more detail on security.
  • Subprocessors. Only with the controller’s general authorisation, under terms no weaker than these, and with notice of any change — see subprocessors.
  • Assistance with data subject rights. Where a data subject writes to us about data inside a customer’s model, we pass it to the controller and help them answer.
  • Assistance with impact assessments and with prior consultation of a supervisory authority, to the extent our knowledge of the processing makes that possible.
  • Breach notification. We tell the controller without undue delay and in any case within [Owner: breach notification window, e.g. 48 hours] of becoming aware of a personal data breach, with what we know and what we are doing.
  • Deletion or return. At the end of the agreement, the controller’s choice of export or deletion, on the timetable in the Terms. Backups age out on the backup cycle rather than instantly, and stay protected until they do.
  • Audit. We make available the information needed to demonstrate compliance and submit to audits on reasonable notice, [Owner: audit frequency, notice and cost terms].

03
Security measures

The technical and organisational measures, in short.

These are the measures actually in place, not a wish list. Security carries the full statement, including what is not in place yet.

  • TLS on every connection to the platform; certificates from Let’s Encrypt, renewed automatically.
  • Passwords hashed with Argon2id. Signed session tokens with a limited lifetime, and short-lived tokens between the control plane and a model’s engine. An address is locked out after repeated failed sign-ins.
  • Role-based access, plus dimensional (selective) access that grants or refuses individual slices of a model. Access is enforced on the read side, so a write into a slice you cannot see is refused before it is sent.
  • Period locks: a closed month refuses every write into it — typed, pasted, imported or scheduled — including the system’s own.
  • An append-only event log: every change to a model is recorded with its author and time, and the state is rebuilt by replaying it.
  • Tenant isolation: each model is its own process and its own data directory, addressed through an authenticated control plane.
  • The application container runs as a non-root user.
  • Nightly backup of the data volume to object storage in the same region.
  • Infrastructure in Amazon Web Services us-east-1, with AWS responsible for physical and environmental security.

04
Transfers

Brazil and Europe to the United States.

Processing takes place in the United States (us-east-1). For a controller in Brazil this is an international transfer under LGPD Chapter V; for one in the EEA or the UK it is a restricted transfer under GDPR Chapter V.

The mechanism relied on is [Owner: transfer mechanism — standard contractual clauses / ANPD clausulas-padrao, module and annexes], with the AWS Data Processing Addendum flowing down to our infrastructure provider.

No other region is offered today. If your data may not leave Brazil or the EEA, tell us before the pilot starts.