Built to pass your security review.
Open Wearables runs inside your own cloud account, behind the network rules and monitoring you already have. This page is what a reviewer asks for next: how a deployment is built, who can reach it, and what we hold.
What the architecture settles
Half the questionnaire stops applying.
Much of a security review asks where the data sits and who can reach it. When the software runs in your account, you answer those from your own environment.
There is no vendor tenant holding your data.
Health data goes from the provider or the phone into your deployment. Nothing in between keeps a copy, so there is no second environment to assess.
Your existing controls apply unchanged.
The deployment sits behind your network policy and your monitoring, because it is in your account rather than adjacent to it.
Your certification covers it.
If you hold SOC 2 or ISO 27001, the deployment can run inside that scope. You are not inheriting somebody else's posture or hoping it holds.
The build
How a deployment is built.
A reviewer usually asks about four things. These are the decisions that get made when we stand a deployment up, and the ones we recommend when you do it yourself.
Key-based access
Access to the machines is individual and key-based. Nobody logs in with a shared password, and administrative access is not the default state.
Closed network
The network is closed by default. Reaching a deployment means coming from somewhere approved rather than from anywhere on the internet.
Encrypted throughout
Data is encrypted at rest and in transit, including the database and the connections to it.
Secrets kept apart
Credentials live outside the codebase, separated per environment and handed over through a channel chosen for the purpose rather than through email or chat.
The application
What the software does on its own.
The build covers the machines. These are the controls inside Open Wearables itself, in code your reviewers can read.
- 01
Hashed credentials.
Developer passwords are stored as bcrypt hashes and API keys as hashes, so the database never holds either in the clear.
- 02
Mobile tokens that cannot read.
The phone gets a short-lived token that can only write its own user's data. The app secret stays on your backend.
- 03
Provider webhooks verified.
Incoming provider webhooks are checked against each provider's signature or secret before anything is stored.
- 04
Signed outgoing events.
Every event sent to your endpoint is HMAC-signed, and the verification library rejects deliveries older than five minutes.
- 05
Off until you turn it on.
Outgoing webhooks and raw payload storage are both off by default, so nothing extra runs or is kept unless you choose.
Who can reach it
Access, in both operating models.
If you deploy it yourself, nobody else has access.
There is no support account and no break-glass credential. What you would be assessing is your own team.
- No standing access
When we work on your system, access is named in a DPA you sign.
It is a defined list of people for the work agreed, rather than standing administrative rights.
- Named in the contract
Either way, what happened is visible in your own logs.
The deployment is in your account, so verifying our answer does not mean trusting it.
- Visible in your logs
Certifications
What we hold, plainly.
- 01
We do not hold SOC 2 or ISO 27001.
The deployment runs inside your certified environment, which is how most teams answer this question in their own audit. If your procurement treats a vendor certificate as mandatory regardless of where the software runs, tell us early and we will be straight with you about whether that works.
- 02
The code is MIT licensed and public.
A security review that wants to know what the software does can read it rather than ask us. That is a different kind of assurance than a certificate, and for engineering-led reviews it is often the one that matters.
Read the code
Send us the questionnaire
Most of it is answered by where the deployment runs. For the rest, we would rather answer in writing early than discover a blocker at signature.
FAQ
Common questions.
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.
Where does our health data live?
In your cloud account, in the region you chose at setup. It does not pass through infrastructure of ours on the way in or out.
Can your team access our deployment?
Only when we work on your system, under a DPA you sign, and then only as named in it. There is no standing access and no support backdoor.
Is the data encrypted?
In the deployments we set up, yes, at rest and in transit. Managed storage is encrypted, connections to the database and cache are encrypted, and public access is HTTPS only.
What happens to credentials?
In the deployments we set up, they stay out of source control, separated per environment, and are handed over through an agreed secure channel rather than email or chat.
How do you handle backups?
In the deployments we set up, automated database backups with point-in-time recovery, running in your own account under your retention policy.
Will you sign a data processing agreement?
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. If your legal team would rather work from your own template, that is normal and we review it.
What else do you sign?
A BAA comes with Enterprise, and depends on your cloud provider and your scope. It is a question of contract rather than of configuration, so it is worth settling early.
Can we audit this?
It is your account, so you can inspect it the way you inspect anything else you run. The software is MIT licensed, so your reviewers can read what it does rather than take our word for it.
We are a small team without a security function. Is that a problem?
It changes what you need from us rather than whether this works. That conversation belongs in scoping, and it is a normal one to have.