On 25 August 2026, Laravel announced that its Private Cloud offering could now host HIPAA-regulated workloads, including dedicated infrastructure and the possibility of entering into a Business Associate Agreement. The announcement is relevant to healthcare software publishers targeting the US market. Above all, it recalls a rule that is often forgotten: a compliant hosting provider supplies a foundation, but product compliance still depends on the application, its subprocessors, its procedures and how the data is actually used.
Key takeaway: never turn a provider’s badge into an overall conclusion. For a healthcare project, the applicable legal framework must be qualified, the appropriate contracts signed, all flows mapped, a risk analysis performed and application controls demonstrated. HIPAA replaces neither the GDPR nor, where it applies in France, HDS certification.
1. What Laravel announced on 25 August 2026
Laravel states that the announced scope concerns its Private Cloud offering, not the shared Starter or Growth offerings. The publisher describes an AWS account, a VPC, a Kubernetes cluster and dedicated compute nodes, without sharing infrastructure with another customer within this scope.
The post also presents several controls: encryption at rest and in transit, SSO and SAML for console access, encrypted backups, business continuity, edge protection and an audit log. These elements are communicated by Laravel; before making a commitment, they must be compared with the reports available in the Trust Center, the contract, the exact service scope and the architecture proposed to the customer.
To process Protected Health Information in the United States, Laravel requires customers to request a Business Associate Agreement, or BAA, before deployment. The US Department of Health and Human Services explains that a cloud provider that creates, receives, maintains or transmits electronic protected health information for a covered entity or another business associate is itself a business associate. This remains true even when it stores only encrypted data without possessing the key.
The announcement therefore simplifies an important part of the project: having an infrastructure offering and contractual framework designed for HIPAA. It does not transfer responsibility for the entire system to Laravel.
2. Why “hosted on a HIPAA foundation” does not mean “compliant application”
HIPAA covers several categories of obligations relating to the privacy, security and breach notification of health information. Hosting is part of this chain, but an application may remain non-compliant on infrastructure that has been properly audited.
A few examples are enough. A controller exposes a patient record to another account. A CSV export remains accessible without an expiry. An error log contains medical data. A queue job is sent to a third-party service not covered by the contract. An administrator shares an account. An encryption key is kept in the same environment as the data. None of these problems is fixed by cluster isolation.
HHS states that covered entities and their business associates must conduct their own risk analysis covering the confidentiality, integrity and availability of electronic health information. The type of cloud influences this analysis, but does not replace it. The service-level agreement must also remain consistent with the BAA, particularly regarding availability, backup, data return, security responsibilities and use or retention limits.
The relevant model is shared responsibility. The provider protects certain physical and cloud components. The platform operates the orchestration and services included in its scope. The product team designs authentication, authorization, use cases, APIs, logs and procedures. The customer organization remains responsible for purpose, access and governance.
3. The BAA and the subprocessor chain
The BAA is not merely a commercial form. It describes permitted uses and disclosures, expected safeguards, incident management, obligations at the end of the service and relationships with subprocessors. It must match the architecture actually being used.
A common mistake is to sign a BAA with the main hosting provider while overlooking other services that receive or retain protected information. HHS explicitly lists cloud providers, application developers, maintenance providers, support services and certain AI tools as business associates when they handle PHI on behalf of a covered entity.
Map the complete chain: cloud platform, managed database, object storage, external backup, observability, email or SMS delivery, search engine, document service, support, analytics and AI provider. For each one, document the data, purpose, region, retention period, human access, encryption, contract and any downstream subprocessors.
This mapping extends a method already detailed in our guide GDPR and generative AI: map data before connecting a model to the company: start from the processing activities and actual copies, then link each flow to an owner, a purpose and evidence. The principle remains valid even when the healthcare project uses no model.
The minimization principle also reduces the contractual scope. A metrics platform probably does not need the patient’s name or clinical content. A pseudonymized technical identifier may be enough. Data useful to support teams can be masked by default and revealed only through a logged procedure.
Finally, verify the exit process. The contract and architecture must allow data to be returned, deleted or made inaccessible at the end of the service, with clear rules for backups and logs.
4. The controls that remain in Laravel code
In Laravel, authorization must be explicit and close to the domain. Policies and gates check access to every record, document, message and action. A broad role such as admin is not enough if some professionals should see only one facility, specialty or time period.
Queries must be constrained by tenant and active identity. This also applies to jobs, Artisan commands, exports and administration tools. An asynchronous process must never rebuild an access context from a customer identifier supplied without validation.
Collection is limited to what is necessary. Forms distinguish required, optional and sensitive data. Attachments are checked, scanned and stored outside the public directory. Signed URLs expire and are not placed in logs or tracking tools with overly broad access.
Encryption should not be reduced to the provider’s disk encryption. Some values may require application-level encryption or tokenization, with separate key management and tested rotation. The choice depends on the threat model, search requirements and responsibilities. HHS recalls that encryption alone guarantees neither integrity nor availability: backup, recovery and administrative controls remain necessary.
Business audit logs are distinct from technical logs. They record who viewed, created, modified, exported or transmitted information, on which object and when. They must resist modification by the current application and avoid copying the complete medical content.
Authentication requires individual accounts, lifecycle management, a second factor appropriate to the risk and sessions that can be revoked quickly. Emergency or support access uses a dedicated, time-limited procedure reviewed afterwards.
5. Mapping the invisible flows around the application
The main database is often not the main blind spot. Data spreads through queues, caches, traces, exports, backups and workstations.
Start with a flow diagram. For each journey — patient creation, appointment, document, messaging, billing and support — identify the systems crossed and the copies created. Add development, test and analysis environments. Real data must not be copied into these environments without necessity, protection and a legal basis.
Inspect the logs. Laravel exceptions may include query parameters, payloads or serialized objects. Configure masked fields, filter sensitive data and control access to observability platforms. Distributed traces should retain correlation without replicating business content.
Check notifications. The body of an email or SMS, its subject and its recipient may reveal health information. Prefer a neutral message that points to an authenticated area when detailed content is not necessary.
Exports deserve special treatment: justification, scope, encryption, expiry, possible one-time download and traceability. A file that is generated correctly but stored indefinitely on secondary storage becomes a new, ungoverned database.
Finally, check the CI/CD pipeline and support process. Database dumps, screenshots and debug artefacts must not enter Git, tickets or support conversations without a secure procedure.
6. Organizing risk, audit and incident response
Risk analysis must connect data, threats, controls and residual risk. It is not a generic document supplied by the hosting provider. It covers the application, its users, integrations and procedures.
Build concrete scenarios: a compromised professional account, a tenant error, an export sent to the wrong recipient, an unavailable backup, an exposed log, a failing subprocessor or a lost key. For each one, check prevention, detection, containment, recovery and notification.
Continuity must be tested. An encrypted backup does not guarantee that it can be restored within the business deadline. Measure the RPO and RTO, repeat restoration and document external dependencies. Plan for continuity when authentication, the network or the cloud platform is unavailable.
Incident response defines responsibilities between the customer, development team, Laravel and other providers. Contractual notification deadlines must allow the organization to meet its own obligations. Logs, timestamps and escalation contacts are prepared before the incident.
Also conduct periodic reviews: accounts and rights, vulnerabilities, dependencies, backups, subprocessors, security exceptions and control evidence. Compliance is an ongoing operation, not a state reached on audit day.
7. Distinguishing HIPAA, GDPR and HDS
HIPAA is a US framework applying to entities and information defined by US law. An offering compatible with HIPAA is not automatically GDPR-compliant and is not an HDS certification.
In Europe, health data is a special category of personal data under Article 9 of the GDPR. The organization must establish a legal basis under Article 6 and a condition permitting the processing of this sensitive data. The CNIL also recalls the accountability principle: the controller and its processors must be able to demonstrate compliance, keep the record of processing activities and conduct an impact assessment when the risk requires it.
In France, some health-data hosting activities fall under the HDS scheme. The Agence du Numérique en Santé distinguishes, in particular, a physical infrastructure scope and a managed-hosting-provider scope covering virtual infrastructure, the platform, administration and backup. Applicability and scope must be legally and technically qualified for each project.
Consequently, a French company targeting the US market may have to address HIPAA, GDPR, international transfers and possibly HDS at the same time, depending on its activities and architecture. The cluster location is only one element. Support access, subprocessors, transfer safeguards, contracts and data-subject rights must be examined.
Never present “HIPAA compliant” as a synonym for “health-compliant everywhere”. Build a matrix by country, role, data type, purpose and provider.
8. The pre-production checklist
Before go-live, require answers and evidence for the following points:
- Legal scope: entities, countries, data categories, roles and applicable laws have been qualified with the appropriate advisers.
- Contracts: the BAA is signed before any PHI is processed; subprocessor, transfer and SLA agreements match the actual flows.
- Hosting: the exact offering, regions, dedicated resources, audit reports and responsibilities are verified; any HDS requirements are covered by the correct certification scope.
- Data: data minimization, retention periods, deletion, return and backups are documented.
- Access: individual identities, MFA, Laravel policies, tenants, emergency support and access-right reviews are tested.
- Application: APIs, files, exports, queues, caches, logs and notifications have specific controls.
- Encryption: data at rest and in transit, key management, rotation and loss scenarios are addressed.
- Audit: sensitive business actions are traceable without unnecessarily copying the data.
- Continuity: restoration, RPO, RTO and degraded mode have been exercised.
- Incident: detection, containment, evidence, escalation and notifications are tested with every provider.
The outcome of this checklist is not a self-certification. It is a preparation file to be compared with the legal, contractual, security and business requirements of the project.
Conclusion
The evolution of Laravel Private Cloud provides an interesting option for Laravel teams processing health information within a HIPAA framework. It reduces the work required to establish a dedicated, contractually supported cloud foundation.
The hardest part nevertheless remains in the complete system: application permissions, minimization, subprocessors, logs, continuity, incident response and territorial compliance. HIPAA, GDPR and HDS cover different scopes and must be qualified separately. Partitech supports organizations with Laravel architecture, flow mapping, application security and preparation of the evidence needed for sustainable operation.
References
- Laravel — “Laravel Private Cloud is now HIPAA compliant”, 25 August 2026: https://laravel.com/blog/hipaa-compliant-hosting-laravel
- U.S. Department of Health and Human Services — “Guidance on HIPAA & Cloud Computing”: https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html
- U.S. Department of Health and Human Services — “Business Associates”: https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/index.html
- Agence du Numérique en Santé — “Certification des hébergeurs de données de santé”: https://esante.gouv.fr/labels-certifications/hds/certification-des-hebergeurs-de-donnees-de-sante
- CNIL — “What formalities apply to health-data processing?”: https://www.cnil.fr/fr/quelles-formalites-pour-les-traitements-de-donnees-de-sante