Documentation/Managing Your App/Compliance & Trust
Compliance & Trust
An honest answer to the questions a security review asks: which legal documents exist and where to read them, what Supero is and is not certified for, where your data lives, how to report a vulnerability, and which questions this page deliberately does not answer.
What This Page Is
Three questions come up before a signature, every time: what are we agreeing to, what happens to our data, and what can you show us on paper. This page answers the first two from the documents that already exist, and is specific about which parts of the third do not exist yet.
It is written to be forwarded to someone doing a review. It states the posture Supero actually has rather than the posture a vendor page usually claims, because a claim your reviewer cannot verify costs you a second round of questions rather than saving you one.
ℹ️ The short version
Supero is designed around the controls a security review looks for — authentication, scoped credentials, tenant isolation, role and record-level access control, audit logging, encryption in transit. It is not certified against SOC 2, ISO 27001, or PCI DSS, and no Business Associate Agreement is offered. If a certification is a hard requirement for your project, the supported answer is to run the platform on your own infrastructure. Each of those statements is expanded below.
The Legal Documents
Three documents govern your use of Supero. All three are presented at signup and all three are readable without an account, so your legal and security reviewers can read them before you commit to anything.
| Document | Version | What it covers |
|---|---|---|
| Terms & Conditions | 1.0 | The service agreement: your content and who owns it, intellectual property and portability, subprocessors, availability and support, fees. |
| Mutual NDA | 1.0 | Confidentiality in both directions, with a stated survival period. |
| Privacy Policy | 1.0 | What information is collected, how it is used, AI processing, subprocessor categories, retention and deletion, your rights, and international transfers. |
All three live in the Legal Center at app.supero.dev/legal, which is public — no login, no trial, no sales call. Each document has its own deep link: Terms & Conditions, Mutual NDA, Privacy Policy. Once you have an account, the same viewer is in the dashboard under Settings.
At signup a single consent line covers all three, and each document name opens in a new tab so you do not lose the form. It is ticked by default rather than presented as a hard gate — see Create Your Account for where it sits in the flow. Acceptance is captured with the version number of each document and a timestamp, so what you agreed to is identifiable rather than being "whatever the page said at the time". If you need that acceptance produced as evidence, ask [email protected] rather than assuming you can retrieve it yourself.
⚠️ The Legal Center displays a working-draft notice
At the top of the Legal Center is a banner stating that the documents are a working draft pending legal review, and that some details — the contracting legal entity, the governing law, and the registered address — are placeholders still to be finalised. Your reviewer will see it, so it is better read here first than discovered mid-review. The substantive terms are written out in full; what is bracketed is the entity and jurisdiction detail. If your procurement needs a counter-signed agreement, the contracting entity named, or a specific governing law, that is a conversation rather than a click-through: mail [email protected].
💡 Two addresses, two different questions
Contract wording, entity details, counter-signature and amendments go to [email protected]. Data-protection questions — the subprocessor list, a Data Processing Addendum, data-subject requests, deletion requests — go to [email protected]. Both are named in the documents themselves.
What Supero Is Not Certified For
This is the section most vendor pages leave vague. Stated plainly so you can close the question in one read:
| Framework | Status today |
|---|---|
| SOC 2 (Type I or Type II) | No report exists. Supero has not been audited against SOC 2, and no completion date is being committed to here. |
| ISO/IEC 27001 | Not certified. |
| HIPAA | No Business Associate Agreement is offered. Do not put protected health information into Supero Cloud on the basis of this documentation. |
| PCI DSS | Not certified. Supero is not a payment processor — card entry happens on your payment provider’s hosted checkout, under that provider’s own compliance program. Confirm the scope with your provider, not with Supero. |
| GDPR | Not a certification, and nobody can be "GDPR certified". The relevant question is the roles, which the Privacy Policy sets out — see below. A Data Processing Addendum is not offered self-service; request one from [email protected]. |
| Penetration test | No third-party penetration-test report is published. If your review requires one, ask [email protected] what can be shared and under what terms. |
The honest framing is that the platform is designed for these controls, not certified against them. Designed-for means the mechanisms a reviewer will ask about are present and documented: scoped credentials with defined lifetimes, role-based access control, record and field-level access policies, audit logging, and client-held field encryption. Certified-against means an auditor has tested them and signed a report. The second has not happened.
ℹ️ The Terms say the same thing
The Terms & Conditions carry a shared-compliance clause with the same position: the platform offers tools that can support regulated use cases, those tools do not by themselves make your deployment compliant with any framework, you are responsible for configuring the service correctly and for your own regulatory obligations, and processing regulated data requires a separate written agreement where one applies. This page is not softening the contract; it is pointing at it.
Who Is Responsible for What
For data your users put into an application you built on Supero, the Privacy Policy places Supero as a processor acting on your instructions, and you as the controller. Practically, that means the obligations below are yours and cannot be delegated to the platform by using it.
- •The lawful basis for processing your end users’ data, and any consent you need to collect.
- •Your own privacy notice to your end users. Supero’s Privacy Policy governs your relationship with Supero; it is not a notice you can hand to your customers.
- •Configuring access correctly. The platform default is permissive until you narrow it — see the checklist on Security and the rules on Access Policies.
- •Deciding what belongs in the system at all. Encrypting a field client-side is a control you apply, not a default — see Field Encryption.
- •Handling data-subject requests from your own end users. Route them to yourself, not to Supero; Supero assists you as your processor rather than answering your users directly.
For your own account information — the identity you signed up with, billing, support correspondence — Supero is the controller, and requests about it go to [email protected].
Where Data Lives and Who Can Reach It
The summary a security reviewer needs, with the detail pages linked. None of this is new on this page; it is assembled here so it can be reviewed in one place.
- •Every request is scoped by the domain carried in its credential, and within that by project and tenant. There is no cross-domain query capability: a credential issued for one domain cannot address another domain’s records regardless of the path or filter it sends. See Security.
- •Within a domain, visibility follows role scope — domain-wide, project-scoped, or tenant-scoped. The full role catalogue and what each can reach is on Roles & Permissions Reference.
- •Row and field visibility inside a role’s scope is governed by object-level access policies, including owner-scoping that restricts a role to rows tied to the caller’s own identity. See Access Policies (Entity, Record & Field).
- •Credentials are of two kinds only — a user JWT with a bounded lifetime, or a service API key you create, scope and revoke. See Authentication.
- •Platform activity is recorded per domain as audit entries you can read through the normal API — authentication attempts, administrative actions, schema changes and CRUD operations, each with actor, timestamp, target and client address. Default retention is 90 days. See Security.
- •Tenant boundaries in a multi-tenant application are a design decision you make, not an automatic property. Building Multi-Tenant Apps covers the model and its edges.
Two behaviours in that model surprise reviewers often enough to be worth stating here rather than leaving them to be found. First, an access policy set to no access on an entity stops a role writing it; it is not consulted on reads, so the records stay readable. If a value must not be seen by a role, it must not live on an entity that role can reach at all. Second, a policy change is not instant — an affected user can keep the old policy for a short cache window after you save, so never report to an operator that access has been revoked on the strength of a successful write. Both are documented with the exact behaviour on Access Policies (Entity, Record & Field).
🚨 One isolation edge a reviewer should be told about
Membership of a tenant named default-tenant grants project-wide cross-tenant access on the tenant name alone, with no role check. Any account provisioned into it can read across every tenant in that project. Never provision a customer, a contractor, or a shared service account into default-tenant, and audit your existing memberships for it before a launch. This is documented in full under Data Isolation on Security.
Physical location
On Supero Cloud there is no region or residency selection, and no residency guarantee is published here. If data residency is a requirement rather than a preference, the two supported answers are deploying into your own AWS or GCP account, where you pick the region and the resources are yours, or running the platform on your own infrastructure. Both are covered below. The Privacy Policy notes that Supero and its subprocessors may process information outside your own country, relying on safeguards such as standard contractual clauses where required.
⚠️ A project’s region field is a label, not a placement control
Projects carry a region field, and it is easy to read it as a residency setting. It is not. It accepts any short string without validation, so a typo is stored silently and reads back as whatever you typed, and setting it does not move where anything runs. Do not cite it in a residency answer. See Going to Production.
Encryption Posture
Stated at the level a reviewer will ask about, with the condition attached rather than omitted.
| Where | Position |
|---|---|
| In transit | All external traffic to api.supero.dev and app.supero.dev is TLS-encrypted, as stated on Architecture. The Privacy Policy names encryption in transit as one of the technical measures in place. |
| At rest — your application records | No general at-rest encryption of your records is claimed in this documentation, and there is no schema flag that transparently encrypts a field. If a value needs protection beyond transport and access control, you encrypt it client-side with a key you generate and hold. Treat the absence of a claim as the answer, not as an omission. |
| At rest — integration credentials | Sealed, conditionally. The credential blob you enter when configuring a managed integration is sealed at rest only when the deployment’s key store is enabled and a key is provisioned. |
🚨 At-rest sealing is conditional, and silent when it is off
When the key store is not enabled, sealing is a pass-through: the credential is stored in plaintext, with no error, no warning, and a record that looks identical through the API. On Supero Cloud the key store is managed for you. On a self-hosted or on-premise deployment it is not on by default, so every integration credential configured before it was enabled is in plaintext and nothing in the product will tell you. Confirm the key store is enabled before entering a real vendor credential. The full detail is under Field-Level Protection on Security, and On-Premise Deployment covers turning it on.
Client-side field encryption is the mechanism you control: field values are encrypted before they leave your process and decrypted when you read them back, with a key Supero never sees and cannot recover. It has real trade-offs a reviewer should weigh rather than tick — encrypted values cannot be filtered, sorted or matched server-side, a small fixed set of system fields always stays plaintext, and there is no support-assisted key recovery. It is also plan-gated rather than universally available; see Plans & Billing. Field Encryption covers the setup and the key-management consequences before you commit to it.
Subprocessors and Third Parties
The Privacy Policy publishes the categories of subprocessor, not the vendor names. The categories are AI model providers, payment processing, cloud hosting and database providers, and communications providers for the email, SMS and notification messages your application triggers.
A current list of named subprocessors is available on request from [email protected]. It is not published on a page that updates itself, so if your review needs a list with names and a change-notification commitment, ask for it in writing rather than citing this page.
ℹ️ Integrations you enable are their own supply chain
Every provider you connect from the managed services catalog — a payment gateway, a mail provider, an identity provider — processes data under its own terms, with its own compliance posture and its own subprocessors. Those are yours to review. The same is true of a database or warehouse you attach through a connector: the source stays where it is and remains under your control and your obligations.
One case is worth calling out because it is easy to miss. Generating and enhancing an application sends your prompts and certain inputs to third-party AI model providers acting as subprocessors. The Privacy Policy states that this happens and that prompts and customer content are not sold. If your organisation restricts what may be sent to an external model, that restriction applies to what you type into the app generator, not only to what your finished application does.
Reporting a Vulnerability
Mail [email protected]. That is the published address for vulnerability disclosure and it is the fastest route to someone who can act on the report.
- •Mail before going public. Please do not open a public issue, post a thread, or publish a write-up as the first step.
- •You will get an acknowledgement, and a disclosure timeline is agreed with you rather than imposed on you.
- •Include what a triager needs: the host (api.supero.dev, app.supero.dev, or a published app on supero.live), the exact request, the response, a timestamp, and the correlation_id if the response carried one.
ℹ️ What this is not
There is no published bug-bounty program, no safe-harbour legal text, no formal severity or payout schedule, and no security.txt file to discover the address from — if you were looking for one, this page and Contact & Links are where the address is published. What exists is a monitored mailbox and a commitment to acknowledge and agree a timeline. If your disclosure process requires written safe-harbour terms before you test anything, ask for them at the same address first.
Operational problems that are not security issues — something erroring, something behaving differently from these docs — go to [email protected] instead. Contact & Links lists the full set of addresses and which host an error belongs to.
When Certification Is a Hard Requirement
Some reviews cannot be passed with a well-argued page. If your requirement is that the data never leaves your network, or that the environment falls inside a certification you already hold, the supported answer is not to wait for Supero to be certified — it is to run Supero inside the boundary you have already certified.
The platform ships as an on-premise package you install on your own hosts. Once running it has no runtime dependency on Supero: logins, CRUD calls and schema uploads all stay inside your network, and the licence is a signed file verified locally and offline, with no licence server to reach. Air-gapped operation is supported, with the install-time network requirements set out explicitly. See On-Premise Deployment.
There is a middle option. Building on Supero Cloud while deploying the finished application into your own AWS or GCP account puts the running application, its region and its logs inside your cloud, under your existing controls — while the build environment stays hosted. That satisfies some reviews and not others; it is worth establishing which kind yours is before you plan around it.
⚠️ Self-hosting moves the controls to you, it does not switch them on
An on-premise deployment inherits none of Supero Cloud’s managed defaults. The key store is off until you enable it, the database ships with a local default you must secure before real data goes on it, and backups, patching, monitoring and retention become yours. Two scope points also belong in the review rather than in a surprise later: application generation still happens in Supero Cloud — the on-premise package is where you deploy and run apps, not where you author them — and connectors, the integrations catalog and a self-hosted AI agent are separate optional add-on packages rather than part of the core install. Read the system requirements and the security notes on On-Premise Deployment as a work list, not as background.
Retention, Deletion and Recovery
Two questions a reviewer asks late and should ask early.
- •Retention. Audit entries are retained for 90 days by default. For account information, the Privacy Policy states that data is retained while your account is active and as needed to provide the service, then deleted or anonymised in the ordinary course, subject to legal retention requirements, with customer content available for export for a limited period after termination. The length of that period is not fixed in this documentation — if you need a number, get it in writing from [email protected].
- •Deletion of a record. There is no soft delete, no trash, no undo and no restore, and no self-service point-in-time recovery. Your own export is the only recovery path that exists. See Continuity & Exit, which includes a working export script and the reasons to run it on a schedule rather than only on your way out.
💡 An export is part of a compliance answer, not just an exit plan
"Can we get our data out, in a format we can read, without your help?" is a review question as often as it is a break-up question. The answer is yes, through documented endpoints — with one caveat worth knowing in advance: a record export does not include uploaded files. Attachments are fetched separately by identifier. See Files & Media.
What This Page Cannot Answer
Listed so you do not spend a review discovering it. Each of these is a real question with no published answer, routed to the address that can give you one in writing.
| Question | Where to ask |
|---|---|
| An uptime commitment or a service-level agreement. None is published in this documentation. The Terms state that availability is not guaranteed except under a separately executed SLA, which is an Enterprise-plan arrangement. | [email protected] |
| A named subprocessor list, and notification when it changes. | [email protected] |
| A Data Processing Addendum, or a Business Associate Agreement. | [email protected], copying [email protected] |
| A third-party penetration-test report, an architecture review, or a completed security questionnaire. | [email protected] |
| Backup frequency, restore procedure, and recovery objectives. | [email protected] |
| Data residency guarantees on Supero Cloud, or a contractual region commitment. | [email protected] |
| A counter-signed agreement, the contracting entity, or a change of governing law. | [email protected] |
| Source-code escrow. No arrangement is documented; it would have to be negotiated. | [email protected] |
ℹ️ Ask for the answer in writing
A sentence in a mail from the vendor is worth more to your reviewer than a sentence on a vendor documentation page, and this page will not claim a commitment that has not been made. If you are working to a deadline, send the whole list at once rather than one question at a time.
Related Pages
- •Security — authentication, API keys, data isolation, field protection and audit logging in detail.
- •Access Policies (Entity, Record & Field) — how row and field visibility is actually enforced.
- •Field Encryption — the client-held encryption mechanism, its trade-offs, and key management.
- •Continuity & Exit — getting your code and your data out, and what does not come with you.
- •On-Premise Deployment — running the platform inside your own boundary.
- •Contact & Links — every published address and which one to use.
On this page