HIPAA

Overview#

The Health Insurance Portability and Accountability Act 1996 — Public Law 104-191, universally referred to as HIPAA — is the United States' foundational healthcare data law. It was enacted on 21 August 1996 with two primary purposes: portability of health insurance coverage when individuals change jobs, and accountability for the protection of individually identifiable health information. The operational rules sit in Title 45 of the Code of Federal Regulations, specifically Parts 160 (general provisions), 162 (administrative requirements for transactions and code sets) and 164 (security and privacy). The original 1996 statute has been substantially amended by the Health Information Technology for Economic and Clinical Health (HITECH) Act 2009 and by the Omnibus Final Rule 2013 — the latter being the amendment that made business associates directly liable to the Office for Civil Rights for HIPAA violations.

HIPAA is enforced by the Office for Civil Rights (OCR) at the US Department of Health and Human Services. The regulator's caseload is dominated by complaint-driven investigations, periodic compliance audits (the Phase 2 audit programme concluded in 2017 and the post-2024 Phase 3 audits are increasingly automated), and breach notifications received through the OCR breach portal. Civil monetary penalties are tiered by culpability under 42 USC § 1320d-5 — from USD 137 per violation at the lowest tier to USD 2,067,813 per violation category per year at the highest tier in 2026-adjusted figures. Criminal penalties under 42 USC § 1320d-6 apply for knowing misuse of PHI and carry up to ten years' imprisonment.

What makes HIPAA operationally durable across thirty years of changing technology is its flexibility-and-scalability model. The Security Rule does not name specific cryptographic algorithms, specific authentication factors or specific cloud architectures. Instead it requires that covered entities and business associates implement 'reasonable and appropriate' safeguards proportionate to their size, complexity, technical capability and the cost of implementation — taking into account the probability and criticality of potential risks to electronic PHI. That principles-based posture means a clinical AI startup using a cloud-native architecture and a 200-bed regional hospital running on-premises EHR can both comply, but each must document the risk analysis that justifies its chosen controls.

Yobitel's healthcare-vertical posture is built around HIPAA from the start. MediQuery — the Yobitel clinical AI application — ships with a BAA-ready stack: encryption-by-default for PHI at rest (AES-256 with customer-managed keys via AWS KMS, GCP Cloud KMS or Azure Key Vault depending on the deployment region), TLS 1.3 in transit, RBAC tied to OIDC identity, audit logs streamed in the standard `audit.k8s.io/v1` schema to a customer-controlled SIEM, and 60-day breach notification commitments anchored in the BAA. Yobibyte clinical-app workspaces inherit the same posture; customers consuming Yobitel for healthcare workloads absorb the technical safeguards as a baseline and focus their own engineering on the application-level controls.

This entry helps you assemble defensible HIPAA evidence for OCR, for a BAA negotiation with a covered entity, or for a HITRUST CSF assessor — it walks the four rules clause by clause, names the safeguards the Security Rule enumerates, distinguishes 'required' from 'addressable' specifications, maps HIPAA to the adjacent frameworks (HITRUST, SOC 2, ISO 27001, GDPR), and ends with an honest cost ledger and the failure modes OCR has actually fined on.

Scope — who and what HIPAA binds#

HIPAA binds two categories of actor. The covered entity is the original regulated party: healthcare providers (hospitals, clinics, physicians, dentists, pharmacies) that transmit health information electronically in connection with HIPAA-named transactions; health plans (commercial insurers, HMOs, Medicare, Medicaid, employer-sponsored group health plans); and healthcare clearinghouses (entities that process non-standard health information into standard formats). The covered-entity definition is at 45 CFR § 160.103 and is the boundary that determines whether HIPAA applies at all.

The business associate is anyone who creates, receives, maintains or transmits PHI on behalf of a covered entity to perform a function or activity regulated by HIPAA. Cloud providers, SaaS vendors, AI platforms, managed-service operators, claims processors, transcription services, legal counsel that handles patient files, and shredding companies all fall under this definition when they touch PHI. Before the 2013 Omnibus Rule a business associate's HIPAA exposure was contractual via the BAA; the Omnibus Rule made business associates directly liable to OCR for HIPAA violations, materially raising the operational stakes for cloud providers. A business associate that subcontracts any part of its PHI processing creates a sub-business-associate relationship and must execute a downstream BAA with the sub-business-associate.

Protected Health Information is the asset class HIPAA protects. PHI is individually identifiable health information transmitted by or maintained in electronic media, or in any other form. The de-identification standard at 45 CFR § 164.514 names two routes to de-identify PHI such that it falls outside HIPAA: the Safe Harbor method (removal of 18 named identifiers including names, geographic subdivisions smaller than state, dates more precise than year, telephone numbers, email addresses, medical record numbers, biometric identifiers, full-face photographs and others) and the Expert Determination method (a qualified statistician determines the risk of re-identification is very small). Limited Data Sets sit in a middle category — partially de-identified, still PHI, may be used for research and public health with a Data Use Agreement.

Scope also turns on where the work happens. HIPAA is United States federal law and applies to covered entities and business associates regardless of where their data centres or staff are physically located. A UK-headquartered cloud provider serving a US covered entity is fully bound by HIPAA in respect of the PHI it touches, and must sign a BAA on the same terms as a US-domiciled provider. This is the structural reason Yobitel maintains a HIPAA programme for US healthcare customers despite being UK-headquartered — the obligation attaches to the data and the relationship, not to the jurisdiction of the processor.

• Covered entity — healthcare provider transmitting electronically, health plan, or healthcare clearinghouse; defined at 45 CFR § 160.103.
• Business associate — entity creating, receiving, maintaining or transmitting PHI on behalf of a covered entity; directly liable to OCR since 2013 Omnibus Rule.
• Sub-business-associate — vendor a business associate uses; back-to-back BAA mandatory; same liability transfer.
• Protected Health Information (PHI) — individually identifiable health information in electronic or any other form; the asset class HIPAA protects.
• De-identification — Safe Harbor method (18-identifier strip) or Expert Determination method (statistician attestation); de-identified data falls outside HIPAA.
• Limited Data Set — partially de-identified PHI, still HIPAA-bound, may be used for research and public health with a Data Use Agreement.
• Geographic reach — US federal law binds covered entities and business associates regardless of data-centre or staff location; Yobitel's UK headquarters does not exempt the platform from HIPAA when touching US PHI.
• Hybrid entity — a single legal entity that operates both covered and non-covered functions; must designate the covered function and segregate access.

The framework — the four rules and the safeguards#

HIPAA's operational obligations live in four rules. The Privacy Rule (45 CFR Part 164, Subpart E) governs use and disclosure of PHI and defines individual rights — access, amendment, accounting of disclosures, restriction requests. The Security Rule (45 CFR Part 164, Subpart C) defines administrative, physical and technical safeguards for electronic PHI specifically. The Breach Notification Rule (45 CFR Part 164, Subpart D) defines what counts as a breach and the obligations to notify individuals, HHS and media. The Enforcement Rule (45 CFR Part 160, Subparts C, D, E) defines OCR's investigation, civil monetary penalty and criminal-referral processes.

For cloud providers and business associates, the Security Rule is the most operationally consequential. It enumerates 18 standards grouped into three safeguard categories, each standard accompanied by one or more implementation specifications classified as either 'Required' (must be implemented) or 'Addressable' (must be assessed and implemented unless an alternative equivalent measure is documented; 'addressable' does not mean optional). The table below distils the Security Rule's standards, names the implementation specifications, and identifies the evidence regulators expect.

Evidence patterns — the BAA, the risk analysis, and the audit trail#

HIPAA compliance is evidenced by three artefact families. The Business Associate Agreement is the contractual spine. The risk analysis under 45 CFR § 164.308(a)(1)(ii)(A) is the documentary spine that justifies every control choice. The audit trail under 45 CFR § 164.312(b) is the operational spine that survives an OCR investigation. Each is the artefact OCR will request on day one.

The Business Associate Agreement is the contract a covered entity signs with each business associate before any PHI flows. The required terms are enumerated at 45 CFR § 164.504(e) and include: the permitted and required uses and disclosures of PHI; appropriate safeguards to prevent unauthorised use or disclosure; reporting of unauthorised use, disclosure or security incidents; agreement that sub-business-associates execute back-to-back BAAs; return or destruction of PHI at contract termination; and termination of the contract if the covered entity determines a material breach has occurred and has not been remediated. Cloud providers — Yobitel among them — publish standard BAA templates that customer legal teams review and either accept or negotiate. The most commonly negotiated terms are breach-notification timelines (often shortened from 60 days to 24-72 hours by customer demand), sub-processor obligations, and indemnification caps.

The risk analysis is the documentary basis for every Security Rule control choice. HHS guidance — the 2010 'Guidance on Risk Analysis Requirements under the HIPAA Security Rule' — and the NIST SP 800-66 Rev 2 'Implementing the HIPAA Security Rule' framework define what a defensible risk analysis looks like: scope all electronic PHI the entity creates, receives, maintains or transmits; identify and document potential threats and vulnerabilities; assess current security measures; determine the likelihood and impact of threat occurrence; assign risk levels; and document the result. The risk analysis must be reviewed and updated periodically — annually at minimum, and after every significant change to the technology, operations or environment.

The audit trail is the operational evidence that the Security Rule controls are operating. The technical audit-control standard at § 164.312(b) requires hardware, software and procedural mechanisms that record and examine activity in information systems that contain or use ePHI. In practice this means: every authentication and authorisation event attributable to a named human (no shared service accounts touching PHI), every PHI access logged with timestamp and user identity, every change to RBAC roles and policies captured, every encryption key access recorded, and every breach-relevant event (failed authentications, after-hours access, bulk exports) flagged to a SIEM with a documented review process. The audit trail must be retained for six years from the date of creation or last effective date under the document-retention standard at § 164.316(b)(2).

• Business Associate Agreement — required terms at 45 CFR § 164.504(e); standard template published by cloud providers; commonly negotiated terms are breach-notification timelines, sub-processor obligations, indemnification caps.
• Risk Analysis under § 164.308(a)(1)(ii)(A) — scope all ePHI, identify threats and vulnerabilities, assess current measures, determine likelihood and impact, assign risk levels, document; review annually and after significant change.
• Audit Trail under § 164.312(b) — every authentication/authorisation, every PHI access, every RBAC change, every encryption-key access, every breach-relevant event; retained for six years.
• Sanction Policy — workforce-member misconduct documented and consistently applied; an OCR-cited recurring gap is informal sanctions.
• Information System Activity Review — documented log-review process with frequency and responsible role; not just 'logs exist'.
• Workforce training records — completion timestamps per worker per module; the 'reasonable refresher' frequency is generally annual.
• Incident response plan — written, tested, with clear decision points for breach determination; tabletop exercises documented annually.
• Tested backup — restoration tested at least annually; restoration time recorded; backup encryption posture verified.
• Disaster recovery plan — documented alternate processing path; tested annually; restoration-time-objective recorded.
• Periodic evaluation under § 164.308(a)(8) — annual technical and non-technical evaluation; documented in a report retained for six years.

Audit and accountability — breach notification and the OCR investigation#

Breach Notification under 45 CFR Part 164, Subpart D, is the operational obligation most often triggered in practice. A breach is defined as the acquisition, access, use or disclosure of PHI in a manner not permitted by the Privacy Rule that compromises the security or privacy of the PHI. The Omnibus Rule introduced a four-factor risk assessment to determine whether a presumed-breach disclosure rises to the threshold of actual breach: the nature and extent of the PHI involved; the unauthorised person who used the PHI or to whom the disclosure was made; whether the PHI was actually acquired or viewed; and the extent to which the risk to the PHI has been mitigated. A 'low probability of compromise' demonstrable through the four-factor assessment exempts from notification.

Where a breach is determined, the covered entity must notify affected individuals without unreasonable delay and in no case later than 60 calendar days after discovery (§ 164.404). Breaches affecting 500 or more individuals must additionally be reported to HHS contemporaneously with individual notification, and to prominent media outlets serving the state or jurisdiction where 500+ individuals are affected (§ 164.406, § 164.408(b)). Breaches affecting fewer than 500 individuals must be reported to HHS annually within 60 days of the end of the calendar year. Business associates must report breaches to the covered entity without unreasonable delay (§ 164.410) — the BAA typically shortens this to 24-72 hours.

The encryption safe harbour is the single most consequential operational lever in the breach notification regime. Under the Breach Notification Rule, PHI that is rendered unusable, unreadable or indecipherable to unauthorised individuals through encryption (to NIST-specified standards, currently AES-256 at rest and TLS 1.2+ in transit) is not 'unsecured' PHI, and a breach of encrypted PHI generally does not trigger the notification obligations. This is the operative defence that makes encryption-by-default and HSM-managed keys the highest-leverage technical safeguard a cloud provider can ship.

OCR investigation typically begins with a complaint from a data subject, a Compliance Review triggered by a breach-portal submission, or a compliance audit. The investigation is documentary — OCR requests the risk analysis, the security policies and procedures, the workforce training records, the audit logs covering the period in question, the BAA register, and the incident response documentation. The investigation timeline is highly variable: simple cases close in months, complex multi-state cases take years. Resolution Agreements with Corrective Action Plans are the dominant settlement model — a covered entity or business associate agrees to remediate the cited gaps, accept a monitoring period (typically 2-3 years) and pay a civil monetary penalty.

• Breach determination — four-factor risk assessment under Omnibus Rule; low-probability-of-compromise exempts; document the analysis regardless.
• Individual notification — without unreasonable delay, no later than 60 calendar days after discovery; written notice with prescribed content (§ 164.404(c)).
• HHS notification — contemporaneous for 500+ individual breaches; annual for sub-500 (60 days after year-end).
• Media notification — prominent media outlets in state/jurisdiction where 500+ individuals affected.
• Business associate to covered entity — without unreasonable delay; BAA commonly shortens to 24-72 hours.
• Encryption safe harbour — NIST-standard encryption at rest (AES-256) and in transit (TLS 1.2+) generally exempts from breach notification.
• OCR investigation triggers — complaint, breach portal submission, periodic compliance audit.
• Resolution Agreement / Corrective Action Plan — dominant settlement model; typically 2-3 year monitoring period.
• Civil monetary penalties — tiered by culpability (Unknowing, Reasonable Cause, Wilful Neglect-corrected, Wilful Neglect-uncorrected); USD 137 to USD 2,067,813 per violation in 2026 figures; cap of USD 2,067,813 per identical violation per calendar year.
• Criminal penalties — 42 USC § 1320d-6; knowing disclosure for personal gain or malicious harm up to USD 250,000 and 10 years' imprisonment.

Mapping to other frameworks#

HIPAA does not stand alone. Healthcare-vertical cloud providers and SaaS vendors typically hold a layered posture combining HIPAA with one or more adjacent frameworks. The mapping below is the working cross-reference most security architects use when reusing an existing evidence base for a HIPAA programme — or extending a HIPAA programme to satisfy a UK or EU customer's data-protection obligation.

• HITRUST CSF — the dominant industry shortcut for evidencing HIPAA Security Rule controls; HITRUST r2 certification covers HIPAA + state breach laws + NIST CSF in a single attestation; widely accepted by US health plans and academic medical centres.
• SOC 2 Type II — provides operating-effectiveness evidence for the technical safeguards over a 6-12 month window; commonly bundled with HITRUST in BAA negotiations.
• ISO 27001 + 27017 + 27018 — provides the management-system spine and cloud-specific overlays; reduces audit-prep effort substantially for a HIPAA programme.
• GDPR Article 32 — overlaps materially with HIPAA Security Rule § 164.308-312; a single ISO 27001 + 27018 + SOC 2 Type II evidence base typically discharges both frameworks' technical-control obligations.
• FedRAMP Moderate — required for federal healthcare workloads (VA, Indian Health Service, CMS); layered on top of HIPAA Security Rule.
• HITECH Act — amended HIPAA in 2009; introduced breach notification, increased penalties, extended business-associate liability; codified at 42 USC § 17921-17954.
• Omnibus Rule 2013 — made business associates directly liable to OCR; introduced four-factor breach assessment; codified at 45 CFR Parts 160 + 164.
• State breach laws — 50 US states have their own breach notification laws; many are stricter than HIPAA (shorter timelines, broader data definitions); state law often pre-empts HIPAA where stricter.

UK, EU and US considerations#

HIPAA is United States federal law and does not apply to UK or EU healthcare workloads on its own. UK and EU healthcare organisations are governed by their own data-protection regimes — UK GDPR + Data Protection Act 2018 + the NHS Data Security and Protection Toolkit (DSPT) + the NHS Digital Technology Assessment Criteria (DTAC) in the UK; EU GDPR + national health-data laws (Bundesdatenschutzgesetz in Germany, Code de la santé publique in France, the Italian Codice della privacy etc.) in the EU. Yobitel's UK and EU healthcare workloads run under those regimes, not HIPAA.

Where the jurisdictions cross — a UK-headquartered cloud provider serving a US healthcare customer, or a US healthcare research collaboration involving EU clinical data — the layered posture is to hold HIPAA for the US obligation, UK GDPR + DPSI for the UK obligation, and GDPR Article 32 for the EU obligation. The same ISO 27001 + 27017 + 27018 + SOC 2 Type II evidence base typically discharges the technical-control obligations of all three; the differences are the contractual artefacts (BAA for HIPAA, Data Processing Agreement under Article 28 for GDPR, NHS DSPT submission for UK NHS) and the regulator (OCR for HIPAA, ICO for UK GDPR, each member-state SA for EU GDPR). Yobitel maintains the HIPAA programme alongside the UK and EU programmes precisely so customers do not have to choose between them.

For the United Kingdom NHS workloads specifically, the operative framework is the NHS Data Security and Protection Toolkit aligned to the National Data Guardian's Data Security Standards. The technical controls overlap substantially with HIPAA — encryption at rest and in transit, MFA on privileged access, audit logging, breach notification — but the procurement bar is set by the NHS DTAC clinical safety, data protection and technical security standards. Yobitel MediQuery in the UK ships with NHS DSPT alignment and is positioned for DTAC submission; the equivalent US-bound MediQuery deployment carries the HIPAA BAA.

For the European Union, GDPR Article 32 is the operative security clause. The technical controls expected — encryption, access control, audit, resilience, regular testing — overlap with HIPAA Security Rule § 164.308-312 almost line for line. The differences are the additional obligations under GDPR (Article 30 record of processing activities, Article 35 DPIA for high-risk processing, Article 33 72-hour breach notification to the supervisory authority, joint-controller agreement under Article 26) and the cross-border transfer regime under Chapter V if PHI flows from the EU to the US. Yobitel's EU clinical workloads — Sovereign EU regions in Frankfurt and Paris — discharge the GDPR Article 32 obligation; PHI flows from EU clinical research to US collaborators require Standard Contractual Clauses and a Schrems II transfer impact assessment.

• US — HIPAA is the operative federal framework; HITRUST CSF is the dominant industry shortcut; state breach laws often stricter and pre-empt HIPAA where so.
• UK — UK GDPR + DPA 2018 + NHS DSPT + NHS DTAC; ICO is the regulator; Yobitel MediQuery and Yobibyte clinical workspaces run under this stack in the UK.
• EU — GDPR Article 32 + national health-data laws; each member-state SA enforces; Yobitel Sovereign EU regions discharge the obligation.
• Cross-jurisdictional — layered posture with HIPAA + UK GDPR/DPA + EU GDPR Article 32; ISO 27001 + 27017 + 27018 + SOC 2 Type II evidence base discharges the technical-control obligations of all three; differences are contractual artefacts and regulator engagement.
• EU-to-US PHI flow — Standard Contractual Clauses + Schrems II transfer impact assessment; supplementary measures where the assessment identifies a risk.
• US federal healthcare — Veterans Affairs, Indian Health Service, CMS require FedRAMP Moderate or High in addition to HIPAA.
• Adequacy as of June 2026 — UK and EEA mutually recognised; EU-US Data Privacy Framework in force but under live legal challenge.

Common implementation gaps#

HIPAA enforcement actions cluster around a remarkably consistent set of operational failures. The gaps below are the failure modes OCR has actually fined on over the last decade — the patterns named in published Resolution Agreements and Corrective Action Plans. None is novel. Each is closable through deliberate planning; each is dramatically more expensive to defend in an OCR investigation than to remediate in advance.

The single largest fine pattern in OCR enforcement is the missing or inadequate risk analysis under § 164.308(a)(1)(ii)(A). Published Resolution Agreements have cited entities for: not performing a risk analysis at all; performing one limited to a subset of ePHI; not updating the risk analysis after a major architecture change; or producing a checklist-style document that does not satisfy the NIST SP 800-66 Rev 2 substance. The fix is a documented, scoped, periodically-reviewed risk analysis that covers every system creating, receiving, maintaining or transmitting ePHI. This is the artefact OCR requests on day one of every investigation; absence is a near-certain Wilful Neglect finding.

Missing or stale BAAs are the second-most-common pattern. OCR Resolution Agreements have cited entities for: PHI flowing to a vendor before the BAA was signed; BAA not updated after the Omnibus Rule; sub-business-associate relationships without back-to-back BAAs; cloud providers used without recognising the cloud provider as a business associate. The fix is a BAA register with vendor, BAA date, expiry, sub-business-associate inventory and the scope of PHI accessed; gate procurement on BAA execution.

Encryption gaps — particularly on backups, mobile devices and removable media — are the third recurring pattern. The encryption-and-decryption implementation specification at § 164.312(a)(2)(iv) is Addressable, but the encryption safe harbour in the Breach Notification Rule makes encryption the operative defence against notification exposure. Unencrypted backups stolen from offsite storage facilities and unencrypted laptops lost in cars are among the most frequently cited breach causes in HHS public breach reports.

Workforce training gaps and informal sanctions sit close behind. OCR has cited entities for inconsistent application of sanction policies, for failure to document training completion, and for failure to train new starters within a reasonable window. The fix is an LMS-tracked training programme with mandatory completion gating access to PHI systems.

Audit-log gaps — under § 164.312(b) — round out the list. The standard does not specify what to log, but Information System Activity Review under § 164.308(a)(1)(ii)(D) does require a documented review process. The fix is a SIEM-driven log-review programme with documented frequency, responsible role, and exception-handling workflow; retain logs for six years under § 164.316(b)(2).

On the breach-notification side, the recurring gap is missed 60-day notification, often caused by late discovery rather than late notification — the 60-day clock starts when the entity knows or should have known. Continuous monitoring tooling that catches PHI exposure within hours, not weeks, is the operative defence.

• Missing or inadequate risk analysis under § 164.308(a)(1)(ii)(A) — single largest fine pattern; documented, scoped, periodically reviewed; covers every ePHI system; aligned to NIST SP 800-66 Rev 2.
• Missing or stale BAAs — PHI to vendor before BAA execution; sub-business-associate without back-to-back BAA; gate procurement on BAA register status.
• Encryption gaps on backups, mobile devices, removable media — § 164.312(a)(2)(iv) Addressable but Breach Notification safe harbour makes encryption operative defence; AES-256 at rest + TLS 1.2+ in transit + HSM-managed keys.
• Workforce training gaps and informal sanctions — LMS-tracked training, mandatory completion gating PHI access, documented sanctions consistently applied.
• Audit-log review gaps under § 164.308(a)(1)(ii)(D) — SIEM-driven log-review programme with documented frequency, responsible role, exception-handling workflow; retain six years.
• Missed 60-day breach notification — late discovery rather than late notification; continuous monitoring tooling catching PHI exposure within hours not weeks.
• Sub-business-associate inventory drift — sub-BAA register out of date; gate procurement on register update.
• Termination procedure gaps — workforce member's access not revoked at termination; SCIM-driven deprovisioning gating the BAA.
• Periodic evaluation skipped — § 164.308(a)(8) annual technical and non-technical evaluation; documented report retained six years.
• Wrong jurisdiction for non-US workloads — applying HIPAA to UK NHS or EU clinical data when UK GDPR/DPSI or EU GDPR is the actual operative framework.

Cost of compliance#

HIPAA compliance is materially cheaper than FedRAMP authorisation but more expensive than informal security hygiene. The cost is dominated by the engineering effort to implement the Security Rule safeguards (front-loaded), the ongoing programme overhead (annual evaluation, training, BAA management, audit-log review), and — where pursued — HITRUST CSF certification fees. The figures below are typical US market ranges for a mid-sized cloud-native SaaS or platform serving healthcare customers. They are not Yobitel-internal numbers; they are presented so customers and partners building MediQuery deployments or Yobibyte clinical workspaces can budget realistically.

Initial HIPAA readiness — risk analysis, policies and procedures, technical control implementation, BAA template development, workforce training programme stand-up, incident response plan — typically falls in the USD 75,000 to USD 250,000 range for an organisation with mature general security posture. Annual ongoing programme cost typically falls in the USD 30,000 to USD 100,000 range plus the engineering capacity to operate the technical controls. HITRUST r2 certification — increasingly demanded by US health plans and academic medical centres — adds USD 60,000 to USD 250,000 over a two-year initial cycle plus interim reviews. SOC 2 Type II covering Security + Availability + Confidentiality TSC categories is commonly bundled and costs USD 44,000 to USD 112,000 annually.

Where this fits in the Yobitel stack#

Yobitel's healthcare-vertical posture is built around HIPAA from the start. MediQuery — the Yobitel clinical AI application for medical-knowledge query, clinical decision support and physician workflow — ships with a BAA-ready stack for US healthcare customers: encryption-by-default for PHI at rest using AES-256 with customer-managed keys via the relevant cloud's KMS service, TLS 1.3 in transit with mTLS service-to-service, RBAC tied to OIDC identity federation, audit logs in the standard `audit.k8s.io/v1` schema streamed to a customer-controlled SIEM, and 60-day breach notification commitments anchored in the published BAA. The MediQuery air-gapped on-premises deployment mode for regulated healthcare carries the same posture inside the customer's own datacentre boundary.

Yobibyte clinical-app workspaces — workspaces dedicated to clinical-vertical AI workloads — inherit the same HIPAA-ready posture as the platform default. The workspace's namespace labels declare the HIPAA classification, the customer-managed KMS key reference, the BAA reference and the sub-processor footprint; the audit stream is configured to a customer-chosen sink on workspace creation; the breach-notification workflow is wired into the Yobitel managed-service operations team's incident response with the BAA-defined notification timeline. Customers building on Yobibyte for US healthcare workloads absorb Yobitel's technical safeguards as a baseline rather than building the encryption, audit, RBAC and breach-notification stack from primitives.

InferenceBench — the Yobitel public benchmarking and evaluation platform — does not directly touch PHI in its open-data form but contributes to the Periodic Evaluation obligation under § 164.308(a)(8) for clinical AI models. A clinical AI deployment can cite InferenceBench evaluation runs as evidence of model-quality baselines in the annual evaluation report, providing reproducible, timestamped benchmark evidence that a customer's compliance team can fold into the HIPAA evidence pack without commissioning a separate evaluation programme.

The honest scope of inheritance. Yobitel as the business associate carries the technical safeguard obligation for the platform layer: encryption at rest and in transit, audit logging, MFA on privileged paths, RBAC, sub-processor management, breach detection and notification within the BAA-defined timeline. The customer organisation as the covered entity carries the administrative-safeguard obligations: the risk analysis covering the use of MediQuery or Yobibyte, the workforce training programme, the sanction policy, the incident response process for the application-level workflow, the periodic evaluation. Yobitel provides the BAA, the sub-processor register and the technical-control evidence; the customer brings the application-level controls and the relationship with OCR. NeoCloud-style GPU capacity for healthcare-AI workloads is sourced from HIPAA-aligned partner-cloud regions where the underlying IaaS authorisation carries the physical safeguard obligations, leaving Yobitel to focus on the technical and administrative layers.