Quick read: Claimaro is built for HIPAA-regulated workloads. We encrypt PHI in transit (TLS 1.2+) and at rest (AES-256), enforce role-based access with multi-factor authentication, log every PHI access to an append-only audit trail, sign a BAA with every customer whose data includes PHI, and run on SOC 2 Type II-audited hosting and database infrastructure. Claimaro has not completed a SOC 2 audit of its own; our control environment is aligned to the trust services criteria and a formal audit is on our roadmap. Our security documentation and subprocessor list are available to qualified customers under NDA.
1. Compliance & frameworks
- HIPAA — Claimaro operates as a Business Associate to covered entities and other business associates. We sign a Business Associate Agreement (BAA) with every customer whose data includes Protected Health Information (PHI) before any PHI is processed. See our HIPAA page for the shared-responsibility model and BAA process.
- SOC 2 — We maintain a control environment aligned to the SOC 2 trust services criteria: security, availability, confidentiality, and processing integrity. We have not yet completed a formal SOC 2 audit; documentation of our controls is available under NDA to customers and qualified prospects.
- HITECH, ACA, and state insurance regulations — Our controls are designed to support customer obligations under HITECH, the Affordable Care Act, and applicable state insurance and consumer-protection laws.
- PCI DSS — Card data is handled by PCI-DSS Level 1 payment processors (Stripe, NMI, Authorize.net, Deluxe). Claimaro does not store full card numbers; tokenization happens in the processor's hosted fields.
2. Encryption
- In transit: all traffic to and from Claimaro is encrypted with TLS 1.2 or higher. HSTS is enforced on all public domains. Internal service-to-service traffic uses TLS or runs over private networks.
- At rest: all customer data — including PHI, files, and backups — is encrypted at rest with AES-256. Database storage, object storage, and backups inherit encryption from our managed cloud providers.
- Key management: encryption keys are managed by our cloud providers (AWS KMS via Supabase, Vercel-managed secrets). Application secrets are stored in environment variables scoped per environment (production, preview, development) and never committed to source control.
- Field-level masking: highly sensitive fields (SSN, government ID, full DOB) are masked by default in the administrative UI. Reveal actions are logged with the user, timestamp, and reason.
3. Access control & authentication
- Role-based access control (RBAC): seven system roles with permissions enforced server-side. Customer admins control their own users' roles and access.
- Multi-factor authentication (MFA): TOTP-based MFA for administrative access to the platform, with customer-controlled enforcement for their organization's users. Claimaro accounts that can reach production systems are MFA-protected.
- Tenant isolation: every customer runs on its own isolated database. Every read and write is additionally scoped at the application layer to the authenticated user's tenant, with a database-level Row Level Security (RLS) backstop. Cross-tenant data exposure is an automatic security incident.
- Least privilege for staff: Claimaro staff access customer environments only when necessary to support, debug, or maintain the Service. Staff access to a customer tenant is time-boxed, logged in both our cross-tenant audit trail and the customer's own audit log, and customers can disable it entirely.
4. Audit logging
Every authenticated action that touches PHI or sensitive configuration is recorded in an append-only audit log that captures the actor, action, resource, tenant, and timestamp. Logs are retained for a minimum of six years to support HIPAA audit requirements, and automated anomaly detection runs over audit events to flag unusual PHI access patterns for review.
5. Infrastructure & network security
- Hosting: Claimaro runs on Vercel (compute, CDN, edge) and Supabase / AWS (managed Postgres, storage, authentication) in U.S. regions. Both vendors are SOC 2 Type II audited and support HIPAA workloads under Business Associate Agreements.
- Network controls: production databases are not exposed to the public internet for direct connections; application access goes through pooled connections with credentials scoped per environment. Administrative database access is restricted to a small named set of engineers.
- DDoS protection: edge-level DDoS mitigation is provided by our hosting platform on all public surfaces. Authentication endpoints are rate-limited.
- Logging & monitoring: application logs and error events are captured in our hosting platform's observability stack and reviewed as part of operations.
6. Application security
- Secure development lifecycle: all production changes go through pull request review, automated testing, type checking, and linting before merge.
- Static analysis & dependency scanning: ESLint, TypeScript strict mode, and automated dependency vulnerability scanning run on every change. We target remediation of critical vulnerabilities in production dependencies within seven days.
- Input validation & output encoding: all server actions validate input with Zod schemas at the trust boundary. The framework escapes output by default to prevent XSS. Parameterized queries prevent SQL injection.
- RLS-first data model: tables with PHI carry tenant-scoped Row Level Security policies in addition to application-layer filters, so a code bug cannot leak data across tenants.
- Browser security headers: we set HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and a Content Security Policy on application surfaces.
7. Vulnerability management
- Independent assessment: an independent third-party security assessment of the platform was completed in April 2026, and its findings were remediated through our standard severity workflow. We plan recurring independent testing as the platform grows.
- Continuous scanning: automated dependency vulnerability scanning runs continuously. Findings are triaged into our standard severity workflow.
- Patch cadence: our remediation targets are seven days for critical vulnerabilities, 30 days for high, 90 days for medium, and the next scheduled release for low.
- Coordinated disclosure: see Section 13 below — we welcome reports from security researchers.
8. Incident response & breach notification
Claimaro maintains a documented incident response plan covering detection, triage, containment, eradication, recovery, and post-incident review. Security events are escalated immediately to engineering leadership and, when applicable, the customer's HIPAA privacy officer.
In the event of a breach of unsecured PHI, we notify affected customers without unreasonable delay and within the timelines required by HIPAA and the signed BAA — typically within five business days and not later than 60 days from discovery. Notifications include the nature of the breach, the PHI involved, the steps customers should take, and the steps Claimaro is taking to investigate and mitigate.
9. Backups & business continuity
- Backups: production databases are backed up continuously (point-in-time recovery) with daily snapshots. Backups are encrypted at rest.
- Recovery objectives: our target Recovery Time Objective (RTO) is four hours and Recovery Point Objective (RPO) is one hour for production data.
10. Subprocessors & vendor management
We rely on a short list of subprocessors to deliver the Service. Every subprocessor that may access PHI is engaged under a BAA before any PHI is processed. New subprocessors go through a documented vendor security review covering SOC 2 (or equivalent), HIPAA posture, data residency, and incident history.
Current core subprocessors include: Vercel (hosting, edge, build), Supabase / AWS (Postgres, storage, authentication), and a HIPAA-eligible transactional email provider. Payment processing and SMS run through PCI-DSS Level 1 payment processors and carriers selected and contracted by the customer (Stripe, NMI, Authorize.net, Deluxe; Twilio).
The current, complete subprocessor list is available to customers on request at security@claimaro.com. We notify customers in advance of material changes to the subprocessor list and provide a reasonable window to object.
11. Personnel security
- Least privilege: access to production systems is limited to a small, named set of engineers and protected by MFA.
- Confidentiality: everyone with access to customer data is bound by confidentiality obligations covering customer data and PHI.
- Offboarding: production access is revoked immediately upon role change or departure.
12. Shared responsibility
Security is a shared responsibility between Claimaro and our customers.
Claimaro is responsible for the security of the platform — infrastructure, encryption, application code, tenant isolation, audit logging, vendor management, and the controls described above.
Customers are responsible for the security of how they use the platform, including: configuring user accounts and roles, enforcing strong passwords and MFA for their own users, training their staff on HIPAA, controlling who they share access with, accurately classifying their data, and notifying us promptly of suspected account compromise.
13. Reporting a security issue
If you believe you have found a security vulnerability in Claimaro, please report it to security@claimaro.com. Include a clear description, steps to reproduce, and any relevant proof-of-concept. We acknowledge reports within two business days and will keep you updated through remediation. We do not pursue legal action against researchers who report in good faith, stay within the scope below, and give us a reasonable window to remediate before public disclosure.
In scope: claimaro.com, app.claimaro.com, and authenticated areas of the platform using a researcher-owned test account.
Out of scope: denial-of-service testing, social engineering of employees or customers, physical attacks, testing against other customers' tenants, and any access to real PHI.
14. Contact
Note: This document describes the security program at Claimaro at the date above. Specific control descriptions, certifications, and subprocessor lists evolve over time — request our current security documentation and subprocessor list before relying on this page for procurement decisions.