Everything your security review needs.
Sahha processes health and wearable data for apps in regulated markets. This page is written for the people who have to sign off on that: legal, IT, privacy and procurement. The documents, the architecture and the controls are all here, and nothing on this page sits behind an NDA.
The document library.
Most of these are linked directly. The rest, including the SOC 2 Type II report, are one email away. No NDA, no form, no call required first.
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.
Audit and assurance
Third-party evidence of our control environment and our cover. Email us and it goes out. There is no NDA to sign first.
-
SOC 2 Type II report
The full report from our most recent audit, covering the security, availability and confidentiality criteria. Ask and we send it.
Contracts
Signed alongside your agreement. Templates are available before you commit.
-
Business Associate Agreement (BAA)
Supplements the API Licence Agreement. Covers you whether you act as a covered entity or as a business associate, requires the same safeguards of any subcontractor, and provides for return or destruction of PHI on termination. Signed on request.
-
Data Processing Agreement (DPA)
GDPR Article 28 processor terms for customers who require them. Signed on request.
-
API Licence Agreement
The terms governing use of the Sahha API and SDKs. Custom contracts can include a service level agreement; ask us if your procurement process requires one.
-
Terms of Use
Terms covering the Sahha dashboard and website.
Privacy
Public documents describing what we collect, why, and what rights your end users have.
-
Privacy Policy
How Sahha handles personal data as a company.
-
End User Privacy Policy
Written for the people whose data flows through Sahha. Referenceable from your own app if you need a downstream link.
-
Sub-processor register
Every third party that stores or processes customer data on our behalf, what they do, and where they process it. Only one of them touches health data.
-
Security FAQ
Hosting, encryption, de-identification, retention and incident response, answered in full.
How the environment is secured.
The controls below are covered by our SOC 2 Type II audit, which has the detail and the auditor's opinion. Where a line names a specific algorithm, TLS version or AWS region, that specificity comes from AWS platform documentation: the report evidences that data is encrypted in transit and at rest, not which cipher implements it.
| 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 | |
| Regional hosting in other AWS regions on request for enterprise customers | |
| 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 72 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 |
The vendors behind the platform.
Who they are and what they do. What each one processes and where, which is what a DPA needs, is on the register itself — it has its own URL so your agreement can reference it directly.
View the register-
Amazon Web Services (AWS)
Cloud hosting, storage, and compute for all data processing
-
Netlify
Cloud hosting for front-end applications
-
Auth0
Authentication for Sahha dashboard users
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. As in the controls table, the TLS and cipher specifics below come from AWS platform documentation rather than from the SOC 2, which evidences that data is encrypted without naming the implementation.
- 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
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
Optional, your call
- Date of birth, which improves score accuracy but is not required
- Gender, which improves score accuracy but is not required
Scores, insights and archetypes are derived from health data, and remain health data. Being aggregated and non-diagnostic does not change how they should be treated downstream.
No health data goes to third-party AI services.
Sahha does not send customer health or wearable data to OpenAI or to any other third-party AI service. 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
Data is retained for as long as the user 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
Deleting a profile through the API permanently removes all data associated with it within 30 days. You can trigger this at any time, for any profile, without contacting us.
Revocation
When a user revokes health permissions at the device, collection stops. Data already collected remains until the profile is deleted.
Who does what.
Sahha is a processor. The split below describes how the work divides in practice. What your own obligations are in your jurisdiction is a determination for you and your counsel, not one we can make for you.
| 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, lives on the security and 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. There is no NDA to sign first.
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 and a Data Processing Agreement (DPA) is available on request for customers who require one.
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.