Si estás construyendo software que toca datos de salud en cualquier forma — una plataforma de telemedicina, un portal de pacientes, una SaaS de seguimiento de salud, o incluso un sitio web de marketing para un proveedor de cuidado de salud — el cumplimiento HIPAA no es opcional. Y en 2026, las reglas se volvieron más estrictas.

La Regla de Seguridad Final de HIPAA 2026 eliminó el espacio que muchos equipos aprovechaban. MFA ahora es requerida, no direccionable. El cifrado en reposo y en tránsito ahora es requerido, no direccionable. Si tu postura de cumplimiento fue construida en excepciones documentadas para cualquiera de esas, esa postura está muerta.

He pasado años construyendo aplicaciones web compatibles con HIPAA, y el error más grande que veo que cometen los equipos es tratar el cumplimiento como un ejercicio de papeleo. No lo es. Es un problema de ingeniería con consecuencias legales. Esta lista de verificación está escrita desde esa perspectiva — menos jerga legal, más orientación práctica de implementación para desarrolladores, CTOs y líderes de producto que necesitan lanzar software compatible.

Tabla de Contenidos

Lista de Verificación de Cumplimiento HIPAA 2026: Sitios Web, SaaS y Software

Entendiendo las Tres Reglas Principales de HIPAA

HIPAA organiza las obligaciones de cumplimiento en reglas distintas. Tres de ellas importan más para equipos de software y web:

La Regla de Privacidad

La Regla de Privacidad rige cómo la Información de Salud Protegida (PHI) puede ser usada y divulgada. PHI es cualquier información relacionada con la salud vinculada a un individuo identificable — registros médicos, resultados de laboratorio, detalles de seguros, fechas de citas, incluso direcciones IP si se recopilan junto con datos de salud.

Requisitos clave:

  • Debe publicarse un Aviso de Prácticas de Privacidad y ser accesible
  • Se aplica el estándar de "lo mínimo necesario": solo accede y comparte el PHI que realmente necesitas
  • Los pacientes tienen derechos para acceder, enmendar y solicitar un registro de divulgaciones de su PHI
  • Se requieren autorizaciones para usos más allá de tratamiento, pago y operaciones de cuidado de salud

La Regla de Seguridad

La Regla de Seguridad protege específicamente PHI electrónico (ePHI). Requiere tres categorías de salvaguardas: administrativa, física y técnica. Para aplicaciones SaaS y web, las salvaguardas técnicas son donde va la mayoría del esfuerzo de ingeniería — controles de acceso, registro de auditoría, cifrado, controles de integridad y seguridad de transmisión.

La Regla de Seguridad se asigna a 45 CFR Parte 164, y cada salvaguarda tiene una sección específica: controles de acceso (164.312(a)), controles de auditoría (164.312(b)), controles de integridad (164.312(c)), autenticación (164.312(d)) y seguridad de transmisión (164.312(e)).

La Regla de Notificación de Brechas

Cuando se expone PHI no asegurado, debes notificar a los individuos afectados, HHS y a veces a los medios. El reloj comienza a correr en el momento en que descubres la brecha — no cuando terminas de investigarla. Más sobre los plazos específicos a continuación.

También hay una Regla de Cumplimiento que rige cómo OCR investiga y penaliza violaciones, pero las tres reglas anteriores son donde vive tu programa de cumplimiento.

Quién Necesita Cumplir: Entidades Cubiertas vs. Asociados Comerciales

Aquí es donde muchos equipos SaaS se confunden. No necesitas ser un hospital para caer bajo HIPAA.

Entidades Cubiertas son planes de salud, cámaras de compensación de cuidado de salud y proveedores de cuidado de salud que transmiten información de salud electrónicamente.

Asociados Comerciales son proveedores que crean, reciben, mantienen o transmiten PHI en nombre de una entidad cubierta. Si tu producto SaaS procesa datos de salud para un cliente de cuidado de salud, eres un asociado comercial. Punto.

Desde la Regla Omnibus de HIPAA, los asociados comerciales tienen obligaciones de cumplimiento directas. No puedes esconderte en el programa de cumplimiento de tu cliente. Necesitas el tuyo propio.

Esto significa:

  • Debes firmar un Acuerdo de Asociado Comercial (BAA) con cada entidad cubierta a la que sirvas
  • Debes firmar BAAs con tus propios sub-procesadores (AWS, GCP, tu proveedor de base de datos, tu servicio de correo electrónico)
  • Debes implementar las salvaguardas de la Regla de Seguridad independientemente
  • Estás sujeto a cumplimiento de OCR directamente

La Regla de Seguridad Final de HIPAA 2026: Qué Cambió

La Regla de Seguridad original (2003) dividía las especificaciones de implementación en "requeridas" y "direccionables". Requerida significaba que tenías que hacerlo. Direccionable significaba que tenías que implementarla, documentar por qué se usaba una medida equivalente o documentar por qué no era razonable. En la práctica, muchas organizaciones trataban "direccionable" como "opcional".

La Regla Final de 2026 elimina esa ambigüedad en dos áreas críticas:

Control Estado Anterior Estado 2026 Impacto
Autenticación Multifactor Direccionable Requerida Todos los sistemas que acceden ePHI deben hacer cumplir MFA. Sin excepciones.
Cifrado en Reposo Direccionable Requerida Todo el almacenamiento de ePHI debe estar cifrado. Los controles compensatorios ya no se aceptan.
Cifrado en Tránsito Direccionable Requerida Toda la transmisión de ePHI debe estar cifrada. Mínimo TLS 1.2.
Análisis de Riesgo Requerida Requerida (expandida) Debe ser continua, no anual. Se espera monitoreo automatizado.
Registro de Auditoría Requerida Requerida (expandida) Los registros deben ser inmutables y retenidos según la política documentada.

Si has estado confiando en excepciones documentadas para MFA o cifrado, necesitas remediar inmediatamente. Esa postura ya no es defendible bajo la regla actualizada.

Lista de Verificación de Cumplimiento HIPAA 2026: Sitios Web, SaaS y Software - arquitectura

Lista de Verificación de la Regla de Privacidad para Sitios Web y SaaS

Aquí es donde los sitios web específicamente se pierden. Tu sitio de marketing para un producto de cuidado de salud tiene obligaciones de Regla de Privacidad que la mayoría de equipos web no consideran.

  • Publica un Aviso de Prácticas de Privacidad (NPP) — Debe ser prominentemente accesible en tu sitio web. No enterrado en un laberinto de enlaces de pie de página.
  • Implementa el estándar de lo mínimo necesario — Tus formularios deben recopilar solo el PHI que realmente necesitas. ¿Ese formulario de entrada de 15 campos? Audita cada campo.
  • Honra las solicitudes de acceso del paciente — Si tu software almacena PHI, debes proporcionar a los pacientes una forma de acceder a sus registros dentro de 30 días.
  • Implementa flujos de autorización — Cualquier uso de PHI más allá de tratamiento/pago/operaciones requiere autorización explícita del paciente.
  • Rastreo de divulgaciones — Mantén un registro de cada divulgación de PHI durante al menos seis años.
  • Entrena tu fuerza laboral — Todos los que tocan PHI necesitan entrenamiento de Regla de Privacidad. Documéntalo.
  • Designa un Oficial de Privacidad — Alguien tiene que ser dueño de esto. Puede ser un rol compartido, pero debe estar documentado.
  • Revisa el rastreo de terceros — Este es el grande para sitios web. Google Analytics, Meta Pixel, rastreo de HubSpot — si estas herramientas pueden capturar PHI (y a menudo pueden), tienes un problema de Regla de Privacidad.

Lista de Verificación de la Regla de Seguridad: Salvaguardas Administrativas

Las salvaguardas administrativas son las políticas y procedimientos que rigen tu programa de seguridad. A menudo son la parte menos emocionante del cumplimiento, pero son lo que OCR ve primero durante una investigación.

  • Realiza un análisis de riesgo — No un ejercicio único. La regla de 2026 espera evaluación de riesgos continua. Asigna cada sistema que toca ePHI, identifica amenazas, evalúa vulnerabilidades y documenta tu nivel de riesgo.
  • Implementa un plan de gestión de riesgos — Para cada riesgo identificado, documenta cómo lo estás mitigando. Los riesgos aceptados deben estar formalmente documentados con justificación.
  • Asigna un Oficial de Seguridad — Alguien es dueño del programa de seguridad. Documenta quién.
  • Implementa controles de acceso de la fuerza laboral — Políticas de acceso basadas en roles. Quién puede acceder a qué ePHI y por qué.
  • Realiza entrenamiento de conciencia de seguridad — Mínimo anual, pero trimestral es mejor. Documenta la asistencia.
  • Implementa política de sanciones — ¿Qué sucede cuando alguien viola la política? Documéntalo.
  • Revisa la actividad del sistema de información — Revisión regular de registros de auditoría. No solo recopilarlos — realmente revisarlos.
  • Desarrolla un plan de contingencia — Respaldo de datos, recuperación ante desastres, operaciones de emergencia. Pruébalo al menos anualmente.
  • Evalúa BAAs — Revisa todos los acuerdos de asociado comercial. Cada vendedor que toca ePHI necesita uno.

Lista de Verificación de la Regla de Seguridad: Salvaguardas Físicas

Para equipos SaaS ejecutándose en infraestructura de nube, las salvaguardas físicas principalmente se trasladan a tu proveedor de nube — pero aún tienes obligaciones.

  • Controles de acceso a instalaciones — Si tienes oficinas donde ePHI es accesible, controla el acceso físico. Lectores de insignias, registros de visitantes, salas de servidores cerradas.
  • Seguridad de estación de trabajo — Las computadoras portátiles utilizadas por desarrolladores que acceden a ePHI de producción deben tener cifrado de disco completo, políticas de bloqueo de pantalla y capacidad de borrado remoto.
  • Controles de dispositivo y medios — Políticas de disposición de hardware que almacenó ePHI. Documenta métodos de destrucción.
  • Validación del proveedor de nube — Verifica las certificaciones de seguridad física de tu proveedor de nube. AWS, GCP y Azure todos publican reportes SOC 2 cubriendo controles físicos — solicita y revísalos.

Lista de Verificación de la Regla de Seguridad: Salvaguardas Técnicas

Aquí es donde los equipos de ingeniería pasan la mayoría de su esfuerzo. Cada salvaguarda se asigna a un control testeable.

Controles de Acceso (164.312(a))

  • Identificación única del usuario — Cada usuario obtiene una ID única. Sin cuentas compartidas. Nunca.
  • Procedimiento de acceso de emergencia — Proceso documentado para acceder a ePHI durante emergencias.
  • Cierre de sesión automático — Tiempos de espera de sesión en todos los sistemas que acceden a ePHI. 15 minutos es un valor predeterminado razonable.
  • Cifrado y descifrado — ePHI debe estar cifrado en reposo. AES-256 es el estándar.
# Ejemplo: Verificar cifrado en reposo en AWS RDS
import boto3

def check_rds_encryption():
    rds = boto3.client('rds')
    instances = rds.describe_db_instances()
    for db in instances['DBInstances']:
        if not db['StorageEncrypted']:
            print(f"ADVERTENCIA: {db['DBInstanceIdentifier']} NO está cifrado")
            # Esto ahora es una violación de cumplimiento bajo las reglas de 2026
        else:
            print(f"OK: {db['DBInstanceIdentifier']} cifrado con {db['KmsKeyId']}")

Controles de Auditoría (164.312(b))

  • Registra todo acceso a ePHI — Cada lectura, escritura, actualización y eliminación.
  • Haz inmutables los registros — Usa almacenamiento de solo anexión. CloudWatch Logs con políticas de retención, o envía a un SIEM inmutable.
  • Retén registros según la política — Seis años es el valor predeterminado seguro para coincidir con el requisito de retención general de HIPAA.
  • Automatiza la revisión de registros — Configura alertas para patrones de acceso anómalos. Un desarrollador consultando 10,000 registros de pacientes a las 3 AM debe desencadenar una alerta.
// Ejemplo: Middleware Express para registro de acceso a ePHI
const logPhiAccess = (req, res, next) => {
  const logEntry = {
    timestamp: new Date().toISOString(),
    userId: req.user?.id,
    action: req.method,
    resource: req.originalUrl,
    sourceIp: req.ip,
    userAgent: req.get('User-Agent'),
    // No registres el PHI real en el registro de auditoría
    resourceType: 'ePHI',
  };
  
  // Envía a almacén de registro inmutable
  auditLogger.write(logEntry);
  next();
};

app.use('/api/patients/*', logPhiAccess);

Controles de Integridad (164.312(c))

  • Implementa mecanismos para verificar que ePHI no ha sido alterado — Sumas de verificación, firmas digitales o controles de integridad a nivel de base de datos.
  • Protege contra modificación no autorizada — El acceso de escritura debe estar estrictamente limitado.

Autenticación (164.312(d))

  • Verifica la identidad de cualquiera que acceda a ePHI — Autenticación fuerte requerida.
  • Implementa MFA — Ahora obligatorio bajo la regla de 2026. TOTP, claves de hardware o MFA basada en notificación. MFA basada en SMS es técnicamente compatible pero no se recomienda debido a riesgos de intercambio de SIM.

Seguridad de Transmisión (164.312(e))

  • Cifra ePHI en tránsito — Mínimo TLS 1.2. TLS 1.3 preferido.
  • Aplica HTTPS en todas partes — Sin contenido mixto. Se requieren encabezados HSTS.
  • Asegura comunicaciones de API — Todas las llamadas de API que transmiten ePHI deben usar canales cifrados. TLS mutuo para comunicación de servicio a servicio es un patrón fuerte.
# Configuración Nginx aplicando TLS 1.2+ y HSTS
server {
    listen 443 ssl http2;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5:!RC4;
    ssl_prefer_server_ciphers on;
    
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Content-Type-Options nosniff always;
    add_header X-Frame-Options DENY always;
}

Lista de Verificación de la Regla de Notificación de Brechas

Una brecha es cualquier uso o divulgación no permitida que comprometa la seguridad o privacidad de PHI. Aquí está lo que necesitas en su lugar antes de que ocurra una — porque si lo estás construyendo durante un incidente, ya estás atrasado.

  • Define tu plan de respuesta a incidentes — ¿Quién hace qué cuando se descubre una brecha? Documenta roles, rutas de escalada y plantillas de comunicación.
  • Establece una ventana de notificación de 60 días — Los individuos afectados deben ser notificados dentro de 60 días del descubrimiento de la brecha. No 60 días desde que sucedió — 60 días desde que lo supiste.
  • Notifica a HHS — Si 500+ individuos son afectados, notifica a HHS simultáneamente con notificaciones individuales. Para brechas que afectan menos de 500 individuos, puedes reportar anualmente (pero no retrases la investigación).
  • Notifica a los medios — Brechas que afectan a 500+ individuos en un solo estado o jurisdicción requieren notificación de medios.
  • Documenta la evaluación de riesgo — Para cada brecha potencial, realiza una evaluación de riesgo de cuatro factores: naturaleza y extensión de PHI involucrado, persona no autorizada que lo accedió, si PHI fue realmente adquirido o visto, extensión de mitigación de riesgo.
  • Conoce el puerto seguro de cifrado — Si los datos breachados fueron cifrados con cifrado estándar NIST y la clave no fue comprometida, puede que no constituya una brecha que requiera notificación. Este es uno de los argumentos más fuertes para cifrado en todas partes.
  • Realiza ejercicios de mesa — Ejecuta simulaciones de brecha al menos anualmente. Cronometra la respuesta de tu equipo. Identifica brechas.

Problemas Específicos de Sitios Web HIPAA que la Mayoría de Equipos Olvidan

Esta es la sección que desearía que alguien hubiera escrito para mí hace cinco años. Los sitios web tienen puntos de exposición HIPAA que los ingenieros de backend no siempre consideran.

Rastreo de Terceros y Análisis

En diciembre de 2022, HHS emitió orientación aclarando que las tecnologías de rastreo en sitios web de cuidado de salud pueden crear violaciones de HIPAA. Esto no ha cambiado — se ha vuelto más estricto. Si tu sitio web de cuidado de salud usa Google Analytics, Meta Pixel o herramientas similares, y esas herramientas pueden capturar PHI (incluyendo direcciones IP combinadas con visitas a páginas relacionadas con la salud), puedes estar transmitiendo PHI a terceros sin un BAA.

Qué hacer:

  • Audita cada script de terceros ejecutándose en tu sitio
  • Elimina píxeles de rastreo de páginas que recopilen o muestren información de salud
  • Usa análisis del lado del servidor donde sea posible
  • Si debes usar análisis del lado del cliente, asegúrate de que estén configurados para excluir PHI
  • Considera alternativas enfocadas en privacidad como Plausible o Fathom que no recopilan PII

JavaScript del Lado del Cliente y Riesgo de la Cadena de Suministro

Cada paquete npm, cada script alojado en CDN, cada widget de chat es un vector potencial para exposición de ePHI. Un script de terceros comprometido puede exfiltrar datos de formularios — incluyendo PHI — al servidor de un atacante.

  • Implementa encabezados de Política de Seguridad de Contenido (CSP)
  • Usa Integridad de Subrecurso (SRI) para activos alojados en CDN
  • Audita tus dependencias del lado del cliente regularmente
  • Monitorea tu Lista de Materiales de Software (SBOM)

Manejo de Formularios

Formularios de contacto, formularios de solicitud de citas, verificadores de síntomas — si recopilan información de salud, están manejando PHI.

  • Cifra envíos de formularios en tránsito (HTTPS)
  • No almacenes datos de formularios en texto plano
  • No envíes por correo electrónico contenidos de formularios sin cifrar
  • Implementa CAPTCHA para prevenir extracción automatizada de PHI
  • Establece políticas de retención de datos apropiadas — no guardes envíos de formularios para siempre

Si estás trabajando con una arquitectura de CMS headless, asegúrate de que tu canalización de manejo de formularios sea compatible con HIPAA de extremo a extremo. En Social Animal, construimos soluciones de CMS headless con estos requisitos de seguridad integrados desde el inicio, no añadidos después.

Comparación de Cumplimiento HIPAA: Proveedores de Nube

Tu elección de infraestructura importa. Aquí está cómo los principales proveedores de nube se alinean para cargas de trabajo HIPAA en 2026:

Característica AWS Google Cloud Azure Vercel Netlify
Ofrece BAA Sí Sí Sí Sí (Empresa) No
Servicios elegibles HIPAA documentados 150+ 100+ 130+ Limitado N/A
Cifrado predeterminado en reposo Sí (mayoría de servicios) Sí Sí Parcial N/A
Certificado CSF HITRUST Sí Sí Sí No No
Documentación de cumplimiento dedicada Extensa Extensa Extensa Mínima N/A
FedRAMP autorizado Sí (GovCloud) Sí Sí (Gov) No No

Una nota crítica en plataformas de alojamiento estático: Si estás desplegando un sitio Next.js o Astro que maneja ePHI, ten mucho cuidado con tu elección de alojamiento. Vercel firmará un BAA en planes empresariales, pero necesitas verificar qué servicios específicos están cubiertos. Netlify actualmente no ofrece un BAA, lo que la hace inadecuada para cargas de trabajo HIPAA.

Para equipos construyendo con frameworks como Next.js o Astro, las decisiones arquitectónicas que haces temprano — dónde se procesan los datos, qué APIs manejan PHI, cómo la representación del lado del servidor interactúa con el estado del lado del cliente — todas tienen implicaciones HIPAA.

Documentación y Preparación para Auditoría

HIPAA requiere que retengas documentación por seis años. Eso incluye políticas, procedimientos, evaluaciones de riesgo, registros de entrenamiento, BAAs e informes de incidentes. Aquí está cómo mantenerse listo para auditoría sin perder la cabeza:

  • Automatiza recopilación de evidencia — Usa herramientas como Vanta, Drata o Secureframe para recopilar continuamente evidencia de cumplimiento. Las hojas de cálculo manuales no escalan.
  • Controla versiones tus políticas — Almacena documentos de cumplimiento en Git. Cada cambio es rastreado con autor, marca de tiempo y contexto.
  • Automatiza escaneo de seguridad — Ejecuta escáneres de infraestructura como código (Checkov, tfsec) en tu canalización CI/CD para detectar configuraciones erróneas antes de que lleguen a producción.
  • Programa revisiones de acceso trimestrales — ¿Quién tiene acceso a qué? ¿Aún es apropiado? Documenta la revisión.
  • Mantén un registro de riesgos vivo — Tu evaluación de riesgo no es un PDF que actualizas anualmente. Es un documento vivo que cambia a medida que tu infraestructura evoluciona.
# Ejemplo: Paso de GitHub Actions para escaneo de seguridad HIPAA
- name: Run Checkov security scan
  uses: bridgecrewio/checkov-action@v12
  with:
    directory: ./terraform
    framework: terraform
    check: CKV_AWS_17,CKV_AWS_19,CKV_AWS_145  # Cifrado RDS, cifrado S3, etc.
    soft_fail: false  # Falla la canalización en violaciones

No existe certificación oficial HIPAA emitida por el gobierno. HHS y OCR no emiten certificaciones. Si alguien te dice que es "certificado HIPAA", pregunta qué significa realmente. Marcos de terceros como HITRUST CSF y SOC 2 Type II pueden demostrar madurez de cumplimiento a los clientes, pero no reemplazan la supervisión de OCR o proporcionan puerto seguro.

Niveles de Penalización: Qué Está en Juego

Seamos concretos sobre las consecuencias:

Nivel Nivel de Conocimiento Penalización Por Violación Máximo Anual
Nivel 1 No sabía (y no podría haber) $137 – $68,928 $2,067,813
Nivel 2 Causa razonable, no negligencia deliberada $1,379 – $68,928 $2,067,813
Nivel 3 Negligencia deliberada, corregida dentro de 30 días $13,785 – $68,928 $2,067,813
Nivel 4 Negligencia deliberada, no corregida $68,928 $2,067,813

Montos de penalización ajustados por inflación a partir de 2026. Las penalidades criminales pueden incluir hasta 10 años de encarcelamiento por delitos cometidos con intención de vender PHI.

Estos no son teóricos. OCR ha sido cada vez más activo en cumplimiento. El costo promedio de una brecha de datos de cuidado de salud en 2025 fue de $10.93 millones de acuerdo con el Informe de Costo de una Brecha de Datos de IBM. El cumplimiento es más barato que la alternativa.

Preguntas Frecuentes

¿Mi producto SaaS necesita ser compatible con HIPAA si no almacenamos datos de salud directamente? Si tu software crea, recibe, mantiene o transmite PHI en nombre de una entidad cubierta, eres un asociado comercial y debes cumplir. Incluso pasar a través de ePHI sin almacenarlo desencadena requisitos de cumplimiento. La pregunta clave es si PHI toca tus sistemas en algún momento.

¿Hay una certificación oficial de HIPAA que pueda obtener? No. HHS y OCR no emiten ni avalan ninguna certificación de HIPAA. Marcos de terceros como HITRUST CSF, SOC 2 Type II o ISO 27001 pueden demostrar tu postura de seguridad a clientes y socios, pero no constituyen certificación de HIPAA. Ten cuidado con cualquier vendedor que afirme ser "certificado HIPAA".

¿Cuál es la diferencia entre especificaciones requeridas y direccionables en 2026? La Regla de Seguridad Final de 2026 hizo MFA y cifrado explícitamente requeridos, eliminando su estado anterior "direccionable". Para especificaciones direccionables restantes, debes implementar la especificación, implementar una alternativa equivalente y documentar por qué, o documentar por qué no es razonable y apropiada. "Direccionable" nunca ha significado "opcional" — la actualización de 2026 solo lo hizo innegable para los dos controles que más importan.

¿Necesito un BAA con mi proveedor de alojamiento en nube? Sí. Si tu proveedor de nube procesa, almacena o transmite ePHI en tu nombre, necesitas un BAA. AWS, Google Cloud y Azure todos ofrecen BAAs. Asegúrate de que solo estés usando servicios que estén explícitamente listados como HIPAA-elegibles por tu proveedor — no todos los servicios dentro de una plataforma de nube están cubiertos.

¿Puedo usar Google Analytics en un sitio web de cuidado de salud? Es arriesgado. La orientación de HHS de 2022 (y reforzada desde entonces) deja claro que las tecnologías de rastreo que pueden combinar direcciones IP con visitas a páginas relacionadas con la salud pueden constituir transmisión de PHI a un tercero sin un BAA. Google no firma un BAA para Google Analytics. Los análisis del lado del servidor o alternativas enfocadas en privacidad son opciones más seguras para sitios web de cuidado de salud.

¿Con qué frecuencia necesito realizar un análisis de riesgos de HIPAA? La regla de 2026 enfatiza evaluación de riesgos continua en lugar de un ejercicio periódico. Como mínimo, realiza un análisis de riesgo formal anualmente y siempre que hay un cambio significativo en tus sistemas, ambiente u operaciones. Muchas organizaciones están transitando a monitoreo de riesgos automatizado y continuo usando plataformas de cumplimiento.

¿Qué cuenta como una brecha bajo HIPAA? Una brecha es cualquier uso o divulgación no permitida de PHI que comprometa su seguridad o privacidad. Sin embargo, hay tres excepciones: adquisición no intencional por un miembro de la fuerza laboral actuando de buena fe, divulgación inadvertida entre personas autorizadas dentro de la organización, y situaciones donde tienes buena fe que el recipiente no autorizado no podría retener la información. Los datos cifrados que se pierden pueden calificar para puerto seguro si el cifrado cumple con estándares NIST y la clave no fue comprometida.

¿Qué debo hacer en las primeras 24 horas después de descubrir una brecha potencial? Activa tu plan de respuesta a incidentes. Contiene la brecha — aísla los sistemas afectados si es necesario. Comienza a documentar todo: qué sucedió, cuándo fue descubierto, quién estuvo involucrado, qué datos fueron afectados. Comienza la evaluación de riesgo de cuatro factores. Notifica a tu asesor legal y a tus Oficiales de Privacidad y Seguridad HIPAA. No esperes investigar completamente antes de tomar acciones de contención. El reloj de notificación de 60 días comienza en el descubrimiento, así que cada hora cuenta.

Si estás construyendo software de cuidado de salud y necesitas ayuda para hacer la arquitectura correcta desde el principio, trabajamos con equipos de ingeniería para diseñar aplicaciones web compatibles con HIPAA. Revisa nuestras capacidades de desarrollo o comunícate para discutir tu proyecto.