We never learn who your users are.
Health and wearable data reaches us against an external ID you assign. No name, email address, phone number or postal address ever does, and the mapping back to a real person stays in your systems. Everything else a review needs is below; anything we do not publish is one email away.
- Attestation
- SOC 2 Type 2 Security, Availability, Confidentiality
- HIPAA
- BAA signed on request We act as business associate
- GDPR
- DPA published We act as processor
- Hosting
- AWS us-east-1
The document library.
Most of these are linked directly. The rest are restricted-use documents, so we send them by email rather than publish them — usually the same day.
SOC 2 Type 2 · Security, Availability, Confidentiality
- Period
- August 1 to November 14, 2025
- Entity
- Sahha Pty Ltd, Sydney, Australia
- Opinion
- Unqualified. Controls were suitably designed and operated effectively across the period.
- Incidents
- No significant system incidents were identified during the period.
-
Business Associate Agreement (BAA)
HIPAA terms supplementing the API Licence Agreement. Covers you whether you act as a covered entity or as a business associate.
-
Data Processing Addendum (DPA)
GDPR Article 28 processor terms, including the EU Standard Contractual Clauses and the UK Addendum. Incorporated into the API Licence Agreement; no separate signature required.
-
API Licence Agreement
The terms governing use of the Sahha API and SDKs. Custom contracts can carry an SLA.
-
Privacy Policy
How Sahha handles personal data as a company.
-
End User Privacy Policy
Written for the people whose data flows through Sahha. Linkable from your own app.
-
Sub-processor register
Every third party that processes data on our behalf, split into sub-processors and service providers.
-
Security FAQ
Hosting, encryption, retention and incident response, answered in full.
How the environment is secured.
Every control below is covered by our SOC 2 Type II audit, which carries the detail and the auditor's opinion on each.
| Domain | Control |
|---|---|
| Infrastructure | Hosted on AWS in the US (us-east-1) |
| Deployed across multiple availability zones, so no single zone is a point of failure | |
| VPC network isolation and security group restrictions | |
| Infrastructure managed as code, under change control | |
| Automated monitoring across the environment | |
| Encryption | TLS 1.2 or above for all data in transit |
| AES-256 for all data at rest, via AWS-managed encryption | |
| Keys managed through AWS KMS under strict access policies | |
| Credentials, tokens and API keys held in a managed secret store | |
| Access | Multi-factor authentication required on every critical system |
| Role-based access control on customer data, on a least-privilege basis | |
| Formal onboarding and termination process, with access revoked on departure | |
| System access reviews performed annually | |
| All access to customer data logged with audit trails | |
| People | Reference checks before onboarding, proportional to the role |
| Security training required on hire and renewed annually | |
| Written confidentiality terms with personnel, vendors and business partners | |
| A documented information security policy set, reviewed on a defined cycle | |
| Development | Source control with change management over what reaches production |
| Automated dependency scanning on the codebase | |
| A secure development policy governing how changes are built and released | |
| Continuity | Automated backups of all customer and system data, daily |
| Business continuity, backup and recovery plans documented | |
| Continuity, disaster recovery and incident response plans tested and updated annually | |
| Formal risk assessment performed at least annually | |
| Incident response | Documented incident response process, owned by an identified response team |
| Incidents tracked through root cause, remediation and lessons learned | |
| Affected customers notified within 24 hours of a confirmed breach | |
| Vendors | Maintained inventory of third parties, risk-rated by access and criticality |
| Security, confidentiality and privacy reviewed before a vendor is accepted | |
| Vendor compliance reports requested and reviewed on re-review | |
| Vendor risk reassessed at least annually |
Where a line names an algorithm, a TLS version or an AWS region, that specificity comes from AWS platform documentation rather than the report, which evidences that data is encrypted without naming the implementation. Hosting in another AWS region is available to enterprise customers as a scoped engagement with lead time — a commercial arrangement rather than an audited control, which is why it is not in the table.
AWS is the only third-party vendor that processes health data.
Sahha (New Zealand) Limited, a group affiliate, has authorised personnel who access that data to operate and support the Services. Slack and Microsoft 365 can see profile identifiers when those come up in a support conversation. Neither receives health data. The register adds what each party handles and where, plus the service providers that hold our business data rather than yours.
View the register-
Amazon Web Services (AWS)
All customer health data and derived outputs
-
Sahha (New Zealand) Limited
Customer health data and derived outputs
-
Slack
Profile and external identifiers
-
Microsoft 365
Profile and external identifiers
Where health data goes, and what protects it at each hop.
Four stages, from the user's device to your systems. Nothing leaves Sahha infrastructure between stage two and stage four.
- 01
Device
A user grants health permissions in your app through Apple Health or Android Health Connect. Permissions are granted and revoked by the user, in device settings, at any time.
User-held consent at the OS layer
- 02
SDK
The Sahha SDK reads the permitted data and sends it to our ingest API against the external ID you assigned to that user. We never receive a name, an email address or a phone number.
TLS 1.2+ in transit
- 03
Processing
Data is stored and processed entirely inside Sahha infrastructure on AWS, where it is turned into biomarkers, scores, insights and archetypes.
AES-256 at rest, AWS KMS key management
- 04
Delivery
You retrieve outputs from the API, or receive them by webhook as they are produced. Re-associating an external ID with a real person happens in your systems, not ours.
Account-scoped tokens, TLS 1.2+ in transit
TLS versions and cipher names above are AWS platform defaults, not audited controls — see the note in Controls.
An external ID, and the health data attached to it.
Everything Sahha stores against a profile, everything that never reaches us, and the two fields that are yours to send or withhold.
What Sahha stores
- An external ID, chosen and assigned by you
- Health and wearable data permitted by the user at the device
- Biomarkers, scores, insights and archetypes derived from that data
- Device and platform metadata needed to interpret the readings
What Sahha never receives
- Names
- Email addresses
- Phone numbers
- Postal addresses
- Government identifiers
- Payment details
What Sahha stores if sent
- Date of birth
- Gender
Yours to send or withhold. Both improve the accuracy of scores, insights and archetypes.
A score is still health data. Wherever you send one next — your CRM, your analytics, a partner — it carries the same obligations as the readings it came from. Being aggregated or non-diagnostic does not make it something else.
No health data goes to third-party AI services.
Scores, biomarkers, insights and archetypes are produced by Sahha models running inside Sahha infrastructure on AWS.
Our SOC 2 report lists OpenAI among the tools Sahha uses internally. Health data is not one of the inputs: the report maps user health information to AWS alone.
You can delete any profile, at any time, without asking us.
Deletion is an API call rather than a support ticket, which is what makes it usable as the back end of your own data subject request process.
Retention
As long as the profile is active
Data from direct cloud integrations is the exception: it passes through a transient delivery cache and is deleted automatically within 3 days, as set out in the Customer Data Use Policy.
Deletion
Within 30 days of the API call
Deleting a profile permanently removes everything associated with it. You can trigger this at any time, for any profile, without contacting us.
Revocation
Collection stops immediately
When a user revokes health permissions at the device, nothing further is collected. Data already held remains until the profile is deleted.
You are the controller. We are the processor.
That split decides most of what follows, and the table below is how it divides in practice. Your own obligations in your own jurisdiction are for you and your counsel to determine, not us.
| Area | Sahha | You |
|---|---|---|
| Identity | Stores data against the external ID you supply. Holds no direct identifiers. | Generates external IDs and holds the mapping between them and real people. |
| End-user consent | Processes only what the OS health permission allows, and stops when it is revoked. | Obtains and records the consent your own regulator expects, and discloses what your app does with health data. |
| GDPR roles | Acts as processor for customer health data, under the DPA. | Acts as controller, and determines the purposes and means of processing. |
| HIPAA roles | Acts as business associate where a BAA is in place. | Determines whether it is a covered entity or business associate for its own use. |
| Data subject requests | Deletes profile data on request through the API, and supports export. | Receives requests from end users, verifies identity, and triggers the deletion. |
| Downstream use | Delivers outputs to the endpoints you configure. | Decides where those outputs go next, and under what terms. |
Sahha is not a medical device.
Sahha measures behavioural patterns. Scores, biomarkers, insights and archetypes do not detect, diagnose, screen for or predict any medical condition, and they are not intended to be used for clinical decision-making.
Where our published research cites associations between behavioural measures and health outcomes, those associations are population-level. They do not support inferring an individual user's risk, and content built on Sahha outputs should not present them that way.
If your intended use sits closer to a regulated clinical context than the above allows, raise it with us early. That conversation is easier before an integration is built than after.
Found something? Tell us.
Report suspected vulnerabilities to security@sahha.ai. Include enough detail to reproduce the issue, and give us a way to reach you for follow-up.
We will acknowledge your report and keep you updated through remediation. We will not pursue legal action against researchers who report in good faith, avoid privacy violations and service degradation, and give us reasonable time to fix the issue before disclosing it.
Please do not test against production profiles containing real user health data. Ask us for sandbox credentials instead.
Security and compliance questions.
The compliance facts a review needs to confirm quickly.
The full set, with search, is on the Security & Compliance FAQ.
Is Sahha SOC 2 compliant?
Yes. Sahha has completed a SOC 2 Type II audit. Request the report from the security page and we will send it by email, usually the same day. It is a restricted-use document, so we do not publish it.
Is Sahha HIPAA compliant?
Yes. Sahha is HIPAA compliant and a Business Associate Agreement (BAA) is available on request for customers who require one.
Is Sahha GDPR compliant?
Yes. Sahha is GDPR compliant. A Data Processing Addendum (DPA) is published and is incorporated into the API Licence Agreement; no separate signature is required.
Where is Sahha data hosted?
Data is hosted on AWS in the US (us-east-1). Regional hosting in other AWS regions can be arranged for enterprise customers on request.
What encryption is used in transit and at rest?
All data in transit is encrypted using TLS 1.2+. Data at rest is encrypted using AES-256 via AWS-managed encryption. Keys are managed through AWS KMS with strict access policies.
Is health data classified as PHI?
Sahha treats all health data with PHI-level controls even though direct identifiers are not stored. Data is pseudonymized — the only PII retained is gender and date of birth — and all infrastructure, access controls, and processes are designed to meet HIPAA requirements.
Still have questions?
Send us your questionnaire and we'll complete it. If it's faster to talk it through, book a call and bring your security lead.