What we sign

Before your legal team asks.

Paperwork is where a good technical conversation goes quiet for three weeks. This is our position on the documents a security review asks for, written down so it can be read early.

What we sign

The documents, and where we stand on each.

Self-hosted: nothing to sign

On Core you deploy MIT-licensed software into your own account. We never reach it, so there is no agreement and no processor relationship.

A DPA whenever we reach it

Whenever our people work on your running system, under Pro support, a Deployment or Integration service, or Enterprise, we sign a data processing agreement. The signing follows the access.

A BAA if HIPAA applies

A business associate agreement under Enterprise, where your cloud provider and your scope support it.

Questionnaires answered by us

Under Enterprise we fill in your customers' and auditors' security questionnaires, rather than leave them with you.

Where the paperwork sits

It follows who can reach your deployment.

  1. 01

    Core, self-hosted

    None of this applies. There is nothing to sign, because we are not party to anything you run yourself.

  2. 02

    Pro, or a Deployment or Integration service

    A DPA covers the work while our people can reach the deployment, from onboarding to deployment and integration support. A deployment we set up comes with its region stated in writing.

  3. 03

    Enterprise

    A signed DPA and, where supported, a BAA for as long as the agreement runs, security questionnaires and reviews answered by us, and SLA support.

Boundaries

Where our responsibility ends.

  • We do not hold SOC 2 or ISO 27001.

    The deployment runs inside your certified environment, which is how most teams answer this in their own audit. If your procurement requires a vendor certificate regardless of architecture, tell us early.

  • We do not hold your certification for you.

    For DiGA, CE marking or FDA clearance, we provide auditable inputs and tested releases. The clearance stays yours.

  • We do not sign up to outcomes we cannot control.

    The path from a watch to a phone to a provider's cloud belongs to the provider. We commit to what happens once the data reaches your deployment, and say plainly where our responsibility starts.

Send it to your legal team first

This page exists so the paperwork conversation happens early rather than at signature. If there is a clause you know will be a problem, bring it to the first call.

FAQ

Common questions.

Will you sign a DPA?

Yes, whenever our people can reach your deployment: under Pro support, during a Deployment or Integration service, and for as long as Enterprise runs. Where you self-host on Core, there is no processing for us to agree to, because we never touch it.

Will you sign a BAA?

Under Enterprise, where it is supported. It depends on your cloud provider and your scope: the deployment runs on your infrastructure, so access, encryption, retention and logging are yours to control and to evidence. Tell us the scope and we will give you a straight answer.

Do you hold SOC 2 or ISO 27001?

No. The deployment runs inside your certified environment, which is how most teams answer this in their own audit.

Our customer sent a sixty-page security questionnaire. Will you fill it in?

Yes, under Enterprise, because it takes real time. Most of it is answered by where the deployment runs, so it is usually shorter work than it looks.

We need a DiGA listing. Can you help?

With the inputs, yes. With the clearance itself, no. We provide data a reviewer can audit and tested releases, and you hold the certification. That is a limit worth knowing before you plan a timeline around it.

What happens if we stop working with you?

The deployment and the data stay in your account, because they were never anywhere else. The agreement covers what we stop doing rather than what you have to retrieve.

Our contract has a clause about sub-processors. Where do we stand?

When you run the deployment yourselves, it is in your account and we are not party to it. When we support or maintain it, we act as your processor under a DPA you sign, and we name the sub-processors we use for that access. The sub-processors page covers it in full.