--- title: "¿Cumple Supabase con HIPAA? Lo que el BAA le deja a usted" description: "Supabase HIPAA: firma un BAA en el plan Team con el complemento HIPAA. Diez obligaciones son suyas, de PITR a los logs. Cuáles ve una auditoría gratis." url: "https://madsalt.tech/es/blog/is-supabase-hipaa-compliant/" author: "Denys Zaichenko" author_url: "https://madsalt.tech/es/about/" language: "es" published: 2026-11-03 --- # ¿Cumple Supabase con HIPAA? Lo que el BAA le deja a usted En resumen Sí, el Supabase alojado puede guardar datos de salud: firma un Business Associate Agreement (BAA) en el plan Team y superiores, una vez activado el complemento HIPAA. El Supabase autoalojado no está cubierto. El BAA no configura su proyecto. El modelo de responsabilidad compartida de Supabase enumera diez obligaciones que siguen siendo suyas, entre ellas point-in-time recovery, la exigencia de SSL, las restricciones de red y el registro de conexiones de Postgres. De esas diez, mi auditoría gratuita de Supabase marca 3 directamente, 2 solo en parte y no puede ver las otras 5. Soy Denys, ingeniero full-stack y de IA, y la mayoría de las apps que construyo o arreglo corren sobre Supabase. Cuando una app de salud o bienestar pregunta si puede usar Supabase, la respuesta honesta tiene dos partes: qué firma Supabase y qué tiene que activar usted. Este artículo las toma en ese orden, a partir de los propios documentos de Supabase, leídos el 29 de octubre de 2026. ## ¿Es Supabase compatible con HIPAA? La plataforma alojada, sí. La [guía de cumplimiento de HIPAA](https://supabase.com/docs/guides/security/hipaa-compliance) de Supabase dice que actúa como business associate para los clientes que manejan Protected Health Information (PHI), que ha firmado BAA con sus propios proveedores que pueden acceder a esos datos, como AWS, y que sus controles de HIPAA se auditan cada año en el mismo periodo de auditoría que SOC 2. Los proyectos HIPAA reciben además todos los controles SOC 2 que tiene el resto de la plataforma. La misma guía pone dos límites. El Supabase autoalojado no trae estos controles de serie, y el cumplimiento de HIPAA allí es un asunto entre usted y su auditor. Y el BAA cubre solo la parte de Supabase: la guía enumera sus responsabilidades como cumplir las reglas de Privacidad, Seguridad y Notificación de Brechas de HIPAA, firmar el BAA y configurar sus proyectos HIPAA como indica el Security Advisor. ## ¿Qué necesita antes de guardar PHI? Según la [página de proyectos HIPAA](https://supabase.com/docs/guides/platform/hipaa-projects) y el [modelo de responsabilidad compartida](https://supabase.com/docs/guides/deployment/shared-responsibility-model): 1. **Un plan Team o superior.** El BAA no está disponible por debajo. 2. **El complemento HIPAA y un BAA firmado.** Ambos se solicitan a Supabase; el complemento se activa en la organización. 3. **High Compliance en cada proyecto.** Con el complemento activo, un proyecto puede marcarse como High Compliance en General Project Settings. Desde entonces Supabase ejecuta comprobaciones adicionales sobre ese proyecto de forma continua, y un ajuste no conforme aparece como aviso en el Security Advisor. El Security Advisor avisa; no corrige. La guía de Supabase es directa al respecto: la responsabilidad de aplicar los controles recomendados recae en el cliente. ## ¿Qué ajustes necesita un proyecto HIPAA? Esta es la lista completa del modelo de responsabilidad compartida, con el lugar donde vive cada una y si la [auditoría de seguridad de Supabase](https://madsalt.tech/es/tools/supabase-security-check/) gratuita puede verla. La herramienta lee un proyecto a través de la Management API de Supabase después de que usted inicie sesión con Supabase, así que ve ajustes, no contratos. | Su obligación bajo el BAA | Dónde vive | Auditoría gratuita | | ------------------------------------------------ | -------------------------------------------------------------- | ----------------------------------------------------------- | | Firmar el BAA, plan Team o superior | Contrato con Supabase | No lo ve | | Marcar los proyectos como HIPAA, corregir avisos | General Project Settings, Security Advisor | En parte: muestra cada lint del Security Advisor que recibe | | MFA en cada cuenta de Supabase, obligatorio | Ajustes de la organización | No lo ve | | Point-in-time recovery (PITR) | Database → Backups, requiere un pequeño complemento de cómputo | En parte: pasa solo con copias diarias | | Exigir SSL | Database Settings → SSL Configuration | Lo marca: "SSL not enforced on database connections" | | Restricciones de red | Database Settings → Network Restrictions | Lo marca: "Database open to every IP address" | | Registro de conexiones de Postgres activado | `log_connections`, desactivado por defecto en proyectos nuevos | No lo ve | | Cifrado según la HIPAA Security Rule | Supabase cifra en reposo y en tránsito | No lo ve; el cifrado a nivel de aplicación es decisión suya | | Sin PHI en buckets públicos de Storage | Storage → ajustes del bucket | Marca cada bucket público; si contiene PHI lo decide usted | | Sin transferencia a una organización no HIPAA | Transferencia de proyecto | No lo ve | ![Las 10 obligaciones HIPAA de Supabase: qué ve una auditoría gratuita. Obligaciones del modelo de responsabilidad compartida de Supabase. Marcado por una regla: 3; Visto solo en parte: 2; No visible para la auditoría: 5.](https://madsalt.tech/charts/es/is-supabase-hipaa-compliant.svg) *Figura 1. Modelo de responsabilidad compartida de Supabase, leído el 29 de octubre de 2026, frente a las reglas de mi auditoría gratuita de Supabase.* ## ¿Qué se le escapa a la auditoría gratuita? Vale la pena detallar tres huecos, porque un resultado en verde puede parecer más de lo que es. **Las copias diarias no son PITR.** La regla de copias de la herramienta pasa cuando el proyecto tiene point-in-time recovery o al menos una copia. Un proyecto de pago con copias diarias y sin PITR la pasa. Los proyectos HIPAA necesitan PITR en concreto, así que revise Database → Backups usted mismo; PITR exige al menos el pequeño complemento de cómputo. Qué guarda cada plan, y una prueba de restauración, está en Copias de Supabase: qué guarda cada plan y una restauración. **Dos ajustes de MFA distintos.** El "No multi-factor method enabled" de la herramienta se refiere a los usuarios de su app: si Supabase Auth les ofrece un segundo factor. La obligación HIPAA se refiere a las personas que pueden abrir su panel de Supabase: MFA en cada cuenta de la organización, exigido como requisito. Conviene tener ambos, y se activan en sitios distintos. **Registro de conexiones.** Supabase deja `log_connections` desactivado en los proyectos nuevos, y los proyectos HIPAA deberían mantenerlo activado para el rastro de auditoría. La herramienta no tiene ninguna regla que lo lea. En el editor SQL, `show log_connections;` lo responde en una línea, y el Security Advisor avisa de ello en un proyecto High Compliance. La herramienta muestra cada lint que devuelve el Security Advisor, errores y avisos por igual. No la he ejecutado sobre un proyecto High Compliance, así que no puedo confirmar que los avisos de HIPAA lleguen en esa misma lista. Léalos en el panel de todos modos. ## Lo que los ajustes de HIPAA no cubren Ninguna de las diez obligaciones menciona Row Level Security. Un proyecto HIPAA con todos los ajustes anteriores en su sitio puede aun así servir una tabla de pacientes a cualquiera que tenga la clave pública, si esa tabla tiene RLS desactivado o una política que permite todas las filas. Esa es la parte que la herramienta sí lee por completo: grants, políticas, funciones que se saltan RLS y columnas de aspecto sensible legibles por visitantes anónimos. La diferencia entre las dos claves está en [Supabase anon key vs service role key](https://madsalt.tech/es/blog/supabase-anon-key-vs-service-role-key/), y cómo compruebo cada permiso contra la API está en [cómo probar Supabase RLS](https://madsalt.tech/es/blog/how-to-test-supabase-rls/). Lo mismo vale para todo lo que queda fuera de Supabase. El modelo de responsabilidad compartida pone en su lado los servicios de terceros: proveedores de SMTP y SMS, inicio de sesión con OAuth y cualquier API externa que llame una Edge Function o un trigger de la base de datos. Si alguno recibe PHI, forma parte de su cuadro HIPAA, no del de Supabase, así que compruebe si cada proveedor firma un BAA antes de que los datos le lleguen. ## ¿Cómo se comprueba su proyecto? 1. En el panel, confirme que la organización tiene el complemento HIPAA y que el proyecto está marcado como High Compliance; después abra el Security Advisor y trabaje cada aviso. 2. Abra Database → Backups y confirme que PITR está activo, no solo las copias diarias. 3. Ejecute `show log_connections;` en el editor SQL. Debe devolver `on`. 4. En los ajustes de la organización, confirme que cada miembro tiene MFA y que MFA es obligatorio. 5. Ejecute la [auditoría de seguridad de Supabase](https://madsalt.tech/es/tools/supabase-security-check/) gratuita para SSL, restricciones de red, buckets públicos y las reglas de acceso anteriores. Mi nota sobre buckets públicos explica cómo pasar los archivos a URL firmadas. Para la pregunta más amplia de qué garantiza la plataforma y qué no, vea [¿es seguro Supabase?](https://madsalt.tech/es/blog/is-supabase-secure/). Este artículo no es asesoramiento legal; su responsable de cumplimiento o su auditor decide qué exigen su BAA y su programa HIPAA. ¿Construye una app de salud sobre Supabase? Me gustaría revisar los ajustes de su proyecto y comparar notas. Sin pitch. [Escríbame](https://madsalt.tech/es/#contact)