Our security posture, in plain language.

§1 · Posture

What this page is, and what it is not.

This page documents Uphealth's actual security practices today — not aspirational, not certified-pending. Where a control is in place, we describe it concretely enough that a reviewer can verify by reading our code, our infrastructure configuration, or the relevant subprocessor's posture page. Where a control depends on a paid attestation (SOC 2 audit, third-party penetration test, BAA legal review), we say so plainly and explain the trigger that funds it — typically the first Deliver-mode engagement of sufficient size.

§2 · Architecture

Display by default. Deliver by contract.

Uphealth ships two integration modes, and the security posture for each is shaped by what data crosses our infrastructure.

Buyers who are evaluating Display mode should treat this page as their full coverage. Buyers evaluating Deliver mode should plan on a parallel conversation that produces the BAA, the HIPAA risk assessment, the security packet, and any tier-specific controls.

§3 · Application security

What runs in the application layer.

Controls below are in production today across the live Uphealth surface. Each is implemented in our application code or in the hosting layer and is exercised on every relevant request.

• Transport security. TLS 1.2 minimum across all surfaces. Certificates issued and renewed by Let's Encrypt (automated, no manual rotation). HSTS enabled on all public hosts (two-year max-age, includeSubDomains); HSTS preload submission pending.
• API authentication. Token-based authentication on the Signal API. Tokens are scoped to the issuing tenant, stored only as SHA-256 digests at rest, and the bare token is shown to the operator exactly once at issuance. Rotation is supported without downtime; revocation is immediate. Deliver mode is gated: a stream cannot request Uphealth-sent delivery without the deliver scope and explicit Deliver approval.
• Authorization + IDOR defense. Every content-read endpoint validates ownership before returning the requested record. Cross-tenant reads return 404 (not 403) so an attacker cannot enumerate by response shape. A separate IDOR-attempt detector watches for 404 bursts on show endpoints and emits an audit-log event when a threshold is tripped.
• Rate limiting. Rack-based throttles cap content-show requests per actor, authentication attempts per IP, Signal API calls per token, and the self-serve capture and signup forms per IP and per email. Throttle trips are stamped to the audit log with the actor identifier and route fingerprint.
• Anti-bot signup defenses. Honeypot field plus a four-second timestamp gate plus a typo-suggest pass on the email field on every public signup form. Suspicious-name heuristic catches the long random-ASCII pattern common in bot signups. All trips are stamped to a dedicated audit log channel.
• Dependency + code scanning. Dependabot watches the Gemfile and npm dependencies for known CVEs, with automatic security-update pull requests. Bundler-audit and Brakeman run on every pull request and block new findings from merging.
• Audit logging. Security-relevant events (anti-bot trips, rate-limit trips, IDOR-attempt detections, authentication failures) are stamped to the application log with stable prefixes that downstream tooling can pattern-match. Outbound email events (delivery, open, click, bounce, complaint) are captured to a dedicated database table via the Postmark webhook.

§4 · Infrastructure

Where the application runs.

Uphealth runs in a single US region on dedicated DigitalOcean infrastructure. Components and their roles:

• Hosting region. DigitalOcean SFO3 (San Francisco), US. All compute, storage, and database resources are pinned to this region.
• Compute. Dedicated DigitalOcean Droplet (not shared tenancy). Operating system is patched on a documented cadence; the application runs under systemd with restart-on-failure for the web tier and the recurring-job worker.
• Database. PostgreSQL on DigitalOcean Managed Postgres. Network access restricted to the application droplet via a Virtual Private Cloud (VPC); no public network address. Automated daily backups retained per DigitalOcean's Managed Database backup policy; manual snapshots taken before any destructive migration.
• Object storage. DigitalOcean Spaces for static assets. No PHI is stored in object storage in the Display-mode default; any Deliver-mode use of object storage for PHI is configured at activation under the BAA umbrella.
• Network controls. DigitalOcean Cloud Firewall in front of the droplet restricts ingress to HTTPS (443) and SSH (22 from operator IPs only). VPC isolation between the application droplet and the managed database. Outbound traffic restricted to known subprocessor endpoints.
• Encryption at rest. DigitalOcean encrypts compute volumes and Managed Postgres storage at the infrastructure layer. Database backups inherit the same encryption.
• Encryption in transit. TLS 1.2 minimum on all external surfaces (web, API, webhook receivers). Internal traffic between the application droplet and the database is restricted to the VPC's private network.
• Email delivery. Postmark Pro for transactional email. TLS in transit between Uphealth and Postmark; DKIM + SPF + DMARC published on our sending domain, uphealth.me, with DMARC at p=reject. Postmark's standard retention applies for message bodies; outbound event data (delivery, open, click, bounce) is mirrored to a dedicated table in our database for durable join.

§5 · Data handling

Three classifications, plus content provenance.

Data is classified by sensitivity, and each tier has its own handling rules.

Content provenance. Every health message in the catalog (currently 18,739 active messages across 2,447 active topics in 31 active interests) carries a primary federal source citation in the database, captured at ingestion — primary-source coverage is 100% and is enforced by the linter. Secondary cross-source citations are captured on every active message as well, validated against the same federal allowlist at ingestion. The federal-source-only sourcing policy is locked at the ingestion layer — a manuscript that cites a non-federal source is rejected by the linter before review.

§6 · BAA + Deliver mode

What the BAA covers, and how it is executed.

Uphealth offers a standard Business Associate Agreement to Deliver-mode customers at the PMPM tier and above, and supports custom Enterprise BAA terms negotiated alongside the contract. The BAA is the legal frame for PHI handling under HIPAA; it is not a substitute for the technical controls in §3–§5 above, which apply universally.

The hosting layer participates in HIPAA compliance through DigitalOcean's HIPAA Covered Products program. DigitalOcean offers a Business Associate Agreement covering its HIPAA-eligible products (Droplets, Spaces, Cloud Firewall, VPC, Backups, Snapshots, Load Balancers); the Deliver-mode PHI store is provisioned on those covered products, and the DigitalOcean BAA is executed at the activation of the first Deliver-mode engagement — with the scope of any managed-database component confirmed with DigitalOcean as part of that activation. Outbound email is not a BAA dependency: in Deliver mode it runs a notify-and-link pattern, so no PHI reaches the email provider and no email-provider BAA is required. The Shared Responsibility Model that DigitalOcean publishes is the contract between the layers — they handle the infrastructure controls, we handle the application and workload controls.

Activation produces, at minimum: (a) signed Uphealth BAA with the customer, (b) signed downstream BAAs with subprocessors, (c) HIPAA risk assessment documented (we use the HHS Security Risk Assessment Tool as the framework), (d) tier-appropriate access scoping for the customer's workload, (e) any custom audit-log routing the customer requires. Timeline is typically days for the BAA path itself, longer when third-party penetration testing or SOC 2 attestation is also requested (those are tier-scaled costs funded by the deal).

§7 · Subprocessors

Vendors that process Uphealth or customer data.

The list below is the complete set of third parties that process data on Uphealth's behalf. The "BAA available" column indicates whether the vendor signs a BAA for HIPAA workloads — we sign downstream BAAs at Deliver-mode activation for every vendor that handles PHI.

Subprocessor additions are communicated to active Deliver-mode customers in advance with at least thirty days notice. Display-mode customers receive subprocessor notice through updates to this page.

§8 · Availability

How operational state is monitored and surfaced.

Operational state is monitored continuously and surfaced to buyers without a human gate. The chain:

• Authoritative monitor. An external service runs a five-minute keyword check against the application health endpoint (/health). A missed keyword on two consecutive checks alerts the operations contact.
• Customer-facing status surface. The status page surfaces overall operational state plus per-surface operational dots for Signal API, Reach API, Compass for HR, the member-facing surface at uphealth.me, and the application health endpoint itself.
• Uptime target. A 99.9 percent uptime target applies at the PMPM tier and above, defined in the per-tier contract. Display-mode and Discovery-tier traffic share the same infrastructure but carry no contractual uptime commitment — best-effort, same operational discipline.
• Incident response. Severity 1 incidents (customer-impacting outage or data exposure) trigger immediate customer notification through the channel the customer designates at activation. Status-page state is updated alongside. Post-incident, a documented review captures root cause and any control changes; Deliver-mode customers receive the review.
• Incident history. No customer-impacting security incidents since the operational re-launch in April 2026. Operational history before that date is on the historical record at the member surface.

§9 · Responsible disclosure

Reporting a vulnerability.

We welcome reports of security issues from researchers and customers. Our coordinated-disclosure expectations are below; reports submitted in good faith and within scope will be acknowledged and worked through to resolution.

• Reporting channel. Email security@uphealth.me with a description, affected endpoint or surface, and reproduction steps. Encrypt the report with our PGP key on request; the key fingerprint is published alongside this page when the key is in place.
• Machine-readable contact. /.well-known/security.txt (RFC 9116) carries the canonical reporting address, the policy URL, and the file's expiration date.
• Acknowledgment. We acknowledge receipt within five business days. Validated reports receive a status update at least every fourteen days through resolution.
• Disclosure window. Ninety days from the date of validation, extendable by mutual agreement when a fix is in motion. We coordinate public disclosure with the reporter where the reporter wishes credit; anonymous reports are honored without credit.
• Safe harbor. Good-faith reporting that stays within scope (see below) will not result in legal action against the reporter, will not result in CFAA referral, and will not result in account suspension on the reported surfaces.
• In scope. The uphealth.us API surface, the uphealth.us web pages, the uphealth.me member surface, our published webhook receivers, and our authentication flows.
• Out of scope. Denial-of-service testing, physical attacks, social engineering of staff, attacks on third-party subprocessors (report those to the subprocessor directly), and reports based on outdated software versions when a current version is documented.
• Bug bounty. We run a vulnerability disclosure program without monetary bounties at this time. Valid reports receive written acknowledgment and, where the reporter consents, public credit on a future acknowledgments section of this page.

§11 · Frameworks

What we have done, what we will do at activation.

Paid third-party attestation is deal-gated. The frameworks below are how we orient our practices today; the formal audits and tests below are scoped to the first engagement that funds them.

• OWASP API Security Top 10 (2023) — self-assessment. Self-assessed 2026-05-23. The Signal API surface is the in-scope target; the posture summary is quoted in the security packet PDF (§10) and the full document is available to buyers on request under NDA.
• OWASP ASVS Level 1 — self-assessment. Self-assessed 2026-05-23 (ASVS 4.0.3). The Signal API surface is the in-scope target; covered alongside the OWASP API Top 10 in the application-layer assessment document.
• CIS Controls v8 Implementation Group 1 — self-assessment. Self-assessed 2026-05-23. Scope is the full organization and the application stack; the posture summary is quoted in the security packet PDF (§10) and the full document is available to buyers on request under NDA.
• HIPAA risk assessment. The HHS Security Risk Assessment Tool is the framework we use. The assessment is run at Deliver-mode activation for each engagement.
• SOC 2 Type I. Not engaged. SOC 2 Type I will be engaged when the first Deliver-mode or Enterprise-tier engagement of sufficient size funds the audit.
• Third-party penetration test. Not engaged. Scoped to the first Deliver-mode or Enterprise engagement that funds it. The pen-test scope is documented internally and will execute against the same Signal API surface that the ASVS assessment covers.
• BAA legal review. Our BAA template is in place; outside-counsel review is scoped to the first qualifying Enterprise engagement.