< BACK Pilas de hosting que realmente firman un BAA HIPAA en 2026 -- ilustración de arte lineal

Stacks de Hosting que Realmente Firman un BAA de HIPAA en 2026

Una startup de salud me llamó a principios de 2023. Fundadores amables, presupuesto decente, brief claro: formularios de admisión de pacientes, programación de citas, tal vez un widget de telemedicina más adelante. "Estamos en WP Engine", me dijo el CTO. Le pregunté si WP Engine había firmado su BAA. Pausa larga. "¿Qué es un BAA?"

Ahí es donde vive el problema, no en el código, no en el stack de plugins, sino en el rastro de documentos que la mayoría de desarrolladores nunca leen y que la mayoría de hosts evitan silenciosamente.

Aquí está el punto: el cumplimiento de HIPAA no es una función que actives. Es un marco legal, y el Acuerdo de Asociado de Negocio es el contrato que convierte a tu proveedor de hosting en una parte formal de ese marco. Sin un BAA firmado, no importa si tu servidor ejecuta TLS 1.3 y has cifrado cada campo en la base de datos. Sigues expuesto. Tus clientes también.

Déjame recorrer lo que sé realmente sobre cuáles plataformas firmarán en 2026, y más importante aún, cuáles dicen las cosas correctas pero no firmarán nada.

---

Qué es realmente un BAA (y qué no es)

Un Business Associate Agreement es un contrato bajo la HIPAA Privacy Rule que vincula a un proveedor a obligaciones específicas alrededor de Protected Health Information (PHI). Cuando hosteas un sitio de healthcare, tu proveedor de hosting toca PHI, incluso si es solo a nivel de infraestructura. Eso los hace un Business Associate. Sin excepciones.

Lo que el BAA no hace es hacerte compliant automáticamente. Veo esto mal entendido constantemente. El BAA significa que el host acepta su parte de responsabilidad y se compromete a salvaguardas. Tu capa de aplicación, tus formularios, tus plugins de WordPress, tu logging, eso sigue siendo responsabilidad tuya.

Seahawk tuvo un proyecto en 2022 para un grupo de fisioterapia con sede en EE.UU. ejecutando un sitio WordPress. El cliente tenía un BAA con su proveedor de email (bien), su vendor de EHR (obviamente), pero nada con su host web. Su sitio estaba recopilando datos de síntomas vía Gravity Forms. Cada envío se estaba emailing a una cuenta de Gmail. Tres violaciones separadas en un flujo de trabajo. Lo desatamos en aproximadamente seis semanas.

---

Los Hosts Que Realmente Firmarán en 2026

AWS, GCP, y Azure, Las Opciones Serias

Si necesitas un BAA y necesitas certeza, los hyperscalers son tu respuesta. Los tres, Amazon Web Services, Google Cloud Platform, y Microsoft Azure, ofrecen BAAs y mantienen listas de servicios elegibles para HIPAA.

AWS es lo que busco más. El BAA cubre un rango sólido de servicios: EC2, RDS, S3, CloudFront, Lambda, y más. Críticamente, no todos los servicios de AWS son elegibles. DynamoDB está en la lista; no todos los servicios experimentales lo están. Tienes que revisar la página actual de servicios elegibles antes de que arquitectes cualquier cosa.

El BAA de GCP cubre BigQuery, Cloud SQL, Compute Engine, y Cloud Storage, entre otros. Azure tiene la adopción empresarial más amplia en healthcare específicamente, su BAA y documentación de compliance es madura, y si tu cliente ya está en el ecosistema Microsoft (como la mayoría de organizaciones de healthcare empresariales), Azure frecuentemente tiene sentido organizacional.

La trampa con los tres: no estás obteniendo WordPress administrado aquí. Estás obteniendo infraestructura. Alguien tiene que construir y mantener el stack, patching del SO, configuración de WAF, backups, encriptación en reposo y en tránsito. En Seahawk hemos usado AWS con una instancia EC2 endurecida ejecutando Nginx, PHP-FPM, y MySQL para clientes de healthcare. Funciona. También es mucho más overhead operacional que darle a alguien un login de WP Engine.

Kinsta, Situacionalmente Sí

Kinsta opera en GCP. Ofrecen firma de BAA para clientes en sus planes de nivel más alto (Business 1 y superiores, la última vez que verificué). Esto importa porque Kinsta es genuinamente excelente hosting WordPress administrado. Rápido. Confiable. Buenos entornos de staging.

Pero, y esto vale la pena enfatizar, la cobertura BAA de Kinsta es algo más estrecha que si contratas directamente con GCP. Dependes de los controles internos de Kinsta además de los de GCP. Para muchos proyectos WordPress de salud, está bien. Para cualquier cosa que toque datos muy sensibles en volumen, yo querría entender exactamente qué dice su documentación de seguridad antes de comprometerme.

Cloudways, No

Cloudways es popular en el mundo de las agencias. Buena relación precio-rendimiento. Lo hemos usado en docenas de proyectos no sensibles. Pero en mi última verificación, Cloudways no ofrece un BAA de HIPAA. Incluso se ejecutan en AWS y GCP debajo, lo cual es levemente irónico. La capa administrada introduce incertidumbre que no respaldarán contractualmente para propósitos de HIPAA.

Pantheon, No (para la mayoría de planes)

Pantheon es excelente para agencias de Drupal y WordPress. Cumplimiento de HIPAA no es su mercado. Han sido claros al respecto. No dejes que la marca empresarial te engañe.

WP Engine, No

Ya lo sé. Tienen documentación de cumplimiento. Hablan de seguridad. No firmarán un BAA de HIPAA. Sus términos de servicio explícitamente prohíben almacenar PHI en su plataforma. Esto los descalifica para cualquier caso de uso de salud verdadero. La startup que mencioné en la parte superior de este post? Este es exactamente el lugar donde estaban.

Liquid Web / Nexcess, Posible, con salvedades

Liquid Web ha ofrecido hosting administrado compatible con HIPAA con firma de BAA, típicamente en sus productos de servidor dedicado o VPS en lugar de planes compartidos. Vale la pena una conversación directa con su equipo de ventas. Su postura de cumplimiento ha mejorado. Pero querría el BAA en mano antes de construir nada.

---

Lo que tu stack de WordPress necesita más allá del BAA

El BAA es la base, no la construcción. Aquí está lo que realmente debe suceder en la capa de aplicación para un sitio de WordPress adyacente a HIPAA.

Formularios y recopilación de datos

  • Gravity Forms con la configuración adecuada puede usarse, pero Gravity Forms nativo almacena los envíos en la base de datos de WordPress por defecto. Para PHI, necesitas deshabilitar el almacenamiento en base de datos y enviar datos de forma segura a un destino compatible con HIPAA, o usar su complemento Encrypted Fields cuidadosamente.
  • Cognito Forms y FormAssembly ofrecen niveles compatibles con HIPAA con BAAs. Si el formulario es el punto principal de recopilación de datos, estos suelen ser más limpios que lidiar con GF.
  • Nunca, jamás uses complementos de formulario de contacto gratuitos que envíen datos a servidores de terceros sin verificar su postura de cumplimiento.

Email

Este punto mata gente. Tu sitio WordPress probablemente envía correo a través de wp_mail(), que por defecto usa PHP mail o un plugin SMTP conectado. Gmail estándar, Mailchimp estándar, SendGrid estándar, ninguno de esos firma un BAA HIPAA en los niveles de entrada.

Paubox es el que recomiendo constantemente para clientes de salud pequeños y medianos. Correo compatible con HIPAA, BAA incluido, precios directos. Google Workspace también ofrece un BAA para sus clientes de salud, pero requiere un plan específico y un proceso de solicitud formal, no aplica a una cuenta estándar de Google.

Plugins e Integraciones de Terceros

Todo plugin que se comunica hacia afuera, todo script de analítica, todo widget de chat en vivo, todo potencialmente toca PHI dependiendo de qué datos haya en la página. Ejecuta una auditoría adecuada. Yo uso Query Monitor para identificar qué está haciendo solicitudes externas, luego hago referencias cruzadas contra la documentación de cumplimiento de cada proveedor.

HubSpot firmará un BAA. Intercom no lo hará (en los planes estándar). Hotjar casi con certeza no debería estar ejecutándose en un sitio de salud sin un ejercicio de alcance muy cuidadoso.

---

Cómo Obtener Realmente un BAA Firmado

Esto es más procedural que técnico, pero he visto proyectos estancarse aquí.

  1. Identifica cada proveedor que toca o podría tocar PHI: host, CDN, correo, formularios, analíticas, chat de soporte, proveedor de respaldo.
  2. Solicita documentación de BAA del equipo de ventas o cumplimiento de cada proveedor. No asumas. Obtén todo por escrito.
  3. Revisa el alcance; un BAA que solo cubre ciertos servicios o ciertos tipos de datos necesita ser entendido antes de que firmes.
  4. Almacena los acuerdos firmados en algún lugar donde el equipo legal de tu cliente pueda acceder. No solo en tu bandeja de entrada.
  5. Revisa anualmente, los proveedores cambian sus políticas, los servicios se deprecan, y un BAA que cubría tu stack en 2024 podría tener brechas en 2026.

La orientación de HHS sobre Asociados Comerciales es en realidad legible. Vale treinta minutos de tu tiempo si eres nuevo en esto.

---

El Problema del CDN que Nadie Menciona

Ya solucionaste tu host. Tienes un BAA. Aseguraste la capa de aplicación. Luego pones Cloudflare enfrente.

Cloudflare firmará un BAA, pero solo en su plan Enterprise, que comienza en un precio que lo hace inaccesible para la mayoría de clientes pequeños de salud. ¿Los niveles gratuito y Pro? Sin BAA. Esto significa que Cloudflare técnicamente está descifrando e inspeccionando tu tráfico HTTPS sin un BAA en lugar, en un sitio que podría tener PHI en tránsito.

Para proyectos más pequeños, he evitado esto usando AWS CloudFront (elegible para BAA) como capa CDN cuando el sitio ya está en EC2 o detrás de un Application Load Balancer. Es menos glamoroso que un panel de Cloudflare pero está limpio desde el punto de vista del cumplimiento.

---

Lo que realmente construiría en 2026

Si un cliente de salud viniera a mí mañana con un requisito de WordPress, así es como lo arquitecturaría más o menos:

  • Hosting: AWS EC2 (con un BAA firmado) ejecutando un stack LEMP endurecido, o Kinsta Business con su BAA en mano
  • Email: Paubox para email transaccional y dirigido a proveedores
  • Formularios: FormAssembly o Gravity Forms con almacenamiento de base de datos deshabilitado y enrutamiento de envío cifrado
  • CDN: AWS CloudFront, no Cloudflare free/Pro
  • Analytics: Matomo autohospedado en la misma infraestructura cubierta por BAA, nada de Google Analytics para cualquier cosa que tenga posibilidad de PHI en la URL o parámetros
  • Copias de seguridad: AWS S3 (elegible para BAA) con cifrado del lado del servidor

¿Es más caro que una construcción estándar de WordPress? Sí. ¿Es más complejo operativamente? También. Pero la alternativa es un cliente enfrentando un proceso de notificación de violación HIPAA, multas potenciales comenzando en $100 por violación por día, y una conversación muy incómoda sobre por qué su desarrollador nunca mencionó nada de esto.

---

FAQ

No. Es una frase de marketing. Lo que tiene significado legal es un BAA firmado. Cualquier proveedor puede llamarse a sí mismo compatible con HIPAA, amigable con HIPAA, o algo relacionado con HIPAA. Sin un BAA, esas palabras son meramente decorativas. Siempre pregunta específicamente: "¿Firmarán un Acuerdo de Asociado de Negocio con nosotros?"

¿Mi sitio realmente necesita un BAA si solo tiene un formulario de contacto?

Si el formulario de contacto recopila información que podría constituir PHI, síntomas, diagnósticos, razones de citas, cualquier cosa vinculada a la identidad y estado de salud de un paciente, entonces sí, cada proveedor en esa cadena de datos debería tener un BAA. Un formulario genérico de "agendar una cita" que recopila solo nombre, teléfono y hora preferida es territorio más gris, pero aun así yo optaría por obtener el BAA.

¿Puedo usar WordPress.com para un sitio de cuidado de la salud?

WordPress.com (la plataforma alojada, no el software WordPress auto-alojado) no ofrece un BAA de HIPAA. Punto. Esto es diferente de WordPress auto-alojado ejecutándose en una infraestructura compatible. El software está bien. La plataforma alojada no es apropiada para PHI.

¿Qué pasa si un proveedor que estoy usando es adquirido y el nuevo propietario elimina el BAA?

Este es un riesgo real y lo he visto suceder con herramientas SaaS más pequeñas. Tu BAA debería tener cláusulas de terminación que se activen si el proveedor ya no puede cumplir las obligaciones de HIPAA. Cuando recibas un correo de anuncio de adquisición, no lo descartes, verifica si los compromisos de cumplimiento se mantienen bajo la nueva entidad.

¿Es HIPAA solo una preocupación de Estados Unidos?

Sí, HIPAA es una ley federal estadounidense. Pero si estás construyendo para clientes de salud del Reino Unido o la UE, los equivalentes, estándares de NHS Digital, el Data Security and Protection Toolkit y GDPR aplicado a datos de salud, tienen requisitos similares alrededor de acuerdos de procesador de datos. El marco difiere, la lógica no.

---

La mayoría de los desarrolladores, si somos honestos, no piensan en la BAA hasta que alguien pregunta. Para entonces o todo está bien (tuviste suerte) o estás adaptando una pila bajo presión con un cliente nervioso al teléfono.

Es mejor conocer el panorama antes de empezar el proyecto que darte cuenta a mitad de una construcción que tu proveedor no firmará el único documento que realmente importa.

Lectura relacionada: Seguridad headless vs WordPress en 2026: por qué Next.js y Astro, Next.js, y headless.

< BACK