Skip to content

Compliance Posture

This page documents GiveCare's compliance framing for partnership, health-system, and payer conversations. Specific attestations, audit reports, and tuned control details are deliberately not published here — they are shared under NDA during partner diligence.

GiveCare operates in a caregiver-facing, SMS-delivered, AI-augmented space adjacent to healthcare. Three compliance regimes shape how the product is architected, documented, and partnered.

The three regimes

HIPAA — the regulatory floor

HIPAA is the U.S. regulatory regime governing protected health information (PHI) held by covered entities and business associates. It is not optional for organizations handling PHI, and it is not a certification — it is a continuous compliance posture enforced by the HHS Office for Civil Rights (OCR)1.

The operational HIPAA program centers on:

  • A named HIPAA Compliance Officer (security/compliance point person).
  • Annual risk assessments and audits against HHS OCR's Audit Protocol.
  • Documented administrative, physical, and technical safeguards.
  • Annual workforce training with attestations on file.
  • A breach-reporting process understood and used by staff, with incident tracking.
  • Continuous risk management rather than point-in-time review.

For caregiver-facing products, HIPAA applicability depends on whether the product is acting as a covered entity, a business associate, or neither. Most direct-to-caregiver wellness products are not covered entities but may become business associates when integrated with a health system, payer, or clinical workflow. Partnership architecture decides the answer.

SOC 2 — the enterprise trust signal

SOC 2 is the AICPA framework through which service organizations demonstrate controls over customer data. Reports come in two forms1:

  • SOC 2 Type 1 — point-in-time evaluation of control design.
  • SOC 2 Type 2 — control operating effectiveness over a period (usually 3–12 months).

Every SOC 2 engagement covers the Security Trust Service Criteria. Additional criteria — Availability, Processing Integrity, Confidentiality, Privacy — are scoped in based on business context. The Common Criteria span CC1 through CC9: control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, and risk mitigation.

SOC 2 is widely required for B2B enterprise sales and is typically the first trust-signal deliverable a partnership conversation asks for.

HITRUST — the healthcare assurance layer

HITRUST is a cybersecurity assurance framework widely used in U.S. healthcare. It maps across HIPAA, NIST, ISO 27001, PCI, and other regimes, and is a common purchasing requirement for health-system, payer, and hospital-network partnerships1. Three certification levels exist:

  • e1 — entry-level, foundational.
  • i1 — moderate risk, broader control set.
  • r2 — high-rigor, full risk-based assessment.

Certification is performed by an external Validated Assessor (A-LIGN, Prescient Assurance, Insight Assurance, or others) through a Readiness assessment, remediation, and a Validated Assessment submitted via HITRUST's MyCSF platform for HITRUST QA review.

How the regimes stack

Regime Role Driven by
HIPAA Regulatory floor when PHI is handled U.S. federal law / HHS OCR
SOC 2 Enterprise / B2B trust signal Customer and partnership procurement
HITRUST Healthcare-specific assurance Health-system, payer, hospital-network partnerships

The three are additive rather than alternative. An organization doing serious healthcare partnership work typically needs HIPAA compliance operationally, a SOC 2 Type 2 report for enterprise sales, and HITRUST certification (e1 → i1 → r2 as the partnership bar rises) for health-system integration.

How GiveCare approaches each

GiveCare's public posture is aligned with the three-regime model, with specifics held private where they are sensitive or still being tuned:

  • HIPAA: GiveCare treats caregiver-provided information with HIPAA-grade care by default, regardless of whether a given partnership triggers covered-entity or business-associate status. This avoids a reconfiguration scramble when partnership architecture changes.
  • SOC 2: The operating goal is a Type 2 report with Security, Availability, and Confidentiality criteria scoped in at minimum, with Privacy added when the partnership architecture requires it.
  • HITRUST: HITRUST is treated as a partnership-driven certification — pursued at the level (e1 / i1 / r2) that matches the most demanding active partnership, rather than pre-certified speculatively.

What stays private

Per the public / private boundary described in CLAUDE.md:

  • Specific control configurations, tuned thresholds, and operational evidence are not published.
  • Active attestation reports and audit workpapers are shared under NDA with partners and not published here.
  • Specific incident details, when they occur, are handled under the HIPAA breach process and are not published.

The posture, structure, and rationale are public because they are load-bearing for partnership conversations; the tuned specifics are not.

Adjacent references

  1. Vanta. "HIPAA, SOC 2, and HITRUST Compliance Checklists." Source → ↩↩↩