Un acortador de URL parece una superficie pequeña en una revisión de compras. Dos párrafos en el cuestionario de seguridad del proveedor, una atestación rápida, una casilla de verificación. Luego, el equipo de seguridad abre el diagrama de arquitectura y descubre que el acortador se encuentra en la ruta de solicitud de cada URL de campaña, cada enlace de correo electrónico transaccional y cada redirección de código QR. La revisión de dos párrafos se convierte en tres semanas de seguimiento.
Este post responde a las preguntas que los equipos de compras corporativas realmente hacen sobre SOC 2 Type II e HIPAA cuando evalúan a un proveedor de rastreo de enlaces. Está escrito para la persona que completa el cuestionario y para la persona que revisa la respuesta.
La versión corta#
Elido cuenta con la certificación ISO 27001. El SOC 2 Type II está en progreso con una fecha objetivo de finalización en la segunda mitad de 2026: la ventana de auditoría comenzó en febrero de 2026, la recopilación de pruebas se extiende hasta julio y se espera el informe Type II para finales del cuarto trimestre. HIPAA es compatible con los planes Business y Enterprise con un Business Associate Agreement firmado; los controles subyacentes son los mismos que se utilizan para SOC 2.
La postura de cumplimiento de GDPR es independiente de SOC 2 e HIPAA y se trata en la guía fundamental de GDPR para acortadores de URL. Este post se centra en los marcos de atestación de estilo estadounidense que impulsan las revisiones de compras empresariales.
Lo que SOC 2 dice realmente sobre un acortador de URL#
SOC 2 es un informe, no una certificación. Un auditor independiente (una firma de CPA en los US, o un organismo de auditoría reconocido en la EU) examina a una organización de servicios frente a los Trust Services Criteria de AICPA y emite una opinión. El Type I documenta que los controles están diseñados adecuadamente en un momento dado; el Type II documenta que operaron de manera efectiva durante un período, generalmente de seis a doce meses.
Los Trust Services Criteria se dividen en cinco categorías. Cada informe SOC 2 cubre Security (Seguridad); los otros cuatro (Availability, Processing Integrity, Confidentiality, Privacy) se incluyen a elección de la organización de servicios según las necesidades de su base de clientes.
Security — la categoría siempre incluida#
Los criterios de Security cubren el control de acceso, la gestión de cambios, el monitoreo, la respuesta a incidentes y la evaluación de riesgos. Para un acortador de URL, los controles que más importan son:
- CC6.1 Logical access: quién puede crear, modificar o eliminar un enlace corto, y cómo se otorga y revoca ese acceso. La auditoría rastreará a usuarios específicos desde el registro de incorporación de RR. HH. a través del IdP (Ory Kratos para Elido) hasta la asignación de roles en el espacio de trabajo, y verificará que su acceso fue eliminado dentro de la ventana de la política después de la desvinculación.
- CC6.6 External access: cómo se autentican los usuarios externos (propietarios de dominios personalizados, consumidores de API, integraciones de socios) y qué alcances reciben. El modelo de token de API con claves de idempotencia y alcance por espacio de trabajo es el artefacto que el auditor querrá ver.
- CC7.2 Monitoring: qué se registra, a dónde van los registros y cómo surgen las anomalías. Para un servicio de redirección, las señales relevantes son un volumen inusual de redirecciones por espacio de trabajo, disparadores de límite de tasa en el edge y fallos de autenticación.
- CC8.1 Change management: cambios de código desde la pull request hasta el despliegue, con separación de funciones entre el ingeniero que escribió el cambio y el revisor que lo aprobó. La auditoría tomará muestras de pull requests y revisará el registro de aprobación y despliegue.
Los criterios de Security son también donde SOC 2 espera un plan de respuesta a incidentes documentado. Para un servicio de redirección, los incidentes relevantes son la creación de enlaces no autorizada, la manipulación del destino de la redirección y la exfiltración de datos a través de los puntos finales de exportación de analíticas. El manual en /docs/runbooks/ cubre el procedimiento para cada uno.
Availability — la segunda categoría más común#
Availability cubre los compromisos de tiempo de actividad, la planificación de capacidad y la recuperación ante desastres. Para un acortador de URL, los artefactos relevantes son:
- Un objetivo de nivel de servicio documentado. El SLO publicado de Elido es del 99.95% de disponibilidad de redirección por trimestre, con SLO independientes para el dashboard (99.9%) y la API de analíticas (99.5%).
- Evidencia de pruebas de capacidad. El servicio de redirección en el edge ejecuta pruebas de carga continuas en staging; la auditoría busca evidencia de que el envoltorio de capacidad de producción es conocido y monitoreado frente al SLO.
- Evidencia de respaldo y restauración. Postgres ejecuta Patroni HA con recuperación en un punto del tiempo; ClickHouse se exporta diariamente a almacenamiento de objetos; la auditoría requiere el registro del simulacro de restauración que demuestre que el objetivo de tiempo de restauración es alcanzable.
- Documentación de failover multiregión. Los tres POP (Frankfurt, Ashburn, Singapore) están en modo activo-activo para las redirecciones; el auditor leerá el manual de failover y el post-mortem del evento regional más reciente.
Confidentiality y Privacy — incluidos selectivamente#
Confidentiality y Privacy añaden categorías que se solapan con la postura de GDPR. La mayoría de los clientes empresariales en la EU prefieren abordar la privacidad a través de la documentación de GDPR (acuerdos de encargado del tratamiento del Artículo 28, evaluaciones de impacto de transferencia, el DPA público) en lugar de a través de SOC 2 Privacy. El alcance actual de la auditoría SOC 2 de Elido incluye Security, Availability y Confidentiality. Privacy se aborda por separado a través de la suite de documentación de GDPR en /trust.
La razón de la división: SOC 2 Privacy se mapea con los Generally Accepted Privacy Principles de AICPA, que fueron diseñados para los marcos de privacidad de estilo estadounidense. GDPR es un marco legal independiente con sus propios controles. Combinar ambos en una sola atestación tiende a debilitar a ambos.
Lo que HIPAA dice realmente sobre un acortador de URL#
HIPAA — la Health Insurance Portability and Accountability Act, actualizada por HITECH y la Omnibus Rule de 2013 — regula cómo se maneja la Protected Health Information (PHI) por parte de las entidades cubiertas (proveedores de salud, pagadores, cámaras de compensación) y sus Business Associates.
Un acortador de URL se convierte en un Business Associate cuando el enlace corto o los datos detrás de él contienen PHI. La pregunta interesante es si alguna vez lo hace, y la respuesta es más matizada de lo que suponen la mayoría de las revisiones de compras.
Cuando la PHI fluye a través de una redirección#
Un enlace corto en sí mismo — s.elido.me/abc123 — no es PHI. La URL de destino, los metadatos del espacio de trabajo y las etiquetas de campaña tampoco son PHI en el caso general.
La cuestión de la PHI reside en tres lugares específicos:
- URLs de destino que contienen identificadores: un enlace corto que redirige a
https://provider.example/patient/12345/resultscontiene un identificador de paciente en la ruta de la URL. Esa URL de destino es almacenada por el acortador y, por lo tanto, es PHI en sentido estricto, aunque el enlace funcione perfectamente sin que nadie en el acortador interprete el identificador del paciente. - Parámetros personalizados añadidos al momento del clic: si una redirección añade un identificador de sesión o un identificador de usuario como parámetro de URL y ese identificador es vinculable posteriormente a PHI, el evento de clic se convierte en parte de la cadena de PHI.
- Eventos de clic con datos de referente: un evento de clic incluye la URL de referente (referrer). Si un referente incluye casualmente un identificador de paciente (una página de portal de pacientes con enlace profundo que remitió al usuario al enlace acortado), el campo del referente es PHI.
La mayoría de los casos de uso de marketing de salud no generan PHI a través de ninguno de estos canales. Un departamento de marketing de un sistema de salud que realiza campañas para vacunas contra la gripe, eventos de bienestar o contenido de salud general produce redirecciones con destinos libres de PHI y referentes libres de PHI. Para esa carga de trabajo, el BAA es precautorio, no arquitectónicamente necesario.
Para las cargas de trabajo que sí pasan por destinos con PHI — portales de pacientes, enlaces de confirmación de citas, URLs de entrega de resultados de laboratorio — el BAA es obligatorio, y los controles arquitectónicos descritos a continuación deben estar implementados en el acortador.
La HIPAA Security Rule mapeada a un servicio de redirección#
La HIPAA Security Rule (45 CFR Part 164, Subpart C) prescribe salvaguardas administrativas, físicas y técnicas. Para un servicio de redirección que maneja PHI en los destinos:
- Access controls (164.312(a)): identificación de usuario única, cierre de sesión automático, cifrado de ePHI en tránsito y en reposo. Elido impone identificadores de usuario únicos asignados por IdP, tiempo de espera de sesión configurable por espacio de trabajo, TLS 1.3 en todos los puntos finales externos y cifrado de envoltorio AES-256 en reposo para los almacenes de datos relevantes.
- Audit controls (164.312(b)): registro y examen de la actividad en sistemas que contienen o utilizan ePHI. Elido emite registros de auditoría para la creación de enlaces, modificación de enlaces, cambios de destino y exportación de analíticas a un almacén de solo adición a prueba de manipulaciones. La retención de los registros de auditoría es de 24 meses por defecto en los planes Business+.
- Integrity controls (164.312(c)): protección de la ePHI contra alteraciones indebidas. Las URLs de destino se almacenan con historial a nivel de fila; cualquier modificación se registra con la identidad del actor y la marca de tiempo, y el valor anterior permanece en la tabla de historial.
- Transmission security (164.312(e)): protección de la ePHI en tránsito sobre redes abiertas. TLS 1.3 en todos los puntos finales de redirección; precarga de HSTS; fijación de certificados (certificate pinning) disponible en dominios personalizados.
Las salvaguardas administrativas y físicas (capacitación de la fuerza laboral, políticas de sanción, controles de acceso a las instalaciones) se solapan fuertemente con los controles de Security de SOC 2. La misma evidencia respalda ambas auditorías, razón por la cual las ejecutamos en un cronograma de evidencia compartido.
Qué cubre y qué no cubre el BAA#
Un Business Associate Agreement es un contrato bajo HIPAA 164.504(e). Compromete al Business Associate a salvaguardas específicas, plazos de notificación de brechas y obligaciones de transferencia a subcontratistas. No cambia la arquitectura subyacente; compromete al proveedor a operar la arquitectura de una manera que cumpla con HIPAA.
El BAA estándar de Elido, disponible en los planes Business y Enterprise, cubre:
- Las cuatro categorías de salvaguardas de la HIPAA Security Rule aplicadas a todos los datos que el cliente encamine a través del servicio de redirección.
- Notificación de brechas dentro de los 60 días posteriores al descubrimiento, con plazos detallados de respuesta a incidentes cubiertos en el BAA y el manual correspondiente en
/docs/runbooks/incident-response. - Transferencia a subcontratistas a los sub-procesadores nombrados (Hetzner, OVH, Postmark, Cloudflare, monobank Plata) bajo sus propios BAA cuando corresponda. La lista actual de sub-procesadores está en
/legal/subprocessorsy es la misma lista utilizada para la documentación del Artículo 28 de GDPR. - Devolución o destrucción de PHI al finalizar el contrato, con una ventana de 30 días para que el cliente exporte los datos antes de la eliminación.
Lo que el BAA no hace: no hace que un nivel de plan no elegible para HIPAA se vuelva elegible. Los planes Free y Pro no incluyen la ejecución del BAA. La infraestructura es la misma en todos los niveles de pago; los compromisos legales no lo son.
El cuestionario de compras — respuestas que puede pegar#
La mayoría de los cuestionarios de compras corporativas hacen el mismo conjunto de preguntas. Las respuestas a continuación son las que proporcionamos directamente, con enlaces a los artefactos.
¿Tienen un informe SOC 2 Type II actual? Contamos con la certificación ISO 27001; la auditoría SOC 2 Type II está en curso, con el informe Type II previsto para el Q4 2026. Las cartas puente (bridge letters) y el certificado ISO 27001 actual están disponibles bajo NDA a través de /trust. SOC 2 Type I se completó en noviembre de 2025; el informe Type I también está disponible bajo NDA.
¿Firmarán nuestro BAA? Firmamos nuestro BAA estándar en los planes Business y Enterprise. Los BAA con el formato del cliente se revisan en los planes Enterprise; se aceptan modificaciones comunes (ventanas ampliadas de notificación de brechas, atestaciones de salvaguardas adicionales, controles de subcontratistas especificados por el cliente). Contacte a [email protected] para obtener el texto estándar o para iniciar una revisión del documento del cliente.
¿Dónde se almacenan los datos? Los clientes de la EU usan por defecto Frankfurt (Hetzner FRA1, región EU). Los clientes de US pueden elegir Ashburn (Hetzner ASH). Singapore (OVH SGP) está disponible para clientes de APAC. La replicación entre regiones es opcional por espacio de trabajo; sin ella, todos los datos del cliente permanecen en la región elegida. El post sobre residencia de datos cubre la arquitectura de residencia en detalle.
¿Qué cifrado se utiliza? TLS 1.3 en tránsito en todos los puntos finales externos (redirección, API, dashboard, analíticas). Cifrado de envoltorio AES-256 en reposo para el primario de Postgres, el clúster de ClickHouse y el almacenamiento de objetos. El KMS proporcionado por el cliente es compatible con los planes Enterprise a través de la integración BYO KMS.
¿Cómo se provisiona y desprovisiona el acceso? Inicio de sesión único a través de SAML o OIDC mediante WorkOS; aprovisionamiento SCIM para el ciclo de vida del usuario. Control de acceso basado en roles a nivel de espacio de trabajo con roles personalizados disponibles en Enterprise. El post sobre SCIM y SSO cubre la integración y los controles de ciclo de vida.
¿Cuál es su proceso de respuesta a incidentes? Manual documentado con un SLA de respuesta inicial de 60 minutos, un SLA de actualización técnica de 24 horas y rotaciones de comandantes de incidentes designados. Las notificaciones de brechas siguen los plazos en nuestro BAA y nuestro DPA. El índice completo de manuales está en /docs/runbooks/.
¿Quiénes son sus sub-procesadores? Cinco sub-procesadores nombrados: Hetzner (infraestructura, EU), OVH (infraestructura, APAC), Postmark (correo electrónico transaccional), Cloudflare (protección DDoS en superficies de marketing públicas; no en el plano de datos de redirección), monobank Plata (facturación para la base de clientes de la EU). La lista completa con detalles de contacto está en /legal/subprocessors.
¿Cuánto tiempo conservan los datos de los clientes? Los eventos de clic se conservan durante la vigencia del contrato más la ventana de exportación de 30 días al finalizar, luego se eliminan. La configuración de los enlaces se conserva durante la vigencia del contrato más la ventana de exportación. Las métricas agregadas (recuentos de enlaces por espacio de trabajo, recuentos de clics por día, sin PII) se conservan más allá del contrato para facturación y planificación de capacidad interna.
El archivo de evidencia que un auditor querrá ver#
Si usted es un cliente corporativo que realiza su propia auditoría SOC 2 y Elido es un proveedor dentro del alcance, es probable que su auditor solicite evidencia bajo sus controles CC9.2 (gestión de proveedores) y CC1.4 (compromisos). El archivo del proveedor debe contener:
- Nuestro certificado ISO 27001 actual (renovable anualmente).
- Nuestro informe SOC 2 Type I y la carta puente de SOC 2 Type II (disponibles bajo NDA).
- Nuestro DPA y BAA firmados cuando corresponda.
- Nuestra lista de sub-procesadores y las fechas de cualquier cambio.
- Una captura de nuestra página pública de seguridad en
/trusty la versión más reciente de la política de privacidad. - Nuestro historial de notificación de brechas (el historial público está vacío; el registro interno se revisa durante la compra bajo NDA).
El archivo de evidencia se construye una vez por compromiso con el cliente y se actualiza anualmente. La lista anterior es el conjunto estándar; las adiciones específicas de los auditores se manejan caso por caso.
Lo que es genuinamente difícil#
Dos cosas son genuinamente difíciles sobre SOC 2 e HIPAA para un servicio de redirección, y las mencionamos porque la conversación de compras suele sacarlas a la luz eventualmente.
La evidencia de monitoreo continuo para los POP del edge no es trivial. El plano de datos de redirección procesa altos volúmenes de tráfico en tres regiones, y el auditor quiere evidencia de que el monitoreo está operando continuamente, no solo mediante muestreo. El enfoque actual utiliza redirecciones sintéticas de cada región cada minuto, con el estado de alerta capturado en un registro a prueba de manipulaciones. El costo de este monitoreo es real y el diseño ha pasado por tres iteraciones para lograr la relación señal-ruido adecuada. La guía de observabilidad en los docs cubre la configuración actual; el ADR subyacente está en /docs/adr/0024-sla-monitoring.md.
Los plazos de notificación de brechas de HIPAA son más estrictos que los de GDPR. HIPAA requiere la notificación a las personas afectadas dentro de los 60 días posteriores al descubrimiento; para brechas que afectan a más de 500 personas, se requieren notificaciones adicionales al HHS y a los medios de comunicación. GDPR permite 72 horas a la autoridad de control, pero el plazo de notificación a las personas afectadas es "sin dilación indebida". Para una brecha multijurisdiccional, el plazo de HIPAA suele dominar. Nos comprometemos con el plazo de HIPAA por defecto para cualquier incidente que afecte a datos de clientes encaminados por US, y nuestro manual de respuesta a incidentes lo refleja.
Lecturas relacionadas#
- GDPR para acortadores de URL: lo que su DPO realmente quiere ver — la guía fundamental para el clúster de cumplimiento.
- Residencia de datos en la EU para analíticas de marketing — la arquitectura de residencia y las opciones de fijación.
- Schrems II y sus píxeles de seguimiento — contexto de la evaluación de impacto de transferencia.
- SCIM y SSO para herramientas de marketing — los controles de acceso que satisfacen el CC6.1.
- Atribución de clics tras Safari ITP — post adyacente sobre las restricciones de privacidad del lado del navegador.
- Recorrido operativo: la guía de evidencia SOC 2 en los docs — cómo funciona la recopilación de evidencia en la práctica.
- Superficie del producto:
/solutions/compliancey/solutions/enterprisepara la elegibilidad del nivel del plan y el mapeo de características.