Security Overview | Healthdex

Updated September 17, 2026

SOC 2 readiness is in progress; Healthdex is not SOC 2 certified. Healthdex has not completed a SOC 2 Type I or Type II examination and does not have a SOC 2 report. Our current work is intended to build and document a SOC 2-ready control foundation; it is not independent assurance that controls have operated effectively over a period.

Current data boundary

The current service uses governed public and licensed market evidence, ordinary account and operational data, user-created workflow content, and fixed Healthdex-created synthetic claim-like records. It does not currently accept real customer claims, protected health information, membership or eligibility files, patient records, or other sensitive patient information. Any future customer-data pilot requires separate written authorization, security and privacy review, prohibited-field validation, retention and deletion rules, tenant controls, and appropriate contractual terms before transfer.

Identity and access

Named-user accounts with password hashing, password-strength requirements, and compromised-password screening.
Generic authentication errors and login throttling designed to reduce account enumeration and automated abuse.
Secure, HTTP-only, same-site session cookies; session identifier rotation; idle and absolute expiry; and session revocation.
Role, permission, tenant-membership, and platform-global authorization checks for protected functions.
Controlled administrative and command-line workflows for elevated operations.

Tenant and application controls

Tenant predicates and guarded writes are used to keep customer-scoped work within authorized tenant boundaries.
Mutation requests use anti-cross-site-request-forgery controls, and rendered and exported content uses contextual output protections.
Inputs, queries, background jobs, and exports use validation and bounded execution patterns intended to reduce misuse and failure propagation.
Public-source lineage, methodology versions, checksums, decision records, and publication gates support traceability of market evidence.

Transport, secrets, and infrastructure

Production operation is designed to require encrypted HTTPS transport with explicit trusted-proxy boundaries. Application secrets are kept outside source code through environment-managed configuration. Access to infrastructure and service-provider systems is limited by role and operational need. Specific architecture, credentials, detection rules, and exploitable implementation detail are not published.

Logging and incident response

Healthdex records bounded authentication, authorization, tenant, administrative, and workflow events needed for security and accountability. Security telemetry is designed to avoid raw passwords, session secrets, and unnecessary direct identifiers; selected identifiers may be hashed. Healthdex maintains incident-response procedures covering assessment, containment, evidence preservation, recovery, communication, and retrospective improvement. Contract-specific notification commitments apply only when agreed in writing.

Secure development and governance

Healthdex maintains documented threat models, tenant-isolation rules, authentication operations, data-scope restrictions, release checks, and automated tests for critical boundaries. Changes are reviewed and validated in proportion to risk. Dependencies, infrastructure, data sources, and third-party services are evaluated as the product evolves.

SOC 2-ready direction

Healthdex is preparing for SOC 2 readiness by mapping control objectives, owners, policies, procedures, evidence, exceptions, and remediation work to the applicable AICPA Trust Services Criteria. “SOC 2 ready” describes preparation for a possible future independent examination; it does not mean certified, compliant, audited, or guaranteed secure. Healthdex is not currently pursuing or promising a SOC 2 examination on a particular date. If that changes, only a report issued by an independent CPA firm would provide SOC 2 assurance for its stated scope and period.

Current limitations and roadmap

Security is an ongoing program, not a one-time checklist. Healthdex has not yet completed an independent penetration test, deployed multifactor authentication or passkeys, completed formal backup-and-recovery and disaster-recovery exercises with measured objectives, or established production monitoring evidence across an extended operating period. Additional work remains for multi-instance rate limiting, browser security policy review, managed-secret rotation exercises, dependency and host scanning, cross-tenant negative testing with additional production-like tenants, and formal control-evidence review. These items are tracked as readiness work and should not be interpreted as completed controls.

Shared responsibility

Customers and evaluators must secure their devices, accounts, and downloaded files; assign access only to authorized personnel; remove access promptly when roles change; follow the Acceptable Use Policy; and avoid submitting prohibited data. Customers remain responsible for deciding whether Healthdex is appropriate for a proposed use and for independently validating evidence used in material decisions.

Report a concern

If you suspect unauthorized access, exposed information, or a vulnerability, stop any testing and report it through the request form on our public website. Do not include credentials, patient information, exploit payloads containing sensitive data, or other prohibited data. A dedicated security contact and vulnerability-disclosure process will be added as the program matures.

About this overview

This overview is a public summary, not a certification, audit opinion, warranty, service-level agreement, or exhaustive description of controls. Safeguards and limitations may change as the service evolves. Specific contractual security commitments must appear in a signed agreement.