SOC 2 and HIPAA controls
How each SOC 2 criterion (security, availability, confidentiality) and each HIPAA Security Rule technical safeguard is met in Sovaria, what is still open, and what is your part. Our own assessment, not an auditor's.
Security reviewers usually ask the same question: for each control, what does the platform actually do? This page answers it control by control. It is written from the code and configuration, and it lists what is still open.
#HIPAA Security Rule: technical safeguards
These apply to organizations with HIPAA mode on (Enterprise, after the BAA) and to projects marked as holding PHI. Your own version of this table, judged from your live configuration, is the HIPAA safeguards report.
| Safeguard (45 CFR 164.312) | How Sovaria meets it | Status |
|---|---|---|
| Access control | Every request is checked on the server against your access policies and Postgres row-level security; nothing is allowed by default. The organization and project come from the session or key, never from what the caller names. | In place |
| Unique user identification | Every member and app user has their own account; API keys are per project, named and revocable. | In place |
| Emergency access | A sealed break-glass procedure held by a second person. | Planned |
| Automatic logoff | HIPAA mode signs people out after 15 minutes idle and 12 hours in total. Every paid plan can also set organization session timeouts. Sessions end when they next refresh, so up to 15 minutes after the limit. | In place |
| Encryption and decryption | Backups are encrypted before they leave the server (project database backups with AES-256-GCM, platform backups with AES-256), and PHI projects are never backed up unencrypted. The platform database is on encrypted storage. Your own key (BYOK) is available. Encryption of the disks under project databases is being verified. | Partly in place |
| Audit controls | A hash-chained audit log per organization: every request to a PHI project is logged, reads included, and kept at least six years. You can export it, filter it to PHI access, and verify the chain. | In place |
| Integrity | The audit chain proves nothing was changed or removed; point-in-time recovery for dedicated databases; signed database-worker releases. | In place |
| Person or entity authentication | Two-factor authentication is required for every member of a HIPAA organization; passkeys, SAML SSO and SCIM for your staff. | In place |
| Transmission security | TLS 1.2 and 1.3 only on every public endpoint, with HSTS. Database connection strings require TLS. Some traffic between our own servers inside the private network is not yet encrypted. | Partly in place |
Administrative and physical safeguards (risk analysis, workforce training, contingency plan, facility access) are covered by our policies (written and awaiting formal approval) and, for facilities, by AWS. We have not yet accepted the AWS Business Associate Addendum; we will before the first HIPAA customer goes live, and until then we can't sign a BAA for protected health information.
#SOC 2: security
| Criterion | How Sovaria meets it | Status |
|---|---|---|
| CC6.1 Logical access | Default-deny policies and row-level security; each Sovaria service has its own database login with least privilege; scoped API keys; MFA and session timeouts for members. | In place |
| CC6.2–6.3 Granting and removing access | Staff roles in a Control Center that needs a device certificate, password and one-time code; quarterly access reviews; SCIM and roles for your own team. | Partly in place (first quarterly review pending) |
| CC6.6 Boundary protection | Firewall, request filtering (WAF), rate limits, an egress proxy that only connects to public addresses it checked. | Partly in place (network segmentation planned) |
| CC6.7 Data in transit | As transmission security above. | Partly in place |
| CC6.8 Malicious code | Functions run in a gVisor sandbox with a syscall filter; uploads can be scanned for malware; images are signed and the signature is checked before deploy; dependencies and secrets are scanned in CI. | Partly in place |
| CC7.1 Vulnerability management | Full code audits and dependency audits (How we secure and test the platform); a weekly penetration-test suite, isolation matrix and OWASP ZAP scan against production, and weekly CI scans. | Partly in place: code audits in place; the weekly scans are set up, verification pending (external pentest planned) |
| CC7.2–7.3 Monitoring | Tamper-evident audit logs and health checks every 5 minutes with alerts; security logs archived off the server, encrypted, for 400 days. | Partly in place: audit logs and health checks in place; the 400-day archive is set up, verification pending |
| CC7.4–7.5 Incident response | A written incident process with notification clocks; incidents recorded with their timeline; status page. | Partly in place (policy approval pending) |
| CC8.1 Change management | Every change reviewed by someone who didn't write it, to a recorded MERGE verdict with every finding fixed (since 10 November 2026); one deploy path with smoke tests and automatic rollback, and a record of every deploy. | Partly in place (branch protection that enforces the review is planned) |
| CC9.2 Vendors | A public subprocessor list with 30 days' notice of changes. | Partly in place (vendor reports being collected) |
#SOC 2: availability
| Criterion | How Sovaria meets it | Status |
|---|---|---|
| A1.1 Capacity | Resource caps per service, plan limits and our own load tests (Benchmarks). | Partly in place |
| A1.2 Backups and recovery | Daily encrypted backups; point-in-time recovery for dedicated databases (a minute or two of changes at most). Off-site copies of the platform database in storage that can't be deleted for 35 days are being switched on. | Partly in place |
| A1.2 Redundancy | Production runs in one AWS region, with one availability zone for the platform database. | Planned |
| A1.3 Recovery testing | A backup is restored into a throwaway database every month, automatically. | Set up; verification pending |
#SOC 2: confidentiality
| Criterion | How Sovaria meets it | Status |
|---|---|---|
| C1.1 Protecting confidential data | PHI projects with server-enforced rules; your own encryption key; secrets encrypted; evidence packs list keys by prefix, never their values. | In place |
| C1.2 Disposal | Account erasure 30 days after a request; deleting an organization purges every service; a deletion record without content is kept. | In place |
#Your part
- Write access policies and row-level security for every table and bucket; Security advisor flags gaps.
- Require MFA and set session timeouts for your organization (Organizations, members and roles).
- Keep service-role keys on servers, and review members and keys at least every quarter. The evidence pack lists both.
- For health data: be on Enterprise, sign the BAA, mark PHI projects, and download the HIPAA report before go-live.
- Run your own risk analysis, policies and training; they are yours under HIPAA and SOC 2.
The full split, and how to use Sovaria for your own audits: Shared responsibility. Ready-made questionnaire answers: Security questionnaire answers. Questions, or the detailed version for your security team (under NDA): tech@sovaria.in.