Trust

Security at Titan.Care

Last updated: September 8, 2026 · Titan.Care, Chicago, IL

What this page is

Titan.Care holds health records for families and operational and clinical records for home-care agencies and medical practices. This page describes how that information is protected today. Where a control is planned rather than in place, it says so. Customers under a business associate agreement can request the full system description, current policy summaries and evidence on request at security@titan.care.

Where your data lives

  • All application servers, databases, file storage, AI processing and image moderation run inside one Amazon Web Services account in the United States, under a signed business associate agreement with AWS.
  • Health information does not leave that account for AI processing. Every AI feature in the product runs on AWS.
  • Application configuration and credentials are held in AWS Secrets Manager and are never built into the application image.

Encryption

  • In transit: TLS at the edge and between services, with HTTP Strict Transport Security preloaded for titan.care.
  • At rest: the database and document storage are encrypted with AES-256 managed by AWS. Third-party credentials the product holds on your behalf (for example, connections to an electronic health record) are additionally encrypted at the application level.
  • Passwords are hashed with bcrypt and are never stored or logged in clear text.

Access control

  • Sign-in requires a password and a one-time code sent by email. A device can be trusted for a limited time; trust can be revoked.
  • Families decide who can see a record and which categories, through explicit consent. Views are limited to what the viewer was granted.
  • Agency and practice users see only their own organization, and within it only what their role allows. Every request re-checks the role.
  • Administrative access to the cloud account requires multi-factor authentication. Access is reviewed quarterly.

Auditing and monitoring

  • Access to health records is recorded in an audit log that names the user, the record, the action, the route and the purpose of access. Audit records are retained for six years.
  • The public edge is protected by a web application firewall with managed rules and rate limits on sign-in.
  • Container images are scanned for known vulnerabilities before deployment; dependencies are audited on every change and known vulnerabilities are fixed within defined windows.
  • Account activity logging and threat detection for the cloud account are being enabled in September 2026.

Availability and recovery

  • The application runs on multiple servers across two availability zones behind a health-checked load balancer; failed deployments roll back automatically.
  • The database is backed up daily with point-in-time recovery. Documents are versioned.
  • Recovery objectives, restore rehearsals and a public status page are part of the program described below.

Change management and development

  • Every change to the product goes through a pull request with an automated type check and a suite of more than 1,500 tests, including authorization tests for every surface.
  • Deployments are automated from the main branch through a short-lived, identity-based connection to AWS; no long-lived deployment credentials exist.
  • Secrets scanning, dependency auditing and static analysis run on every change.

Vendors

Vendors that may handle information on our behalf, and the role of each. A vendor that receives health information is engaged under a business associate agreement or is given none.

  • Amazon Web Services: hosting, storage, AI processing and monitoring. Business associate agreement in place.
  • Resend: transactional email such as sign-in codes and invitations.
  • Sentry: application error monitoring, with identifiers removed before transmission.
  • Stripe: payment processing. No health information is shared.
  • Apple and Google: application distribution and push notifications.
  • Epic and connected device makers: data sources you authorize directly from your own accounts.
  • Clearinghouse and state visit-verification aggregators: used for agency billing and Medicaid reporting when a customer activates them.

Our program

  • A written information security program aligned to the HIPAA Security Rule, with a named security official, policies reviewed annually, an annual risk assessment, workforce training, an incident response procedure and a vendor management procedure.
  • We act as a business associate to the agencies and practices that use Titan.Care and sign a business associate agreement with each.
  • We are preparing for a SOC 2 examination covering security, availability and confidentiality.

Reporting a concern

If you believe you have found a security vulnerability or that information has been exposed, write to security@titan.care. We acknowledge reports within two business days and will not take legal action against good-faith research that respects user privacy and does not disrupt the service. Please do not access data that is not yours and do not test against the production system with real accounts other than your own.

What we do not do

  • We do not sell health information and do not use it for advertising.
  • We do not send health information to any AI provider outside our AWS account.
  • We do not practice medicine. Titan.Care supports care; clinicians make clinical decisions.